Pola solusi Azure Stream Analytics
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 menggoreng dan mengecilkan data untuk laporan, dan opsi visualisasi yang jauh lebih banyak. Anda juga mendapatkan fleksibilitas menggunakan solusi dasbor lain, seperti Tableau.
SQL bukan penyimpanan data throughput tinggi. Throughput maksimum ke SQL Database dari Azure Stream Analytics saat ini sekitar 24 MB/dtk. 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.
Menggabungkan wawasan real-time ke dalam aplikasi Anda dengan pesan peristiwa
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 peristiwa hilir untuk menghasilkan pemberitahuan di 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 Azure Event Hubs antara Azure 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 dan Time Series Insights dapat menggunakan peristiwa dari 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 sumber kejadian digunakan untuk mengatasi hambatan performa. 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 linchpin 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 disusupi bersama dengan Event Hubs sebagai broker peristiwa perantara.
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 hilir untuk menyimpulkan peristiwa menggunakan tombol logika di jendela lookback. 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.
Menambahkan Machine Learning 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 kebutuhan Machine Learning yang lebih luas, lihat Azure Stream Analytics terintegrasi dengan layanan penilaian Azure Machine Learning.
Untuk pengguna tingkat lanjut yang ingin menggabungkan pelatihan dan penilaian online ke dalam saluran Stream Analytics yang sama, lihat contoh bagaimana melakukannya dengan regresi linier.
Pergudangan data real-time
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, dan penyimpanan data serta penerusan. 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 real-time 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 menyalurkan data langsung ke Azure Data Lake Analytics, Azure Databricks, dan Azure HDInsight. Azure Stream Analytics digunakan sebagai mesin Extract-Transform-Load (ETL) mendekati real time dalam solusi ini. Anda dapat menjelajahi data yang diarsipkan di Data Lake menggunakan berbagai mesin komputasi.
Menggunakan data referensi untuk pengayaan
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.
Cara memonitor pekerjaan ASA
Pekerjaan Azure Stream Analytics dapat dijalankan 24/7 untuk memproses peristiwa yang masuk secara terus-menerus secara real time. Jaminan waktu aktif 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 dikenakan beberapa tingkat 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 lebih lanjut ke OMS. Untuk informasi selengkapnya, lihat Memantau pekerjaan Azure Stream Analytics dengan 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.
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, mengabaikan pemberitahuan sebelumnya. Semantik waktu mulai pekerjaan adalah dengan waktu output pertama, bukan waktu input pertama. Masukan diputar mundur dengan tepat untuk menjamin input pertama pada waktu yang ditentukan selesai dan benar. Anda tidak akan mendapatkan agregat parsial dan memicu peringatan secara tiba-tiba sebagai hasilnya.
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. Tradeoff adalah seberapa cepat Anda dapat mengejar waktu saat ini dan mulai menghasilkan peringatan baru yang tepat waktu. Data kehilangan nilainya dengan cepat dari waktu ke waktu, jadi penting untuk mengejar waktu saat ini dengan cepat. Ada dua cara untuk mengejar ketinggalan dengan cepat:
- Sediakan lebih banyak sumber daya (SU) saat mengejar ketinggalan.
- Hidupkan ulang dari waktu saat ini.
Menghidupkan ulang dari waktu saat ini mudah dilakukan, dengan tradeoff meninggalkan 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 sejajar.
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 maksimal pada tingkat output 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 bahwa semua peristiwa yang masuk tertunda, mungkin semua peristiwa yang tertunda dibatalkan jika Anda telah menerapkan jendela kedatangan yang terlambat ke pekerjaan Anda. Menjatuhkan peristiwa mungkin tampak sebagai perilaku misterius di awal; namun, mengingat Stream Analytics adalah mesin pemrosesan real time, stream analytics mengharapkan peristiwa masuk mendekati waktu jam dinding. Itu harus menjatuhkan peristiwa yang melanggar batasan ini.
Arsitektur Lambda atau proses Isi Ulang
Untungnya, pola pengarsipan data sebelumnya dapat digunakan untuk memproses peristiwa akhir ini dengan baik. Idenya adalah bahwa pekerjaan pengarsipan memproses peristiwa yang masuk dalam waktu kedatangan dan mengarsipkan peristiwa ke dalam ember waktu yang tepat di Azure Blob atau Azure Data Lake Store dengan 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 | Menghidupkan ulang dari hanya saat ini | Mulai ulang dari waktu terakhir dihentikan | Mulai ulang dari sekarang + isi ulang dengan peristiwa yang diarsipkan |
|---|---|---|---|
| Dasbor | Membuat celah | OK untuk pemadaman singkat | Gunakan untuk pemadaman panjang |
| Pemberitahuan | Dapat diterima | OK untuk pemadaman singkat | Tidak perlu |
| Aplikasi sumber peristiwa | 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 sekarang telah melihat berbagai pola solusi menggunakan Azure Stream Analytics. Selanjutnya, Anda dapat menyelam lebih dalam dan membuat pekerjaan Stream Analytics pertama Anda: