Wie funktioniert die Log Compaction in Apache Kafka und welche Auswirkungen hat sie auf den Consumer-Offset?
Log Compaction in Apache Kafka ist ein Mechanismus, der sicherstellt, dass für jeden Nachrichtenschlüssel nur der letzte bekannte Wert im Log gespeichert wird. Im Gegensatz zur Standard-Retention-Policy, die Daten nach Zeit oder Größe löscht, konzentriert sich die Compaction auf die Schlüssel-Wert-Paare. Dies ist besonders nützlich für die Modellierung von Zuständen (State Stores), bei denen nur der aktuelle Wert einer Entität relevant ist.
Der Prozess wird durch den log.cleaner-Thread gesteuert. Dieser scannt die Log-Segmente und identifiziert Duplikate desselben Schlüssels. Ältere Versionen desselben Schlüssels werden markiert und in einem neuen, bereinigten Segment weggelassen.
Die Unterschiede zur klassischen Löschstrategie lassen sich wie folgt zusammenfassen:
| Merkmal | Delete Policy (Standard) | Compact Policy |
|---|---|---|
| Löschkriterium | Zeit (log.retention.hours) oder Größe | Schlüssel-Duplikate |
| Datenverlust | Älteste Datensätze werden entfernt | Historische Werte desselben Schlüssels verschwinden |
| Primärer Anwendungsfall | Event-Streaming, Telemetrie | Datenbank-Snapshots, Konfigurationen |
| Log-Struktur | Kontinuierlich abnehmend | Behält mindestens einen Wert pro Key |
Bezüglich des Consumer-Offsets führt Log Compaction zu Lücken in der Sequenz der Offsets. Wenn ein Consumer eine Partition liest und auf einen Offset stößt, der durch die Compaction entfernt wurde, springt der Kafka-Client automatisch zum nächsten verfügbaren Offset im Log.
Für den Consumer bedeutet dies, dass er keine Fehlermeldung erhält, sondern einfach die älteren Versionen des Schlüssels überspringt. In unseren Projekten im Bereich IT-Consulting & Digitale Strategie implementieren wir diesen Ansatz häufig, um die Wiederherstellungszeit von State-Stores nach einem Neustart zu verkürzen, da der Consumer nicht das gesamte historische Event-Log lesen muss, sondern nur den kompaktierten Endzustand.
Es ist jedoch zu beachten, dass Tombstones (Nachrichten mit null-Wert) genutzt werden müssen, um einen Schlüssel vollständig aus dem kompaktierten Log zu entfernen. Ohne Tombstone bleibt der letzte bekannte Wert dauerhaft gespeichert.
Wir empfehlen, Log Compaction ausschließlich für die Speicherung von Zuständen einzusetzen und niemals für Event-Streams, bei denen die zeitliche Abfolge oder die Historie aller Änderungen für die Geschäftslogik relevant ist.
Andere Fragen in dieser Kategorie
Andere Nutzer suchten auch nach:
Diese Fragen könnten Sie ebenfalls interessieren.
Inwiefern optimiert der Tungsten-Engine in Spark die Speicherverwaltung durch Binary Layouts und Unsafe-Operationen?
data-engineeringInwiefern unterscheidet sich das Z-Ordering von herkömmlichem Hive-Partitioning hinsichtlich der Data-Skipping-Effizienz?
data-engineeringWas ist der technische Unterschied zwischen 'At-least-once' und 'Exactly-once' Delivery in Kafka-Producer-Konfigurationen?
data-engineeringWas ist der technische Unterschied zwischen einer 'Push-based' und einer 'Pull-based' Orchestrierung in Prefect oder Dagster?
data-engineeringWas ist der technische Unterschied zwischen einer Broadcast Hash Join und einem Sort Merge Join in verteilten Systemen?
