Belajar Apache Kafka - ksqlDB: SQL untuk Stream Processing

#Pendahuluan

Tidak semua orang ingin menulis topologi Kafka Streams dalam kode Java. ksqlDB hadir sebagai lapisan SQL di atas Kafka Streams: kalian mendeskripsikan stream dan table, lalu menulis query SQL untuk filtering, agregasi, dan join — dan ksqlDB mengubahnya menjadi aplikasi Streams yang berjalan di server.

Nilai ksqlDB terletak pada kemudahan: query yang butuh puluhan baris Java bisa ditulis dalam satu pernyataan SQL. Konsep-konsep yang sudah kalian pelajari di episode 13 tetap berlaku — KStream menjadi stream, KTable menjadi table — tetapi sekarang dioperasikan dengan sintaks yang familiar.

Episode 14 ini akan membahas konsep dasar ksqlDB, perbedaan stream dan table, jenis query (persistent, push, pull), agregasi dan join, serta cara menjalankan server dan CLI-nya.

#Konsep Dasar ksqlDB

#SQL Interface untuk Kafka Streams

ksqlDB menerjemahkan pernyataan SQL menjadi topology Kafka Streams. Kalian tidak menulis prosesor — kalian mendeklarasikan apa yang diinginkan, dan engine menghasilkan kode Streams di balik layar. Ini menurunkan hambatan masuk secara drastis untuk tim yang sudah akrab SQL.

#Stream vs Table

Dua entitas inti, sejalan dengan KStream dan KTable:

• STREAM: aliran event yang tidak berubah; setiap record adalah fakta baru. Mirip KStream.
• TABLE: pandangan per key yang menyimpan nilai terbaru. Mirip KTable, di-back oleh changelog compact.

#Persistent vs Push vs Pull Query

Tiga jenis query yang wajib kalian bedakan:

• Persistent query: query yang berjalan terus-menerus di latar belakang dan menulis hasilnya ke topic. Diawali CREATE STREAM AS SELECT atau CREATE TABLE AS SELECT.
• Push query: query yang men-subscribe dan mengalirkan hasil ke klien secara terus-menerus. Diawali SELECT ... EMIT CHANGES.
• Pull query (3.0+): query satu kali yang membaca nilai terkini dari materialized view. Diawali SELECT ... FROM table WHERE ... tanpa EMIT CHANGES.

#Bekerja dengan Stream dan Table

#Membuat Stream dan Table

Stream dibuat dari topic Kafka dengan CREATE STREAM, table dengan CREATE TABLE:

CREATE STREAM orders (
  order_id VARCHAR,
  user_id VARCHAR,
  amount DOUBLE
) WITH (
  KAFKA_TOPIC = 'orders',
  VALUE_FORMAT = 'JSON'
);
 
CREATE TABLE user_profiles (
  user_id VARCHAR PRIMARY KEY,
  name VARCHAR
) WITH (
  KAFKA_TOPIC = 'user-profiles',
  VALUE_FORMAT = 'AVRO'
);

KAFKA_TOPIC='orders' menghubungkan stream ke topic fisik, dan VALUE_FORMAT='JSON' menentukan format serialisasi. Perhatikan: table memakai PRIMARY KEY, stream tidak.

#INSERT INTO

Untuk menulis record ke stream, gunakan INSERT INTO — ksqlDB tidak mendukung INSERT biasa pada stream:

INSERT INTO orders (order_id, user_id, amount)
VALUES ('order-005', 'user-3', 150.50);

INSERT INTO orders menulis satu event ke topic orders melalui stream tersebut. Ini cara cepat menguji pipeline tanpa producer eksternal.

#Stream Processing dengan SQL

#Filtering dan Projection

Transformasi sederhana ditulis seperti SQL biasa:

CREATE STREAM paid_orders AS
  SELECT order_id, user_id, amount * 1.11 AS amount_with_tax
  FROM orders
  WHERE amount > 100
  EMIT CHANGES;

CREATE STREAM AS SELECT mendefinisikan persistent query yang terus mengalirkan hasil ke topic baru paid_orders — setiap record baru di orders langsung diproses.

#Agregasi dan Grouping

Agregasi per window menghasilkan materialized view yang selalu terbarui:

CREATE TABLE total_per_user AS
  SELECT user_id, SUM(amount) AS total
  FROM orders
  WINDOW TUMBLING (SIZE 1 MINUTE)
  GROUP BY user_id
  EMIT CHANGES;

WINDOW TUMBLING (SIZE 1 MINUTE) membuat window satu menit seperti tumbling window di episode 13, dan GROUP BY user_id mengagregasi total per pengguna. Hasilnya adalah KTable yang tersimpan sebagai topic.

#Join Antar Entitas

ksqlDB mendukung tiga pola join yang sama dengan Kafka Streams:

CREATE STREAM orders_enriched AS
  SELECT o.order_id, o.amount, u.name
  FROM orders o
  LEFT JOIN user_profiles u ON o.user_id = u.user_id
  EMIT CHANGES;

LEFT JOIN user_profiles memperkaya setiap order dengan nama pengguna dari table — pola stream-table join yang paling sering dipakai untuk enrichment data real-time.

#Deployment ksqlDB

#Server dan CLI

ksqlDB berjalan sebagai server yang mengeksekusi semua query. CLI terhubung ke server untuk menulis pernyataan:

ksql-server-start config/ksql-server.properties
ksql http://localhost:8088

Server membuka port 8088 untuk koneksi CLI dan REST API. Semua query persistent tersimpan di server, sehingga restart server tidak menghapusnya.

#REST API dan Scaling

REST API memungkinkan integrasi dengan aplikasi:

curl -X POST http://localhost:8088/query \
  -H "Content-Type: application/vnd.ksql.v1+json" \
  -d '{"ksql": "SELECT * FROM total_per_user EMIT CHANGES;", "streamsProperties": {}}'

curl -X POST http://localhost:8088/query mengirim query push dan menerima aliran hasil. Untuk scaling, ksqlDB cluster terdiri dari beberapa server yang berbagi work melalui internal topic — tambah node untuk menambah kapasitas, dengan state store terdistribusi otomatis.

#Penutup

Di episode 14 ini kalian sudah memahami ksqlDB sebagai SQL untuk Kafka Streams, perbedaan stream dan table, persistent, push, dan pull query, operasi filtering, agregasi, dan join, serta deployment server, CLI, dan REST API.

Inti yang harus dibawa pulang:

• ksqlDB menerjemahkan SQL menjadi topology Kafka Streams.
• STREAM untuk event, TABLE untuk state per key.
• Persistent query menulis terus ke topic; push query mengalir ke klien; pull query membaca sekali.
• Agregasi windowing dengan WINDOW TUMBLING menghasilkan materialized view.
• Stream-table join untuk enrichment data real-time.
• Server ksqlDB mengeksekusi query dan menyimpannya lintas restart.

Di episode 15 selanjutnya kita akan membahas network configuration dan multi-datacenter — advertised listeners, protokol PLAINTEXT dan SSL, komunikasi inter-broker, hingga pola active-active dan active-passive lintas datacenter. Persiapkan pemahaman networking kalian, karena keamanan di episode 16-18 bergantung pada fondasi ini.