Tiered Storage in Kafka – Zusammenfassung aus dem Technologie-Blog von Uber

Der Technologieblog von Uber veröffentlichte einen Artikel mit dem Titel „Einführung in Kafka Tiered Storage bei Uber“, der darauf abzielt, die Datenaufbewahrung mit weniger Kafka-Brokern und weniger Speicher zu maximieren. Dies ermöglicht längere Nachrichtenaufbewahrungszeiten in verschiedenen Geschäftsanwendungen.

Eine gängige Lösung besteht darin, externen Speicher manuell zu integrieren und die Daten regelmäßig mit dem externen System zu synchronisieren. Dies erfordert jedoch einen erheblichen Entwicklungs- und Wartungsaufwand, z. B. die Festlegung, wie die Daten gespeichert werden sollen, das Festlegen der Synchronisierungshäufigkeit, das Auslösen von Prozessen, das Abrufen von Daten und die Verwendung der Indizierung.

Daher hat Uber eine Lösung vorgeschlagen, die die Logik des externen Speichers kapselt und ihn mit einfachen Konfigurationen Plug-and-Play-fähig macht. Diese Funktion wird in Zusammenarbeit mit der Apache Foundation entwickelt und wird in zukünftigen Versionen verfügbar sein.

Szenario

Es ist wichtig zu verstehen, dass Kafka eine reine Append-Message-Queue-Komponente (MQ) mit sehr hohen Durchsatzfunktionen ist. Kafka speichert Protokolle im lokalen Speicher des Brokers und Benutzer können die Aufbewahrungszeit oder Protokollgröße konfigurieren. In meinem vorherigen Unternehmen (Lenovo) haben wir Flink verwendet, um kontinuierlich Daten zu verbrauchen. Eine große Datenmenge würde dazu führen, dass Kafka das Festplattenspeicherlimit überschreitet, was zu Datenschreibfehlern und Geschäftsfehlern führen würde. Um die Kosten zu senken, konnten wir, anstatt mehr Maschinen einzusetzen, nur die Aufbewahrungszeit anpassen.

Wenn außerdem jedes Unternehmen ein eigenes System entwickeln würde, um ältere Daten auf einem externen Speicher zu speichern, wäre ein enormer Entwicklungsaufwand erforderlich. Außerdem gäbe es zahlreiche Probleme im Zusammenhang mit der Synchronisierung und Datenkonsistenz.

Lösung

Das Wesentliche besteht darin, den Broker zu transformieren, indem ihm Remote-Protokollverwaltung und Speicherverwaltung hinzugefügt werden.

RemoteLogManager: Verwaltet den Lebenszyklus von Remote-Protokollsegmenten, einschließlich Kopieren, Bereinigen und Abrufen.

RemoteStorageManager: Verwaltet Aktionen für Remote-Protokollsegmente, einschließlich Kopieren, Abrufen und Löschen. Die mit Remote-Protokollsegmenten verknüpften Metadaten umfassen Informationen über die Start- und Endoffsets des Segments, Zeitstempel, Snapshots des Produzentenstatus und Checkpoints der Führungsepoche.
RemoteLogMetadataManager verfolgt diese Metadaten, um sicherzustellen, dass das System weiß, wo jedes Segment beginnt und endet, sowie andere wichtige Informationen, die für den Datenabruf und die Datenverwaltung benötigt werden.

RemoteLogMetadataManager: Verwaltet den Metadatenlebenszyklus für Remote-Protokollsegmente mit starker Konsistenz.

Unter anderem fungiert RemoteLogManager als Steuerungskomponente und stellt eine direkte Verbindung zur Festplatte im Broker her, um die gelesenen Daten abzurufen. Es ist auch für den Rückruf der Remote-Daten verantwortlich. RemoteStorageManager ist die Entität, die mit den Daten arbeitet, und RemoteLogMetadataManager ist für die Verwaltung der Metadaten verantwortlich.

Zusammenfassung der drei Aktionen in Kafka Tiered Storage

1. Segmente in den Remote-Speicher kopieren
   Ein Protokollsegment gilt als zum Kopieren in den Remotespeicher geeignet, wenn sein Endoffset (der Offset der letzten Nachricht im Segment) kleiner als der Last-Stable-Offset der Partition ist.（Last-Stable-Offset (LSO): Der höchste Offset Dabei werden alle vorherigen Nachrichten von allen synchronen Replikaten vollständig bestätigt, wodurch kein Datenverlust gewährleistet wird.）RemoteStorageManager übernimmt das Kopieren von Protokollsegmenten zusammen mit den zugehörigen Indizes, Zeitstempeln, Produzenten-Snapshots und dem Leader-Epochen-Cache.

2. Bereinigung von Remote-Segmenten
   Remote-Daten werden in regelmäßigen Abständen bereinigt, indem die geeigneten Segmente durch einen dedizierten Thread-Pool berechnet werden. Dies unterscheidet sich von der asynchronen Bereinigung der lokalen Protokollsegmente. Wenn ein Thema gelöscht wird, erfolgt die Bereinigung von Remote-Protokollsegmenten asynchron und es wird weder der vorhandene Löschvorgang blockiert noch ein neues Thema neu erstellt.

3. Abrufen von Segmenten aus dem Remote-Speicher
   RemoteLogManager bestimmt das Ziel-Remote-Segment basierend auf dem gewünschten Offset und der Leader-Epoche, indem es mit RemoteLogMetadataManager in den Metadatenspeicher schaut. Es verwendet RemoteStorageManager, um die Position innerhalb des Segments zu finden und mit dem Abrufen der gewünschten Daten zu beginnen.

Das obige ist der detaillierte Inhalt vonTiered Storage in Kafka – Zusammenfassung aus dem Technologie-Blog von Uber. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!