Memahami penanganan waktu di Azure Stream Analytics
Dalam artikel ini, Anda akan mempelajari cara membuat pilihan desain untuk menyelesaikan masalah penanganan waktu praktis dalam tugas Azure Stream Analytics. Keputusan desain penanganan waktu berkaitan erat dengan faktor pemesanan pengurutan peristiwa.
Konsep waktu latar belakang
Untuk membingkai diskusi dengan lebih baik, mari kita definisikan beberapa konsep latar belakang:
Waktu peristiwa: Waktu saat peristiwa awal terjadi. Misalnya, saat mobil yang bergerak di jalan raya mendekati pintu tol.
Waktu pemrosesan: Waktu saat peristiwa mencapai sistem pemrosesan dan diamati. Misalnya, saat sensor gerbang tol melihat mobil dan sistem komputer membutuhkan beberapa saat untuk memproses data.
Marka air: Penanda waktu peristiwa yang menunjukkan pada titik mana peristiwa dimasukkan ke prosesor streaming. Marka air memungkinkan sistem menunjukkan kemajuan yang jelas saat memasukkan peristiwa. Berdasarkan sifat aliran, data peristiwa yang masuk tidak akan pernah berhenti, sehingga marka air menunjukkan kemajuan ke titik tertentu di aliran.
Konsep marka air penting. Marka air memungkinkan Azure Stream Analytics menentukan kapan sistem dapat menghasilkan hasil yang lengkap, benar, dan dapat diulang yang tidak perlu ditarik kembali. Pemrosesan dapat dilakukan dengan cara yang dapat diprediksi dan dapat diulang. Misalnya, jika penghitungan ulang perlu dilakukan untuk beberapa kondisi penanganan kesalahan, marka air adalah titik awal dan akhir yang aman.
Untuk sumber daya tambahan tentang subjek ini, lihat posting blog Tyler Akidau Streaming 101 dan Streaming 102.
Memilih waktu mulai terbaik
Azure Stream Analytics memberi pengguna dua pilihan untuk memilih waktu peristiwa: waktu kedatangan dan waktu aplikasi.
Waktu kedatangan
Waktu kedatangan ditetapkan di sumber input saat peristiwa mencapai sumber. Anda dapat mengakses waktu kedatangan dengan menggunakan properti EventEnqueuedUtcTime untuk input Azure Event Hubs, properti IoTHub.EnqueuedTime untuk input IoT Hub, dan properti BlobProperties.LastModified untuk input blob.
Waktu kedatangan digunakan secara default dan paling tepat digunakan untuk skenario pengarsipan data saat logika temporal tidak diperlukan.
Waktu aplikasi (juga disebut Waktu Peristiwa)
Waktu aplikasi ditetapkan saat peristiwa dihasilkan, dan ini adalah bagian dari payload peristiwa. Untuk memproses peristiwa berdasarkan waktu aplikasi, gunakan klausul Timestamp by dalam kueri PILIH. Jika Timestamp by tidak ada, peristiwa diproses oleh waktu kedatangan.
Tanda waktu harus digunakan dalam payload ketika logika temporal digunakan untuk memperhitungkan keterlambatan dalam sistem sumber atau dalam jaringan. Waktu yang ditetapkan untuk peristiwa tersedia di SYSTEM.TIMESTAMP.
Perkembangan waktu di Azure Stream Analytics
Saat Anda menggunakan waktu aplikasi, perkembangan waktu didasarkan pada peristiwa masuk. Sistem pemrosesan aliran sulit mengetahui apakah tidak ada peristiwa, atau apakah peristiwa tertunda. Untuk alasan ini, Azure Stream Analytics menghasilkan marka air heuristik dengan cara berikut untuk setiap partisi input:
Jika ada peristiwa masuk, marka air menjadi waktu peristiwa terbesar yang dilihat Azure Stream Analytics sejauh ini dikurangi ukuran periode toleransi tak berurutan.
Jika tidak ada peristiwa masuk, marka air menjadi perkiraan waktu kedatangan saat ini dikurangi periode toleransi kedatangan terlambat. Perkiraan waktu kedatangan adalah waktu yang telah berlalu dari terakhir kali peristiwa input terlihat ditambah waktu kedatangan peristiwa input.
Waktu kedatangan hanya dapat diestimasi karena waktu kedatangan yang nyata dihasilkan pada broker peristiwa input, seperti Event Hubs, atau pada VM Azure Stream Analytics yang memproses peristiwa.
Desainnya melayani dua tujuan tambahan selain menghasilkan marka air:
Sistem menghasilkan hasil secara tepat waktu dengan atau tanpa peristiwa masuk.
Anda memiliki kontrol atas ketepatan waktu yang Anda inginkan untuk melihat hasil output. Di portal Azure, pada halaman Urutan peristiwa tugas Stream Analytics, Anda dapat mengonfigurasi pengaturan peristiwa tak berurutan. Saat Anda mengonfigurasi pengaturan tersebut, pertimbangkan kompensasi ketepatan waktu dengan toleransi peristiwa tak berurutan di aliran peristiwa.
Periode toleransi kedatangan yang terlambat diperlukan untuk tetap menghasilkan marka air, meski tidak ada peristiwa yang masuk. Terkadang, mungkin ada periode di mana tidak ada peristiwa masuk yang masuk, seperti ketika aliran input peristiwanya jarang. Masalah ini diperburuk oleh penggunaan beberapa partisi di broker peristiwa input.
Sistem pemrosesan data streaming tanpa periode toleransi kedatangan yang terlambat mungkin mengalami output tertunda saat inputnya jarang dan beberapa partisi digunakan.
Perilaku sistem perlu diulang. Pengulangan adalah properti penting dari sistem pemrosesan data streaming.
Marka air berasal dari waktu kedatangan dan waktu aplikasi. Keduanya bertahan di broker acara, dan dengan demikian dapat diulang. Jika waktu kedatangan diperkirakan saat tidak ada peristiwa, Azure Stream Analytics melaporkan perkiraan waktu kedatangan untuk pengulangan selama pemutaran ulang untuk pemulihan kegagalan.
Saat memilih untuk menggunakan waktu kedatangan sebagai waktu peristiwa, di sana Anda tidak perlu mengonfigurasi toleransi tak berurutan dan toleransi kedatangan yang terlambat. Karena waktu kedatangan dipastikan meningkat di broker peristiwa input, Azure Stream Analytics mengabaikan konfigurasi.
Peristiwa kedatangan terlambat
Menurut definisi periode toleransi kedatangan terlambat, untuk setiap peristiwa yang masuk, Azure Stream Analytics membandingkan waktu peristiwa dengan waktu kedatangan. Jika waktu peristiwa berada di luar periode toleransi, Anda dapat mengonfigurasi sistem untuk menghilangkan peristiwa atau menyesuaikan waktu peristiwa agar berada dalam toleransi.
Setelah marka air dihasilkan, layanan dapat berpotensi menerima peristiwa dengan waktu peristiwa yang lebih rendah daripada marka air. Anda dapat mengonfigurasi layanan untuk menghilangkan peristiwa tersebut, atau menyesuaikan waktu peristiwa dengan nilai marka air.
Sebagai bagian dari penyesuaian, System.Timestamp peristiwa diatur ke nilai baru, tapi bidang waktu peristiwa itu sendiri tidak berubah. Penyesuaian ini adalah satu-satunya situasi saat System.Timestamp peristiwa bisa berbeda dengan nilai di bidang waktu peristiwa dan dapat menyebabkan hasil yang tidak terduga.
Menangani variasi waktu dengan sub-aliran
Mekanisme pembuatan marka air heuristik yang dijelaskan bekerja dengan baik dalam sebagian besar kasus ketika waktu sebagian besar disinkronkan antara berbagai pengirim peristiwa. Namun, dalam kehidupan nyata, terutama dalam banyak skenario IoT, sistem memiliki sedikit kontrol atas jam pada pengirim peristiwa. Pengirim peristiwa bisa berupa semua jenis perangkat di lapangan, mungkin pada versi perangkat keras dan perangkat lunak yang berbeda.
Alih-alih menggunakan marka air yang bersifat global untuk semua peristiwa dalam partisi input, Azure Stream Analytics memiliki mekanisme lain yang disebut sub-aliran. Anda dapat menggunakan sub-aliran dalam pekerjaan Anda dengan menulis kueri pekerjaan yang menggunakan klausul TIMESTAMP BY dan kata kunci OVER. Untuk menunjuk sub-aliran, masukkan nama kolom kunci setelah kata kunci OVER, seperti deviceid, sehingga sistem menerapkan kebijakan waktu berdasarkan kolom tersebut. Setiap sub-aliran mendapatkan marka air independennya sendiri. Mekanisme ini berguna untuk memungkinkan pembuatan output tepat waktu, saat menghadapi perbedaan waktu yang signifikan atau penundaan jaringan antara pengirim peristiwa.
Sub-aliran adalah solusi unik yang disediakan oleh Azure Stream Analytics, dan tidak ditawarkan oleh sistem pemrosesan data streaming lainnya.
Saat Anda menggunakan sub-aliran, Azure Stream Analytics menerapkan periode toleransi kedatangan terlambat ke peristiwa masuk. Toleransi kedatangan terlambat memutuskan jumlah maksimum di mana sub-stream yang berbeda dapat dipisahkan satu sama lain. Misalnya, jika Perangkat 1 berada di Stempel waktu 1, dan Perangkat 2 berada di Stempel waktu 2, toleransi kedatangan yang paling terlambat adalah Stempel waktu 2 dikurangi Stempel waktu 1. Pengaturan default adalah 5 detik dan kemungkinan terlalu kecil untuk perangkat dengan tanda waktu yang berbeda. Sebaiknya Anda mulai dengan 5 menit dan melakukan penyesuaian sesuai dengan pola kecenderungan jam perangkatnya.
Peristiwa kedatangan dini
Anda mungkin telah memperhatikan konsep lain yang disebut periode kedatangan dini yang terlihat seperti kebalikan dari periode toleransi kedatangan terlambat. Periode ini ditetapkan pada 5 menit dan melayani tujuan yang berbeda dari periode toleransi kedatangan terlambat.
Karena Azure Stream Analytics menjamin hasil yang lengkap, Anda hanya dapat menentukan waktu mulai pekerjaan sebagai waktu output pertama pekerjaan, bukan waktu input. Waktu mulai pekerjaan diperlukan agar periode yang lengkap diproses, bukan hanya dari pertengahan periode.
Azure Stream Analytics memperoleh waktu mulai dari spesifikasi kueri. Namun, karena broker peristiwa input hanya diindeks oleh waktu kedatangan, sistem harus menerjemahkan waktu acara awal ke waktu kedatangan. Sistem dapat mulai memproses peristiwa dari titik tersebut di broker peristiwa input. Dengan batas periode kedatangan dini, penerjemahannya dapat dilakukan dengan mudah: waktu peristiwa awal dikurangi periode kedatangan dini 5 menit. Perhitungan ini juga berarti bahwa sistem menghilangkan semua peristiwa yang dianggap memiliki waktu peristiwa 5 menit lebih awal dari waktu kedatangan. Metrik peristiwa input awal bertahap saat peristiwa dihilangkan.
Konsep ini digunakan untuk memastikan bahwa pemrosesan dapat diulang di mana pun Anda memulai output. Tanpa mekanisme seperti itu, pengulangan tidak akan dapat dipastikan, karena banyak sistem streaming lain mengklaim dapat melakukannya.
Efek samping dari toleransi waktu pengurutan peristiwa
Pekerjaan Azure Stream Analytics memiliki beberapa opsi Pengurutan peristiwa. Ada dua opsi yang dapat dikonfigurasi di portal Azure: pengaturan Peristiwa tak berurutan (toleransi tak berurutan), dan pengaturan Peristiwa yang datang terlambat (toleransi kedatangan terlambat). Toleransi kedatangan dini diperbaiki dan tidak dapat disesuaikan. Kebijakan waktu ini digunakan oleh Azure Stream Analytics untuk memberikan kepastian yang kuat. Namun, pengaturan ini memang memiliki beberapa implikasi yang terkadang tidak terduga:
Secara tidak sengaja mengirim peristiwa yang terlalu dini.
Peristiwa dini awal tidak akan keluar secara normal. Ada kemungkinan bahwa peristiwa dini dikirim ke output jika jam pengirim berjalan terlalu cepat sekalipun. Semua acara yang tiba lebih awal dihilangan, sehingga Anda tidak akan melihat peristiwa apa pun dari output.
Mengirim peristiwa lama ke Event Hubs untuk diproses oleh Azure Stream Analytics.
Meskipun peristiwa lama mungkin tampak tidak berbahaya pada awalnya, karena penerapan toleransi kedatangan terlambat, peristiwa lama mungkin dihilangkan. Jika peristiwa terlalu lama, nilai System.Timestamp diubah selama memasukkan peristiwa. Karena perilaku ini, saat ini Azure Stream Analytics lebih cocok untuk skenario pemrosesan peristiwa yang hampir real-time, sebagai pengganti skenario pemrosesan peristiwa historis. Anda dapat mengatur Peristiwa yang datang terlambat ke kemungkinan nilai terbesar (20 hari) untuk menangani perilaku ini dalam beberapa kasus.
Output tampaknya tertunda.
Marka air pertama dihasilkan pada waktu terhitung: waktu peristiwa maksimum telah diamati sistem sejauh ini, dikurangi ukuran periode toleransi tak berurutan. Secara default, toleransi tak berurutan dikonfigurasi ke nol (00 menit dan 00 detik). Saat Anda mengaturnya ke nilai waktu yang lebih tinggi dan bukan nol, output pertama pekerjaan streaming tertunda oleh nilai waktu tersebut (atau lebih besar) karena waktu marka air pertama yang dihitung.
Input jarang.
Jika tidak ada input dalam partisi tertentu, waktu marka air dihitung sebagai waktu kedatangan dikurangi periode toleransi kedatangan terlambat. Akibatnya, jika peristiwa input tidak sering dan jarang, output dapat tertunda oleh jumlah waktu tersebut. Nilai default Peristiwa yang datang terlambat adalah 5 detik. Anda akan melihat penundaan saat mengirim peristiwa input satu per satu, misalnya. Penundaan bisa menjadi lebih buruk jika Anda mengatur periode Peristiwa yang datang terlambat ke nilai besar.
Nilai System.Timestamp berbeda dengan waktu di bidang waktu peristiwa.
Seperti yang dijelaskan sebelumnya, sistem menyesuaikan waktu peristiwa dengan toleransi di luar urutan atau periode toleransi kedatangan terlambat. Nilai System.Timestamp peristiwa disesuaikan, tetapi bukan bidang waktu peristiwa. Ini dapat digunakan untuk mengidentifikasi peristiwa mana yang tanda waktunya disesuaikan. Jika sistem mengubah tanda waktu karena salah satu toleransi, biasanya semuanya sama.
Metrik untuk diamati
Anda dapat mengamati sejumlah efek toleransi waktu pengurutan Peristiwa melalui metrik pekerjaan Azure Stream Analytics. Berikut adalah metrik yang relevan:
| Metrik | Deskripsi |
|---|---|
| Peristiwa Tak Berurutan | Menunjukkan jumlah peristiwa tak berurutan yang diterima, yang dihilangkan atau diberi tanda waktu yang disesuaikan. Metrik ini dipengaruhi langsung oleh konfigurasi pengaturan Peristiwa tak berurutan di halaman Urutan peristiwa pada pekerjaan di portal Azure. |
| Peristiwa Input Terlambat | Menunjukkan jumlah kejadian yang datang terlambat dari sumbernya. Metrik ini mencakup acara yang telah dihilangkan atau yang tanda waktunya telah disesuaikan. Metrik ini dipengaruhi langsung oleh konfigurasi pengaturan Peristiwa yang datang terlambat di halaman Urutan peristiwa pada pekerjaan di portal Azure. |
| Peristiwa Input Awal | Menunjukkan jumlah peristiwa yang datang lebih awal dari sumber yang telah dihilangkan, atau tanda waktunya telah disesuaikan jika mereka melebihi 5 menit lebih awal. |
| Penundaan Marka Air | Menunjukkan penundaan pekerjaan pemrosesan data streaming. Lihat informasi selengkapnya di bagian berikut. |
Detail penundaan marka air
Metrik Penundaan marka air dihitung sebagai waktu jam dinding simpul pemrosesan dikurangi marka air terbesar yang telah dilihat sejauh ini. Untuk informasi selengkapnya, lihat posting blog penundaan marka air.
Mungkin ada beberapa alasan nilai metrik ini lebih besar dari 0 dalam operasi normal:
Penundaan pemrosesan inheren dari alur streaming. Penundaan ini biasanya bersifat nominal.
Periode toleransi tak berurutan menyebabkan penundaan, karena marka air dikurangi oleh ukuran periode toleransi.
Periode kedatangan terlambat menyebabkan penundaan, karena marka air dikurangi oleh ukuran periode toleransi.
Perbedaan waktu simpul pemrosesan yang menghasilkan metrik.
Ada sejumlah kendala sumber daya lain yang dapat menyebabkan alur streaming melambat. Metrik penundaan marka air bisa naik karena:
Sumber daya pemrosesan di Azure Stream Analytics untuk menangani volume peristiwa input tidak memadai. Untuk meningkatkan skala sumber daya, lihat Memahami dan menyesuaikan Unit Streaming.
Throughput dalam broker peristiwa input tidak memadai, sehingga dibatasi. Sebagai solusinya, lihat Meningkatkan skala unit throughput Azure Event Hubs secara otomatis.
Sink output tidak diprovisikan dengan kapasitas yang memadai, sehingga dibatasi. Kemungkinan solusinya sangat bervariasi berdasarkan karakteristik layanan output yang digunakan.
Frekuensi peristiwa output
Azure Stream Analytics menggunakan kemajuan marka air sebagai satu-satunya pemicu untuk menghasilkan peristiwa output. Karena marka air berasal dari data input, ini dapat diulang selama pemulihan kegagalan dan juga dalam pemrosesan ulang yang diinisiasi pengguna. Saat menggunakan agregat berperiode, layanan hanya menghasilkan output di akhir periode. Dalam beberapa kasus, pengguna sebaiknya melihat agregat parsial yang dihasilkan dari periode tersebut. Agregat parsial saat ini tidak didukung di Azure Stream Analytics.
Dalam solusi streaming lainnya, peristiwa output dapat terwujud di berbagai titik pemicu, bergantung pada keadaan eksternal. Dalam beberapa solusi, peristiwa output selama periode waktu tertentu dapat dihasilkan beberapa kali. Karena nilai input disempurnakan, hasil agregatnya menjadi lebih akurat. Peristiwa dapat dispekulasikan pada awalnya, dan direvisi dari waktu ke waktu. Misalnya, saat perangkat tertentu offline dari jaringan, nilai perkiraan dapat digunakan oleh sistem. Kemudian, perangkat yang sama menjadi online di jaringan. Kemudian, data peristiwa aktual dapat dimasukkan dalam aliran input. Hasil output dari pemrosesan periode waktu tersebut menghasilkan output yang lebih akurat.
Contoh ilustrasi marka air
Gambar berikut mengilustrasikan kemajuan marka air berkembang dalam keadaan yang berbeda.
Tabel ini memperlihatkan contoh data yang dipetakan di bawah. Perhatikan bahwa waktu peristiwa dan waktu kedatangan bervariasi, terkadang cocok, terkadang tidak.
| Waktu peristiwa | Waktu kedatangan | PerangkatId |
|---|---|---|
| 12:07 | 12:07 | perangkat1 |
| 12:08 | 12:08 | perangkat2 |
| 12:17 | 12:11 | perangkat1 |
| 12:08 | 12:13 | perangkat3 |
| 12:19 | 12:16 | perangkat1 |
| 12:12 | 12:17 | perangkat3 |
| 12:17 | 12:18 | perangkat2 |
| 12:20 | 12:19 | perangkat2 |
| 12:16 | 12:21 | perangkat3 |
| 12:23 | 12:22 | perangkat2 |
| 12:22 | 12:24 | perangkat2 |
| 12:21 | 12:27 | perangkat3 |
Dalam ilustrasi ini, toleransi berikut digunakan:
- Periode kedatangan dini adalah 5 menit
- Periode kedatangan terlambat adalah 5 menit
- Periode urutan ulang adalah 2 menit
Ilustrasi marka air yang berkembang selama peristiwa ini:
Proses penting yang diilustrasikan dalam grafik sebelumnya:
Peristiwa pertama (perangkat1), dan peristiwa kedua (perangkat2) telah menyelaraskan waktu dan diproses tanpa penyesuaian. Marka air berlangsung di setiap peristiwa.
Saat peristiwa ketiga (perangkat1) diproses, waktu kedatangan (12:11) mendahului waktu peristiwa (12:17). Peristiwa tiba 6 menit lebih awal, sehingga peristiwa tersebut dihilangkan karena toleransi kedatangan dini 5 menit.
Marka air tidak berkembang dalam hal peristiwa dini ini.
Peristiwa keempat (perangkat3), dan peristiwa kelima (perangkat1) telah menyelaraskan waktu dan diproses tanpa penyesuaian. Marka air berlangsung di setiap peristiwa.
Saat peristiwa keenam (perangkat3) diproses, waktu kedatangan (12:17) dan waktu peristiwa (12:12) berada di bawah ketinggian marka air. Waktu peristiwa disesuaikan dengan ketinggian marka air (12:17).
Saat peristiwa kedua belas (perangkat3) diproses, waktu kedatangan (12:27) adalah 6 menit sebelum waktu peristiwa (12:21). Kebijakan kedatangan terlambat diterapkan. Waktu peristiwa disesuaikan (12:22), yang berada di atas marka air (12:21) sehingga tidak ada penyesuaian lebih lanjut yang diterapkan.
Ilustrasi kedua marka air yang berkembang tanpa kebijakan kedatangan dini:
Dalam contoh ini, tidak ada kebijakan kedatangan dini yang diterapkan. Peristiwa outlier yang tiba lebih awal menaikkan marka air secara signifikan. Perhatikan bahwa peristiwa ketiga (Idperangkat1 pada pukul 12:11) tidak dihilangkan dalam skenario ini, dan marka air naik menjadi ke 12:15. Akibatnya, waktu peristiwa keempat disesuaikan maju 7 menit (12:08 ke 12:15).
Dalam ilustrasi terakhhir, sub-aliran digunakan (MELEBIHI Idperangkat). Beberapa marka air dilacak, satu per aliran. Akibatnya, ada lebih sedikit peristiwa yang waktunya disesuaikan.
