Apache Hudi: die Koexistenzphase, Änderungsdaten aus dem alten ERP in die Aufzeichnung

Kein Unternehmen wechselt sein Betriebssystem an einem Montagmorgen. Das Auftragsbuch, der Bestand, die offenen Rechnungen und zwanzig Jahre Kundengeschichte leben in einem ERP, das weiterläuft, während die ersten Module einen Prozess nach dem anderen übernehmen. Monate, manchmal Jahre lang schreiben zwei Systeme in dasselbe Geschäft, und die Aufzeichnung muss beiden treu bleiben.

Das ist die Koexistenzphase, und sie hat eine bestimmte technische Form. Das alte System ändert weiter Zeilen; die Aufzeichnung braucht diese Änderungen in Minuten, nicht in einem nächtlichen Export; und sie braucht sie als Änderungen, damit die Korrektur einer Rechnung nicht bedeutet, ein Jahr neu zu laden. Apache Hudi wurde um diese Form herum gebaut. Die Datenschicht in Hurukan ist im Aufbau; dieser Text handelt davon, wie der Koexistenzpfad entworfen wird und wo Hudi hineinpasst. Warum die Aufzeichnung vom laufenden Zustand getrennt ist, steht in Laufender Zustand und Aufzeichnung.

Was Koexistenz verlangt

Änderungen, keine Schnappschüsse. Ein ERP ändert Tausende Zeilen pro Stunde: einen Status, eine Zahlung, eine korrigierte Adresse. Eine nächtliche Kopie jeder Tabelle ist zu langsam und zu teuer zugleich. Die Aufzeichnung braucht die Zeile, die sich geändert hat, mit Vorher und Nachher.

Aktualisierungen nach Schlüssel. Derselbe Kunde, Auftrag oder dieselbe Rechnung kommt viele Male mit neuen Werten an. Die Aufzeichnung muss die vorherige Version dieses einen Schlüssels finden und ersetzen, ohne die Partition neu zu schreiben, in der er liegt.

Inkrementelles Lesen. Alles nachgelagerte — die Sicht der Ontologie auf einen Kunden, ein Agent, der eine Kreditentscheidung vorbereitet, ein Bericht — sollte verarbeiten, was sich seit dem letzten Lauf geändert hat, nicht erneut die ganze Geschichte.

Löschung nach Schlüssel. Ein Löschersuchen während der Koexistenz muss die Aufzeichnung so sicher erreichen wie das ERP, und nach der Bereinigung nachweisbar vollständig sein.

Wie die Änderung ankommt

Die Datenbank des ERP schreibt für ihre eigene Wiederherstellung bereits ein Log ihrer eigenen Änderungen. Change Data Capture liest dieses Log und veröffentlicht jede Änderung als Ereignis. Im Entwurf, den Hurukan baut, trägt dieses Ereignis den Vertrag, den die Reihe unter Apache Avro beschreibt, sodass der Konsument die Form der Zeile vorher und nachher kennt.

Von dort liest Hudi Streamer, das Ingest-Werkzeug des Projekts, aus Kafka oder direkt aus Debezium-Änderungsereignissen, in einem kontinuierlichen Modus, mit einer Schema-Registry, und schreibt die Tabelle (geprüft am 21. Oktober 2026). Für den üblichen Fall wird kein Code geschrieben; die Konfiguration ist der Entwurf, und in Hurukan ist sie ein Vorschlag, den ein Agent entwirft und ein Mensch freigibt.

Was Hudi damit tut

Hudi gibt jedem Datensatz einen Schlüssel und führt einen Index, wo dieser Schlüssel liegt, sodass eine Aktualisierung die Dateigruppe berührt, die den Schlüssel hält, statt einer Partition. Die Index-Dokumentation listet die in den Metadaten der Tabelle geführten Optionen: Bloom-Filter, einen Index auf Datensatzebene, der global sein kann, Sekundärindizes und Ausdrucksindizes, hinzugefügt in Version 1.0.0 (geprüft am 21. Oktober 2026).

Zwei Tabellentypen beantworten zwei Bedürfnisse, beschrieben unter Tabellentypen. Copy-on-Write schreibt die Parquet-Basisdatei bei jeder Änderung neu; das Lesen ist einfach und schnell. Merge-on-Read hängt Änderungen an Logdateien neben der Basisdatei an und führt sie beim Lesen zusammen; die Verdichtung faltet sie im Hintergrund in neue Basisdateien. Während der Koexistenz sind die ERP-Tabellen meist Merge-on-Read, weil die Schreibvorgänge nie aufhören; eine Berichtstabelle, die sich einmal am Tag ändert, kann Copy-on-Write sein.

Jede Aktion landet auf der Zeitleiste der Tabelle — Commit, Delta-Commit, Verdichtung, Bereinigung, Rollback — mit den Zuständen angefordert, laufend und abgeschlossen, und die Geschichte wird in einer LSM-Struktur archiviert. Version 1.2.1 vom September 2026 ist aktuell; 1.1.0 und 1.0.0 davor bauten Zeitleiste und Indizes neu (geprüft am 21. Oktober 2026).

Drei Folgen zählen für die Aufzeichnung. Abfragen können inkrementell sein: Gib mir, was sich seit diesem Zeitpunkt geändert hat, als letzten Zustand oder als Vorher-Nachher-Bilder. Mehrere Schreiber können sich eine Merge-on-Read-Tabelle unter nicht blockierender Nebenläufigkeitskontrolle teilen, die die Dokumentation zur Nebenläufigkeit auf bestimmte Indextypen beschränkt und noch nicht auf Clustering. Und eine Löschung nach Schlüssel ist ein gewöhnlicher Schreibvorgang, endgültig, nachdem der Cleaner die alten Dateiversionen entfernt hat.

Was Menschen entscheiden

Der Schlüssel. Welche Kombination von Feldern eine Zeile im alten System identifiziert und ob sie über die Migration hinweg stabil bleibt. Ein falscher Schlüssel dupliziert Kunden für die Lebensdauer der Aufzeichnung.

Der Tabellentyp und das Verdichtungsbudget. Merge-on-Read hält die Schreiblatenz niedrig und verschiebt die Kosten in die Verdichtung, die dauernd läuft und dauernd bezahlt wird. Ein Agent schlägt den Zeitplan vor; ein Mensch unterschreibt die Kosten.

Aufbewahrung und der Cleaner. Wie viele Dateiversionen behalten werden, ist dieselbe Entscheidung wie die, wie weit „was hat der Agent gesehen” zurückreicht, und wann eine gelöschte Person weg ist. Sie wird je Tabelle gesetzt und aufgezeichnet.

Wo die Engines sind. Hudi wird nativ von Spark, Flink, Trino und Presto gelesen. Ein Unternehmen, dessen übrige Werkzeuge Iceberg oder Delta erwarten, erreicht eine Hudi-Tabelle über Metadatenübersetzung, mit den Grenzen, die die Reihe für XTable und UniForm beschreibt. Das ist ein Grund, Hudi dort zu halten, wo es seinen Platz verdient — auf dem Koexistenzpfad — statt überall.

Die Schicht Daten beschreibt die Konnektoren und das eine Datenmodell, das dieser Pfad speist. Wenn der letzte Prozess in ein Modul gewandert ist, hört das ERP auf zu schreiben, der Änderungsstrom endet, und die Aufzeichnung läuft weiter, ohne es zu bemerken.

Ein Test, den Sie heute machen können

Wählen Sie eine Tabelle in Ihrem ERP, die sich den ganzen Tag ändert: Auftragspositionen oder Zahlungen. Fragen Sie, wie sie heute Ihr Berichtswesen erreicht, und schreiben Sie drei Zahlen auf: wie alt die Kopie ist, wenn jemand sie liest, wie viel der Tabelle neu geladen wird, um einen Tag an Änderungen anzuwenden, und wie lange ein Löschersuchen braucht, bis es dort nachweisbar vollständig ist. Diese drei Zahlen muss der Koexistenzpfad schlagen.