Menskalakan pekerjaan Azure Stream Analytics untuk meningkatkan throughput

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, Anda mungkin perlu membaca 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:

  1. Tulis kueri Anda agar benar-benar paralel dengan menggunakan kata kunci PARTISI BERDASARKAN. Lihat detail selengkapnya di bagian Pekerjaan yang benar2 paralel di halaman ini.
  2. Bergantung pada tipe output yang digunakan dalam kueri Anda, beberapa output mungkin tidak dapat diparalelkan, atau perlu konfigurasi lebih lanjut agar sangat paralel. Misalnya, output PowerBI tidak dapat diparalelkan. Output selalu digabungkan sebelum dikirim ke sink output. Blob, Tabel, ADLS, Bus Layanan, dan Fungsi Azure secara otomatis diparalelkan. Output SQL dan Azure Synapse Analytics memiliki opsi untuk paralelisasi. Event Hub harus mengatur konfigurasi PartitionKey agar sesuai dengan bidang PARTISI BERDASARKAN (biasanya PartitionId). Untuk Event Hub, perhatikan juga pencocokan jumlah partisi untuk semua input dan semua output untuk menghindari penyebrangan antar partisi.
  3. Jalankan kueri Anda dengan 6 SU (yang merupakan kapasitas penuh dari satu simpul komputasi) untuk mengukur throughput maksimum yang dapat dicapai, dan jika Anda menggunakan GRUP BERDASARKAN, ukur berapa banyak grup (kardinalitas) yang dapat ditangani pekerjaan. Gejala umum pekerjaan yang telah mencapai batas sumber daya sistem adalah sebagai berikut.
    • Metrik pemakaian SU % lebih dari 80%. Ini menunjukkan penggunaan memori tinggi. Faktor-faktor yang berkontribusi pada peningkatan metrik ini dijelaskan di sini.
    • Tanda waktu output tertinggal sehubungan dengan waktu jam dinding. Bergantung pada logika kueri Anda, tanda waktu output mungkin 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 masalah ini disebabkan oleh pembatasan sink, Anda mungkin perlu meningkatkan jumlah partisi output (dan juga partisi input untuk menjaga pekerjaan sepenuhnya dapat diparalelkan), atau meningkatkan jumlah sumber daya sink (misalnya jumlah Unit Permintaan untuk CosmosDB).
    • 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).
  4. Setelah Anda menentukan batas apa yang dapat dijangkau oleh pekerjaan SU 6, Anda dapat mengekstrapolasi kapasitas pemrosesan pekerjaan secara linier saat Anda menambahkan lebih banyak SUs, dengan asumsi Anda tidak memiliki penyimpangan data yang membuat partisi tertentu "panas."

Catatan

Pilih jumlah Unit Streaming yang tepat: Karena Azure Stream Analytics membuat simpul pemrosesan untuk setiap 6 SU 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 pekerjaan 6 SU Anda dapat mencapai tingkat pemrosesan 4 MB/s, dan jumlah partisi input Anda adalah 4. Anda dapat memilih menjalankan pekerjaan Anda dengan 12 SU untuk mencapai sekitar 8 MB/s tingkat pemrosesan, atau 24 SU untuk mencapai 16 MB/s. 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 benar-benar paralel.

Jika kueri Anda tidak benar-benar paralel, Anda bisa mengikuti langkah-langkah berikut.

  1. Mulailah dengan kueri tanpa PARTISI BERDASARKAN terlebih dahulu untuk menghindari kompleksitas partisi, dan jalankan kueri Anda dengan 6 SU untuk mengukur beban maksimum seperti dalam Kasus 1.
  2. Jika Anda dapat mencapai beban yang diantisipasi dalam hal throughput, Anda sudah selesai. Atau, Anda dapat memilih untuk mengukur pekerjaan yang sama yang berjalan pada 3 SU dan 1 SU, untuk mengetahui jumlah minimum SU yang berfungsi untuk skenario Anda.
  3. Jika Anda tidak dapat mencapai throughput yang diinginkan, cobalah untuk memecah kueri Anda menjadi beberapa langkah jika memungkinkan, jika belum memiliki beberapa langkah, dan alokasikan hingga 6 SU untuk setiap langkah dalam kueri. Misalnya jika Anda memiliki 3 langkah, alokasikan 18 SU di opsi "Skala".
  4. Saat menjalankan pekerjaan seperti itu, Azure Stream Analytics menempatkan setiap langkah pada simpulnya sendiri dengan sumber daya SU 6 khusus.
  5. Jika Anda masih belum mencapai target beban, Anda dapat mencoba menggunakan PARTISI BERDASARKAN dimulai dari langkah-langkah yang lebih dekat ke input. Untuk operator GRUP BERDASARKAN yang mungkin tidak dapat dipartisi secara alami, Anda dapat menggunakan pola agregat lokal/global untuk melakukan yang dipartisi GRUP BERDASARKAN diikuti oleh GRUP BERDASARKAN non-partisi. Misalnya, jika Anda ingin menghitung berapa banyak mobil yang melalui setiap pintu tol setiap 3 menit, dan volume data tidak dapat dihandel oleh 6 SU.

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 di atas, Anda menghitung mobil per pintu tol per partisi, dan kemudian menambahkan hitungan dari semua partisi bersama-sama.

Setelah dipartisi, untuk setiap partisi langkah, alokasikan hingga 6 SU, setiap partisi yang memiliki 6 SU adalah maksimum, sehingga setiap partisi dapat ditempatkan pada simpul 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 di atas 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 mungkin akhirnya menjalankan hanya beberapa (misalnya 20) kueri independen dalam satu pekerjaan. Asumsinya adalah setiap beban kueri bertumpuk tersebut relatif kecil. Dalam hal ini, Anda dapat mengikuti langkah-langkah berikut.

  1. Dalam hal ini, jangan gunakan PARTISI BERDASARKAN dalam kueri
  2. Kurangi jumlah partisi input ke nilai serendah-rendahnya 2 jika Anda menggunakan Hub Peristiwa.
  3. Jalankan kueri dengan 6 SU. 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 ini terjadi.
  4. Setelah Anda mencapai batas kueri bertumpukyang diukur di atas, mulai tambahkan kueri bertumpuk 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 6 SU yang perlu Anda jalankan sebagai fungsi dari jumlah penyewa yang ingin Anda layani.
  5. 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, tinggal di bawah 40 penyewa untuk pekerjaan 1 SU, dan 60 penyewa untuk 3 su dan pekerjaan 6 SU. 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 kami.

Langkah berikutnya