Memahami dan menyesuaikan unit streaming Stream Analytics

Memahami unit streaming dan node streaming

Unit streaming (SU) mewakili sumber daya komputasi yang menjalankan pekerjaan Azure Stream Analytics. Semakin tinggi jumlah SU, semakin banyak sumber daya CPU dan memori yang Anda alokasikan untuk pekerjaan Anda. Kapasitas ini memungkinkan Anda fokus pada logika kueri dan mengabstraksi kebutuhan untuk mengelola perangkat keras untuk menjalankan pekerjaan Stream Analytics Anda secara tepat waktu.

Azure Stream Analytics mendukung dua struktur unit streaming: SU V1(agar tidak digunakan lagi) dan SU V2(disarankan).

Model SU V1 merupakan penawaran awal Azure Stream Analytics di mana setiap 6 SU setara dengan satu node streaming untuk sebuah pekerjaan. Pekerjaan mungkin berjalan dengan 1 dan 3 SU juga, dan sesuai dengan node streaming pecahan. Penskalaan terjadi dalam kelipatan 6 lebih dari 6 pekerjaan SU, hingga 12, 18, 24, dan seterusnya dengan menambahkan lebih banyak node streaming yang menyediakan sumber daya komputasi terdistribusi.

Model SU V2 (disarankan) adalah struktur yang disederhanakan dengan harga yang menguntungkan untuk sumber daya komputasi yang sama. Dalam model SU V2, 1 SU V2 sesuai dengan satu simpul streaming untuk pekerjaan Anda. 2 SU V2 sesuai dengan 2 simpul streaming, 3 hingga 3, dan sebagainya. Pekerjaan dengan konfigurasi 1/3 dan 2/3 SU V2 juga tersedia dengan menggunakan satu simpul streaming, tetapi hanya dengan sebagian sumber daya komputasi. Pekerjaan SU V2 1/3 dan 2/3 menyediakan opsi hemat biaya untuk beban kerja yang membutuhkan skala yang lebih kecil.

Tabel berikut ini memperlihatkan daya komputasi yang mendasar untuk unit streaming V1 dan V2:

Untuk informasi tentang harga SU, kunjungi Halaman Harga Azure Stream Analytics.

Memahami konversi unit streaming dan di mana mereka menerapkannya

Sistem secara otomatis mengonversi unit streaming dari lapisan REST API ke UI (portal Microsoft Azure dan Visual Studio Code). Anda juga melihat konversi ini di log Aktivitas , di mana nilai unit streaming muncul berbeda dari nilai di UI. Perilaku ini dirancang. Bidang REST API terbatas pada nilai bilangan bulat, tetapi pekerjaan Stream Analytics mendukung simpul pecahan (unit streaming 1/3 dan 2/3). Antarmuka pengguna Azure Stream Analytics menampilkan nilai simpul sebagai 1/3, 2/3, 1, 2, 3, dan seterusnya, sementara backend (log aktivitas, lapisan REST API) menampilkan nilai yang sama dikalikan dengan 10 dengan masing-masing 3, 7, 10, 20, dan 30.

Standard	Standar V2 (UI)	V2 Standar (Backend seperti log, REST API, dll.)
1	1/3	3
3	2/3	7
6	1	10
12	2	20
18	3	30
...	...	...

Konversi ini menyampaikan granularitas yang sama dan menghilangkan titik desimal pada lapisan API untuk Unit Penyimpanan Saham (SKU) V2. Konversi ini bersifat otomatis dan tidak berdampak pada performa pekerjaan Anda.

Memahami penggunaan konsumsi dan memori

Untuk mencapai pemrosesan aliran latensi rendah, pekerjaan Azure Stream Analytics melakukan semua pemrosesan dalam memori. Ketika proses kehabisan memori, pekerjaan streaming gagal. Akibatnya, untuk pekerjaan produksi, penting untuk memantau penggunaan sumber daya pekerjaan streaming, dan memastikan ada cukup sumber daya yang dialokasikan untuk menjaga pekerjaan tetap berjalan 24/7.

Metrik pemanfaatan SU%, yang berkisar antara 0% hingga 100%, menjelaskan konsumsi memori beban kerja Anda. Untuk pekerjaan streaming dengan jejak minimal, metrik ini biasanya antara 10% hingga 20%. Jika pemanfaatan SU% tinggi (di atas 80%), atau jika peristiwa input tertunda (meskipun dengan pemanfaatan SU% yang rendah karena tidak menunjukkan penggunaan CPU), beban kerja Anda kemungkinan memerlukan lebih banyak sumber daya komputasi, yang memerlukan Anda untuk meningkatkan jumlah unit streaming. Sebaiknya jaga metrik SU di bawah 80% untuk memperhitungkan lonjakan sesekali. Untuk bereaksi terhadap peningkatan beban kerja dan meningkatkan unit streaming, pertimbangkan untuk mengatur peringatan 80% pada metrik Pemanfaatan SU. Selain itu, Anda dapat menggunakan metrik penundaan watermark dan peristiwa tertunda untuk melihat apakah ada dampaknya.

Mengonfigurasi unit streaming (SU) Azure Stream Analytics

Masuk ke portal Microsoft Azure.
Dalam daftar sumber daya, temukan tugas Stream Analytics yang ingin Anda skalakan lalu buka.
Di halaman tugas, di bawah judul Konfigurasi, pilih Skalakan. Jumlah default SU adalah 1 saat membuat pekerjaan.

Pilih opsi SU di daftar drop-down untuk mengatur SU untuk pekerjaan tersebut. Anda terbatas pada rentang SU tertentu.
Anda dapat mengubah jumlah SU yang ditetapkan ke pekerjaan Anda selama proses berjalan. Anda mungkin dibatasi untuk memilih dari sekumpulan nilai SU saat pekerjaan berjalan jika pekerjaan Anda menggunakan output yang tidak dipartisi atau memiliki kueri multi-langkah dengan nilai PARTITION BY yang berbeda.

Memantau performa pekerjaan

Dengan menggunakan portal Microsoft Azure, Anda dapat melacak metrik pekerjaan terkait performa. Untuk informasi selengkapnya tentang definisi metrik, lihat Metrik pekerjaan Azure Stream Analytics. Untuk informasi selengkapnya tentang pemantauan metrik di portal, lihat Memantau pekerjaan Azure Stream Analytics dengan portal Microsoft Azure.

Menghitung throughput yang diharapkan dari beban kerja. Jika throughput kurang dari yang diharapkan, sesuaikan partisi input, optimalkan kueri, dan tambahkan Unit Streaming (SU) ke pekerjaan Anda.

Berapa banyak SU yang diperlukan untuk pekerjaan?

Jumlah SU yang diperlukan bergantung pada konfigurasi partisi untuk input dan kueri yang Anda tentukan dalam pekerjaan. Halaman Skalakan memungkinkan Anda untuk mengatur jumlah SU yang tepat. Alokasikan lebih banyak SU daripada yang Anda butuhkan. Mesin pemrosesan Stream Analytics mengoptimalkan latensi dan throughput dengan mengorbankan alokasi memori tambahan.

Secara umum, mulailah dengan 1 SU V2 untuk kueri yang tidak menggunakan PARTITION BY. Kemudian temukan angka terbaik berdasarkan percobaan dan kesalahan. Ubah jumlah SU setelah Anda memproses jumlah data yang memadai dan periksa metrik Penggunaan SU%. Jumlah maksimum unit streaming yang dapat digunakan pekerjaan Azure Stream Analytics bergantung pada jumlah langkah dalam kueri yang ditentukan untuk pekerjaan dan jumlah partisi di setiap langkah. Anda dapat mempelajari lebih lanjut tentang batasan di sini.

Untuk informasi selengkapnya tentang memilih jumlah SU yang tepat, lihat Menskalakan pekerjaan Azure Stream Analytics untuk meningkatkan throughput.

Catatan

Jumlah SU yang dibutuhkan pekerjaan bergantung pada konfigurasi partisi untuk input dan pada kueri yang Anda tentukan untuk pekerjaan tersebut. Anda dapat memilih hingga kuota dalam SU untuk sebuah pekerjaan. Untuk informasi tentang kuota langganan Azure Stream Analytics, kunjungi batas Azure Stream Analytics. Untuk menambah SU langganan Anda di luar kuota ini, hubungi Dukungan Microsoft. Nilai yang valid untuk SU per pekerjaan adalah 1/3, 2/3, 1, 2, 3, dan sebagainya.

Faktor-faktor yang meningkatkan pemanfaatan persentase SU%

Elemen kueri Temporal (berorientasi waktu) adalah kumpulan inti operator berstatus yang disediakan Stream Analytics. Azure Stream Analytics mengelola status operasi ini secara internal atas nama Anda. Ini mengelola konsumsi memori, titik pemeriksaan untuk ketahanan, dan pemulihan status selama peningkatan layanan. Meskipun Azure Stream Analytics sepenuhnya mengelola status, pertimbangkan banyak rekomendasi praktik terbaik.

Pekerjaan dengan logika kueri yang kompleks dapat memiliki pemanfaatan SU % yang tinggi bahkan ketika tidak terus menerima peristiwa input. Ini dapat terjadi setelah lonjakan mendadak dalam peristiwa input dan output. Tugas tersebut mungkin akan terus mempertahankan status dalam memori jika kuerinya kompleks.

Kesalahan sementara atau peningkatan yang dimulai sistem dapat menyebabkan pemanfaatan SU% tiba-tiba turun ke 0 untuk waktu yang singkat sebelum kembali ke tingkat yang diharapkan. Meningkatkan jumlah unit streaming untuk pekerjaan mungkin tidak mengurangi Pemanfaatan SU% jika kueri Anda tidak sepenuhnya paralel.

Saat Anda membandingkan pemanfaatan selama jangka waktu tertentu, gunakan metrik tingkat peristiwa. Metrik InputEvents dan OutputEvents menunjukkan berapa banyak peristiwa yang dibaca dan diproses. Metrik seperti kesalahan deserialisasi menunjukkan jumlah peristiwa kesalahan. Ketika jumlah peristiwa per unit waktu meningkat, SU% meningkat dalam banyak kasus.

Logika kueri berstatus dalam elemen temporal

Salah satu kemampuan unik dari tugas Azure Stream Analytics adalah pemrosesan berbasis status, seperti agregat berjendela, penggabungan temporal, dan fungsi analitik temporal. Masing-masing operator ini menyimpan informasi status. 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 geser
Gabungan temporal: JOIN dengan fungsi DATEDIFF
Fungsi analitik temporal: ISFIRST, LAST, dan LAG dengan LIMIT DURATION

Faktor-faktor berikut memengaruhi memori yang digunakan (bagian dari metrik unit streaming) oleh pekerjaan Stream Analytics:

Agregat Jendela

Memori yang digunakan (ukuran status) untuk agregat berjendela tidak selalu sebanding secara langsung dengan ukuran jendela. Sebaliknya, memori yang digunakan sebanding dengan kardinalitas data, atau jumlah grup di setiap jendela waktu.

Misalnya, dalam kueri berikut, angka yang terkait dengan clusterid adalah kardinalitas kueri.

SELECT count(*)
FROM input 
GROUP BY  clusterid, tumblingwindow (minutes, 5)

Untuk mengurangi masalah yang disebabkan oleh kardinalitas tinggi dalam kueri sebelumnya, kirim event ke Azure Event Hubs yang dipartisi oleh clusterid. Skalakan kueri dengan memungkinkan sistem memproses setiap partisi input secara terpisah dengan menggunakan PARTITION BY seperti yang ditunjukkan dalam contoh berikut:

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

Setelah kueri dipartisi, kueri tersebut tersebar ke beberapa node. Akibatnya, jumlah clusterid nilai yang masuk ke setiap simpul berkurang, yang mengurangi kardinalitas GROUP BY operator.

Partisi Event Hubs dengan kunci pengelompokan untuk menghindari kebutuhan akan langkah pengurangan. Untuk informasi selengkapnya, lihat gambaran umum Event Hubs.

Penggabungan Temporal

Memori yang dikonsumsi (ukuran status) oleh gabungan temporal sebanding dengan jumlah peristiwa dalam kelonggaran waktu temporal dari gabungan tersebut. Angka ini sama dengan laju input peristiwa yang dikalikan dengan ukuran ruang wiggle. Dengan kata lain, memori yang digunakan oleh join sebanding dengan rentang waktu DateDiff dikalikan dengan tingkat rata-rata kejadian.

Jumlah peristiwa yang tidak cocok dalam gabungan memengaruhi pemanfaatan memori untuk kueri. Kueri berikut mencari tayangan iklan yang menghasilkan klik:

SELECT clicks.id
FROM clicks 
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.

Dalam contoh ini, kemungkinan besar banyak iklan ditampilkan dan hanya beberapa orang yang mengkliknya. Anda perlu menyimpan semua peristiwa di jendela waktu. Memori yang digunakan sebanding dengan ukuran jendela dan laju peristiwa.

Untuk mengatasi perilaku ini, kirim peristiwa ke Event Hubs yang dipartisi oleh kunci gabungan (ID dalam hal ini), dan skalakan kueri dengan memungkinkan sistem memproses setiap partisi input secara terpisah menggunakan PARTITION BY seperti yang ditunjukkan.

SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId 
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10

Setelah Anda mempartisi kueri, Anda menyebarkannya ke beberapa simpul. Akibatnya, Anda mengurangi jumlah peristiwa yang masuk ke setiap simpul dan mengurangi ukuran status yang disimpan di jendela gabungan.

Fungsi analitik temporal

Memori yang digunakan (ukuran status) oleh fungsi analitik temporal sebanding dengan tingkat peristiwa yang dikalikan dengan durasi. Memori yang digunakan oleh fungsi analitik tidak sebanding dengan ukuran jendela, tetapi lebih ke jumlah partisi di setiap jendela waktu.

Proses remediasinya mirip dengan temporal join. Anda dapat menskalakan kueri dengan menggunakan PARTITION BY.

Buffer tidak teratur

Anda dapat mengonfigurasi ukuran buffer keluar dari urutan di panel konfigurasi Pengurutan Peristiwa. Buffer menampung input selama durasi jendela waktu dan menyusunnya ulang. Ukuran buffer sebanding dengan laju input peristiwa yang dikalikan dengan ukuran jendela yang tidak berurutan. Ukuran jendela default adalah 0.

Untuk memulihkan overflow dari buffer yang rusak, skalakan kueri menggunakan PARTITION BY. Setelah kueri dipartisi, kueri tersebut disebar di beberapa node. Akibatnya, jumlah peristiwa yang masuk ke setiap simpul berkurang, sehingga mengurangi jumlah peristiwa dalam setiap buffer penataan ulang.

Jumlah partisi input

Setiap partisi input pekerjaan memiliki buffer. Semakin besar jumlah partisi input, semakin banyak sumber daya yang digunakan pekerjaan. Untuk setiap unit streaming, Azure Stream Analytics dapat memproses sekitar 7 MB/dtk input. Oleh karena itu, Anda dapat mengoptimalkan dengan mencocokkan jumlah unit streaming Stream Analytics dengan jumlah partisi di Event Hub Anda.

Biasanya, sebuah pekerjaan yang dikonfigurasi dengan sepertiga unit streaming cukup untuk sebuah event hub dengan dua partisi (yang merupakan minimum untuk event hub). Jika event hub memiliki lebih banyak partisi, pekerjaan Stream Analytics Anda menggunakan lebih banyak sumber daya, tetapi tidak selalu menggunakan throughput tambahan yang disediakan oleh Event Hubs.

Untuk pekerjaan dengan satu unit streaming V2, mungkin diperlukan 4 atau 8 partisi dari Event Hub. Namun, hindari terlalu banyak partisi yang tidak perlu karena menyebabkan penggunaan sumber daya yang berlebihan. Misalnya, event hub dengan 16 partisi atau lebih besar dalam tugas Stream Analytics yang memiliki 1 unit streaming.

Data referensi

Azure Stream Analytics memuat data referensi ke dalam memori untuk pencarian cepat. Dengan implementasi saat ini, setiap operasi gabungan dengan data referensi menyimpan salinan data referensi dalam memori, bahkan jika Anda bergabung dengan data referensi yang sama beberapa kali. Untuk kueri dengan PARTITION BY, setiap partisi memiliki salinan data referensi, sehingga partisi sepenuhnya dipisahkan. Dengan efek pengganda, penggunaan memori dapat dengan cepat menjadi sangat tinggi jika Anda menggabungkan data referensi beberapa kali dengan berbagai partisi.

Penggunaan fungsi UDF

Saat Anda menambahkan fungsi UDF, Azure Stream Analytics memuat runtime JavaScript ke dalam memori, yang memengaruhi SU%.

Langkah berikutnya

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-02-20