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.
Seperti banyak layanan lain di Azure, Stream Analytics paling baik digunakan dengan layanan lain untuk membuat solusi ujung-ke-ujung yang lebih besar. Artikel ini membahas solusi Azure Stream Analytics sederhana dan berbagai pola arsitektur. Anda dapat membangun pola-pola ini untuk mengembangkan solusi yang lebih kompleks. Pola yang dijelaskan dalam artikel ini dapat digunakan dalam berbagai skenario. Contoh pola khusus skenario tersedia di arsitektur solusi Azure.
Membuat pekerjaan Stream Analytics untuk meningkatkan pengalaman dasbor real-time
Dengan Azure Stream Analytics, Anda dapat dengan cepat membuat dasbor dan pemberitahuan real-time. Solusi sederhana menyerap peristiwa dari Event Hubs atau IoT Hub, dan menyalurkan dasbor Power BI dengan kumpulan data streaming. Untuk informasi selengkapnya, lihat tutorial mendetail Menganalisis data panggilan palsu dengan Stream Analytics dan memvisualisasikan hasilnya di dasbor Power BI.
Anda dapat membangun solusi ini hanya dalam beberapa menit menggunakan portal Azure. Anda tidak perlu membuat kode secara ekstensif. Sebagai gantinya, Anda dapat menggunakan bahasa SQL untuk mengekspresikan logika bisnis.
Pola solusi ini menawarkan latensi terendah dari sumber peristiwa ke dasbor Power BI di browser. Azure Stream Analytics adalah satu-satunya layanan Azure dengan kemampuan bawaan ini.
Menggunakan SQL untuk dasbor
Dasbor Power BI menawarkan latensi rendah, tetapi Anda tidak dapat menggunakannya untuk menghasilkan laporan Power BI lengkap. Pola pelaporan umum adalah untuk menghasilkan data Anda ke SQL Database terlebih dahulu. Lalu gunakan konektor SQL Power BI untuk membuat kueri SQL untuk data terbaru.
Saat Anda menggunakan SQL Database, itu memberi Anda lebih banyak fleksibilitas tetapi dengan mengorbankan latensi yang sedikit lebih tinggi. Solusi ini optimal untuk pekerjaan dengan persyaratan latensi lebih dari satu detik. Saat Anda menggunakan metode ini, Anda dapat memaksimalkan kemampuan Power BI untuk menganalisis dan memecah data untuk laporan, serta berbagai pilihan visualisasi lainnya. Anda juga mendapatkan fleksibilitas menggunakan solusi dasbor lain, seperti Tableau.
SQL bukan penyimpanan data dengan tingkat throughput yang tinggi. Throughput maksimum ke SQL Database dari Azure Stream Analytics saat ini sekitar 24 MB/s. Jika sumber peristiwa dalam solusi Anda menghasilkan data pada tingkat yang lebih tinggi, Anda perlu menggunakan logika pemrosesan di Stream Analytics untuk mengurangi tingkat output ke SQL. Anda dapat menggunakan teknik seperti pemfilteran, agregat berjendela, pencocokan pola dengan gabungan temporal, dan fungsi analitik. Anda dapat mengoptimalkan laju output ke SQL menggunakan teknik yang dijelaskan dalam output Azure Stream Analytics ke Azure SQL Database.
Mengintegrasikan wawasan real-time ke dalam aplikasi Anda dengan pesan berbasis kejadian
Penggunaan Stream Analytics kedua yang paling populer adalah menghasilkan peringatan real-time. Dalam pola solusi ini, logika bisnis di Stream Analytics dapat digunakan untuk mendeteksi pola temporal dan spasialatau anomali, kemudian menghasilkan sinyal peringatan. Namun, tidak seperti solusi dasbor di mana Azure Stream Analytics menggunakan Power BI sebagai titik akhir pilihan, Anda dapat menggunakan sink data perantara lainnya. Sink ini termasuk Event Hubs, Service Bus, dan Azure Functions. Anda, sebagai pembuat aplikasi, perlu memutuskan sink data mana yang paling cocok untuk skenario Anda.
Anda perlu menerapkan logika konsumen acara hilir guna menghasilkan notifikasi dalam alur kerja bisnis yang ada. Karena Anda dapat menerapkan logika kustom di Azure Functions, Azure Functions adalah cara tercepat untuk melakukan integrasi ini. Untuk tutorial tentang menggunakan Azure Function sebagai output untuk pekerjaan Azure Stream Analytics, lihat Menjalankan Azure Functions dari pekerjaan Azure Stream Analytics. Azure Functions juga mendukung berbagai jenis pemberitahuan termasuk teks dan email. Anda juga dapat menggunakan Logic Apps untuk integrasi tersebut, dengan Event Hubs antara Stream Analytics dan Logic Apps.
Layanan Azure Event Hubs, di sisi lain, menawarkan titik integrasi yang paling fleksibel. Banyak layanan lain, seperti Azure Data Explorer, dapat menggunakan peristiwa dari Azure Event Hubs. Layanan dapat dihubungkan langsung ke sink Event Hubs dari Azure Stream Analytics untuk menyelesaikan solusi. Event Hubs juga merupakan broker pesan throughput tertinggi yang tersedia di Azure untuk skenario integrasi tersebut.
Aplikasi dan situs web dinamis
Anda dapat membuat visualisasi real-time kustom, seperti visualisasi dasbor atau peta, menggunakan Azure Stream Analytics dan Azure SignalR Service. Saat Anda menggunakan SignalR, klien web dapat diperbarui dan menampilkan konten dinamis secara real time.
Menggabungkan wawasan real-time ke dalam aplikasi Anda melalui penyimpanan data
Sebagian besar layanan web dan aplikasi web saat ini menggunakan pola permintaan/respons untuk melayani lapisan presentasi. Pola permintaan/respons mudah dibuat dan dapat dengan mudah diskalakan dengan waktu respons rendah menggunakan frontend stateless dan penyimpanan yang dapat diskalakan seperti Azure Cosmos DB.
Volume data yang tinggi sering menciptakan hambatan performa dalam sistem berbasis CRUD. Pola solusi pengambilan peristiwa digunakan untuk mengatasi hambatan kinerja. Pola dan wawasan temporal juga sulit dan tidak efisien untuk diekstraks dari penyimpanan data tradisional. Aplikasi modern berbasis data volume tinggi sering mengadopsi arsitektur berbasis aliran data. Azure Stream Analytics sebagai mesin komputasi untuk data yang bergerak adalah elemen penting dalam arsitektur tersebut.
Dalam pola solusi ini, peristiwa diproses dan digabungkan ke dalam penyimpanan data oleh Azure Stream Analytics. Lapisan aplikasi berinteraksi dengan penyimpanan data menggunakan pola permintaan/respons tradisional. Karena kemampuan Stream Analytics untuk memproses sejumlah besar peristiwa secara real-time, aplikasi ini sangat dapat diskalakan tanpa perlu memperbesar lapisan penyimpanan data. Lapisan penyimpanan data pada dasarnya adalah tampilan yang terwujud dalam sistem. Output Azure Stream Analytics ke Azure Cosmos DB menjelaskan bagaimana Azure Cosmos DB digunakan sebagai output Azure Stream Analytics.
Dalam aplikasi nyata di mana logika pemrosesan rumit dan ada kebutuhan untuk meningkatkan bagian tertentu dari logika secara independen, beberapa pekerjaan Azure Stream Analytics dapat dikombinasikan bersama dengan Event Hubs sebagai perantara broker peristiwa.
Pola ini meningkatkan ketahanan dan pengelolaan sistem. Namun, meskipun Stream Analytics menjamin pemrosesan tepat sekali, ada kemungkinan kecil peristiwa duplikat mendarat di Pusat Aktivitas perantara. Penting bagi pekerjaan Stream Analytics di bagian hilir untuk menghapus duplikasi peristiwa menggunakan kunci logika di jendela tinjau ulang. Untuk informasi selengkapnya tentang pengiriman peristiwa, lihat referensi Jaminan Pengiriman Peristiwa.
Menggunakan data referensi untuk kustomisasi aplikasi
Fitur data referensi Azure Stream Analytics dirancang khusus untuk penyesuaian pengguna akhir seperti ambang peringatan, aturan pemrosesan, dan geofence. Lapisan aplikasi dapat menerima perubahan parameter dan menyimpannya di SQL Database. Pekerjaan Stream Analytics secara berkala meminta perubahan dari database dan membuat parameter penyesuaian dapat diakses melalui gabungan data referensi. Untuk informasi selengkapnya tentang cara menggunakan data referensi untuk penyesuaian aplikasi, lihat data referensi SQL dan gabungan data referensi.
Pola ini juga dapat digunakan untuk mengimplementasikan mesin aturan tempat ambang aturan didefinisikan dari data referensi. Untuk informasi selengkapnya tentang aturan, lihat Memproses aturan berbasis ambang yang dapat dikonfigurasi di Azure Stream Analytics.
Tambahkan Pembelajaran Mesin ke wawasan real-time Anda
Model Deteksi Anomali bawaan Azure Stream Analytics adalah cara yang nyaman untuk memperkenalkan Machine Learning ke aplikasi real-time Anda. Untuk berbagai kebutuhan Pembelajaran Mesin, lihat Integrasi Azure Stream Analytics dengan Azure Machine Learning. Anda dapat menyebarkan model dari Azure Machine Learning dan memanggilnya sebagai fungsi yang ditentukan pengguna (UDF) dalam kueri Azure Stream Analytics Anda.
Untuk pengguna tingkat lanjut yang ingin menggabungkan pelatihan dan penilaian online ke dalam alur Azure Stream Analytics yang sama, lihat contoh cara melakukannya dengan regresi linier.
Pergudangan data waktu nyata
Pola umum lainnya adalah pergudangan data real-time, juga disebut pergudangan data streaming. Selain peristiwa yang tiba di Event Hubs dan IoT Hub dari aplikasi Anda, Azure Stream Analytics yang berjalan di IoT Edge dapat digunakan untuk memenuhi kebutuhan pembersihan data, pengurangan data, serta penyimpanan dan penerusan data. Stream Analytics yang berjalan di IoT Edge dapat menangani batasan bandwidth dan masalah konektivitas dengan baik di sistem. Azure Stream Analytics dapat mendukung tingkat throughput hingga 200 MB/detik saat menulis ke Azure Synapse Analytics.
Pengarsipan data waktu nyata untuk analitik
Sebagian besar aktivitas ilmu data dan analitik masih terjadi secara offline. Anda dapat mengarsipkan data di Azure Stream Analytics melalui output Azure Data Lake Store Gen2 dan format output Parquet. Kemampuan ini menghapus gesekan untuk mengumpan data langsung ke Azure Synapse Analytics, Azure Databricks, Microsoft Fabric, dan Azure HDInsight. Azure Stream Analytics digunakan sebagai mesin Extract-Transform-Load (ETL) nyaris real-time dalam solusi ini. Anda dapat menjelajahi data yang diarsipkan di Data Lake menggunakan berbagai mesin komputasi.
Menggunakan data referensi untuk memperkaya
Pengayaan data sering kali menjadi persyaratan untuk mesin ETL. Azure Stream Analytics mendukung pengayaan data dengan data referensi dari SQL Database dan penyimpanan Azure Blob. Pengayaan data dapat dilakukan untuk pendaratan data di Azure Data Lake dan Azure Synapse Analytics.
Mengoperasionalkan wawasan dari data yang diarsipkan
Jika Anda menggabungkan pola analitik offline dengan pola aplikasi yang hampir real-time, Anda dapat membuat loop umpan balik. Loop umpan balik memungkinkan aplikasi secara otomatis menyesuaikan untuk mengubah pola dalam data. Putaran umpan balik ini bisa sesederhana mengubah nilai ambang untuk peringatan, atau serumit melatih kembali model Machine Learning. Arsitektur solusi yang sama dapat diterapkan pada pekerjaan ASA yang berjalan di cloud dan di IoT Edge.
Integrasi Apache Kafka
Azure Stream Analytics mendukung Apache Kafka sebagai input dan output melalui Azure Event Hubs dengan endpoint Kafka. Pola ini memungkinkan:
- Migrasi dari arsitektur berbasis Kafka yang ada ke Azure
- Skenario hibrid yang menghubungkan kluster Kafka lokal ke Azure
- Integrasi dengan alat dan konektor ekosistem Apache Kafka
Output dari Delta Lake untuk arsitektur lakehouse
Untuk arsitektur lakehouse modern, Stream Analytics dapat menulis langsung ke format Delta Lake di Azure Data Lake Storage Gen2. Delta Lake menyediakan:
- Transaksi ACID untuk penyerapan data yang andal
- Penerapan dan Evolusi Skema
- Kemampuan perjalanan waktu untuk penerapan versi data
- Akses data batch dan streaming terpadu
Memilih pola yang tepat
Gunakan tabel ini untuk membantu memilih pola yang sesuai untuk skenario Anda:
| Skenario | Pola yang direkomendasikan | Manfaat utama |
|---|---|---|
| Dasbor real-time | Himpunan data streaming Power BI | Latensi terendah |
| Pelaporan kompleks | SQL Database + Power BI | Kemampuan BI penuh |
| Pemberitahuan berbasis peristiwa | Event Hubs + Azure Functions | Integrasi fleksibel |
| Analitik danau data | Hasil Delta Lake | Transaksi ACID |
| Beban kerja Kafka | Titik akhir Event Hubs Kafka | Kompatibilitas protokol |
Cara memantau tugas ASA
Pekerjaan Azure Stream Analytics dapat dijalankan 24/7 untuk memproses peristiwa yang masuk secara terus-menerus secara real time. Jaminan waktu operasi sangat penting untuk kesehatan aplikasi secara keseluruhan. Meskipun Stream Analytics adalah satu-satunya layanan analitik streaming di industri yang menawarkan jaminan ketersediaan 99,9%, Anda masih akan mengalami beberapa waktu henti. Selama bertahun-tahun, Stream Analytics telah memperkenalkan metrik, log, dan status pekerjaan untuk mencerminkan kesehatan pekerjaan. Semuanya muncul melalui layanan Azure Monitor dan dapat diekspor ke ruang kerja Analitik Log untuk analisis yang lebih mendalam. Untuk informasi selengkapnya, lihat Monitor pekerjaan Stream Analytics menggunakan portal Azure.
Ada dua hal utama untuk dipantau:
-
Pertama dan terpenting, Anda perlu memastikan pekerjaan berjalan. Tanpa pekerjaan dalam status berjalan, tidak ada metrik atau log baru yang dihasilkan. Pekerjaan dapat berubah menjadi status gagal karena berbagai alasan, termasuk memiliki tingkat pemanfaatan SU yang tinggi (yaitu, kehabisan sumber daya).
-
Metrik ini mencerminkan seberapa jauh di belakang alur pemrosesan Anda dalam waktu jam dinding (detik). Beberapa penundaan dikaitkan dengan logika pemrosesan yang melekat. Akibatnya, memantau tren yang meningkat jauh lebih penting daripada memantau nilai absolutnya. Penundaan kondisi stabil harus ditangani oleh desain aplikasi Anda, bukan dengan pemantauan atau peringatan.
Menyiapkan peringatan dan dasbor
Mengonfigurasi pemberitahuan Azure Monitor untuk pemantauan proaktif:
- Pemanfaatan SU - Pemberitahuan saat berkelanjutan di atas 80% untuk mencegah kegagalan pekerjaan
- Penundaan watermark - Pemberitahuan tentang peningkatan tren yang menunjukkan kelambatan pemrosesan
- Peristiwa Input/Output - Memantau penurunan mendadak yang menunjukkan masalah konektivitas
- Kesalahan runtime - Melacak deserialisasi dan kegagalan konversi data
Untuk pengamatan terpusat, ekspor metrik dan log Stream Analytics ke ruang kerja Log Analytics. Ini memungkinkan:
- Korelasi dan analisis lintas pekerjaan
- Kueri Kusto khusus untuk analisis mendalam
- Integrasi dengan dasbor dan buku kerja Azure
Setelah kegagalan, log aktivitas dan log diagnostik adalah tempat terbaik untuk mulai mencari kesalahan.
Membangun aplikasi yang tangguh dan untuk misi penting
Terlepas dari jaminan SLA Azure Stream Analytics dan seberapa hati-hati Anda menjalankan aplikasi ujung-ke-ujung, pemadaman tetap terjadi. Jika aplikasi Anda sangat penting untuk misi, Anda harus bersiap untuk pemadaman agar dapat pulih dengan baik.
Untuk aplikasi peringatan, yang terpenting adalah mendeteksi peringatan berikutnya. Anda dapat memilih untuk memulai ulang pekerjaan dari waktu saat ini saat memulihkan sistem, mengabaikan peringatan sebelumnya. Semantik waktu mulai pekerjaan adalah dengan waktu output pertama, bukan waktu input pertama. Masukan diputar mundur dalam rentang waktu yang sesuai untuk menjamin keluaran pertama pada waktu yang ditentukan selesai dan benar. Anda tidak akan mendapatkan agregat parsial maupun memicu peringatan secara tiba-tiba sebagai akibatnya.
Anda juga dapat memilih untuk memulai output dari beberapa waktu di masa lalu. Kebijakan retensi Event Hub dan IoT Hub menyimpan sejumlah data yang wajar untuk memungkinkan pemrosesan dari masa lalu. Kompromi adalah seberapa cepat Anda dapat mengejar ketertinggalan hingga waktu saat ini dan mulai menghasilkan peringatan baru yang tepat waktu. Data cepat kehilangan nilai seiring berjalannya waktu, jadi penting untuk segera menyesuaikan diri dengan waktu saat ini. Ada dua cara untuk mengejar ketinggalan dengan cepat:
- Sediakan lebih banyak sumber daya (SU) saat mengejar ketinggalan.
- Mulai ulang dari waktu saat ini.
Menghidupkan ulang dari waktu sekarang mudah dilakukan, dengan kompromi akan ada celah selama pemrosesan. Menghidupkan ulang dengan cara ini mungkin baik-baik saja untuk skenario peringatan, tetapi bisa menjadi masalah untuk skenario dasbor dan bukan merupakan permulaan untuk skenario pengarsipan dan pergudangan data.
Penyediaan lebih banyak sumber daya dapat mempercepat proses, tetapi efek dari lonjakan kecepatan pemrosesan adalah kompleks.
Uji apakah pekerjaan Anda dapat diskalakan ke jumlah SU yang lebih besar. Tidak semua kueri dapat diskalakan. Anda perlu memastikan kueri Anda diparalelkan.
Pastikan ada cukup banyak partisi di Event Hub upstream atau IoT Hub sehingga Anda dapat menambahkan lebih banyak Unit Throughput (TU) untuk menskalakan throughput input. Ingat, setiap TU Event Hubs memiliki kecepatan output maksimum 2 MB/s.
Pastikan Anda telah menyediakan sumber daya yang cukup di sink output (yaitu, SQL Database, Azure Cosmos DB), sehingga mereka tidak membatasi lonjakan output, yang terkadang dapat menyebabkan sistem terkunci.
Yang paling penting adalah mengantisipasi perubahan laju pemrosesan, menguji skenario ini sebelum masuk ke produksi, dan siap untuk menskalakan pemrosesan dengan benar selama waktu pemulihan kegagalan.
Dalam skenario ekstrem di mana semua peristiwa yang masuk mengalami keterlambatan, mungkin semua peristiwa yang tertunda dihapus jika Anda telah menerapkan jendela kedatangan terlambat ke pekerjaan Anda. Penghilangan peristiwa mungkin tampak sebagai perilaku misterius di awal; namun, mengingat Stream Analytics adalah mesin pemrosesan real-time, Stream Analytics mengharapkan peristiwa masuk mendekati waktu nyata. Harus mengabaikan acara yang melanggar batasan ini.
Arsitektur Lambda atau proses Isi Ulang
Untungnya, pola pengarsipan data sebelumnya dapat digunakan untuk memproses peristiwa akhir ini dengan baik. Pekerjaan pengarsipan memproses event yang masuk berdasarkan waktu diterima dan mengarsipkan event ke dalam bucket waktu yang tepat di Azure Blob atau Azure Data Lake Store berdasarkan waktu peristiwa mereka. Tidak peduli seberapa terlambat suatu peristiwa datang, itu tidak akan pernah dibatalkan. Itu akan selalu mendarat di wadah waktu yang tepat. Selama pemulihan, dimungkinkan untuk memproses ulang peristiwa yang diarsipkan dan mengisi ulang hasilnya ke penyimpanan pilihan. Ini mirip dengan cara pola lambda diterapkan.
Proses pengisian ulang harus dilakukan dengan sistem pemrosesan batch offline, yang kemungkinan besar memiliki model pemrograman yang berbeda dari Azure Stream Analytics. Ini berarti Anda harus mengisi ulang seluruh logika pemrosesan.
Untuk pengisian ulang, masih penting untuk setidaknya sementara menyediakan lebih banyak sumber daya ke sink output untuk menangani throughput yang lebih tinggi daripada kebutuhan pemrosesan kondisi yang stabil.
| Skenario | Mulai ulang hanya dari sekarang | Mulai ulang dari waktu saat terakhir kali dihentikan | Mulai ulang dari sekarang + isi ulang dengan peristiwa yang diarsipkan |
|---|---|---|---|
| Aktivitas Mendasbor | Menciptakan celah | OK untuk pemadaman singkat | Gunakan untuk pemadaman panjang |
| Pemberitahuan | Dapat diterima | OK untuk pemadaman singkat | Tidak perlu |
| Aplikasi Event Sourcing | Dapat diterima | OK untuk pemadaman singkat | Gunakan untuk pemadaman panjang |
| Pergudangan data | Kehilangan data | Dapat diterima | Tidak perlu |
| Analitik offline | Kehilangan data | Dapat diterima | Tidak perlu |
Merangkum semuanya
Tidak sulit untuk membayangkan bahwa semua pola solusi yang disebutkan sebelumnya dapat digabungkan bersama-sama dalam sistem end-to-end yang kompleks. Sistem gabungan dapat mencakup dasbor, peringatan, aplikasi sumber peritiwa, pergudangan data, dan kemampuan analitik offline.
Kuncinya adalah mendesain sistem Anda dalam pola yang dapat dikomposisi, sehingga setiap subsistem dapat dibangun, diuji, ditingkatkan, dan dipulihkan secara independen.
Langkah berikutnya
Anda telah mempelajari tentang berbagai pola solusi menggunakan Azure Stream Analytics. Selanjutnya, Anda dapat menyelam lebih dalam dan membuat pekerjaan Stream Analytics pertama Anda: