Belajar Apache Kafka - Log Compaction

#Pendahuluan

Pada episode 4 kalian sudah mengenal cleanup policy compact sekilas. Sekarang kita bedah secara utuh. Log compaction adalah mekanisme Kafka untuk membersihkan log dengan cara yang berbeda dari retention delete: alih-alih membuang data berdasarkan umur, kompaksi membuang semua versi lama dari sebuah key dan hanya mempertahankan nilai terbaru.

Kenapa ini penting? Bayangkan topic user-profiles: setiap update profil menulis record baru dengan key user_id. Seiring waktu, mayoritas data di log adalah versi lama yang tidak lagi relevan. Dengan kompaksi, Kafka meringkas log menjadi satu nilai terbaru per user — tanpa kehilangan informasi terkini.

Episode 10 ini akan membahas konsep kompaksi dengan tombstone, parameter konfigurasi yang mengendalikan perilakunya, use case di dunia nyata seperti changelog topic dan materialized views, serta cara memantau kesehatan kompaksi.

#Konsep Log Compaction

#Cleanup Policy Compact

Dengan cleanup.policy=compact, broker tidak menghapus record berdasarkan waktu, melainkan menjaga log sedemikian rupa sehingga untuk setiap key hanya nilai terbaru yang tersimpan. Record dengan key yang sama yang lebih tua dibuang oleh proses background bernama cleaner.

Kompaksi mempertahankan satu snapshot per key sambil tetap menyimpan record dengan key unik selama retention masih berlaku. Akibatnya, jumlah data dalam topic compact terus mendekati jumlah key, bukan jumlah tulis.

#Tombstone untuk Menghapus

Bagaimana cara menghapus sebuah key sepenuhnya? Jawabannya adalah tombstone: record dengan key tertentu dan value null. Cleaner menganggap tombstone sebagai penanda "hapus key ini" dan membuang key tersebut dari log beserta semua versi sebelumnya.

Sebelum : (k1,v1) (k1,v2) (k2,v1) (k1,v3) (k2,v2) (k2,null)
Sesudah : (k1,v3) (k2,null)

Tombstone sendiri tidak langsung hilang; ia ditahan selama delete.retention.ms sebelum akhirnya dihapus juga. Ini memberi konsumen waktu untuk menangkap peristiwa penghapusan.

#Retaining Latest Value per Key

Perhatikan nuansa penting: kompaksi bukan jaminan waktu nyata. Record di segmen aktif yang masih terbuka tidak bisa dikompaksi. Kompaksi baru bekerja pada segmen yang sudah tertutup dan cukup "kotor" (mengandung banyak versi usang), sehingga data terbaru selalu utuh selama segmen aktif masih menerima tulis.

#Konfigurasi Kompaksi

#Parameter Inti

Konfigurasi kompaksi diatur lewat kafka-configs.sh per topic:

bin/kafka-configs.sh --bootstrap-server localhost:9092 \
  --alter --entity-type topics --entity-name user-profiles \
  --add-config cleanup.policy=compact,min.compaction.lag.ms=60000,min.cleanable.dirty.ratio=0.5

Parameter kunci yang perlu kalian pahami:

• min.compaction.lag.ms: berapa lama sebuah record minimal bertahan sebelum bisa dikompaksi. Melindungi konsumen yang masih membaca data dengan penundaan.
• max.compaction.lag.ms: batas maksimum waktu record boleh menunggu kompaksi; memastikan data tidak menumpuk selamanya jika dirty ratio rendah.
• delete.retention.ms: berapa lama tombstone dipertahankan setelah kompaksi.
• min.cleanable.dirty.ratio: rasio bagian log yang "kotor" sebelum cleaner mulai bekerja. Nilai 0.5 berarti cleaner menunggu sampai setengah segmen berisi versi usang.
• segment.ms dan segment.bytes: menentukan kapan segmen ditutup, yang menjadi syarat awal kompaksi bisa bekerja.

#Menyetel Keseimbangan

cleanup.policy=compact
min.compaction.lag.ms=60000
max.compaction.lag.ms=300000
delete.retention.ms=86400000
min.cleanable.dirty.ratio=0.5

Aturan praktis: min.cleanable.dirty.ratio rendah membuat kompaksi lebih sering (lebih banyak CPU) tapi log lebih ringkas; nilai tinggi menghemat CPU namun log membengkak lebih lama. Kombinasi min.compaction.lag.ms dan delete.retention.ms wajib direncanakan agar konsumen lambat tidak kehilangan data.

#Use Case Log Compaction

#Changelog Topic dan Materialized Views

Kafka Streams menyimpan state di dalam state store dan mereplikasikannya lewat changelog topic yang ber-cleanup.policy=compact. Karena hanya nilai terbaru per key yang dibutuhkan untuk pemulihan state, kompaksi membuat changelog tetap kecil. Materialized view yang dibangun dari compact topic otomatis merepresentasikan state terkini.

#State Store Backends

RocksDB dan state store lainnya memakai changelog compact untuk recovery: ketika instance crash, ia membaca changelog dari posisi terakhir checkpoint. Tanpa kompaksi, recovery harus membaca seluruh sejarah; dengan kompaksi, hanya snapshot terakhir per key.

#CDC dan Snapshot Data

Pola Change Data Capture (episode 27) sering menulis perubahan database ke topic compact. Satu compact topic accounts merepresentasikan tabel terbaru di database: setiap key adalah primary key, dan nilai terbaru adalah state terkini baris tersebut. Data warehouse bisa dibangun ulang dengan membaca snapshot lengkap kapan pun.

#Memantau Kompaksi

#Metrik Cleaner

Broker mengekspos metrik untuk proses cleaner melalui JMX:

• log-cleaner-clean-time-percent: persentase waktu cleaner aktif; nilai konsisten di atas 50-70 persen menandakan beban kompaksi tinggi.
• log-cleaner-cleaner-buffer-utilization: penggunaan buffer cleaner; mendekati 100 persen berarti log terlalu besar untuk buffer yang tersedia.
• log-cleaner-dirty-ratio: dirty ratio rata-rata log yang sedang dikompaksi.

#Kompaksi Lag dan Dirty Ratio

Kompaksi dikatakan lag ketika ada segmen tua yang tidak kunjung dibersihkan, biasanya karena max.compaction.lag.ms terlalu besar atau cleaner kekurangan thread. Pantau dua hal: jumlah segmen yang melebihi max.compaction.lag.ms, dan dirty ratio yang terus naik. Keduanya menandakan cleaner tidak mampu mengejar laju tulis.

bin/kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.log:type=LogCleaner,name=clean-time-percent --report-format=txt

kafka.tools.JmxTool adalah alat bawaan untuk membacakan metrik JMX dari terminal. Dalam praktik produksi, metrik ini lebih sering dikumpulkan ke Prometheus (detail di episode 22).

#Penutup

Di episode 10 ini kalian sudah memahami bahwa log compaction meringkas log menjadi nilai terbaru per key, cara tombstone menghapus key, parameter konfigurasi seperti min.compaction.lag.ms, max.compaction.lag.ms, delete.retention.ms, dan min.cleanable.dirty.ratio, serta use case changelog topic, materialized views, state store, dan CDC.

Inti yang harus dibawa pulang:

• Compaction menyimpan nilai terbaru per key, bukan semua histori.
• Tombstone (value null) adalah cara menghapus key dari log compact.
• Cleaner hanya bekerja pada segmen tertutup, jadi data aktif selalu utuh.
• Dirty ratio mengontrol frekuensi kompaksi; kompaksi lag berarti cleaner kewalahan.
• Changelog topic dan state store Kafka Streams bergantung pada kompaksi.
• compact,delete menggabungkan ringkasan per key dengan batasan umur data.

Di episode 11 selanjutnya kita akan membahas tiered storage (KIP-405) — kemampuan Kafka meng-offload segmen lama ke object storage seperti S3, GCS, dan Azure Blob. Kalian akan belajar konfigurasi remote storage, perbedaan retention lokal dan remote, serta trade-off biaya penyimpanan versus latensi baca.