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 Azure 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 dalam 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 Azure Stream Analytics memanfaatkan partisi dalam input dan output. Pekerjaan Azure Stream Analytics dapat mengkonsumsi 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, kunci partisi akan ditetapkan sebagai properti input, tanpa perlu kata kunci PARTITION BY dalam kueri. Untuk tingkat kompatibilitas 1.1 dan ke bawah, kunci partisi akan ditetapkan dengan kata kunci PARTITION BY dalam kueri.
Output
Saat bekerja dengan Azure Stream Analytics, Anda dapat memanfaatkan partisi dalam output:
- Azure Data Lake Storage
- Azure Functions
- Tabel Azure
- Penyimpanan blob (dapat mengatur kunci partisi secara eksplisit)
- Azure Cosmos DB (perlu mengatur kunci partisi secara eksplisit)
- Azure Event Hubs (perlu mengatur kunci partisi secara eksplisit)
- IoT Hub (perlu mengatur kunci partisi secara eksplisit)
- Service Bus
- 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 ini dapat diabaikan jika logika kueri tidak dikunci (proyeksi, filter, gabungan referensial...).
- Jika input dan output dipartisi oleh
WarehouseId, dan grup kueri denganProductIdtanpaWarehouseId, maka pekerjaan tidak paralel. - Jika dua input yang akan digabungkan dipartisi oleh kunci partisi yang berbeda (
WarehouseIddanProductId), maka pekerjaan tersebut tidak paralel. - Jika dua atau lebih aliran data independen terkandung dalam satu pekerjaan, masing-masing dengan kunci partisi masing-masing, maka pekerjaan tersebut tidak paralel.
Hanya ketika semua input, output, dan langkah kueri menggunakan kunci yang sama, pekerjaannya paralel.
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 Azure 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, ini berarti bahwa peristiwa dikirim ke folder partisi yang sama. Contohnya adalah instans kueri yang menggabungkan data per userID di mana event hub input yang 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.
Langkah selanjutnya adalah membuat kueri Anda dipartisi. Untuk pekerjaan dengan tingkat kompatibilitas 1.2 atau lebih tinggi (disarankan), kolom kustom dapat ditentukan sebagai Kunci Partisi dalam pengaturan input dan pekerjaan akan paralel secara otomatis. Pekerjaan dengan tingkat kompatibilitas 1.0 atau 1.1, mengharuskan Anda menggunakan PARTITION BY PartitionId di semua langkah kueri Anda. Beberapa langkah diperbolehkan, 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 akan menjadi pararel yang memalukan. Untuk output Azure Event Hubs, pastikan kolom kunci Partisi diatur ke kunci partisi yang sama yang digunakan dalam kueri. Untuk informasi selengkapnya, lihat bagian output.
Jumlah partisi input harus sama dengan jumlah partisi output. Output penyimpanan blob dapat mendukung partisi dan mewarisi skema partisi kueri upstram. Ketika kunci partisi untuk penyimpanan Blob ditentukan, 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, kita tidak perlu khawatir tentang partisi input yang sedang dikirim ke event hub. Perhatikan bahwa pekerjaan dengan tingkat kompatibilitas sebelum 1.2 harus menyertakan klausa PARTITION BY PartitionId, sehingga memenuhi persyaratan #2 dari sebelumnya. Untuk output, kita perlu mengonfigurasi output event hub dalam pekerjaan untuk mengatur kunci partisi 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 kita mengelompokkan menurut TollBoothID, kita harus yakin bahwa TollBoothID digunakan sebagai kunci partisi ketika 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, kita tidak perlu khawatir tentang mengonfigurasi nilai kunci partisi, sesuai #4.
Contoh skenario yang tidak* paralel 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 kita masih bisa mendapatkan beberapa tingkat paralelisasi.
Kueri menggunakan output non-partisi
- Input: Pusat aktivitas dengan delapan partisi
- Output: 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 mengharuskan kita untuk melakukan acakan.
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 akan dipartisi selama kolom "TollBoothId" diatur sebagai input Partition Key. Klausa PARTITION BY PartitionId tidak diperlukan.
Menghitung unit streaming maksimum pekerjaan
Jumlah total unit streaming yang dapat digunakan oleh 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.
Mempartisi langkah
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 yang tidak dipartisi untuk diagregasi.
Menghitung unit streaming maks untuk pekerjaan
Semua langkah yang tidak dipartisi bersama-sama dapat meningkatkan skala hingga satu unit streaming (SU V2) untuk pekerjaan Azure Stream Analytics. Selain itu, Anda dapat menambahkan satu SU V2 untuk setiap partisi dalam langkah yang dipartisi. Anda dapat melihat beberapa contoh dalam tabel berikut.
| Kueri | Max SUs untuk pekerjaan tersebut |
|---|---|
|
1 SU V2 |
|
16 SU V2 (1 * 16 partisi) |
|
1 SU V2 |
|
4 SU V2 (3 untuk langkah yang dipartisi + 1 untuk langkah-langkah yang tidak dipartisi |
Contoh penskalaan
Kueri berikut menghitung jumlah mobil dalam jendela tiga menit melalui stasiun tol yang memiliki tiga tollbooth. Kueri ini dapat diskalakan hingga satu SU V2.
SELECT COUNT(*) AS Count, TollBoothId
FROM Input1
GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
Untuk menggunakan lebih banyak SUs untuk kueri, aliran data input dan kueri harus dipartisi. 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 kueri dipartisi, peristiwa input diproses dan dikumpulkan dalam grup partisi terpisah. Peristiwa output juga dihasilkan 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, data dari TollBooth #1 dapat tersebar di beberapa partisi.
Masing-masing partisi Input1 akan diproses secara terpisah oleh Azure Stream Analytics. Akibatnya, beberapa catatan jumlah mobil untuk tollbooth yang sama di jendela Tumbling yang sama akan dibuat. Jika kunci partisi input tidak dapat diubah, masalah ini dapat diperbaiki dengan menambahkan langkah nonpartisi untuk menggabungkan 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
Kueri ini dapat diskalakan ke 4 SU V2.
Catatan
Jika Anda bergabung dengan dua aliran, pastikan bahwa stream dipartisi oleh kunci partisi kolom yang Anda gunakan untuk membuat gabungan. 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 Azure Stream Analytics yang sesuai, memiliki variasi tentang cara mencapai throughput tulis terbaik. Seperti halnya skenario dalam skala besar, ada beberapa tantangan yang dapat diselesaikan dengan menggunakan konfigurasi yang tepat. Bagian ini membahas konfigurasi untuk beberapa output umum dan menyediakan sampel untuk mempertahankan tingkat penyerapan peristiwa 1 K, 5 K, dan 10 K per detik.
Pengamatan berikut menggunakan pekerjaan Azure Stream Analytics dengan kueri stateless (passthrough), UDF JavaScript dasar yang menulis ke Azure Event Hubs, Azure SQL, atau Azure Cosmos DB.
Event Hubs
| Tingkat Penyerapan (peristiwa per detik) | Unit Streaming | Sumber Daya Output |
|---|---|---|
| 1 K | 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. Pekerjaan dapat diskalakan hingga 66 SU V2, yang kira-kira diterjemahkan untuk memproses hingga 400 MB/dtk, atau 38 triliun peristiwa per hari.
Azure SQL
| Tingkat Penyerapan (peristiwa per detik) | Unit Streaming | Sumber Daya Output |
|---|---|---|
| 1 K | 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 tulis SQL bergantung secara signifikan pada konfigurasi database dan skema tabel Anda. Artikel SQL Output Performance memiliki 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 menskalakan secara linier sebagai alur yang sepenuhnya paralel di luar 8 partisi dan mungkin perlu partisi ulang sebelum output SQL (lihat INTO). SKU premium diperlukan untuk mempertahankan tarif IO tinggi bersama dengan overhead dari pencadangan log yang terjadi setiap beberapa menit.
Azure Cosmos DB
| Tingkat Penyerapan (peristiwa per detik) | Unit Streaming | Sumber Daya Output |
|---|---|---|
| 1 K | 2/3 | 20 K RU |
| 5 K | 4 | 60 K RU |
| 10 K | 8 | 120 K RU |
Output Azure Cosmos DB dari Azure Stream Analytics telah diperbarui untuk menggunakan integrasi asli di bawah tingkat kompatibilitas 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 penyempitan
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 Azure Event Hubs, cari Permintaan Pembatasan dan sesuaikan Unit Ambang. Untuk metrik Azure Cosmos DB, tinjau Ru/dtk yang dikonsumsi maks per rentang kunci partisi di bawah Throughput untuk memastikan 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 Microsoft Q&A untuk Azure Stream Analytics.