Fitur dan terminologi Azure Event Hubs

Artikel ini menjelaskan konsep inti dan terminologi Azure Event Hubs. Untuk gambaran umum tingkat tinggi, lihat Apa itu Azure Event Hubs?

Sekilas konsep

Konsep	Description
Namespace	Kontainer manajemen untuk satu atau beberapa pusat aktivitas. Mengontrol akses dan penskalakan jaringan.
Event hub	Log khusus tambahan yang menyimpan peristiwa. Setara dengan topik Kafka.
Partisi	Urutan peristiwa dalam hub acara. Mengaktifkan pemrosesan paralel.
Produser/Penerbit	Aplikasi yang mengirim peristiwa ke hub peristiwa.
Konsumen	Aplikasi yang membaca peristiwa dari pusat aktivitas.
Grup konsumen	Tampilan independen aliran peristiwa. Beberapa grup dapat membaca data yang sama secara terpisah.
Offset	Posisi peristiwa dalam partisi. Digunakan untuk melacak kemajuan membaca.
Titik Pemeriksaan	Menyimpan offset saat ini sehingga pengguna dapat melanjutkan dari tempat mereka berhenti.

Architecture

Ruang Nama

Namespace untuk Event Hubs adalah kontainer manajemen untuk hub peristiwa (atau topik, dalam istilah Kafka). Ini menyediakan titik akhir jaringan dan mengontrol akses melalui fitur seperti pemfilteran IP, titik akhir layanan jaringan virtual, dan Private Link.

Diagram memperlihatkan namespace layanan Azure Event Hubs yang berisi beberapa hub peristiwa.

Sekat

Azure Event Hubs mengatur urutan peristiwa yang dikirim ke event hub ke dalam satu atau beberapa partisi. Ketika peristiwa yang lebih baru tiba, peristiwa tersebut akan ditambahkan ke akhir urutan ini.

Gambar yang menunjukkan Event Hub dengan beberapa partisi.

Partisi dapat dianggap sebagai catatan komit. Partisi menyimpan data peristiwa yang berisi informasi berikut:

Isi peristiwa
Kumpulan properti yang ditentukan pengguna yang menjelaskan acara
Metadata seperti offsetnya dalam partisi, jumlahnya dalam urutan aliran
Tanda waktu sisi layanan saat diterima

Diagram yang menampilkan urutan peristiwa yang lebih lama ke yang lebih baru.

Manfaat menggunakan partisi

Azure Event Hubs dirancang untuk membantu pemrosesan acara dalam jumlah besar, dan partisi membantu dengan dua cara:

Meskipun Azure Event Hubs adalah layanan PaaS, ada realitas fisik di bawahnya. Memelihara log yang menjaga urutan peristiwa mensyaratkan bahwa peristiwa-peristiwa ini disimpan bersama-sama dalam penyimpanan dasar dan replikanya, yang mengakibatkan adanya batas throughput untuk log tersebut. Partisi memungkinkan penggunaan beberapa log paralel untuk hub peristiwa yang sama dan dengan demikian meningkatkan kapasitas throughput IO mentah yang tersedia.
Aplikasi Anda sendiri harus dapat mengikuti pemrosesan volume peristiwa yang dikirim ke hub peristiwa. Ini mungkin kompleks dan membutuhkan kapasitas pemrosesan paralel yang signifikan dan terukur. Kapasitas satu proses untuk menangani peristiwa terbatas, sehingga Anda memerlukan beberapa proses. Partisi adalah cara solusi Anda mendukung proses tersebut dan memastikan bahwa setiap kejadian memiliki pemilik pemrosesan yang jelas.

Jumlah partisi

Jumlah partisi ditentukan pada saat membuat hub peristiwa. Ini harus antara satu dan jumlah partisi maksimum yang diizinkan untuk setiap tingkat harga. Untuk batas jumlah partisi untuk setiap tingkat, lihat artikel ini.

Kami menyarankan Anda memilih setidaknya sebanyak partisi yang Anda perkirakan diperlukan selama beban puncak aplikasi Anda untuk hub peristiwa tertentu tersebut.

Untuk tingkatan selain tingkat premium dan khusus, Anda tidak dapat mengubah jumlah partisi untuk pusat aktivitas setelah pembuatannya. Untuk hub peristiwa di tingkat premium atau khusus, Anda dapat meningkatkan jumlah partisi setelah pembuatannya, tetapi Anda tidak dapat menguranginya lagi. Distribusi aliran di seluruh partisi akan berubah ketika kunci partisi dipetakan ulang ke partisi. Oleh karena itu, Anda harus berusaha keras untuk menghindari perubahan tersebut jika urutan peristiwa penting bagi aplikasi Anda.

Mengatur jumlah partisi ke nilai maksimum yang diizinkan mungkin menarik, tetapi selalu ingat bahwa aliran peristiwa Anda harus terstruktur sedemikian rupa sehingga Anda memang dapat memanfaatkan banyak partisi. Jika Anda memerlukan pelestarian urutan secara mutlak untuk semua kejadian atau hanya beberapa sub-aliran, Anda mungkin tidak dapat memanfaatkan banyak partisi. Juga, partisi dalam jumlah banyak membuat sisi pemrosesan lebih kompleks.

Tidak masalah berapa banyak partisi yang ada di event hub dalam hal harga. Hal ini bergantung pada jumlah unit harga (unit throughput (TU) untuk tingkat standar, unit pemrosesan (PU) untuk tingkat premium, dan unit kapasitas (CU) untuk tingkat khusus) untuk namespace atau kluster khusus. Misalnya, pusat aktivitas tingkat standar dengan 32 partisi atau dengan satu partisi dikenakan biaya yang sama persis ketika namespace diatur ke satu kapasitas TU. Selain itu, Anda dapat menskalakan TU atau PU pada namespace atau CU kluster khusus Anda terlepas dari jumlah partisi.

Partisi adalah mekanisme organisasi data yang memungkinkan penerbitan dan konsumsi paralel. Meskipun mendukung pemrosesan dan penskalaan paralel, total kapasitas tetap dibatasi oleh alokasi penskalaan namespace. Unit penskalaan keseimbangan (unit throughput untuk tingkat standar, unit pemrosesan untuk tingkat premium, atau unit kapasitas untuk tingkat khusus) dan partisi untuk mencapai skala optimal.

Mulailah dengan profil beban kerja Anda: ukuran payload rata-rata, peristiwa per detik, dan sensitivitas terhadap penurunan throughput atau lonjakan latensi. Gunakan throughput per partisi di bawah ini sebagai titik awal, lalu validasi dengan pengujian beban:

Tingkat standar: ~1 MB/dtk masuk dan ~2 MB/dtk keluar per partisi.
Tingkat premium dan Khusus: ~1-2 MB/dtk masuk dan ~2-5 MB/dtk keluar per partisi.

Perkirakan partisi dengan membagi masukan dan keluaran yang diharapkan dengan tarif per partisi yang diterapkan dan menggunakan hasil yang lebih besar. Jika throughput atau latensi yang diamati tidak memenuhi ekspektasi, tingkatkan partisi (hanya tingkat Premium dan Khusus) dan coba lagi.

Partisi juga mengatur batas untuk paralelisme konsumen. Cara kerja langit-langit itu tergantung pada jenis konsumen:

Konsumen Eksklusif Epoch — Digunakan oleh EventProcessorClient (.NET, Java) dan EventHubConsumerClient (Python, JavaScript), yang merupakan pola yang direkomendasikan untuk beban kerja AMQP dalam produksi. Hanya satu konsumen epoch yang dapat memiliki partisi tertentu dalam grup konsumen pada satu waktu. Jika Anda menyebarkan lebih banyak instans prosesor daripada partisi, instans tambahan tidak diberi partisi apa pun dan menganggur sampai pemilik saat ini melepaskan partisi. Jika konsumen epoch baru terhubung dengan tingkat pemilik yang lebih tinggi, layanan memutuskan pemilik saat ini dengan kesalahan ConsumerDisconnected, dan konsumen baru tersebut mengambil alih.
Konsumen non-epoch — Hingga 5 penerima non-epoch dapat membaca partisi yang sama secara bersamaan dalam grup konsumen. Setiap penerima melihat peristiwa yang sama (fan-out), sehingga mode ini tidak meningkatkan throughput pemrosesan per partisi. Menyambungkan konsumen epoch ke sebuah partisi akan memutus semua konsumen non-epoch pada partisi tersebut.
Konsumen Kafka — Konsumen Kafka menggunakan protokol koordinasi grup (group.id) alih-alih epoch AMQP, tetapi model kepemilikan partisi setara: setiap partisi ditetapkan untuk tepat satu anggota konsumen dalam grup konsumen pada satu waktu. Saat anggota baru bergabung atau anggota yang sudah ada keluar, grup menyeimbangkan kembali dan mendistribusikan ulang penetapan partisi. Jika ada lebih banyak anggota konsumen daripada partisi, kelebihan anggota tidak mendapatkan penugasan dan tetap tidak aktif sampai penyeimbangan ulang di masa mendatang melepaskan partisi. Untuk mengurangi penyeimbangan ulang yang tidak perlu dari pemutusan sementara, atur instans unik group.instance.id per konsumen (keanggotaan statis).

Dalam praktiknya, jumlah partisi sama dengan jumlah maksimum konsumen paralel per grup konsumen terlepas dari apakah Anda menggunakan konsumen epoch AMQP atau konsumen Kafka. Faktorkan ini ke dalam jumlah partisi Anda saat Anda merencanakan peluasan skala.

Jika aplikasi Anda memiliki afinitas ke partisi tertentu, meningkatkan jumlah partisi tidak bermanfaat. Untuk informasi selengkapnya, lihat ketersediaan dan konsistensi.

Pemetaan peristiwa ke partisi

Anda dapat menggunakan kunci partisi untuk memetakan data peristiwa yang masuk ke dalam partisi tertentu untuk tujuan organisasi data. Kunci partisi adalah nilai yang disediakan pengirim yang diteruskan ke event hub. Ini diproses melalui fungsi hashing statis, yang membuat penetapan partisi. Jika Anda tidak menentukan kunci partisi saat menerbitkan peristiwa, maka penugasan round-robin akan digunakan.

Penerbit acara hanya mengetahui kunci partisinya, bukan partisi di mana peristiwa diterbitkan. Pemisahan kunci dan partisi ini membuat pengirim tidak perlu mengetahui terlalu banyak tentang pemrosesan hilir. Identitas unik per perangkat atau pengguna membuat kunci partisi yang baik, tetapi atribut lain seperti geografi juga dapat digunakan untuk mengelompokkan peristiwa terkait ke dalam satu partisi.

Menentukan kunci partisi memungkinkan menyimpan peristiwa terkait bersama-sama di partisi yang sama dan dalam urutan yang tepat di mana mereka tiba. Kunci partisi adalah beberapa untai yang diturunkan dari konteks aplikasi Anda dan mengidentifikasi keterkaitan peristiwa. Urutan peristiwa yang diidentifikasi oleh kunci partisi adalah aliran. Partisi adalah penyimpanan log multipleks untuk banyak aliran seperti itu.

Nota

Meskipun Anda dapat mengirim acara langsung ke partisi, kami tidak merekomendasikannya, terutama jika ketersediaan tinggi penting bagi Anda. Ini mengurangi ketersediaan event hub ke tingkat partisi. Untuk informasi selengkapnya, lihat Ketersediaan dan Konsistensi.

Penyelenggara acara

Produsen (atau penerbit) adalah aplikasi apa pun yang mengirim peristiwa ke pusat aktivitas.

Opsi penerbitan

Metode	Description
azure SDK	.NET, Java, Python, JavaScript, Go
REST API	Permintaan HTTP POST untuk klien ringan
Klien Kafka	Gunakan produsen Kafka yang ada tanpa perubahan kode
AMQP 1.0	Setiap klien AMQP seperti Apache Qpid

Perilaku utama

Batch atau individu: Menerbitkan peristiwa satu per satu atau dalam kelompok. Maksimum 1 MB per operasi penerbitan.
Kunci partisi: Tentukan kunci partisi untuk mengelompokkan peristiwa terkait dalam partisi yang sama, memastikan pengiriman yang diurutkan.
Otorisasi: Gunakan ID Microsoft Entra (OAuth2) atau Tanda Tangan Akses Bersama (SAS) untuk kontrol akses.

Diagram memperlihatkan bagaimana kunci partisi memetakan peristiwa ke partisi tertentu.

Kebijakan penerbit

Kebijakan penerbit memungkinkan kontrol terperinci saat Anda memiliki banyak penerbit independen. Setiap penerbit menggunakan pengidentifikasi unik:

//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>

Nama penerbit harus cocok dengan token SAS yang digunakan untuk autentikasi. Saat menggunakan kebijakan penerbit, PartitionKey harus cocok dengan nama penerbit.

Pengguna acara

Konsumen adalah aplikasi apa pun yang membaca peristiwa dari pusat aktivitas. Azure Event Hubs menggunakan model penarikan—konsumen meminta peristiwa daripada peristiwa yang didorong kepada mereka.

Grup konsumen

Grup konsumen adalah tampilan independen dari aliran peristiwa. Beberapa grup konsumen dapat membaca pusat aktivitas yang sama secara bersamaan, masing-masing melacak posisi mereka sendiri.

Pedoman	Recommendation
Pembaca per partisi	Satu pembaca aktif per partisi dalam grup konsumen (hingga lima dalam skenario khusus)
Grup bawaan	Setiap pusat aktivitas memiliki grup konsumen default (`$Default`)
Beberapa aplikasi	Membuat grup konsumen terpisah untuk setiap aplikasi (analitik, arsip, peringatan)

//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>

Diagram memperlihatkan beberapa grup konsumen yang membaca dari hub peristiwa yang sama.

Offset

Offset adalah posisi suatu peristiwa dalam partisi—anggap saja sebagai penunjuk (kursor). Konsumen menggunakan offset untuk menentukan tempat untuk mulai membaca. Anda dapat memulai dari:

Nilai offset tertentu
Stempel waktu
Awal atau akhir aliran

Diagram memperlihatkan peristiwa dalam partisi dengan posisi offset.

Titik Pemeriksaan

Titik pemeriksaan adalah ketika konsumen menyimpan offsetnya saat ini. Ini memungkinkan:

Dimulai kembali: Jika konsumen terputus, maka akan dilanjutkan dari titik pemeriksaan terakhir
Failover: Instans konsumen baru dapat mengambil alih dari posisi terakhir yang ditinggalkan
Pemutaran ulang: Memproses peristiwa historis dengan menentukan offset sebelumnya

Penting

Di AMQP, titik pemeriksaan adalah tanggung jawab konsumen. Layanan Azure Event Hubs menyediakan offset, tetapi konsumen harus menyimpan titik pemeriksaan.

Ikuti rekomendasi ini saat Anda menggunakan Azure Blob Storage sebagai penyimpanan titik pemeriksaan:

Gunakan kontainer terpisah untuk setiap grup konsumen. Anda dapat menggunakan akun penyimpanan yang sama, tetapi menggunakan satu kontainer per setiap grup.
Jangan gunakan akun penyimpanan untuk hal lain.
Jangan gunakan kontainer untuk hal lain.
Buat akun penyimpanan di wilayah yang sama dengan aplikasi yang disebarkan. Jika aplikasi lokal, coba pilih wilayah terdekat yang mungkin.

Pada halaman Akun penyimpanan di portal Azure, di bagian Blob service, pastikan bahwa pengaturan berikut dinonaktifkan.

Namespace hierarkis
Penghapusan sementara blob
Pembuatan Versi

Klien pemroses acara

Azure SDK menyediakan klien konsumen cerdas yang menangani manajemen partisi, penyeimbangan beban, dan titik pemeriksaan secara otomatis:

Bahasa	Klien
.NET	EventProcessorClient
Java	EventProcessorClient
Phyton	EventHubConsumerClient
JavaScript	EventHubConsumerClient

Struktur data peristiwa

Setiap peristiwa berisi:

Isi: Payload peristiwa
Offset: Posisi dalam partisi
Nomor urut: Urutan dalam partisi
Properti pengguna: Metadata kustom
Properti sistem: Metadata yang ditetapkan layanan (waktu antrean, dll.)

Manajemen data

Retensi Peristiwa

Peristiwa dihapus secara otomatis berdasarkan kebijakan penyimpanan berbasis waktu.

Tier	Bawaan	Maximum
Standar	1 jam	7 hari
Premium	1 jam	90 hari
Berdedikasi	1 jam	90 hari

Poin utama:

Peristiwa tidak dapat dihapus secara eksplisit
Perubahan retensi berlaku untuk acara yang ada
Peristiwa akan menjadi tidak tersedia tepat pada saat periode penyimpanan berakhir

Nota

Azure Event Hubs adalah mesin streaming real-time, bukan database. Untuk penyimpanan jangka panjang, gunakan Event Hubs Capture untuk mengarsipkan peristiwa ke Azure Storage, Data Lake Storage, atau Azure Synapse.

Pengambilan Azure Event Hubs

Pengambilan secara otomatis menyimpan data streaming ke Azure Blob Storage atau Azure Data Lake Storage. Konfigurasikan ukuran minimum dan jendela waktu untuk mengontrol frekuensi pengambilan.

Diagram memperlihatkan Azure Event Hubs Capture menulis data ke Azure Storage.

Rancangan	Description
Avro	Format default untuk data yang diambil
Parquet	Tersedia melalui editor tanpa kode di portal Microsoft Azure (pelajari selengkapnya)

Pemadatan log

Log compaction hanya mempertahankan peristiwa terbaru untuk setiap kunci unik, daripada menggunakan retensi berbasis waktu. Berguna untuk mempertahankan status saat ini tanpa menyimpan riwayat penuh.

Protokol

Azure Event Hubs mendukung beberapa protokol untuk fleksibilitas di berbagai jenis klien.

Protokol	Kirim	Menerima	Paling cocok untuk
AMQP 1.0	Yes	Yes	Throughput tinggi, latensi rendah, koneksi persisten
Apache Kafka	Yes	Yes	Aplikasi Kafka yang ada (versi 1.0+)
HTTPS	Yes	Tidak.	Klien ringan, lingkungan yang dibatasi firewall

Perbandingan protokol

AMQP: Memerlukan soket dua arah persisten. Biaya awal yang lebih tinggi, tetapi performa yang lebih baik untuk operasi yang sering. Digunakan oleh Azure SDK.
Kafka: Dukungan asli berarti aplikasi Kafka yang ada berfungsi tanpa perubahan kode. Konfigurasikan ulang saja server bootstrap untuk menunjuk ke namespace Event Hubs Anda.
HTTPS: HTTP POST sederhana untuk dikirim. Tidak menerima dukungan. Baik untuk penerbitan volume rendah sesekali.

Untuk detail integrasi Kafka, lihat Event Hubs untuk Apache Kafka.

Kontrol akses

Microsoft Entra ID

MICROSOFT Entra ID menyediakan autentikasi OAuth 2.0 dengan kontrol akses berbasis peran (RBAC). Tetapkan peran bawaan untuk mengontrol akses:

Role	Permissions
Pemilik Data Azure Event Hubs	Akses penuh untuk mengirim dan menerima peristiwa
Azure Event Hubs Data Sender	Kirim peristiwa saja
Penerima Data Azure Event Hubs	Hanya menerima peristiwa

Untuk detailnya, lihat Mengotorisasi akses dengan ID Microsoft Entra.

Tanda Tangan Akses Bersama (SAS)

Token SAS menyediakan akses terlingkup di namespace atau tingkat event hub. Token SAS dihasilkan dari kunci SAS dan biasanya hanya memberikan izin kirim atau dengarkan .

Untuk detailnya, lihat Autentikasi Tanda Tangan Akses Bersama.

Grup aplikasi

Grup aplikasi memungkinkan Anda menentukan kebijakan akses sumber daya (seperti pembatasan) untuk kumpulan aplikasi klien yang berbagi konteks keamanan (kebijakan SAS atau ID aplikasi Microsoft Entra).