Vergleich von Kafka-Topic-Löschung vs. Aufbewahrungsrichtlinien-Befehle

Die Datenentfernung in Kafka erfolgt in zwei sehr unterschiedlichen Formen: Löschen eines gesamten Topics oder das Entfernen alter Log-Segmente durch Aufbewahrungsrichtlinien aus einem aktiven Topic. Eine effektive Verwaltung von Kafka-Topics ist entscheidend für die Systemgesundheit, die Optimierung des Speichers und die Sicherstellung der Datenintegrität. Dies umfasst nicht nur das Erstellen und Überwachen von Topics, sondern auch das Verständnis, wie Daten, die nicht mehr benötigt werden, ordnungsgemäß entfernt werden können. Es gibt zwei primäre Mechanismen zur Datenentfernung: sofortige Topic-Löschung und zeitbasierte Aufbewahrungsrichtlinien. Obwohl beide letztendlich zur Datenentfernung führen, unterscheiden sich ihre funktionalen Unterschiede, Anwendungsfälle und Auswirkungen erheblich.

Verwenden Sie die Topic-Löschung, wenn das Topic selbst verschwinden soll. Verwenden Sie Aufbewahrungseinstellungen, wenn das Topic bestehen bleiben soll, aber alte Daten automatisch ausgemustert werden sollen.

Verständnis der Kafka-Topic-Löschung (kafka-topics.sh --delete)

Die Topic-Löschung in Kafka ist eine direkte und sofortige Aktion, die darauf abzielt, ein Topic vollständig zu entfernen, einschließlich aller Partitionen, Daten und Metadaten, aus dem Kafka-Cluster. Dies wird typischerweise verwendet, wenn ein Topic veraltet ist, versehentlich erstellt wurde oder keinen Zweck mehr in Ihrem System erfüllt.

Wie die Topic-Löschung funktioniert

Wenn Sie einen Topic-Löschbefehl ausführen, markiert Kafka das Topic zur Löschung. Der eigentliche Löschvorgang umfasst mehrere Schritte:

1. Markierung zur Löschung: Die Metadaten des Topics in ZooKeeper (oder dem Kafka-Raft-Quorum für KRaft-Cluster) werden aktualisiert, um es zur Löschung zu markieren.
2. Controller-Aktion: Der Kafka-Controller (ein Broker mit einer speziellen Rolle) orchestriert die Löschung. Er weist andere Broker an, die Produktion oder den Konsum von den Partitionen des markierten Topics zu stoppen.
3. Bereinigung des Log-Verzeichnisses: Jeder Broker, der Partitionen für das gelöschte Topic hostet, wird schließlich die zugehörigen Log-Segmente und Indexdateien von seiner Festplatte entfernen. Diese Bereinigung erfolgt asynchron und hängt von der Koordination zwischen Broker und Controller sowie der Dateisystembereinigung auf den Brokern ab, die die Partitionen gehostet haben.

Aktivieren der Topic-Löschung

Bevor Sie Topics löschen können, muss die Topic-Löschung auf allen Kafka-Brokern explizit aktiviert werden. Dies ist eine wichtige Sicherheitsmaßnahme, um versehentlichen Datenverlust zu verhindern.

Um die Topic-Löschung zu aktivieren, setzen Sie die folgende Eigenschaft in Ihrer server.properties-Datei auf jedem Kafka-Broker:

delete.topic.enable=true

Nachdem Sie server.properties geändert haben, starten Sie Ihre Kafka-Broker neu, damit die Änderung wirksam wird.

Praktisches Beispiel: Löschen eines Topics

Um ein Topic mit dem Namen my-obsolete-topic zu löschen:

kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic my-obsolete-topic

Beispielausgabe:

Deleting topic my-obsolete-topic.

Sie können überprüfen, ob das Topic zur Löschung markiert ist, indem Sie die Topics auflisten:

kafka-topics.sh --bootstrap-server localhost:9092 --list

Bei Erfolg erscheint my-obsolete-topic möglicherweise zunächst noch in der Liste (zur Löschung markiert), sollte aber nach Abschluss des Bereinigungsprozesses auf allen Brokern vollständig verschwinden.

Warnung: Das Löschen eines Topics ist eine destruktive und irreversible Operation. Sobald die Daten gelöscht sind, sind sie weg. Seien Sie stets äußerst vorsichtig und stellen Sie sicher, dass Sie Backups haben oder sicher sind, dass die Daten nicht mehr benötigt werden.

Konfigurieren von Kafka-Aufbewahrungsrichtlinien

Kafka-Aufbewahrungsrichtlinien bieten eine granulare und automatische Möglichkeit, den Datenlebenszyklus zu verwalten, indem sie definieren, wie lange Nachrichten in einem Topic aufbewahrt werden sollen oder wie viel Speicherplatz sie einnehmen dürfen. Dies ist ideal für Topics, die kontinuierliche Ereignisströme, Logs oder Metriken speichern, bei denen ältere Daten im Laufe der Zeit natürlich an Relevanz verlieren.

Wie Aufbewahrungsrichtlinien funktionieren

Kafka-Broker führen kontinuierlich einen Log-Cleaner-Prozess aus, der regelmäßig Topic-Segmente auf Daten überprüft, die die definierten Aufbewahrungsgrenzen überschritten haben. Es gibt zwei primäre Aufbewahrungskonfigurationen:

1. retention.ms (Zeitbasierte Aufbewahrung): Diese Konfiguration gibt die maximale Zeit (in Millisekunden) an, die Kafka ein Log-Segment aufbewahrt, bevor es zur Löschung freigegeben wird. Wenn retention.ms beispielsweise auf 604800000 (7 Tage) gesetzt ist, werden alle Nachrichten, die älter als 7 Tage sind, entfernt.

2. retention.bytes (Größenbasierte Aufbewahrung): Diese Konfiguration gibt die maximale Größe (in Bytes) an, die die Partitionen eines Topics auf der Festplatte erreichen können, bevor ältere Log-Segmente gelöscht werden, um Speicherplatz freizugeben. Wenn retention.bytes erreicht ist, löscht Kafka die ältesten Segmente, bis die Topic-Größe innerhalb des Limits liegt, unabhängig von retention.ms.

Wenn sowohl retention.ms als auch retention.bytes konfiguriert sind, hat die Richtlinie Vorrang, die zuerst ausgelöst wird. Wenn Daten beispielsweise vor dem Erreichen des Größenlimits ihr Zeitlimit erreichen, werden sie durch retention.ms gelöscht. Wenn das Größenlimit vor dem Zeitlimit erreicht wird, löst retention.bytes die Löschung aus.

Hinweis: Ein retention.ms-Wert von -1 bedeutet unendliche Aufbewahrung (Daten werden nie durch Zeit gelöscht).

Praktisches Beispiel: Erstellen eines Topics mit Aufbewahrung

Um ein Topic my-event-stream mit einer Aufbewahrungsdauer von 24 Stunden (86.400.000 Millisekunden) zu erstellen:

kafka-topics.sh --bootstrap-server localhost:9092 \
                --create \
                --topic my-event-stream \
                --partitions 3 \
                --replication-factor 1 \
                --config retention.ms=86400000

Praktisches Beispiel: Ändern der Aufbewahrung für ein bestehendes Topic

Um die Aufbewahrung für ein bestehendes Topic my-log-topic auf 7 Tage (604.800.000 Millisekunden) zu ändern und ein Größenlimit von 1 GB (1.073.741.824 Bytes) hinzuzufügen:

kafka-configs.sh --bootstrap-server localhost:9092 \
                 --entity-type topics \
                 --entity-name my-log-topic \
                 --alter \
                 --add-config retention.ms=604800000,retention.bytes=1073741824

Um eine bestimmte Aufbewahrungseinstellung zu entfernen (z. B. um zur Standardeinstellung des Brokers für retention.bytes zurückzukehren):

kafka-configs.sh --bootstrap-server localhost:9092 \
                 --entity-type topics \
                 --entity-name my-log-topic \
                 --alter \
                 --delete-config retention.bytes

Anzeigen von Topic-Konfigurationen

Sie können die aktuelle Konfiguration eines Topics, einschließlich seiner Aufbewahrungseinstellungen, überprüfen:

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

Hauptunterschiede und Anwendungsfälle

Merkmal	Topic-Löschung (--delete)	Aufbewahrungsrichtlinie (retention.ms/retention.bytes)
Aktionstyp	Manuell, sofortig, irreversibel	Automatisch, kontinuierlich, konfigurierbar
Umfang	Entfernt das gesamte Topic (alle Daten und Metadaten)	Entfernt alte Datensegmente innerhalb eines aktiven Topics
Zweck	Veraltete Topics beseitigen, Fehler korrigieren	Datenlebenszyklus für aktive Topics verwalten, Speichernutzung kontrollieren
Datenverlustrisiko	Hoch (alle Daten sofort verloren)	Kontrolliert (nur Daten, die die Richtlinie überschreiten, werden entfernt)
Konfiguration	Broker-Ebene delete.topic.enable, dann Befehlsausführung	Topic-Ebene-Konfigurationen (--config oder --alter)
Umkehrbarkeit	Nein	Kann für zukünftige Daten geändert oder deaktiviert werden, aber vergangene Entfernungen sind dauerhaft

Wann sollte die Topic-Löschung verwendet werden?

• Veraltete Topics: Wenn ein Projekt oder ein Dienst außer Betrieb genommen wird und die zugehörigen Kafka-Topics nicht mehr benötigt werden.
• Entwicklungs-/Testbereinigung: Bereinigung temporärer Topics, die während Entwicklungs- oder Testzyklen erstellt wurden.
• Fehlerkorrektur: Wenn ein Topic mit falschen Konfigurationen erstellt wurde (z. B. zu viele Partitionen, falscher Replikationsfaktor) und es einfacher ist, es von Grund auf neu zu erstellen.

Wann sollten Aufbewahrungsrichtlinien verwendet werden?

• Logging-/Überwachungsdaten: Für Topics, die Anwendungslogs, Metriken oder Audit-Ereignisse sammeln, bei denen ältere Daten irgendwann an Wert verlieren.
• Ereignisströme: In ereignisgesteuerten Architekturen, in denen Ereignisse für einen bestimmten Zeitraum für die Wiedergabe oder die Synchronisierung von Verbrauchern zugänglich sein müssen, aber nicht unbegrenzt.
• Ressourcenmanagement: Um zu verhindern, dass Topics übermäßig viel Speicherplatz auf Kafka-Brokern verbrauchen, was die Cluster-Stabilität und Kosteneffizienz gewährleistet.
• Compliance: Zur Einhaltung von Datenaufbewahrungsvorschriften, die die Löschung von Daten nach einem bestimmten Zeitraum vorschreiben.

Best Practices und Überlegungen

• Aktivieren Sie delete.topic.enable=true mit Vorsicht: Obwohl für die Löschung erforderlich, achten Sie darauf, wer in einer Produktionsumgebung Zugriff auf die Durchführung von Löschvorgängen hat.
• Automatisieren Sie die Aufbewahrung: Legen Sie für die meisten aktiven Topics von Anfang an sinnvolle Aufbewahrungsrichtlinien fest, um unerwartete Speicherplatzprobleme zu vermeiden.
• Überwachen Sie die Speichernutzung: Überwachen Sie regelmäßig die Speichernutzung der Kafka-Broker. Wenn Topics unerwartet wachsen, überprüfen Sie ihre Aufbewahrungsrichtlinien oder untersuchen Sie das Verhalten der Produzenten.
• Testen Sie Löschung/Aufbewahrung: Simulieren Sie in Nicht-Produktionsumgebungen Topic-Löschungen und beobachten Sie, wie sich Aufbewahrungsrichtlinien verhalten, um ihre Auswirkungen vollständig zu verstehen.
• Sichern Sie kritische Daten: Für Topics mit geschäftskritischen oder langfristigen Archivdaten sollten Sie externe Archivierungslösungen (z. B. S3, HDFS) in Betracht ziehen, anstatt sich ausschließlich auf Kafkas unendliche Aufbewahrung zu verlassen, oder stellen Sie sicher, dass Ihr retention.ms auf -1 gesetzt ist und retention.bytes ausreichend groß oder -1 ist.
• Komprimierte Topics: Für Topics mit aktivierter Log-Kompression (cleanup.policy=compact) gilt retention.ms weiterhin für die Löschung alter Segmente (nicht einzelner Nachrichten), die komprimiert wurden, und min.cleanable.dirty.ratio steuert, wann die Kompression ausgeführt wird. Dies ist ein separater Mechanismus von der Standardaufbewahrung und wird für Topics verwendet, bei denen der neueste Wert für einen bestimmten Schlüssel wichtig ist (z. B. Datenbank-Änderungsprotokolle, Benutzerprofile).

Fazit

Löschen Sie ein Kafka-Topic nur, wenn Produzenten, Konsumenten und nachgelagerte Abhängigkeiten es nicht mehr benötigen. Legen Sie für aktive Topics retention.ms und retention.bytes bewusst fest und überwachen Sie die Speichernutzung der Broker, damit alte Daten ablaufen, bevor der Speicherdruck zu einem Vorfall wird.