Menggunakan paralelisasi kueri di Azure Stream Analytics

Artikel ini memperlihatkan kepada Anda cara memanfaatkan paralelisasi di Azure Stream Analytics. Anda mempelajari cara menskalakan pekerjaan Azure Stream Analytics dengan mengonfigurasi partisi input dan menyetel definisi kueri analitik.

Sebagai prasyarat, Anda mungkin ingin terbiasa dengan gagasan unit streaming yang dijelaskan dalam Memahami dan menyesuaikan unit streaming.

Apa saja bagian dari pekerjaan Stream Analytics?

Definisi pekerjaan Azure Stream Analytics mencakup setidaknya satu input streaming, kueri, dan output. Input adalah tempat pekerjaan membaca aliran data. Kueri digunakan untuk mengubah aliran input data, dan output adalah tempat pekerjaan mengirim hasil pekerjaan.

Partisi pada input dan output

Partisi memungkinkan Anda membagi data menjadi subset berdasarkan kunci partisi. Jika input Anda (misalnya Event Hubs) dipartisi oleh kunci, kami sarankan Anda menentukan kunci partisi saat menambahkan input ke pekerjaan Azure Stream Analytics Anda. Menskalakan pekerjaan di Azure Stream Analytics memanfaatkan partisi dalam input dan output. Pekerjaan Stream Analytics dapat mengonsumsi dan menulis partisi yang berbeda secara paralel, yang meningkatkan throughput.

Input

Semua input streaming Azure Stream Analytics dapat memanfaatkan partisi: Event Hubs, IoT Hub, penyimpanan Blob, Data Lake Storage Gen2.

Catatan

Untuk tingkat kompatibilitas 1.2 ke atas, atur kunci partisi sebagai properti input, tanpa perlu kata kunci PARTITION BY dalam kueri. Untuk tingkat kompatibilitas 1.1 ke bawah, tentukan kunci partisi dengan kata kunci PARTITION BY dalam kueri.

Output

Saat Anda bekerja dengan Stream Analytics, manfaatkan pemartisian dalam output berikut:

Azure Data Lake Storage
Azure Functions
Tabel Azure
Penyimpanan blob (atur kunci partisi secara eksplisit)
Azure Cosmos DB (atur kunci partisi secara eksplisit)
Event Hubs (atur kunci partisi secara eksplisit)
IoT Hub (atur kunci partisi secara eksplisit)
Bus Layanan
SQL dan Azure Synapse Analytics dengan partisi opsional: lihat informasi selengkapnya tentang halaman Output ke Azure SQL Database.

Power BI tidak mendukung partisi. Namun, Anda masih dapat mempartisi input seperti yang dijelaskan di bagian ini.

Untuk informasi selengkapnya tentang partisi, lihat artikel berikut ini:

Kueri

Agar pekerjaan menjadi paralel, kunci partisi perlu diselaraskan di antara semua input, semua langkah logika kueri, dan semua output. Pemartisian logika kueri ditentukan oleh kunci yang digunakan untuk gabungan dan agregasi (GROUP BY). Persyaratan terakhir dapat diabaikan jika logika kueri tidak dikunci (proyeksi, filter, gabungan referensial...).

Jika input dan output dipartisi oleh WarehouseId, dan grup kueri dengan ProductId tanpa WarehouseId, pekerjaan tidak paralel.
Jika dua input yang akan digabungkan dipartisi oleh kunci partisi yang berbeda (WarehouseId dan ProductId), pekerjaan tidak paralel.
Jika satu pekerjaan berisi dua atau lebih aliran data independen, masing-masing dengan kunci partisinya sendiri, pekerjaan tersebut tidak paralel.

Pekerjaan ini hanya dapat diparalelkan bila semua input, output, dan langkah kueri menggunakan kunci yang sama.

Pekerjaan paralel yang memalukan

Pekerjaan paralel yang memalukan adalah skenario yang paling dapat diskalakan di Azure Stream Analytics. Ini menghubungkan satu partisi input ke satu instans kueri ke satu partisi output. Paralelisme ini memiliki persyaratan berikut:

Jika logika kueri Anda bergantung pada kunci yang sama yang sedang diproses oleh instans kueri yang sama, Anda harus memastikan bahwa peristiwa masuk ke partisi input yang sama. Untuk Event Hubs atau IoT Hub, itu berarti bahwa data peristiwa harus memiliki nilai PartitionKey yang ditetapkan. Atau, Anda dapat menggunakan pengirim yang dipartisi. Untuk penyimpanan blob, yang berarti bahwa peristiwa dikirim ke folder partisi yang sama. Contohnya adalah kueri yang mengagregasikan data berdasarkan userID dengan event hub input dipartisi menggunakan userID sebagai kunci partisi. Namun, jika logika kueri Anda tidak memerlukan kunci yang sama untuk diproses oleh instans kueri yang sama, Anda dapat mengabaikan persyaratan ini. Contoh logika ini akan menjadi kueri select-project-filter sederhana.
Selanjutnya, buat kueri Anda terpartisi. Untuk pekerjaan dengan tingkat kompatibilitas 1.2 atau lebih tinggi (disarankan), tentukan kolom kustom sebagai Kunci Partisi dalam pengaturan input dan pekerjaan akan diparalelkan secara otomatis. Untuk pekerjaan dengan tingkat kompatibilitas 1.0 atau 1.1, gunakan PARTITION BY PartitionId di semua langkah kueri Anda. Anda dapat memiliki beberapa langkah, tetapi semuanya harus dipartisi oleh kunci yang sama.
Sebagian besar output yang didukung di Azure Stream Analytics dapat memanfaatkan partisi. Jika Anda menggunakan jenis output yang tidak mendukung partisi, pekerjaan Anda tidak paralel secara memalukan. Pastikan kolom kunci Partisi diatur ke kunci partisi yang sama yang digunakan dalam kueri untuk output Event Hub. Untuk informasi selengkapnya, lihat bagian keluaran.
Jumlah partisi input harus sama dengan jumlah partisi output. Output penyimpanan blob dapat mendukung partisi dan mewarisi skema partisi dari kueri upstream. Saat Anda menentukan kunci partisi untuk penyimpanan Blob, data dipartisi per partisi input sehingga hasilnya masih sepenuhnya paralel. Berikut adalah contoh nilai partisi yang memungkinkan pekerjaan yang sepenuhnya paralel:
- Delapan partisi input event hub dan delapan partisi output event hub
- Delapan partisi input event hub dan output penyimpanan blob
- Delapan partisi input event hub dan output penyimpanan blob yang dipartisi oleh bidang kustom dengan kardinalitas arbitrer
- Delapan partisi input penyimpanan blob dan output penyimpanan blob
- Delapan partisi input penyimpanan blob dan delapan partisi output event hub

Bagian berikut membahas beberapa contoh skenario paralel yang memalukan.

Kueri sederhana

Input: Pusat aktivitas dengan delapan partisi
Output: Pusat aktivitas dengan delapan partisi ("Kolom kunci partisi" harus diatur untuk menggunakan PartitionId)

Kueri:

    --Using compatibility level 1.2 or above
    SELECT TollBoothId
    FROM Input1
    WHERE TollBoothId > 100
    
    --Using compatibility level 1.0 or 1.1
    SELECT TollBoothId
    FROM Input1 PARTITION BY PartitionId
    WHERE TollBoothId > 100

Kueri ini adalah filter sederhana. Oleh karena itu, Anda tidak perlu khawatir tentang pemartisian input yang sedang dikirim ke pusat aktivitas. Perhatikan bahwa pekerjaan dengan tingkat kompatibilitas sebelum 1.2 harus menyertakan klausa PARTITION BY PartitionId, sehingga memenuhi persyaratan #2 dari sebelumnya. Untuk output, Anda perlu mengonfigurasi output event hub dalam tugas agar kunci partisi diatur ke PartitionId. Satu pemeriksaan terakhir adalah memastikan bahwa jumlah partisi input sama dengan jumlah partisi output.

Kueri dengan kunci pengelompokan

Input: Event hub dengan delapan partisi
Output: Penyimpanan Blob

Kueri:

    --Using compatibility level 1.2 or above
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId
    
    --Using compatibility level 1.0 or 1.1
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1 Partition By PartitionId
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

Kueri ini memiliki kunci pengelompokan. Oleh karena itu, acara yang dikelompokkan bersama harus dikirim ke partisi Azure Event Hubs yang sama. Karena dalam contoh ini Anda mengelompokkan menurut TollBoothID, Anda harus yakin bahwa TollBoothID digunakan sebagai kunci partisi saat peristiwa dikirim ke Azure Event Hubs. Kemudian di Azure Stream Analytics, Anda dapat menggunakan PARTITION BY PartitionId untuk mewarisi dari skema partisi ini dan mengaktifkan paralelisasi penuh. Karena outputnya adalah penyimpanan blob, Anda tidak perlu khawatir tentang mengonfigurasi nilai kunci partisi, sesuai persyaratan #4.

Contoh skenario yang tidak sepenuhnya paralel yang memalukan

Di bagian sebelumnya, artikel ini membahas beberapa skenario paralel yang memalukan. Di bagian ini, Anda mempelajari tentang skenario yang tidak memenuhi semua persyaratan untuk menjadi paralel yang memalukan.

Jumlah partisi yang tidak cocok

Input: Pusat aktivitas dengan delapan partisi
Output: Pusat aktivitas dengan 32 partisi

Jika jumlah partisi input tidak cocok dengan jumlah partisi output, topologi bukan paralel yang memalukan terlepas dari kueri. Namun, Anda masih bisa mendapatkan beberapa tingkat paralelisasi.

Kueri menggunakan output tidak terpartisi

Input: Pusat aktivitas dengan delapan partisi
Hasil: Power BI

Output Power BI saat ini tidak mendukung partisi. Karenanya, skenario ini bukan paralel yang memalukan.

Kueri multi-langkah dengan nilai PARTITION BY yang berbeda

Input: Event hub dengan delapan partisi
Output: Event hub dengan delapan partisi
Tingkat kompatibilitas: 1.0 atau 1.1

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 Partition By TollBoothId
    GROUP BY TumblingWindow(minute, 3), TollBoothId

Seperti yang Anda lihat, langkah kedua menggunakan TollBoothId sebagai kunci partisi. Langkah ini tidak sama dengan langkah pertama, dan karena itu memerlukan pengaturan ulang.

Kueri multi-langkah dengan nilai PARTITION BY yang berbeda

Input: Event hub dengan delapan partisi ("Kolom kunci partisi" tidak diatur, default ke "PartitionId")
Output: Event hub dengan delapan partisi ("Kolom kunci partisi" harus diatur untuk menggunakan "TollBoothId")
Tingkat kompatibilitas - 1.2 atau lebih tinggi

Kueri:

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

    SELECT SUM(Count) AS Count, TollBoothId
    FROM Step1
    GROUP BY TumblingWindow(minute, 3), TollBoothId

Tingkat kompatibilitas 1.2 atau lebih tinggi memungkinkan eksekusi kueri paralel secara default. Misalnya, kueri dari bagian sebelumnya dipartisi sepanjang kolom "TollBoothId" ditetapkan sebagai Kunci Partisi Input. Klausul PARTITION BY PartitionId tidak diperlukan.

Menghitung unit streaming maksimum dari sebuah tugas

Jumlah total unit streaming yang dapat digunakan pekerjaan Azure Stream Analytics bergantung pada jumlah langkah dalam kueri yang ditentukan untuk pekerjaan dan jumlah partisi untuk setiap langkah.

Langkah-langkah dalam kueri

Kueri bisa memiliki satu atau banyak langkah. Setiap langkah adalah subkueri yang ditentukan oleh kata kunci WITH. Kueri yang berada di luar kata kunci WITH (satu kueri saja) juga dihitung sebagai langkah, seperti pernyataan SELECT dalam kueri berikut ini:

Kueri:

    WITH Step1 AS (
        SELECT COUNT(*) AS Count, TollBoothId
        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

Kueri ini memiliki dua langkah.

Catatan

Kueri ini dibahas secara lebih rinci nanti di artikel.

Memisahkan langkah proses

Mempartisi langkah membutuhkan kondisi berikut:

Sumber input harus dipartisi.
Pernyataan SELECT kueri harus dibaca dari sumber input yang dipartisi.
Kueri dalam langkah harus memiliki kata kunci PARTITION BY.

Saat kueri dipartisi, peristiwa input diproses dan dikumpulkan dalam grup partisi terpisah, dan peristiwa output dihasilkan untuk setiap grup. Jika Anda menginginkan gabungan agregat, Anda harus membuat langkah kedua tanpa segmentasi untuk mengagregasi.

Menghitung unit streaming maksimum untuk proyek

Semua langkah yang tidak dipartisi bersama-sama meningkatkan skala hingga satu unit streaming (SU V2) untuk pekerjaan Azure Stream Analytics. Selain itu, Anda dapat menambahkan sebuah SU V2 untuk setiap partisi dalam langkah partisi. Anda dapat melihat beberapa contoh dalam tabel berikut.

Kueri	Max SUs untuk pekerjaan tersebut
Kueri berisi satu langkah. Langkah ini tidak dipartisi.	1 SU V2
Aliran data input dipartisi oleh 16. Kueri berisi satu langkah. Langkah ini dibagi dalam beberapa bagian.	16 SU V2 (1 * 16 partisi)
Kueri berisi dua langkah. Tidak satu pun dari langkah-langkah yang dipartisi.	1 SU V2
Aliran data input dipartisi oleh 3. Kueri berisi dua langkah. Langkah input dipartisi dan langkah kedua tidak. Perintah SELECT membaca dari input yang dipartisi.	4 SU V2 (3 untuk langkah yang dipartisi + 1 untuk langkah-langkah yang tidak dipartisi)

Contoh penskalaan

Kueri berikut menghitung jumlah mobil yang lewat dalam jangka waktu tiga menit melalui stasiun tol yang memiliki tiga gerbang tol. Anda dapat menskalakan kueri ini hingga satu SU V2.

    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

Untuk menggunakan lebih banyak SU untuk kueri, partisi aliran data input dan kueri. Karena partisi aliran data diatur ke 3, kueri yang dimodifikasi berikut dapat diskalakan hingga 3 SU V2:

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

Saat Anda mempartisi kueri, peristiwa input diproses dan diagregasi dalam grup partisi terpisah. Kueri menghasilkan peristiwa output untuk setiap grup. Partisi dapat menyebabkan beberapa hasil yang tidak terduga ketika bidang GROUP BY bukan kunci partisi dalam aliran data input. Misalnya, bidang TollBoothId di kueri sebelumnya bukan kunci partisi Input1. Hasilnya adalah bahwa data dari TollBooth #1 dapat tersebar di beberapa partisi.

Azure Stream Analytics memproses masing-masing partisi Input1 secara terpisah. Akibatnya, kueri membuat beberapa catatan jumlah mobil untuk gerbang tol yang sama dalam jendela bergulir yang sama. Jika Anda tidak dapat mengubah kunci partisi input, perbaiki masalah ini dengan menambahkan langkah nonpartisi untuk mengagregasi nilai di seluruh partisi, seperti dalam contoh berikut:

    WITH Step1 AS (
        SELECT COUNT(*) AS Count, TollBoothId
        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

Anda dapat menskalakan kueri ini ke 4 SU V2.

Catatan

Jika Anda menggabungkan dua aliran, pastikan aliran tersebut dipartisi oleh kunci partisi dari kolom yang Anda gunakan saat membuat penggabungan. Pastikan juga bahwa Anda memiliki jumlah partisi yang sama di kedua aliran.

Mencapai throughput yang lebih tinggi dalam skala besar

Pekerjaan paralel yang memalukan diperlukan tetapi tidak cukup untuk mempertahankan throughput yang lebih tinggi dalam skala besar. Setiap sistem penyimpanan dan output Stream Analytics yang sesuai memiliki variasi cara untuk mencapai throughput tulis sebaik mungkin. Seperti halnya skenario dalam skala besar, beberapa tantangan memerlukan konfigurasi yang tepat untuk diselesaikan. Bagian ini membahas konfigurasi untuk beberapa output umum dan menyediakan contoh untuk mempertahankan tingkat asupan peristiwa sebesar 1 K, 5 K, dan 10 K per detik.

Pengamatan berikut menggunakan pekerjaan Azure Stream Analytics dengan kueri stateless (passthrough), fungsi dasar yang ditentukan pengguna JavaScript (UDF) yang menulis ke Event Hubs, Azure SQL, atau Azure Cosmos DB.

Pusat Aktivitas

Tingkat Penyerapan (peristiwa per detik)	Unit Streaming	Sumber Daya Output
1 K (1 Kelvin)	1/3	2 TU
5 K	1	6 TU
10 K	2	10 TU

Solusi Azure Event Hubs menskalakan secara linear dalam hal unit streaming (SU) dan throughput, menjadikannya cara paling efisien dan berperforma untuk menganalisis dan melakukan streaming data dari Azure Stream Analytics. Anda dapat menaikkan skala pekerjaan hingga 66 SU V2, yang kira-kira setara dengan memproses hingga 400 MB/detik, atau 38 triliun peristiwa per hari.

Azure SQL

Tingkat Penyerapan (peristiwa per detik)	Unit Streaming	Sumber Daya Output
1 K (1 Kelvin)	2/3	S3
5 K	3	P4
10 K	6	P6

Azure SQL mendukung penulisan secara paralel, yang disebut Inherit Partitioning, tetapi tidak diaktifkan secara default. Namun, mengaktifkan Partisi Warisi, bersama dengan kueri paralel sepenuhnya, mungkin tidak cukup untuk mencapai throughput yang lebih tinggi. Throughput penulisan SQL sangat bergantung pada konfigurasi database dan skema tabel Anda. Artikel SQL Output Performance menyediakan detail lebih lanjut tentang parameter yang dapat memaksimalkan throughput tulis Anda. Seperti yang disebutkan dalam artikel output Azure Stream Analytics ke Azure SQL Database, solusi ini tidak dapat diskalakan secara linier sebagai pipeline yang sepenuhnya paralel di luar 8 partisi dan mungkin perlu di-repartisi sebelum output SQL (lihat INTO). SKU premium diperlukan untuk mempertahankan tingkat IO yang tinggi bersama dengan overhead dari pencadangan log yang berlangsung setiap beberapa menit.

Azure Cosmos DB

Tingkat Penyerapan (peristiwa per detik)	Unit Streaming	Sumber Daya Output
1 K (1 Kelvin)	2/3	20 K RU
5 K	4	60 ribu RU
10 K	8	120 K RU

Azure Cosmos DB output dari Stream Analytics diperbarui untuk menggunakan integrasi asli di bawah kompatibilitas tingkat 1.2. Tingkat kompatibilitas 1.2 memungkinkan throughput yang jauh lebih tinggi dan mengurangi konsumsi RU dibandingkan dengan 1,1, yang merupakan tingkat kompatibilitas default untuk pekerjaan baru. Solusi ini menggunakan kontainer Azure Cosmos DB yang dipartisi pada /deviceId dan solusi lainnya dikonfigurasi secara identik.

Semua sampel Streaming di Scale Azure menggunakan Azure Event Hubs sebagai input yang diumpankan oleh klien uji simulasi beban. Setiap peristiwa input adalah dokumen JSON 1 KB, yang menerjemahkan tingkat penyerapan yang dikonfigurasi ke tingkat throughput (1 MB/dtk, 5 MB/dtk, dan 10 MB/dtk) dengan mudah. Peristiwa mensimulasikan perangkat IoT yang mengirim data JSON berikut (dalam bentuk yang dipersingkat) hingga 1.000 perangkat:

{
    "eventId": "b81d241f-5187-40b0-ab2a-940faf9757c0",
    "complexData": {
        "moreData0": 51.3068118685458,
        "moreData22": 45.34076957651598
    },
    "value": 49.02278128887753,
    "deviceId": "contoso://device-id-1554",
    "type": "CO2",
    "createdAt": "2019-05-16T17:16:40.000003Z"
}

Catatan

Konfigurasi dapat berubah karena berbagai komponen yang digunakan dalam solusi. Untuk perkiraan yang lebih akurat, kustomisasi sampel agar sesuai dengan skenario Anda.

Mengidentifikasi hambatan

Gunakan panel Metrik di pekerjaan Azure Stream Analytics Anda untuk mengidentifikasi penyempitan di alur Anda. Tinjau Peristiwa Input/Output untuk throughput dan "Watermark Delay" atau Backlogged Events untuk melihat apakah pekerjaan mengikuti laju input. Untuk metrik Event Hubs, cari Permintaan yang Dibatasi dan sesuaikan Unit Ambang Batasnya. Untuk metrik Azure Cosmos DB, ditinjau konsumsi RU/dtk maksimum per rentang kunci partisi di bawah Throughput agar rentang kunci partisi Anda dikonsumsi secara seragam. Untuk Azure SQL DB, pantau Log IO dan CPU.

Dapatkan bantuan

Untuk bantuan lebih lanjut, coba halaman pertanyaan Tanya Jawab Microsoft untuk Azure Stream Analytics.

Langkah berikutnya

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-05-01

Menggunakan paralelisasi kueri di Azure Stream Analytics

Apa saja bagian dari pekerjaan Stream Analytics?

Partisi pada input dan output

Input

Output

Kueri

Pekerjaan paralel yang memalukan

Kueri sederhana

Kueri dengan kunci pengelompokan

Contoh skenario yang tidak sepenuhnya paralel yang memalukan

Jumlah partisi yang tidak cocok

Kueri menggunakan output tidak terpartisi

Kueri multi-langkah dengan nilai PARTITION BY yang berbeda

Kueri multi-langkah dengan nilai PARTITION BY yang berbeda

Menghitung unit streaming maksimum dari sebuah tugas

Langkah-langkah dalam kueri

Memisahkan langkah proses

Menghitung unit streaming maksimum untuk proyek

Contoh penskalaan

Mencapai throughput yang lebih tinggi dalam skala besar

Pusat Aktivitas

Azure SQL

Azure Cosmos DB

Mengidentifikasi hambatan

Dapatkan bantuan

Langkah berikutnya

Saran dan Komentar

Sumber Daya Tambahan: