Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Penanganan waktu di Azure Stream Analytics adalah serangkaian mekanisme yang menentukan bagaimana peristiwa streaming diberi tanda waktu, diurutkan, dan diproses berdasarkan kapan peristiwa tersebut terjadi versus saat peristiwa tersebut tiba. Artikel ini menjelaskan cara membuat pilihan desain untuk menyelesaikan masalah penanganan waktu praktis dalam pekerjaan 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 ketika peristiwa asli 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.
Watermark: Penanda waktu peristiwa yang menunjukkan titik di mana prosesor streaming telah mengambil data peristiwa. Penanda memungkinkan sistem menunjukkan kemajuan yang jelas saat menerima 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. Penanda waktu memungkinkan Azure Stream Analytics menentukan kapan sistem dapat menghasilkan hasil yang lengkap, akurat, 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, "tanda batas" 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 Anda 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 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 penerapan ditetapkan saat peristiwa dihasilkan, dan merupakan bagian dari muatan 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 yang ditentukan aplikasi, perkembangan waktu didasarkan pada peristiwa yang 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-cara berikut untuk setiap partisi input:
Saat ada peristiwa masuk, penanda waktu adalah waktu peristiwa terbesar yang dikenali Azure Stream Analytics sejauh ini dikurangi ukuran jendela toleransi kejadian tidak 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 hadir serta waktu kedatangan peristiwa input tersebut.
Waktu kedatangan hanya dapat diperkirakan karena waktu kedatangan nyata dihasilkan pada broker peristiwa input (seperti Azure Event Hubs atau IoT Hub), bukan 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 terlambat diperlukan untuk tetap menghasilkan tanda air, bahkan ketika tidak ada peristiwa yang masuk. Terkadang, mungkin ada periode di mana tidak ada kejadian yang masuk, seperti saat aliran masuk kejadian jarang. Masalah ini diperburuk oleh penggunaan beberapa partisi di broker peristiwa input.
Sistem pemrosesan data streaming tanpa jendela toleransi kedatangan terlambat mungkin menderita output yang tertunda ketika input jarang dan beberapa partisi digunakan.
Perilaku sistem perlu diulang. Pengulangan adalah properti penting dari sistem pemrosesan data streaming.
Marka air ditentukan dari waktu kedatangan dan waktu penggunaan. Keduanya dipertahankan dalam event broker, dan karenanya 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 Anda memilih untuk menggunakan waktu kedatangan sebagai waktu kejadian, Anda tidak perlu mengonfigurasi toleransi di luar urutan dan toleransi kedatangan terlambat. Karena waktu kedatangan dijamin 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 jendela 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 penanda.
Sebagai bagian dari penyesuaian, System.Timestamp peristiwa diatur ke nilai baru, tetapi bidang waktu peristiwa itu sendiri tidak diubah. Penyesuaian ini adalah satu-satunya situasi di mana System.Timestamp peristiwa dapat berbeda dari nilai di bidang waktu peristiwa dan dapat menyebabkan hasil yang tidak terduga dihasilkan.
Menangani variasi waktu dengan sub-aliran
Mekanisme pembuatan watermark heuristik—di mana Azure Stream Analytics melacak perkembangan waktu acara menggunakan cap waktu terbesar yang teramati dikurangi jendela toleransi—berfungsi dengan baik dalam sebagian besar kasus di mana waktu sebagian besar disinkronkan antara berbagai pengirim acara. Namun, dalam kehidupan nyata, terutama dalam banyak skenario IoT, sistem memiliki sedikit kontrol atas jam pada pengirim peristiwa. Pengirim peristiwa bisa berupa berbagai jenis perangkat IoT yang berada di lapangan, mungkin menggunakan versi perangkat keras dan firmware perangkat yang berbeda.
Daripada menggunakan watermark yang bersifat global untuk semua peristiwa dalam partisi masukan, Azure Stream Analytics memiliki mekanisme lain yang disebut substream. Anda dapat menggunakan sub-aliran dalam pekerjaan Anda dengan menulis kueri pekerjaan yang menggunakan klausa 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.
Saat Anda menggunakan sub-aliran, Azure Stream Analytics menerapkan jendela toleransi kedatangan terlambat ke peristiwa masuk. Toleransi keterlambatan kedatangan menentukan jumlah maksimum yang memungkinkan setiap subaliran saling terpisah. Misalnya, jika Perangkat 1 berada di Tanda Waktu 1, dan Perangkat 2 berada pada Tanda Waktu 2, toleransi kedatangan terlambat maksimum adalah Tanda Waktu 2 dikurangi Tanda Waktu 1. Pengaturan toleransi kedatangan terlambat default adalah 5 detik, yang kemungkinan terlalu kecil untuk perangkat IoT dengan tanda waktu yang berbeda. Mulailah dengan 5 menit dan buat penyesuaian sesuai dengan pola condong jam perangkat Anda.
Peristiwa yang datang lebih awal
Jendela kedatangan awal memiliki toleransi 5 menit yang telah ditetapkan, menentukan seberapa awal suatu peristiwa dapat tiba dibandingkan dengan waktu peristiwanya, sebelum Azure Stream Analytics menghapusnya. Jendela ini melayani tujuan yang berbeda dari jendela 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 sistem memproses jendela lengkap, bukan hanya dari tengah jendela.
Azure Stream Analytics memperoleh waktu mulai dari spesifikasi kueri. Namun, karena broker peristiwa input hanya diindeks oleh waktu kedatangan, sistem harus mengubah waktu mulai peristiwa menjadi 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 dinaikkan ketika peristiwa dibuang.
Konsep ini memastikan pemrosesan dapat diulang di mana pun Anda mulai menghasilkan. Tanpa mekanisme seperti itu, tidak mungkin untuk menjamin pengulangan, seperti yang diklaim oleh banyak sistem streaming lainnya.
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 lebih awal ditetapkan dan tidak dapat disesuaikan. Azure Stream Analytics menggunakan kebijakan waktu ini untuk memberikan jaminan yang kuat. Namun, pengaturan ini memang memiliki beberapa implikasi yang terkadang tidak terduga:
Secara tidak sengaja mengirim peristiwa yang terlalu dini.
Peristiwa awal biasanya tidak seharusnya dihasilkan. Ada kemungkinan bahwa peristiwa awal dikirim ke output jika jam pengirim berjalan terlalu cepat. Semua peristiwa yang tiba lebih awal dihilangkan, sehingga Anda tidak akan melihat salah satunya 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, Azure Stream Analytics lebih cocok untuk skenario pemrosesan peristiwa mendekati real-time daripada 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 tidak nol, output pertama pekerjaan streaming tertunda oleh nilai waktu tersebut (atau lebih lama) karena penanda waktu pertama yang dihitung.
Input jarang.
Ketika tidak ada input dalam partisi tertentu, waktu penanda dihitung sebagai waktu kedatangan dikurangi jendela 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. Misalnya, Anda seharusnya mengharapkan penundaan saat mengirim peristiwa input satu per satu. Penundaan dapat menjadi semakin parah jika Anda menetapkan jendela Acara yang tiba terlambat ke nilai besar.
Nilai System.Timestamp berbeda dengan waktu di bidang waktu peristiwa.
Seperti yang dijelaskan sebelumnya, sistem menyesuaikan waktu peristiwa dengan jendela toleransi ketidakurutan atau jendela toleransi keterlambatan kedatangan. Nilai System.Timestamp peristiwa disesuaikan, tetapi bidang waktu peristiwa tidak disesuaikan. Anda dapat menggunakan ini untuk mengidentifikasi peristiwa mana tanda waktu yang disesuaikan. Jika sistem mengubah tanda waktu karena salah satu toleransi, biasanya 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 |
|---|---|
| Kejadian Tak Berurutan | Menunjukkan jumlah peristiwa yang diterima tidak sesuai urutan yang dibuang 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. |
| Input Terlambat Terjadi | Menunjukkan jumlah kejadian yang datang terlambat dari sumbernya. Metrik ini mencakup peristiwa yang dihilangkan atau telah disesuaikan tanda waktunya. 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 tiba lebih awal dari sumber yang dihilangkan atau stempel waktunya disesuaikan jika melebihi 5 menit lebih awal. |
| Penundaan Tanda Air | Menunjukkan penundaan pekerjaan pemrosesan data streaming. Untuk informasi selengkapnya, lihat bagian berikut ini. |
Detail penundaan tanda air
Azure Stream Analytics menghitung metrik penundaan Marka Air sebagai waktu jam dinding simpul pemrosesan dikurangi marka air terbesar yang telah dilihatnya sejauh ini. Untuk informasi selengkapnya, lihat penundaan watermark.
Mungkin ada beberapa alasan nilai metrik ini lebih besar dari 0 dalam operasi normal:
Penundaan pemrosesan bawaan dari jalur streaming. Penundaan ini biasanya bersifat nominal.
Jendela toleransi tidak berurutan memperkenalkan penundaan, karena watermark dikurangi oleh ukuran jendela toleransi.
Kedatangan terlambat memperkenalkan penundaan, karena batas watermark berkurang sesuai ukuran jendela toleransi.
Selisih waktu antara simpul pemrosesan yang menghasilkan metrik.
Ada beberapa batasan sumber daya lain yang dapat menyebabkan alur streaming melambat. Metrik penundaan watermark dapat meningkat disebabkan oleh:
Sumber daya pemrosesan di Azure Stream Analytics tidak cukup untuk menangani volume peristiwa input. Untuk meningkatkan skala sumber daya, lihat Memahami dan menyesuaikan Unit Streaming.
Throughput tidak cukup dalam broker peristiwa input, sehingga dibatasi. Sebagai solusinya, lihat Meningkatkan skala unit throughput Azure Event Hubs secara otomatis.
Output sink (seperti Azure SQL Database, Blob Storage, atau Power BI) tidak disediakan dengan kapasitas yang cukup, sehingga kecepatan atau laju operasinya dibatasi. Solusi yang mungkin sangat bervariasi berdasarkan layanan output yang digunakan.
Frekuensi kejadian output
Azure Stream Analytics menggunakan kemajuan nilai tanda air sebagai satu-satunya pemicu untuk menghasilkan output. Karena marka air berasal dari data input, marka air dapat diulang selama pemulihan setelah gagal dan juga dalam pemrosesan ulang yang dilakukan oleh pengguna. Saat menggunakan agregat berperiode, layanan hanya menghasilkan output di akhir periode. Dalam beberapa kasus, Anda mungkin ingin melihat agregat parsial yang dihasilkan dari jendela. Agregat parsial saat ini tidak didukung di Azure Stream Analytics.
Dalam solusi streaming lainnya, peristiwa output dapat terwujud di berbagai titik pemicu, tergantung pada keadaan eksternal. Dimungkinkan dalam beberapa solusi bahwa peristiwa output untuk jendela 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.
Ilustrasi contoh marka air
Gambar berikut mengilustrasikan bagaimana tanda air maju 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 | DeviceId |
|---|---|---|
| 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:
- Jendela kedatangan awal adalah 5 menit
- Periode kedatangan terlambat adalah 5 menit
- Jendela pemesanan ulang adalah 2 menit
Ilustrasi perkembangan watermark melalui peristiwa-peristiwa ini:
Ilustrasi watermark Azure Stream Analytics
Proses penting yang diilustrasikan dalam grafik sebelumnya:
Peristiwa pertama (perangkat1), dan peristiwa kedua (perangkat2) telah menyelaraskan waktu dan diproses tanpa penyesuaian. Tanda air berkembang pada 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.
Tanda air tidak bergerak maju dalam kasus peristiwa dini ini.
Peristiwa keempat (perangkat3), dan peristiwa kelima (perangkat1) telah menyelaraskan waktu dan diproses tanpa penyesuaian. Watermark berkembang pada setiap acara.
Ketika peristiwa keenam (perangkat3) diproses, waktu kedatangan (12:17) dan waktu peristiwa (12:12) berada di bawah level tanda air. Waktu peristiwa disesuaikan dengan tingkat 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 batas waktu (12:21) sehingga tidak ada penyesuaian lebih lanjut yang diperlukan.
Ilustrasi kedua tentang proses tanda air tanpa kebijakan pemrosesan awal:
Dalam contoh ini, tidak ada kebijakan kedatangan dini yang diterapkan. Peristiwa outlier yang tiba lebih awal menaikkan ambang batas air secara signifikan. Perhatikan peristiwa ketiga (deviceId1 pada waktu 12:11) tidak dihilangkan dalam skenario ini, dan marka air dinaikkan menjadi 12:15. Akibatnya, waktu peristiwa keempat disesuaikan maju 7 menit (12:08 menjadi 12:15).
Dalam ilustrasi terakhir, substream digunakan (di atas DeviceId). Beberapa marka air dilacak, satu per aliran. Akibatnya, ada lebih sedikit peristiwa yang waktunya disesuaikan.
