Apache Hudi: Record-Level-Indizes, CDC-Abfragen und der Build mit -Dspark3.5 -Dflink2.2
Upserts, Löschungen und inkrementelle Verarbeitung von Big Data. Apache Hudi Apache Hudi ist eine offene Daten-Lakehouse-Plattform, die auf einem leistungsstarken offenen Tabellenformat basiert, um Ihre Daten in mehreren Cloud-Datenumgebungen aufzunehmen, zu indizieren, zu speichern, bereitzustellen, zu transformieren und zu verwalten.
Auf einen Blick
- Was ist das?
- Hudi organisiert Upserts und Änderungsströme auf Objektspeicher. Wir arbeiten das README von apache/hudi nach Mechanik, Abfragearten und Bau ab.
- Für wen ist es gedacht?
- Hudi trägt dort, wo Aktualisierungen und Löschungen auf großen Beständen zum Alltag gehören und Änderungsströme an nachgelagerte Systeme weitergereicht werden sollen. Wer lediglich ein Tabellenformat mit Momentaufnahmen braucht und den Dienstbetrieb selbst steuern will, ist mit Apache Iceberg schlanker unterwegs.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Java, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was Hudi als Lakehouse-Plattform über ein Tabellenformat hinaus bietet
Das README von apache/hudi beschreibt das Projekt als offene Lakehouse-Plattform, die auf einem leistungsfähigen offenen Tabellenformat aufbaut. Die Aufgabenliste ist lang: aufnehmen, indizieren, speichern, bereitstellen, umwandeln und verwalten, und das über mehrere Cloud-Datenumgebungen hinweg. Die Kurzbeschreibung des Repositories fasst den Ursprung knapper: Upserts, Löschungen und inkrementelle Verarbeitung auf großen Datenbeständen.
Beide Sätze zusammen erklären die Stellung des Projekts. Wer große Bestände auf Objektspeicher ablegt, steht vor einer Eigenheit dieses Speichers: Dateien lassen sich dort nicht zeilenweise ändern. Eine Aktualisierung bedeutet daher das Neuschreiben von Dateien. Hudi organisiert diese Neuschreibvorgänge so, dass Aktualisierungen nach außen als normaler Vorgang erscheinen.
Alle Daten und Metadaten liegen laut README in offenen Formaten auf Cloud-Speicher. Die Metadaten nennen Java als Sprache sowie die Apache-Lizenz 2.0. Zum Abrufzeitpunkt standen rund 6.200 Sterne und 2.500 Forks im Raum, hinzu kamen gut 2.850 offene Issues.
Upserts über Datensatz-Indizes und zwei Modelle der Nebenläufigkeit
Der Schreibpfad verteilt sich im README auf zwei Abschnitte. Beim Indizieren nennt Hudi ein skalierbares Subsystem, das Momentaufnahme-Abfragen beschleunigt und von Schreibvorgängen selbst gepflegt wird. Es verfolgt Dateilisten sowie Statistiken auf Spalten- und Partitionsebene. Auf der Ebene einzelner Datensätze kommen Indizes auf zeilenorientierten Dateiformaten und Bloom-Filtern zum Einsatz.
Beim Schreiben folgt daraus die Fähigkeit, die dem Projekt seinen Namen gab: schnelle Upserts und Löschungen über Datensatz-Indizes. Hinzu kommen atomare Commits mit Rücknahme und Wiederherstellung sowie Momentaufnahme-Isolation zwischen Schreibern und Abfragen. Für die Nebenläufigkeit nennt das README zwei Modelle. Das optimistische Modell bedient relationale Arbeitsweisen mit Read-Modify-Write-Schreibvorgängen, das nicht-blockierende Modell Streaming-Arbeitsweisen, einschließlich außer der Reihe eintreffender und verspäteter Daten.
Erwähnenswert ist die logische Partitionierung über Ausdrucksindizes. Sie entkoppelt die fachliche Einteilung der Tabelle von der physikalischen Ablage im Speicher, was Umstellungen erlaubt, ohne Daten umzuschichten. Wie aufwendig eine solche Umstellung ist, beschreibt das README nicht.
Snapshot, Incremental, CDC, Time-Travel: fünf Abfragearten auf einer Hudi-Tabelle
Auf einer einzigen Tabelle stellt Hudi fünf Abfragearten bereit. Die Momentaufnahme-Abfrage zeigt den zuletzt festgeschriebenen Zustand, beschleunigt durch Indizes, wo diese greifen. Die inkrementelle Abfrage liefert den neuesten Stand aller Datensätze, die seit einem Zeitpunkt eingefügt oder geändert wurden, womit sich zwei Tabellenzustände miteinander vergleichen lassen.
Die Änderungsdaten-Abfrage geht einen Schritt weiter. Sie gibt einen Strom aus eingefügten, geänderten und gelöschten Datensätzen aus und enthält für jeden Datensatz sowohl das Bild vor als auch nach der Änderung. Für nachgelagerte Systeme, die einen eigenen Bestand fortführen, ist das die brauchbarste der fünf Arten, weil sich daraus ohne erneutes Lesen der Gesamttabelle ein Fortschritt ableiten lässt.
Die Zeitreise-Abfrage zeigt den Zustand zu einem bestimmten Zeitpunkt. Die leseoptimierte Abfrage setzt auf rein spaltenorientierte Speicherung wie Parquet und erreicht ihre gute Leistung laut README erst zusammen mit einer Komprimierungsrichtlinie, die eine Transaktionsgrenze zieht. Zahlen zur Abfrageleistung stehen nicht im README; das Attribut leistungsfähig bleibt unbelegt.
Clustering, Raumfüllkurven und asynchrone Komprimierung in Hudi-Tabellen
Der Abschnitt zur Tabellenverwaltung beschreibt Dienste, die entweder in die Schreiber von Apache Spark und Apache Flink eingebettet oder eigenständig betrieben werden. Genannt werden konfigurierbare Planungsstrategien mit eingebauter Fehlerbehandlung, das Bereinigen alter Versionen über eine Lebensdauer-Regel, Clustering mit Raumfüllkurven zur Optimierung des Datenlayouts sowie die asynchrone Komprimierung zeilenorientierter Daten in spaltenorientierte Formate.
Diese Dienste entscheiden im Betrieb über Tempo und Kosten. Clustering und Komprimierung bestimmen, wie schnell Abfragen laufen, und das Bereinigen bestimmt, wie viel Speicher belegt bleibt. Dass Hudi beide Aufgaben selbst übernimmt, ist ein deutlicher Unterschied zu reinen Tabellenformaten, die sie an externe Werkzeuge abgeben. Der Preis dafür ist ein Dienstbetrieb, der beobachtet werden will.
Für die Katalogsynchronisation nennt das README den Apache Hive Metastore, AWS Glue, Google BigQuery und Apache XTable, ergänzt um ein und mehr. Die Aufzählung bleibt damit offen, und die vollständige Menge unterstützter Kataloge lässt sich dem README nicht entnehmen.
mvn clean package -DskipTests -Dspark3.5 -Dflink2.2 und die Spark-Shell-Konfiguration
Der Bau aus den Quellen verlangt ein Unix-artiges System, Java 11 oder 17, Git und Maven ab Version 3.6.0. Der im README genannte Aufruf lautet mvn clean package -DskipTests -Dspark3.5 -Dflink2.2, ausgeführt im Verzeichnis hudi nach dem Klonen.
Anschließend zeigt das README den Start einer Spark-Shell, und die Konfiguration ist aufschlussreich, weil sie drei Schlüssel setzt. spark.serializer wird auf org.apache.spark.serializer.KryoSerializer gesetzt, spark.sql.extensions auf org.apache.spark.sql.hudi.HoodieSparkSessionExtension und spark.sql.catalog.spark_catalog auf org.apache.spark.sql.hudi.catalog.HoodieCatalog. Fehlt einer dieser Schlüssel, entsteht eine Umgebung, die Hudi-Tabellen nicht erkennt. Als Jar wird das Paket hudi-spark3.5-bundle_2.12 aus dem Verzeichnis packaging/hudi-spark-bundle/target übergeben.
Die Versionen werden über Maven-Profile gesteuert. Der Standard für Spark liegt bei 3.5.3 mit Scala 2.12, Scala 2.13 wird ab Spark 3.5 unterstützt, und für Spark 4.0 heißt das Paket hudi-spark4.0-bundle_2.13. Für Flink nennt das README ein Standardprofil mit Optionen für ältere Linien. Tests laufen über eigene Profile, unter anderem -Punit-tests und -Pfunctional-tests.
release-1.2.0 gegen 0.15.1: parallele Linien und der Vergleich mit Apache Iceberg
Ein Blick auf die Veröffentlichungen überrascht. Die jüngsten Einträge heißen release-0.14.2 vom Juni 2026, release-1.2.0 vom Mai 2026 und release-0.15.1 vom Mai 2026. Es werden also mehrere Linien parallel gepflegt, und eine Version aus der 0.x-Reihe erscheint später als eine aus der 1.x-Reihe. Wer eine Abhängigkeit festschreiben will, muss sich bewusst für eine Linie entscheiden und darf sich nicht an der zeitlichen Reihenfolge orientieren.
Als Alternative bietet sich Apache Iceberg an, wenn ein Tabellenformat mit Momentaufnahmen und verdeckter Partitionierung genügt. Iceberg überlässt die Pflege von Indizes auf Datensatzebene und die asynchrone Komprimierung stärker externen Werkzeugen. Hudi bringt diese Dienste selbst mit, was bei häufigen Aktualisierungen und Änderungsströmen hilft und bei einer schlanken Schicht ohne eigenen Dienstbetrieb eher hinderlich ist.
Die Apache-Lizenz 2.0 erlaubt den kommerziellen Einsatz einschließlich angepasster Varianten, sofern die Hinweispflichten beachtet werden; eine Gewährleistung ist ausgeschlossen. Angesichts von gut 2.850 offenen Issues gegenüber rund 6.200 Sternen empfiehlt es sich, vor der Festlegung zu prüfen, ob die eigenen Anforderungen von offenen Punkten berührt werden.
Redaktionelles Fazit
Hudi trägt dort, wo Aktualisierungen und Löschungen auf großen Beständen zum Alltag gehören und Änderungsströme an nachgelagerte Systeme weitergereicht werden sollen. Wer lediglich ein Tabellenformat mit Momentaufnahmen braucht und den Dienstbetrieb selbst steuern will, ist mit Apache Iceberg schlanker unterwegs. Vor dem Einsatz sollte der Bau mit mvn clean package -DskipTests -Dspark3.5 -Dflink2.2 gelingen und die Spark-Shell mit HoodieCatalog sowie HoodieSparkSessionExtension eine Testtabelle tatsächlich lesen.
Community-Notizen