Kafka-Datenaufbewahrung: Verstehen und Verwalten Ihrer Ereignisströme

Die Kafka-Datenaufbewahrung beantwortet eine praktische Frage: Wie lange sollten Ihre Ereignisströme auf der Festplatte bleiben, bevor Kafka sie löschen kann? Wenn Ihre Einstellungen zu locker sind, können den Brokern der Speicherplatz ausgehen. Wenn sie zu aggressiv sind, könnte ein langsamer Consumer die Möglichkeit verlieren, Daten erneut abzuspielen.

Kafka speichert Datensätze in Partitionslogs. Diese Logs sind in Segmentdateien unterteilt, und die Bereinigung der Aufbewahrung löscht alte geschlossene Segmente. Dieses Detail ist wichtig, da Kafka normalerweise nicht einen Datensatz nach dem anderen löscht, sobald er alt wird. Ein Segment wird erst dann berechtigt, wenn es die konfigurierten Aufbewahrungsregeln erfüllt.

Warum Aufbewahrungseinstellungen wichtig sind

Die Aufbewahrung ist ein Kompromiss zwischen Speicher, Wiedergabebedarf und Betriebsrisiko.

• Speicherkosten: Eine lange Aufbewahrung bei Themen mit hohem Volumen kann viel Festplattenspeicher der Broker verbrauchen.
• Consumer-Wiederherstellung: Ihr Aufbewahrungsfenster muss länger sein als der längste realistische Consumer-Ausfall oder das längste realistische Wiederholungsfenster.
• Stabilität: Volle Festplatten können Broker daran hindern, Schreibvorgänge zu akzeptieren, und können breitere Cluster-Probleme auslösen.
• Compliance: Einige Daten müssen für einen Mindestzeitraum aufbewahrt werden, während andere Daten schnell entfernt werden sollten.

Ein Zahlungsthema benötigt möglicherweise mehrere Tage Wiedergabeverlauf. Ein Debug-Log-Thema in einem Entwicklungschuster benötigt möglicherweise nur wenige Stunden.

Wie Kafka alte Daten löscht

Kafka-Themen sind in Partitionen unterteilt. Jede Partition ist ein geordnetes, nur anfügbares Log. Kafka schreibt neue Datensätze in das aktive Segment und wechselt zu einem neuen Segment, wenn das aktuelle eine konfigurierte Größe oder ein konfiguriertes Alter erreicht.

Die Aufbewahrung gilt pro Partition. Wenn Sie retention.bytes=1073741824 setzen, sind das ungefähr 1 GiB pro Partition, nicht 1 GiB für das gesamte Thema. Ein Thema mit 12 Partitionen kann daher etwa 12 GiB behalten, bevor Replikate gezählt werden.

Wenn sowohl zeitbasierte als auch größenbasierte Aufbewahrung konfiguriert sind, kann Kafka berechtigte alte Segmente löschen, wenn einer der Limits eine Bereinigung erfordert.

Zeitbasierte Aufbewahrung

Die zeitbasierte Aufbewahrung behält Datensätze für einen konfigurierten Zeitraum.

Auf Broker-Ebene legt log.retention.ms den Standardwert für Themen fest, die ihn nicht überschreiben. Auf Themenebene überschreibt retention.ms diesen Standardwert für ein Thema.

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --alter \
  --add-config retention.ms=259200000

Dieses Beispiel setzt orders auf drei Tage. Überprüfen Sie es mit:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --describe

Verwenden Sie die Zeitaufbewahrung, wenn Ihre Hauptanforderung ein Wiedergabefenster ist, z. B. „Consumer müssen in der Lage sein, sich von einem Wochenendausfall zu erholen.“

Größenbasierte Aufbewahrung

Die größenbasierte Aufbewahrung begrenzt, wie viele Logdaten jede Partition behalten kann.

Auf Broker-Ebene legt log.retention.bytes das Standardlimit pro Partition fest. Auf Themenebene überschreibt retention.bytes es für ein Thema. Ein Wert von -1 bedeutet kein Größenlimit von dieser Einstellung.

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name high-volume-logs \
  --alter \
  --add-config retention.bytes=1073741824

Das setzt ein Limit von 1 GiB pro Partition. Verwenden Sie die größenbasierte Aufbewahrung, wenn der Festplattenschutz wichtiger ist als ein festes Zeitfenster. Seien Sie vorsichtig bei Themen mit Burst-Verkehr, da ein Verkehrsspitze das effektive Wiedergabefenster verkürzen kann.

Broker-Standardwerte und Themenüberschreibungen

Broker-Standardwerte befinden sich in server.properties und gelten für Themen, die keine eigenen Aufbewahrungswerte setzen.

log.retention.ms=604800000
log.retention.bytes=-1
log.retention.check.interval.ms=300000

Das Ändern von Broker-Standardwerten erfordert normalerweise einen Broker-Neustart oder eine dynamische Broker-Konfigurationsänderung, abhängig von Ihrer Kafka-Version und Ihren Bereitstellungswerkzeugen. Themenebenen-Änderungen über kafka-configs.sh sind oft sicherer, da verschiedene Themen selten dasselbe Aufbewahrungsfenster benötigen.

Legen Sie für ein neues Thema die Aufbewahrung bei der Erstellung fest:

kafka-topics.sh --bootstrap-server localhost:9092 \
  --create \
  --topic audit-events \
  --partitions 6 \
  --replication-factor 3 \
  --config retention.ms=604800000 \
  --config retention.bytes=2147483648

Ändern Sie für ein vorhandenes Thema die Themenkonfiguration:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --add-config retention.ms=1209600000

Um zum Broker-Standardwert zurückzukehren, löschen Sie die Themenüberschreibung:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --delete-config retention.ms

Aufbewahrung und Log-Kompaktierung

Die Kafka-Bereinigung wird durch cleanup.policy gesteuert. Die üblichen Werte sind delete, compact oder beide als compact,delete.

• delete entfernt alte Log-Segmente basierend auf Aufbewahrungszeit oder -größe.
• compact behält den neuesten Wert für jeden Schlüssel und entfernt im Laufe der Zeit ältere Werte für diesen Schlüssel.
• compact,delete ermöglicht die Anwendung sowohl von Kompaktierungs- als auch von Löschregeln.

Die Kompaktierung ist nützlich für Themen im Changelog-Stil, wie z. B. Kundenprofilaktualisierungen, die nach Kunden-ID sortiert sind. Sie ist kein allgemeiner Ersatz für die Aufbewahrung. Tombstones und Löschaufbewahrung haben ihr eigenes Timing-Verhalten. Testen Sie daher kompaktierte Themen, bevor Sie sich für die Bereinigung auf sie verlassen.

Praktische Checkliste zur Aufbewahrung

Beginnen Sie mit dem längsten Consumer-Ausfall, den Sie tolerieren können. Wenn eine Consumer-Gruppe möglicherweise 48 Stunden offline ist, ist ein Aufbewahrungsfenster von 24 Stunden zu kurz.

Schätzen Sie den Festplattenbedarf, bevor Sie Produktionsthemen ändern:

Erfassungsrate pro Sekunde x beibehaltene Sekunden x Partitionsanzahl x Replikationsfaktor

Dies ist nur eine Schätzung, da Komprimierung, Datensatzgröße, Indizes und Segment-Overhead die tatsächliche Zahl beeinflussen. Dennoch gibt es einen nützlichen Ausgangspunkt.

Überwachen Sie die Festplattennutzung der Broker, die Themenwachstumsrate, unter-replizierte Partitionen und den Consumer-Lag gemeinsam. Festplattendruck plus steigender Lag ist eine Warnung, dass Consumer möglicherweise außerhalb des Aufbewahrungsfensters liegen.

Der sicherste Standardwert ist einfach: Verwenden Sie die Aufbewahrung auf Themenebene, dokumentieren Sie, warum jedes Thema mit hohem Volumen seine Einstellung hat, und testen Sie kürzere Aufbewahrung in der Staging-Umgebung, bevor Sie sie in der Produktion anwenden.