Konsep titik pemeriksaan dan pemutaran ulang dalam pekerjaan Azure Stream Analytics
Artikel ini menjelaskan konsep titik pemeriksaan dan pemutaran ulang di Azure Stream Analytics, dan dampaknya terhadap pemulihan pekerjaan. Setiap kali pekerjaan Analisis Aliran berjalan, informasi status dipertahankan secara internal. Informasi status tersebut disimpan di titik pemeriksaan secara berkala. Dalam beberapa skenario, informasi titik pemeriksaan digunakan untuk pemulihan pekerjaan jika kegagalan pekerjaan atau peningkatan terjadi. Dalam keadaan lain, titik pemeriksaan tidak dapat digunakan untuk pemulihan, dan pemutaran ulang diperlukan.
Logika kueri berstatus dalam elemen temporal
Salah satu kemampuan unik pekerjaan Azure Stream Analytics adalah melakukan pemrosesan yang nyata, seperti agregat berjendela, gabungan temporal, dan fungsi analitik temporal. Masing-masing operator ini menyimpan informasi status saat pekerjaan berjalan. Ukuran jendela maksimum untuk elemen kueri ini adalah tujuh hari.
Konsep jendela temporal muncul di beberapa elemen kueri Analisis Aliran:
Agregat berjendela (GROUP BY jendela Tumbling, Hopping, dan Sliding)
Gabungan temporal (JOIN dengan DATEDIFF)
Fungsi analitik temporal (ISFIRST, LAST, dan LAG dengan LIMIT DURATION)
Pemulihan pekerjaan dari kegagalan simpul, termasuk peningkatan OS
Setiap kali pekerjaan Analisis Aliran berjalan, secara internal diperluas skalanya untuk melakukan pekerjaan di beberapa simpul pekerja. Setiap status simpul pekerja di titik pemeriksaan setiap beberapa menit, yang membantu sistem pulih jika terjadi kegagalan.
Kadang-kadang, simpul pekerja tertentu mungkin gagal, atau peningkatan Sistem Operasi dapat terjadi untuk simpul pekerja itu. Untuk pulih secara otomatis, Analisis Aliran memperoleh simpul sehat baru, dan status simpul pekerja sebelumnya dipulihkan dari titik pemeriksaan terbaru yang tersedia. Untuk melanjutkan pekerjaan, sejumlah kecil pemutaran ulang diperlukan untuk memulihkan keadaan dari waktu ketika titik pemeriksaan diambil. Biasanya, kesenjangan pemulihan hanya beberapa menit. Ketika Unit Streaming yang cukup dipilih untuk pekerjaan, pemutaran ulang harus diselesaikan dengan cepat.
Dalam kueri yang sepenuhnya paralel, waktu yang diperlukan untuk mengejar ketinggalan setelah kegagalan simpul pekerja sebanding dengan:
[laju peristiwa input] x [panjang kesenjangan] / [jumlah partisi pemrosesan]
Jika Anda pernah mengamati penundaan pemrosesan yang signifikan karena kegagalan simpul dan peningkatan OS, sebaiknya buat kueri sepenuhnya paralel, dan skalakan pekerjaan untuk mengalokasikan lebih banyak Unit Streaming. Untuk informasi selengkapnya, lihat Menskalakan pekerjaan Azure Stream Analytics untuk meningkatkan throughput.
Analisis Aliran saat ini tidak menampilkan laporan saat proses pemulihan semacam ini berlangsung.
Pemulihan pekerjaan dari peningkatan layanan
Microsoft sesekali meningkatkan biner yang menjalankan pekerjaan Stream Analytics di layanan Azure. Pada saat ini, pekerjaan pengguna yang sedang berjalan ditingkatkan ke versi yang lebih baru dan pekerjaan dimulai ulang secara otomatis.
Azure Stream Analytics menggunakan titik pemeriksaan jika memungkinkan untuk memulihkan data dari status titik pemeriksaan terakhir. Dalam skenario di mana titik pemeriksaan internal tidak dapat digunakan, status kueri streaming dipulihkan sepenuhnya menggunakan teknik pemutaran ulang. Untuk memungkinkan pekerjaan Analisis Aliran memutar ulang input yang sama persis dari sebelumnya, penting untuk mengatur kebijakan penyimpanan data sumber ke setidaknya ukuran jendela dalam kueri Anda. Gagal melakukannya dapat mengakibatkan hasil yang salah atau sebagian selama peningkatan layanan, karena data sumber mungkin tidak dipertahankan cukup jauh untuk menyertakan ukuran jendela penuh.
Secara umum, jumlah pemutaran ulang yang diperlukan sebanding dengan ukuran jendela dikalikan dengan tingkat peristiwa rata-rata. Sebagai contoh, untuk pekerjaan dengan tingkat input 1.000 peristiwa per detik, ukuran jendela yang lebih besar dari satu jam dianggap memiliki ukuran pemutaran ulang yang besar. Hingga satu jam data mungkin perlu diproses ulang untuk menginisialisasi keadaan sehingga dapat menghasilkan hasil yang penuh dan benar, yang dapat menyebabkan output tertunda (tidak ada output) untuk beberapa periode yang diperpanjang. Kueri tanpa jendela atau operator temporal lainnya, seperti JOIN atau LAG tidak akan memiliki pemutaran ulang.
Memperkirakan waktu catch-up pemutaran ulang
Untuk memperkirakan lamanya penundaan karena peningkatan layanan, Anda dapat mengikuti teknik ini:
Muat Azure Event Hubs input dengan data yang cukup untuk menutupi ukuran jendela terbesar dalam kueri Anda, pada tingkat peristiwa yang diharapkan. Tanda waktu peristiwa harus dekat dengan waktu jam dinding sepanjang periode waktu itu, seolah-olah itu adalah umpan masukan langsung. Misalnya, jika Anda memiliki jendela 3 hari dalam kueri Anda, kirim acara ke Azure Event Hubs selama tiga hari, dan lanjutkan mengirim acara.
Mulai pekerjaan menggunakan Sekarang sebagai waktu mulai.
Ukur waktu antara waktu mulai dan kapan output pertama dihasilkan. Waktunya kasar berapa banyak keterlambatan pekerjaan yang akan terjadi selama peningkatan layanan.
Jika penundaan terlalu lama, cobalah untuk mempartisi pekerjaan dan meningkatkan jumlah SU, sehingga beban disebarkan ke lebih banyak simpul. Atau, sebaiknya kurangi ukuran jendela dalam kueri, dan lakukan agregasi lebih lanjut atau pemrosesan berstatus lainnya pada output yang dihasilkan oleh pekerjaan Stream Analytics di sink hilir (misalnya, menggunakan Azure SQL Database).
Untuk masalah kestabilan layanan umum selama peningkatan pekerjaan penting misi, sebaiknya jalankan pekerjaan duplikat di wilayah Azure yang dipasangkan. Untuk informasi selengkapnya, lihat Menjamin keandalan pekerjaan Analisis Aliran selama pembaruan layanan.
Pemulihan pekerjaan dari pengguna memulai berhenti dan mulai
Untuk mengedit sintaks Kueri pada pekerjaan streaming, atau untuk menyesuaikan input dan output, pekerjaan perlu dihentikan untuk membuat perubahan dan meningkatkan desain pekerjaan. Dalam skenario seperti itu, ketika pengguna menghentikan pekerjaan streaming, dan memulainya lagi, skenario pemulihan mirip dengan peningkatan layanan.
Data titik pemeriksaan tidak dapat digunakan untuk memulai ulang pekerjaan yang dimulai pengguna. Untuk memperkirakan keterlambatan output selama mulai ulang seperti itu, gunakan prosedur yang sama seperti yang dijelaskan di bagian sebelumnya, dan terapkan mitigasi serupa jika penundaan terlalu lama.
Langkah berikutnya
Untuk informasi selengkapnya tentang keandalan dan skalabilitas, lihat artikel ini: