Menskalakan pekerjaan Azure Stream Analytics untuk meningkatkan throughput

  • Artikel

Artikel ini memperlihatkan kepada Anda cara menyetel kueri Azure Stream Analytics untuk meningkatkan throughput pekerjaan Analisis Aliran. Anda dapat menggunakan panduan berikut untuk menskalakan pekerjaan Anda untuk menangani beban yang lebih tinggi dan memanfaatkan lebih banyak sumber daya sistem (seperti lebih banyak bandwidth, lebih banyak sumber daya CPU, lebih banyak memori).

Sebagai prasyarat, baca artikel berikut:

Kasus 1 - Kueri Anda secara inheren sepenuhnya dapat diparalelkan di seluruh partisi input

Jika kueri Anda secara inheren sepenuhnya dapat diparalelkan di seluruh partisi input, Anda dapat mengikuti langkah-langkah berikut:

  • Tulis kueri Anda agar benar-benar paralel dengan menggunakan kata kunci PARTISI BERDASARKAN. Untuk informasi selengkapnya, lihat Menggunakan paralelisasi kueri di Azure Stream Analytics.
  • Bergantung pada jenis output yang digunakan dalam kueri Anda, beberapa output dapat tidak dapat diparalelkan, atau memerlukan konfigurasi lebih lanjut untuk menjadi paralel yang memalukan. Misalnya, output Power BI tidak dapat diparalelkan. Output selalu digabungkan sebelum dikirim ke sink output. Blob, Tabel, Azure Data Lake Storage, Bus Layanan, dan Azure Function secara otomatis diparalelkan. Output SQL dan Azure Synapse Analytics memiliki opsi untuk paralelisasi. Hub peristiwa harus mengatur konfigurasi PartitionKey agar sesuai dengan bidang PARTITION BY (biasanya PartitionId). Untuk Azure Event Hubs, perhatikan juga untuk mencocokkan jumlah partisi untuk semua input dan semua output untuk menghindari cross-over antar partisi.
  • Jalankan kueri Anda dengan 1 unit streaming (SU) V2 (yang merupakan kapasitas penuh dari satu simpul komputasi) untuk mengukur throughput maksimum yang dapat dicapai, dan jika Anda menggunakan GROUP BY, ukur berapa banyak grup (kardinalitas) yang dapat ditangani pekerjaan. Gejala umum pekerjaan yang telah mencapai batas sumber daya sistem adalah sebagai berikut.
    • Metrik pemanfaatan Unit Aliran (SU) % lebih dari 80%. Ini menunjukkan penggunaan memori tinggi. Faktor-faktor yang berkontribusi pada peningkatan metrik ini dijelaskan Memahami dan menyesuaikan unit streaming Azure Stream Analytics.
    • Tanda waktu output tertinggal sehubungan dengan waktu jam dinding. Bergantung pada logika kueri Anda, tanda waktu output dapat memiliki offset logika dari waktu jam dinding. Namun, mereka harus maju pada laju yang kira-kira sama. Jika tanda waktu output jatuh lebih jauh dan lebih jauh di belakang, itu adalah indikator bahwa sistem terlalu banyak bekerja. Ini bisa menjadi hasil dari pembatasan sink output hilir, atau pemakaian CPU yang tinggi. Kami tidak menyediakan metrik pemakaian CPU saat ini, sehingga sulit untuk membedakan keduanya.
      • Jika masalahnya disebabkan oleh pembatasan sink, Anda perlu meningkatkan jumlah partisi output (dan juga partisi input untuk menjaga pekerjaan tetap dapat diparalelkan sepenuhnya), atau meningkatkan jumlah sumber daya sink (misalnya jumlah Unit Permintaan untuk Cosmos DB).
    • Dalam diagram pekerjaan, ada metrik peristiwa backlog per partisi untuk setiap input. Jika metrik peristiwa backlog terus meningkat, itu juga merupakan indikator bahwa sumber daya sistem dibatasi (baik karena pembatasan sink output, atau CPU tinggi).
  • Setelah Anda menentukan batas apa yang dapat dicapai oleh satu pekerjaan SU V2, Anda dapat mengekstrapolasi secara linier kapasitas pemrosesan pekerjaan saat Anda menambahkan lebih banyak SU, dengan asumsi Anda tidak memiliki kemiringan data apa pun yang membuat partisi tertentu "panas."

Catatan

Pilih jumlah unit streaming yang tepat: Karena Azure Stream Analytics membuat simpul pemrosesan untuk setiap 1 SU V2 yang ditambahkan, yang terbaik adalah menjadikan jumlah simpul sebagai pembagi jumlah partisi input, sehingga partisi dapat didistribusikan secara merata di seluruh simpul. Misalnya, Anda telah mengukur 1 pekerjaan SU V2 Anda dapat mencapai tingkat pemrosesan 4 MB/dtk, dan jumlah partisi input Anda adalah 4. Anda dapat memilih untuk menjalankan pekerjaan Anda dengan 2 SU V2 untuk mencapai tingkat pemrosesan sekitar 8 MB/dtk, atau 4 SU V2 untuk mencapai 16 MB/dtk. Anda kemudian dapat memutuskan kapan harus menambah nomor SU untuk pekerjaan ke nilai apa, sebagai fungsi dari kecepatan input Anda.

Kasus 2 - Jika kueri Anda tidak paralel secara memalukan.

Jika kueri Anda tidak paralel secara memalukan, Anda bisa mengikuti langkah-langkah ini.

  • Mulailah dengan kueri tanpa PARTITION BY terlebih dahulu untuk menghindari kompleksitas partisi, dan jalankan kueri Anda dengan 1 SU V2 untuk mengukur beban maksimum seperti pada Kasus 1.
  • Jika Anda dapat mencapai beban yang diantisipasi dalam jangka waktu throughput, Anda sudah selesai. Atau, Anda dapat memilih untuk mengukur pekerjaan yang sama yang berjalan dengan simpul pecahan pada 2/3 SU V2 dan 1/3 SU V2, untuk mengetahui jumlah minimum unit streaming yang berfungsi untuk skenario Anda.
  • Jika Anda tidak dapat mencapai throughput yang diinginkan, coba pecahkan kueri Anda menjadi beberapa langkah jika belum memiliki beberapa langkah, dan alokasikan hingga satu SU V2 untuk setiap langkah dalam kueri. Misalnya jika Anda memiliki tiga langkah, alokasikan tiga SU V2 dalam opsi "Skala".
  • Untuk menjalankan pekerjaan seperti itu, Stream Analytics menempatkan setiap langkah pada simpulnya sendiri dengan satu sumber daya SU V2 khusus.
  • Jika Anda masih belum mencapai target beban, Anda dapat mencoba menggunakan PARTISI BERDASARKAN dimulai dari langkah-langkah yang lebih dekat ke input. Untuk operator GROUP BY yang tidak dapat dipartisi secara alami, Anda dapat menggunakan pola agregat lokal/global untuk melakukan GROUP BY yang dipartisi diikuti oleh GROUP BY yang tidak dipartisi. Misalnya, jika Anda ingin menghitung berapa banyak mobil yang melalui setiap pintu tol setiap 3 menit, dan volume data berada di luar apa yang dapat ditangani oleh satu SU V2.

Kueri:

WITH Step1 AS (
SELECT COUNT(*) AS Count, TollBoothId, PartitionId
FROM Input1 Partition By PartitionId
GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
)
SELECT SUM(Count) AS Count, TollBoothId
FROM Step1
GROUP BY TumblingWindow(minute, 3), TollBoothId

Dalam kueri, Anda menghitung mobil per pintu tol per partisi, lalu menambahkan jumlah dari semua partisi bersama-sama.

Setelah dipartisi, untuk setiap partisi langkah, alokasikan satu SU V2 sehingga setiap partisi dapat ditempatkan pada node pemrosesannya sendiri.

Catatan

Jika kueri Anda tidak dapat dipartisi, menambahkan SU tambahan dalam kueri multi-langkah bisa jadi tidak selalu meningkatkan throughput. Salah satu cara untuk mendapatkan performa adalah dengan mengurangi volume pada langkah-langkah awal menggunakan pola agregat lokal/global, seperti yang dijelaskan pada langkah 5.

Kasus 3 - Anda menjalankan banyak kueri independen dalam pekerjaan.

Untuk kasus penggunaan ISV tertentu, di mana lebih hemat biaya untuk memproses data dari beberapa penyewa dalam satu pekerjaan, menggunakan input dan output terpisah untuk setiap penyewa, Anda akhirnya menjalankan beberapa kueri independen (misalnya 20) dalam satu pekerjaan. Asumsinya adalah setiap beban kueri bertumpuk tersebut relatif kecil.

Dalam hal ini, Anda dapat mengikuti langkah-langkah ini.

  • Dalam hal ini, jangan gunakan PARTITION BY dalam kueri
  • Kurangi jumlah partisi input ke nilai 2 semurah mungkin jika Anda menggunakan Azure Event Hubs.
  • Jalankan kueri dengan satu SU V2. Dengan beban yang diharapkan untuk setiap kueri bertumpuk, tambahkan sebanyak mungkin kueri bertumpuk tersebut, sampai pekerjaan mencapai batas sumber daya sistem. Lihat Kasus 1 untuk gejala ketika itu terjadi.
  • Setelah Anda mencapai batas subkueri yang diukur, mulai tambahkan subkueri ke pekerjaan baru. Jumlah pekerjaan yang akan dijalankan sebagai fungsi dari jumlah kueri independen harus cukup linier, dengan asumsi Anda tidak memiliki penyimpangan beban. Anda kemudian dapat memperkirakan berapa banyak pekerjaan SU V2 yang perlu Anda jalankan sebagai fungsi dari jumlah penyewa yang ingin Anda layani.
  • Saat menggunakan data referensi bersama dengan kueri tersebut, satukan input bersama-sama sebelum bergabung dengan data referensi yang sama. Kemudian, bagilah peristiwa jika perlu. Jika tidak, setiap gabungan data referensi menyimpan salinan data referensi dalam memori, kemungkinan meledakkan penggunaan memori secara tidak perlu.

Catatan

Berapa banyak penyewa yang dimasukkan ke dalam setiap pekerjaan? Pola kueri ini sering memiliki sejumlah besar kueri bertumpuk, dan menghasilkan topologi yang sangat besar dan kompleks. Pengontrol pekerjaan mungkin tidak dapat menangani topologi yang begitu besar. Sebagai aturan praktis, tetap di bawah 40 penyewa untuk pekerjaan 1/3 SU V2, dan 60 penyewa untuk pekerjaan 2/3 dan 1 SU V2. Ketika Anda melebihi kapasitas pengontrol, pekerjaan tidak akan berhasil dimulai.

Dapatkan bantuan

Untuk bantuan lebih lanjut, coba halaman pertanyaan Microsoft Q&A untuk Azure Stream Analytics.

Langkah berikutnya