Peta ekosistem

Broker Kafka menyimpan pesan dan meneruskannya kepada consumer, sedangkan sebagian besar pekerjaan lain di sekitar data, yaitu pengolahan, integrasi, dan pemeliharaan cluster, dikerjakan oleh perangkat lunak yang dibangun di atas atau di sekeliling Kafka. Topik ini memetakan ekosistem tersebut per kategori, yaitu pemrosesan stream, integrasi data, manajemen cluster, dan layanan terkelola, dengan komponen yang paling sering digunakan pada setiap kategori. Setelah membaca topik ini, kebutuhan baru yang muncul dapat dipetakan ke komponen yang tepat sebelum dokumentasi detailnya dibaca.

Peta ekosistem per kategori#

Seluruh komponen pada peta ini berkomunikasi dengan Kafka melalui protokol klien yang sama, yaitu membaca dan menulis pesan topic, sehingga komponen satu kategori dapat digantikan oleh komponen lain tanpa mengubah producer yang sudah berjalan. Kategori pertama, pemrosesan stream, membaca topic, mengolah arus pesannya, dan menulis hasilnya kembali ke topic lain. Kategori kedua, integrasi data, memindahkan data antara Kafka dan sistem di luar Kafka, misalnya basis data, penyimpanan objek, atau mesin pencarian. Kategori ketiga, manajemen cluster, menjaga distribusi beban antar broker agar cluster tetap seimbang, sedangkan kategori keempat, layanan terkelola, memindahkan pekerjaan operasional cluster kepada penyedia cloud. Batas antar kategori bukan batas mutlak, misalnya salah satu komponen pemrosesan berupa pustaka yang menyatu dengan aplikasi, tetapi pembagian ini cukup untuk menentukan arah pencarian alat.

Pemrosesan stream#

Kafka Streams adalah pustaka pemrosesan stream untuk aplikasi Java, sehingga logika pengolahannya menyatu dengan kode aplikasi dan tidak memerlukan proses terpisah. Pustaka ini menyimpan keadaan antar pesan pada state store lokal dan menyediakan operasi penggabungan serta jendela waktu yang menjadi dasar pemrosesan stateful, yaitu pemrosesan yang hasilnya bergantung pada kumpulan pesan sebelumnya. KsqlDB adalah basis data streaming yang dibangun di atas Kafka dan menjalankan query-nya dengan mesin Kafka Streams. Antarmuka SQL-nya bekerja atas stream dan table, yaitu aliran pesan dan ringkasan berjalan yang terus diperbarui, dengan dua cara membaca hasil, yaitu push query yang mengirim pembaruan terus-menerus dan pull query yang mengambil keadaan terkini dari materialized view.

Apache Flink adalah framework pemrosesan stream yang berjalan sebagai cluster terpisah dengan Kafka sebagai sumber dan tujuan data melalui connector resminya. Flink menangani keadaan yang besar, waktu event, dan jaminan exactly-once, sehingga agregasi dan penggabungan yang kompleks dengan cakrawala waktu panjang dapat dilakukan pada Flink. Spark Structured Streaming mengolah stream dengan pola micro-batch, yaitu pemrosesan dalam kelompok kecil yang diulang berkala, dan menjadi pilihan wajar apabila pengolahan, baik batch maupun streaming, sudah berada di ekosistem Spark. Empat komponen ini dibandingkan pada tabel berikut.

Integrasi data#

Ekosistem Connect menyediakan connector source dan sink untuk banyak sistem, dari basis data relasional, penyimpanan objek, mesin pencarian, hingga antrean pesan lain. Connector disediakan oleh komunitas maupun pengembang sistem yang bersangkutan, dan integrasinya berbentuk konfigurasi, bukan kode, sebagaimana model Kafka Connect pada modul ini. Connector source berbasis polling membaca sistem sumber secara berkala, misalnya query tabel pada interval tertentu, sedangkan connector sink menulis pesan topic ke sistem tujuan dengan format yang didukung sistem tersebut.

Debezium adalah keluarga connector change data capture, disingkat CDC, yang membaca log transaksi basis data alih-alih menanyakan isi tabelnya. Setiap perubahan baris berupa penyisipan, pembaharuan, atau penghapusan diterbitkan sebagai pesan topic hampir seketika setelah transaksi selesai, dan connector ini berjalan sebagai source connector pada worker Connect. Debezium mendukung sejumlah basis data, di antaranya PostgreSQL, MySQL, MongoDB, dan SQL Server, dengan connector per basis data yang menyesuaikan bentuk log transaksinya.

Manajemen cluster dan layanan terkelola#

Cruise Control melengkapi kategori manajemen dengan tugas menyeimbangkan beban antar broker. Alat ini membaca metrik sumber daya dari broker, seperti penggunaan diska, jaringan, dan CPU, kemudian menyusun usulan pemindahan replika yang meratakan beban tersebut. Usulannya dapat ditinjau sebelum dijalankan, dan eksekusinya berlangsung sebagai perpindahan replika antar broker tanpa menghentikan cluster. Pekerjaan ini sering dibutuhkan setelah broker ditambahkan, broker gagal, atau pola beban topic bergeser, karena pembagian replika yang tidak merata membuat sebagian broker lebih panas daripada yang lain. Untuk pemantauan sehari-hari, broker dan worker Connect memuat metrik yang siap dikumpulkan oleh sistem pemantauan apa pun.

Kategori keempat berupa cara menyebarkan cluster itu sendiri. Perusahaan penyedia layanan cloud umumnya menawarkan Kafka terkelola, yaitu cluster yang penyediaannya, pembaruan versi, pemantauan, dan penanganan kegagalan broker dikerjakan oleh penyedia layanan. Tim aplikasi tidak lagi mengoperasikan broker dan menanggung biaya langganan sebagai gantinya. Pilihan antara menjalankan cluster sendiri dan menggunakan layanan terkelola bergantung pada ketersediaan tim infrastruktur, kebutuhan kontrol atas konfigurasi broker, serta struktur biaya yang diterima organisasi. Kedua pilihan tetap menggunakan protokol Kafka yang sama, sehingga aplikasi dan komponen ekosistem pada peta ini berjalan di atas keduanya tanpa perubahan kode.

Memilih komponen untuk kebutuhan yang ada#

Pemilihan komponen dimulai dari karakter kebutuhan, bukan dari daftar alat. Kebutuhan yang bersifat integratif dijawab connector, kebutuhan yang bersifat analitis dijawab komponen pemrosesan, kebutuhan operasional dijawab alat manajemen, dan kebutuhan operasi tanpa tim infrastruktur diarahkan ke layanan terkelola. Demo berikut memetakan tujuh kebutuhan yang paling sering muncul ke komponen yang cocok, dan daftar tersebut dapat digunakan sebagai kerangka awal sebelum dokumentasi detail dibaca.

# Pemetaan kebutuhan ke komponen ekosistem Kafka. Setiap kasus dipetakan ke
# satu komponen berdasarkan karakter pekerjaannya, sehingga daftar ini
# berfungsi sebagai kerangka pemilihan alat sebelum dokumentasi detailnya
# dibaca.

kebutuhan = [
    ("arsip pesan topic ke penyimpanan objek", "sink connector"),
    ("perubahan baris basis data masuk ke topic", "Debezium"),
    ("transformasi dan query SQL atas arus pesan", "KsqlDB"),
    ("agregasi stateful kompleks dengan jendela waktu", "Flink"),
    ("penyeimbangan beban partisi antar broker", "Cruise Control"),
    ("replikasi data antar dua cluster", "MirrorMaker 2"),
    ("operasi tanpa tim infrastruktur sendiri", "Kafka terkelola"),
]

lebar = max(len(kasus) for kasus, _ in kebutuhan)
for kasus, komponen in kebutuhan:
    print(f"{kasus:<{lebar}} -> {komponen}")

arsip pesan topic ke penyimpanan objek          -> sink connector
perubahan baris basis data masuk ke topic       -> Debezium
transformasi dan query SQL atas arus pesan      -> KsqlDB
agregasi stateful kompleks dengan jendela waktu -> Flink
penyeimbangan beban partisi antar broker        -> Cruise Control
replikasi data antar dua cluster                -> MirrorMaker 2
operasi tanpa tim infrastruktur sendiri         -> Kafka terkelola

Komponen-komponen pada peta ini saling melengkapi dan sering dipasang bersamaan. Alur yang lazim dimulai dari Debezium menerbitkan perubahan basis data ke topic, komponen pemrosesan mengolah arus tersebut menjadi topic hasil, lalu sink connector mengirim topic hasil ke sistem tujuan. Di luar alur data, Cruise Control menjaga cluster tetap seimbang, dan MirrorMaker 2 menyalin data ke cluster di lokasi lain sebagaimana dibahas pada topik multi-cluster. Satu kebutuhan jarang dijawab satu komponen saja, sehingga peta ini lebih tepat dibaca sebagai kumpulan peran yang digabungkan sesuai arsitektur yang disusun.

Ringkasan#

• Ekosistem Kafka terbagi ke dalam empat kategori, yaitu pemrosesan stream, integrasi data, manajemen cluster, dan layanan terkelola, dan seluruh komponennya berkomunikasi melalui topic beserta protokol klien Kafka.
• Pemrosesan stream tersedia sebagai pustaka aplikasi pada Kafka Streams, basis data SQL pada KsqlDB, cluster terpisah pada Flink, dan pola micro-batch pada Spark Structured Streaming.
• Integrasi data dijalankan connector Connect untuk sistem tujuan yang umum, sedangkan Debezium menangkap perubahan basis data melalui log transaksi tanpa jeda polling.
• Cruise Control menyeimbangkan beban antar broker, dan Kafka terkelola dari penyedia cloud memindahkan pekerjaan operasional cluster kepada penyedia layanan.

Referensi#

• ksqlDB Documentation — ksqlDB — konsep stream dan table, push dan pull query, serta penggunaan SQL di atas Kafka.
• Apache Kafka Connector — Apache Flink Documentation — Kafka sebagai sumber dan tujuan data pada pemrosesan Flink.
• Debezium Documentation — Debezium Community — daftar connector CDC yang didukung beserta model pemasangannya.
• Cruise Control README — GitHub — penyeimbangan beban cluster Kafka berbasis metrik sumber daya.