Kafka Topic Advanced: Log Compaction

Konfigurasi Topik Kafka: Log Compaction

Dalam Apache Kafka, kebijakan retensi data menentukan bagaimana dan kapan data dihapus dari topik untuk mengelola penyimpanan. Salah satu kebijakan retensi yang kuat di Kafka adalah log compaction, yang memungkinkan penyimpanan hanya nilai terbaru untuk setiap kunci dalam topik, menjadikannya ideal untuk kasus penggunaan yang memerlukan snapshot data terkini, bukan riwayat lengkap. Artikel ini akan menjelaskan apa itu log compaction, cara kerjanya, jaminan yang diberikan, serta langkah-langkah praktis untuk mengonfigurasinya menggunakan alat CLI. Kami juga akan membahas mitos umum, kasus penggunaan, dan praktik terbaik untuk mengelola topik dengan log compaction.

Kebijakan Retensi Data di Kafka

Kafka mengelola penyimpanan data melalui kebijakan pembersihan log (log cleanup policy), yang ditentukan oleh parameter log.cleanup.policy. Ada dua kebijakan utama:

1. delete:

   • Deskripsi: Menghapus pesan yang lebih lama dari periode retensi (dikonfigurasi melalui retention.ms atau retention.bytes). Ini adalah kebijakan default untuk topik pengguna.

   • Default: Retensi waktu adalah 1 minggu (604800000 ms).

   • Kasus Penggunaan: Cocok untuk data yang hanya perlu disimpan sementara, seperti log aplikasi atau metrik sementara.

   • Referensi: Kebijakan ini telah dibahas dalam artikel sebelumnya tentang Log Retention.

2. compact:

   • Deskripsi: Hanya menyimpan nilai terbaru untuk setiap kunci dalam topik, menghapus pesan lama dengan kunci yang sama. Ini adalah kebijakan default untuk topik internal Kafka __consumer_offsets.

   • Kasus Penggunaan: Ideal untuk menyimpan snapshot data terkini, seperti informasi status atau konfigurasi.

   • Prasyarat: Topik harus diproduksi dengan pesan yang memiliki kunci dan nilai (key-value pairs).

Tujuan Log Cleanup

Kafka tidak dirancang untuk menyimpan data selamanya (meskipun opsi seperti Tiered Storage kini memungkinkan penyimpanan jangka panjang). Kebijakan pembersihan log memungkinkan administrator untuk:

• Mengontrol Ukuran Data di Disk: Menghapus data usang untuk mencegah disk penuh.

• Mengurangi Beban Pemeliharaan: Mengotomatiskan manajemen penyimpanan di klaster Kafka.

• Membatasi Data Historis: Memastikan konsumer tidak perlu memproses data historis yang berlebihan untuk mengejar ketinggalan.

Teori Log Compaction

Konsep Dasar

Log compaction memastikan bahwa Kafka hanya menyimpan nilai terbaru untuk setiap kunci dalam partisi topik. Ini sangat berguna untuk kasus penggunaan di mana Anda hanya memerlukan snapshot data terkini, bukan riwayat lengkap. Misalnya:

• Contoh Kasus Penggunaan: Menyimpan informasi gaji karyawan, di mana Anda hanya ingin menyimpan gaji terbaru untuk setiap ID karyawan, bukan riwayat perubahan gaji.

• Mekanisme: Kafka menghapus pesan lama dengan kunci yang sama, hanya mempertahankan pesan terbaru untuk setiap kunci dalam partisi.

Cara Kerja Log Compaction

1. Penulisan Data:

   • Aplikasi memproduksi pesan dengan kunci dan nilai ke topik. Kunci (misalnya, ID karyawan) digunakan untuk mengidentifikasi entitas, dan nilai (misalnya, gaji) adalah data yang diperbarui.

   • Pesan ditambahkan ke segmen aktif partisi, seperti operasi normal Kafka.

2. Proses Compaction:

   • Ketika log compaction diaktifkan, Kafka menjalankan cleaner threads di latar belakang untuk memproses segmen yang sudah ditutup (segmen aktif tidak disentuh).

   • Cleaner thread memeriksa setiap pesan dalam segmen lama:

     • Jika pesan adalah nilai terbaru untuk kunci tertentu, pesan tersebut disalin ke segmen pengganti.

     • Jika ada pesan yang lebih baru dengan kunci yang sama di segmen lain, pesan lama diabaikan.

   • Setelah semua pesan terbaru disalin, segmen pengganti menggantikan segmen asli.

3. Hasil:

   • Setiap kunci dalam partisi hanya memiliki satu pesan—yang terbaru.

   • Offset pesan tetap dipertahankan, tetapi offset untuk pesan yang dihapus akan dilewati (skipped).

Jaminan Log Compaction

Kafka memberikan beberapa jaminan penting untuk topik dengan log compaction:

• Ketersediaan Data Terkini: Konsumer yang membaca dari ujung log (tail) akan selalu melihat semua pesan baru yang diproduksi, terlepas dari apakah log compaction diaktifkan.

• Urutan Kunci dan Partisi: Log compaction hanya menghapus pesan lama, tidak mengubah urutan pesan berdasarkan kunci atau partisi.

• Offset Tetap: Offset pesan bersifat immutable (tidak berubah). Jika pesan dihapus, offset-nya tetap ada tetapi dilewati.

• Retensi Penanda Hapus (Tombstone): Pesan dengan nilai null (disebut tombstone) digunakan untuk menandai penghapusan kunci. Tombstone ini disimpan selama periode tertentu (dikonfigurasi melalui log.cleaner.delete.retention.ms, default 24 jam) agar konsumer dapat melihatnya sebelum dihapus.

Tombstone

• Definisi: Pesan dengan kunci tertentu dan nilai null dianggap sebagai tombstone, menandakan bahwa semua pesan sebelumnya dengan kunci tersebut harus dihapus.

• Fungsi: Memungkinkan penghapusan eksplisit data dari topik. Misalnya, jika Anda mengirimkan pesan key: employee123, value: null, semua pesan sebelumnya untuk employee123 akan dihapus selama compaction.

• Retensi: Tombstone disimpan selama log.cleaner.delete.retention.ms untuk memberikan waktu bagi konsumer untuk membaca penanda hapus sebelum dihapus dari log.

Mitos Umum tentang Log Compaction

1. Mitos: Log Compaction Mencegah Data Duplikat Ditulis ke Kafka:

   • Fakta: Log compaction tidak mencegah data duplikat diproduksi. Pesan duplikat akan ditulis ke segmen aktif dan hanya dihapus selama proses compaction setelah segmen ditutup.

2. Mitos: Log Compaction Mencegah Pembacaan Data Duplikat:

   • Fakta: Konsumer yang memulai ulang dari offset sebelumnya mungkin melihat data duplikat karena semantik at-least-once Kafka. Compaction hanya memengaruhi penyimpanan, bukan pembacaan langsung dari tail.

Konfigurasi Log Compaction

Log compaction diaktifkan dengan mengatur log.cleanup.policy=compact. Berikut adalah parameter konfigurasi utama yang memengaruhi log compaction:

1. log.cleanup.policy:

   • Deskripsi: Menentukan kebijakan pembersihan log. Nilai compact mengaktifkan log compaction.

   • Default: delete untuk topik pengguna, compact untuk topik __consumer_offsets.

   • Level: Topik atau broker.

2. log.cleaner.enable:

   • Deskripsi: Mengaktifkan atau menonaktifkan log cleaner. Nonaktifkan sementara hanya jika diperlukan (tidak disarankan, karena memengaruhi topik __consumer_offsets).

   • Default: true.

   • Level: Broker.

3. log.cleaner.threads:

   • Deskripsi: Jumlah thread latar belakang untuk log compaction.

   • Default: 1.

   • Level: Broker.

4. log.segment.ms:

   • Deskripsi: Waktu maksimum sebelum segmen ditutup (default: 7 hari). Segmen yang ditutup dapat diproses untuk compaction.

   • Level: Topik atau broker.

5. log.segment.bytes:

   • Deskripsi: Ukuran maksimum segmen (default: 1 GB). Segmen yang lebih kecil memungkinkan compaction lebih sering.

   • Level: Topik atau broker.

6. log.cleaner.delete.retention.ms:

   • Deskripsi: Durasi penyimpanan tombstone dan penanda transaksi setelah memenuhi syarat untuk dihapus.

   • Default: 24 jam (86400000 ms).

   • Level: Topik atau broker.

7. log.cleaner.min.compaction.lag.ms:

   • Deskripsi: Waktu minimum pesan harus ada sebelum dapat diproses untuk compaction. Melindungi pesan baru dari penghapusan.

   • Default: 0 (semua segmen kecuali segmen aktif dapat diproses).

   • Level: Topik atau broker.

8. log.cleaner.max.compaction.lag.ms:

   • Deskripsi: Waktu maksimum pesan dapat tetap tidak dikompaksi. Mencegah topik dengan tingkat produksi rendah tidak dikompaksi terlalu lama.

   • Default: Tidak terbatas.

   • Level: Topik atau broker.

9. min.cleanable.dirty.ratio:

   • Deskripsi: Rasio minimum data "kotor" (pesan yang belum dikompaksi) terhadap total data untuk memicu compaction. Jika log.cleaner.min.compaction.lag.ms atau log.cleaner.max.compaction.lag.ms juga ditentukan, compaction dipicu ketika salah satu kriteria terpenuhi.

   • Default: 0.5 (50%).

   • Level: Broker.

10. log.cleaner.backoff.ms:

    • Deskripsi: Waktu tidur cleaner threads ketika tidak ada log untuk dikompaksi.

    • Default: 15 detik (15000 ms).

    • Level: Broker.

Praktik Log Compaction

Berikut adalah panduan praktis untuk mengatur topik dengan log compaction menggunakan alat CLI, berdasarkan contoh kasus penggunaan menyimpan gaji terbaru karyawan dalam topik bernama employee-salary.

Prasyarat

• Pastikan klaster Kafka berjalan (mode Zookeeper atau KRaft).

• Gunakan ekstensi CLI yang sesuai: .sh untuk Linux/Mac, .bat untuk Windows.

• Pastikan broker Kafka aktif di localhost:9092.

• Peringatan untuk Pengguna Windows: Log compaction memiliki bug di Windows (KAFKA-1194) yang dapat menyebabkan crash. Gunakan WSL2 untuk menghindari masalah ini, atau hapus folder di log.dirs secara manual jika terjadi crash.

Langkah-langkah Konfigurasi

1. Buat Topik dengan Log Compaction: Buat topik employee-salary dengan 1 partisi, faktor replikasi 1, dan konfigurasi untuk log compaction:

   kafka-topics.sh --bootstrap-server localhost:9092 --create --topic employee-salary \
   --partitions 1 --replication-factor 1 \
   --config cleanup.policy=compact \
   --config min.cleanable.dirty.ratio=0.001 \
   --config segment.ms=5000

   • Penjelasan:

     • partitions=1: Memastikan semua pesan masuk ke partisi yang sama untuk konsistensi kunci.

     • cleanup.policy=compact: Mengaktifkan log compaction.

     • min.cleanable.dirty.ratio=0.001: Memastikan compaction dipicu sering, bahkan dengan sedikit data kotor.

     • segment.ms=5000: Membuat segmen baru setiap 5 detik untuk mempercepat compaction pada segmen yang ditutup.

2. Verifikasi Konfigurasi Topik: Periksa konfigurasi topik:

   kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic employee-salary

   Contoh keluaran:

   Topic: employee-salary TopicId: XYZ123 PartitionCount: 1 ReplicationFactor: 1 Configs: cleanup.policy=compact,min.cleanable.dirty.ratio=0.001,segment.ms=5000
   Topic: employee-salary Partition: 0 Leader: 1 Replicas: 1 Isr: 1

3. Jalankan Konsumer Konsol: Mulai konsumer untuk melihat pesan dari awal, menampilkan kunci dan nilai:

   kafka-console-consumer.sh --bootstrap-server localhost:9092 \
   --topic employee-salary \
   --from-beginning \
   --property print.key=true \
   --property key.separator=,

4. Jalankan Produser Konsol: Buka terminal lain dan jalankan produser untuk mengirim pesan dengan kunci dan nilai, dipisahkan oleh koma:

   kafka-console-producer.sh --bootstrap-server localhost:9092 \
   --topic employee-salary \
   --property parse.key=true \
   --property key.separator=,

5. Kirim Pesan dengan Kunci Duplikat: Kirim beberapa pesan dengan kunci duplikat untuk mensimulasikan pembaruan gaji:

   Patrick,salary: 10000
   Lucy,salary: 20000
   Bob,salary: 20000
   Patrick,salary: 25000
   Lucy,salary: 30000
   Patrick,salary: 30000

   Tunggu beberapa saat (misalnya, 1 menit) agar compaction berjalan.

6. Kirim Pesan Tambahan: Kirim pesan tambahan:

   Stephane,salary: 0

7. Verifikasi Hasil Compaction: Hentikan konsumer dan mulai ulang untuk melihat pesan dari awal:

   kafka-console-consumer.sh --bootstrap-server localhost:9092 \
   --topic employee-salary \
   --from-beginning \
   --property print.key=true \
   --property key.separator=,

   Contoh keluaran setelah compaction:

   Bob,salary: 20000
   Lucy,salary: 30000
   Patrick,salary: 30000
   Stephane,salary: 0

   Hanya nilai terbaru untuk setiap kunci yang tersisa setelah compaction.

Catatan

• Log compaction berjalan otomatis di latar belakang dan tidak dapat dipicu secara manual melalui API.

• Frekuensi compaction dipengaruhi oleh log.segment.ms, min.cleanable.dirty.ratio, dan parameter lainnya.

Praktik Terbaik

1. Gunakan Kunci yang Konsisten:

   • Pastikan aplikasi memproduksi pesan dengan kunci yang konsisten untuk memanfaatkan log compaction. Tanpa kunci, compaction tidak akan bekerja.

2. Atur segment.ms untuk Compaction Cepat:

   • Gunakan nilai segment.ms yang kecil (misalnya, 5000 ms) untuk topik dengan tingkat produksi rendah agar segmen ditutup lebih sering, memungkinkan compaction lebih cepat.

3. Konfigurasi min.cleanable.dirty.ratio Rendah:

   • Atur min.cleanable.dirty.ratio ke nilai kecil (misalnya, 0.001) untuk memicu compaction lebih sering, terutama pada topik dengan lalu lintas rendah.

4. Pantau Retensi Tombstone:

   • Sesuaikan log.cleaner.delete.retention.ms untuk memastikan konsumer memiliki cukup waktu untuk melihat tombstone (default: 24 jam).

5. Uji di Lingkungan Non-Produksi:

   • Uji log compaction di lingkungan pengujian untuk memahami dampaknya pada konsumer dan penyimpanan.

6. Pantau Metrik Compaction:

   • Gunakan metrik seperti uncleanable-partitions-count, max-clean-time-secs, dan max-compaction-delay-secs untuk memantau performa compaction.

7. Hindari Windows Tanpa WSL2:

   • Jika menggunakan Windows, gunakan WSL2 untuk menghindari bug log compaction (KAFKA-1194).

8. Kombinasikan dengan Retensi Waktu atau Ukuran:

   • Gunakan retention.ms atau retention.bytes bersama cleanup.policy=compact untuk membatasi ukuran atau waktu retensi data yang tidak dikompaksi.

Penjelasan Tambahan

Hubungan dengan Segmen

Log compaction hanya bekerja pada segmen yang sudah ditutup. Parameter seperti log.segment.ms dan log.segment.bytes memengaruhi seberapa sering segmen ditutup, sehingga memengaruhi frekuensi compaction. Untuk topik dengan tingkat produksi rendah, atur segment.ms ke nilai kecil untuk mempercepat compaction.

Mode KRaft

Dalam mode KRaft (Kafka tanpa Zookeeper, mulai versi 3.3), log compaction berfungsi sama, tetapi manajemen metadata lebih efisien karena ditangani oleh controller Kafka. Pastikan untuk menguji konfigurasi compaction dalam mode KRaft.

Pemecahan Masalah

Jika log compaction tidak berjalan sesuai harapan:

• Periksa Segmen Aktif:

  ls -l /tmp/kafka-logs/employee-salary-0/

  Pastikan segmen ditutup secara teratur (periksa waktu modifikasi).

• Periksa Konfigurasi:

  kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic employee-salary

  Pastikan cleanup.policy=compact dan parameter lain seperti min.cleanable.dirty.ratio sudah benar.

• Pantau Cleaner Threads: Gunakan metrik JMX untuk memeriksa aktivitas cleaner threads dan memastikan tidak ada kemacetan.

Jika konsumer melihat data duplikat:

• Periksa apakah konsumer memulai ulang dari offset lama.

• Pastikan log.cleaner.delete.retention.ms cukup panjang untuk mendukung latensi konsumer.

Kesimpulan

Log compaction adalah kebijakan retensi yang kuat di Kafka untuk menyimpan hanya nilai terbaru untuk setiap kunci, ideal untuk kasus penggunaan seperti menyimpan snapshot data terkini. Dengan mengatur log.cleanup.policy=compact dan parameter terkait seperti segment.ms dan min.cleanable.dirty.ratio, Anda dapat mengelola penyimpanan secara efisien sambil memastikan konsumer melihat data terbaru. Meskipun compaction berjalan otomatis di latar belakang, konfigurasi yang tepat dan pemantauan metrik penting untuk keberhasilan. Dengan memahami jaminan, mitos, dan praktik terbaik, Anda dapat memanfaatkan log compaction untuk mendukung aplikasi dengan kebutuhan data terkini.