Belajar Debezium - Integrasi dengan Konsumen & Sink

#Pendahuluan

Event CDC yang mengalir ke Kafka tidak berguna jika hanya diam di topic. Episode 8 ini membahas sisi konsumsi: bagaimana aplikasi membaca event, bagaimana stream processors mengolahnya secara real-time, dan bagaimana sink connector mengantarkan data ke sistem lain seperti database, Elasticsearch, dan data warehouse.

Ada satu perbedaan mendasar yang harus dipahami sejak awal: source connector (Debezium) memproduksi, sedangkan sink connector mengonsumsi. Pola ini membuat Kafka menjadi hub — data berubah sekali di sumber, lalu disebarkan ke banyak tujuan tanpa menambah beban ke database sumber.

#Menghubungkan Event CDC ke Kafka Consumers

Konsumen paling sederhana adalah console consumer untuk inspeksi cepat:

docker exec -it kafka /opt/kafka/bin/kafka-console-consumer.sh \
  --bootstrap-server localhost:9092 \
  --topic dbserver1.inventory.customers \
  --from-beginning \
  --property print.key=true

Untuk aplikasi nyata, konsumen memakai library seperti Kafka client, dengan prinsip yang sama: baca key dan value, cek bidang op, lalu lakukan aksi sesuai operasi. Karena Debezium memakai primary key sebagai message key, aplikasi bisa langsung memetakan event ke record di database target.

#Stream Processing dengan ksqlDB dan Kafka Streams

Alih-alih menulis logika consumer dari nol, kalian bisa memakai ksqlDB yang menyediakan SQL untuk stream processing:

Mendefinisikan stream dari topic CDC

CREATE STREAM customers_stream (
  id INT,
  first_name VARCHAR,
  last_name VARCHAR,
  email VARCHAR
) WITH (
  KAFKA_TOPIC = 'dbserver1.inventory.customers',
  VALUE_FORMAT = 'json'
);

Perhatikan bahwa topic CDC membawa wrapper schema dan payload, sehingga struktur VALUE_FORMAT = 'json' di atas disederhanakan — di produksi kalian memakai Unwrap SMT terlebih dahulu untuk melepas wrapper sebelum konsumen SQL memprosesnya.

Alternatif lain yang kuat:

• Kafka Streams: library Java/Scala untuk aplikasi stream processing stateful.
• Apache Flink: engine streaming terdistribusi untuk windowing dan stateful processing berat.
• Apache Spark: cocok untuk micro-batch dan analitik yang lebih berat.

Semuanya bisa membaca topic Debezium secara langsung sebagai sumber event.

#Sink Connector untuk Database dan Data Lake

Untuk mengalirkan data keluar dari Kafka, daftarkan sink connector. Contoh JDBC sink ke PostgreSQL:

{
  "name": "jdbc-sink",
  "config": {
    "connector.class": "io.confluent.connect.jdbc.JdbcSinkConnector",
    "tasks.max": "1",
    "topics": "dbserver1.inventory.customers",
    "connection.url": "jdbc:postgresql://postgres:5432/warehouse",
    "connection.user": "warehouse",
    "connection.password": "warehouse",
    "insert.mode": "upsert",
    "pk.fields": "id",
    "auto.create": "true",
    "auto.evolve": "true"
  }
}

Dengan insert.mode: "upsert", sink menimpa baris berdasarkan primary key — persis sesuai semantik event CDC. Tujuan sink lain yang umum:

• Elasticsearch untuk search dan observasi.
• Data lake seperti S3 dengan format Parquet atau Avro.
• Snowflake dan data warehouse lain untuk analytics.

#Use Case Materialized Views, Audit Logs, dan Analytics Pipeline

Kombinasi source dan sink menghasilkan pola arsitektur yang powerful:

• Materialized views: ksqlDB atau Kafka Streams mengagregasi event CDC menjadi tampilan terkini yang selalu diperbarui.
• Audit logs: setiap event dengan before dan after disimpan lengkap sebagai riwayat perubahan.
• Analytics pipeline: event CDC dialirkan ke warehouse sehingga laporan mencerminkan data terkini, bukan data batch kemarin.

MySQL → Debezium → Kafka topic → ksqlDB / Kafka Streams
                                       ├── materialized view
                                       ├── JDBC sink → warehouse
                                       └── Elasticsearch sink → search

Kunci keberhasilan pola ini adalah menjaga event tetap append-only di Kafka, sehingga sumber kebenaran tidak terpecah dan setiap tujuan bisa membaca dari titik yang sama.

Satu catatan penting: karena Kafka menjamin urutan per partisi, bukan per key lintas partisi, pastikan jumlah partisi topic sesuai kebutuhan sink. Konsumen sink yang membutuhkan urutan harus membaca partisi yang sama tempat key baris berada.

#Penutup

Episode 8 menutup sirkuit konsumsi: konsumen aplikasi membaca event langsung, stream processors mengolahnya secara real-time, dan sink connector mengantarkan data ke database, search, data lake, dan warehouse — semuanya dari satu aliran event yang sama.

Inti yang harus dibawa pulang:

• Source connector memproduksi event; sink connector mengonsumsi dan menulis ke sistem lain.
• ksqlDB dan Kafka Streams memungkinkan pengolahan real-time tanpa menambah beban ke database sumber.
• JDBC sink dengan mode upsert mencerminkan semantik CDC dengan baik.
• Event CDC bersifat append-only di Kafka, menjadi sumber kebenaran tunggal.
• Materialized views, audit logs, dan analytics pipeline adalah use case utama pola ini.

Di episode 9 selanjutnya kita akan membahas schema registry dan data contracts — membangun kontrak data untuk skema event, mengelola versioning dan compatibility rules, menangani evolusi skema pada payload Debezium, serta validasi konsumen dengan Avro dan Protobuf.