Der Prüfpfad ist eine Tabelle: Delta Lake, Iceberg oder Hudi

Ein Prüfer stellt eine einfache Frage zu einer im März freigegebenen Zahlung: Was hat die Person, die sie freigab, auf dem Bildschirm gesehen, und was hatte der Agent, der sie entwarf, gelesen, bevor er sie vorschlug? In den meisten Unternehmen ist die Antwort eine Rekonstruktion. Jemand holt ein Backup, jemand anderes durchsucht ein Postfach, und das Ergebnis ist eine begründete Vermutung über einen Zustand, den es nicht mehr gibt.

In Hurukan ist jeder Agentenvorschlag und jede menschliche Entscheidung ein Ereignis in der Aufzeichnung des Unternehmens, und die Aufzeichnung ist so entworfen, dass diese Frage eine klare Antwort hat: eine Version der Tabellen, wie sie in jenem Moment standen. Diese Eigenschaft kommt nicht von den Dateien. Sie kommt vom Tabellenformat darüber. Dieser Text handelt davon, was die drei offenen Tabellenformate mit der Frage tun und wie man zwischen ihnen wählt. Die Datenschicht ist im Aufbau; was folgt, ist die Art, wie sie entworfen wird. Die Begründung, warum es überhaupt eine Aufzeichnung gibt, steht in Laufender Zustand und Aufzeichnung.

Was ein Prüfpfad von einer Tabelle braucht

Dateien in der Aufzeichnung werden nie bearbeitet. Eine Änderung schreibt neue Dateien und eine neue Version der Tabellenmetadaten, die sagt, welche Dateien jetzt zählen. Drei Dinge folgen daraus für die Prüfung.

Jede Version ist adressierbar. „Die Tabelle, Stand 12. März, 14:02” muss eine gültige Abfrage sein, kein Wiederherstellungsauftrag. In den Formaten unten heißt das Zeitreise (time travel), und sie ist der Mechanismus hinter „was hat der Agent gesehen”.

Jede Version hat einen Urheber. Die Metadaten einer Änderung müssen tragen, wer oder was sie gemacht hat: eine Person, ein Agent auf Grundlage einer menschlichen Freigabe oder eine Systemaufgabe wie die Verdichtung. Hurukan hält den Akteur in seinem eigenen Entscheidungsprotokoll fest, aber die Tabellenversion ist der Beweis, dass das Protokoll zu den Daten passt.

Alte Versionen laufen absichtlich ab, nicht zufällig. Jede Version für immer zu behalten kostet; sie zu entfernen ist eine Entscheidung über Aufbewahrung und, bei personenbezogenen Daten, über Löschung. Diese Entscheidung gehört einem Menschen, und das Tabellenformat muss sie explizit machen.

Drei Arten, den Plan zu führen

Jedes Format führt einen Plan, welche Dateien die Tabelle bilden. Im Plan lebt die Prüfung.

Delta Lake führt ein Log: ein Verzeichnis _delta_log/ mit einer JSON-Datei je Commit, benannt nach einer zwanzigstelligen Versionsnummer, die jeweils Aktionen wie add, remove, metaData und protocol auflistet, mit periodischen Parquet-Checkpoints, damit ein Leser nicht die ganze Geschichte abspielt. Das Protokoll definiert es; die aktuelle Version ist 4.4.0 (geprüft am 21. Oktober 2026). Die Log-Aufbewahrung beträgt standardmäßig 30 Tage und VACUUM 7 Tage, das heißt, die Zeitreise reicht nur so weit zurück, wie diese zwei Einstellungen erlauben.

Apache Iceberg führt einen Baum: Eine Tabellenmetadatendatei zeigt auf einen Schnappschuss, der Schnappschuss auf eine Manifestliste, die Manifeste auf Daten- und Löschdateien mit ihren Statistiken. Ein Commit ist ein atomarer Tausch des Zeigers auf die Metadatendatei, und der Tausch geschieht im Katalog. Die Spezifikation steht bei Version 3, mit Löschvektoren, Zeilenherkunft und dem Typ VARIANT; die aktuelle Version ist 1.12.0 (geprüft am 21. Oktober 2026).

Apache Hudi führt eine Zeitleiste: Jede Aktion an der Tabelle — Commit, Verdichtung, Bereinigung, Rollback, Wiederherstellung — ist ein Zeitpunkt mit einem Zustand, und die Geschichte der Zeitleiste wird in einer LSM-Struktur archiviert. Datensätze haben Schlüssel und einen Index, sodass eine Änderung an einem Kunden eine Dateigruppe berührt statt einer Partition. Tabellen sind Copy-on-Write oder Merge-on-Read, und Version 1.2.1 brachte Tabellenversion 9 (geprüft am 21. Oktober 2026). Die Dokumentation zur Zeitleiste beschreibt die Zustände.

Alle drei antworten dem Prüfer. Der Unterschied liegt darin, wo die Antwort aufbewahrt wird und wer sie sonst noch lesen kann.

Wählen Sie nach Katalog, nicht nach Funktionsliste

Die Funktionslisten haben sich angeglichen: Transaktionen, Zeitreise, Schemaevolution, Löschungen auf Zeilenebene und Streaming-Schreibvorgänge gibt es in jedem. Nicht angeglichen hat sich der Ort, an dem die aktuelle Version einer Tabelle erklärt wird, und an diesem Ort wird Souveränität entschieden.

Bei Delta Lake ist es das Log-Verzeichnis selbst, sodass jede Engine, die den Speicher lesen kann, die aktuelle Version findet. In der Praxis ist der Katalog darum herum Unity Catalog oder, in Microsoft Fabric, OneLake, das seine Tabellen laut Microsofts Dokumentation als Delta Parquet speichert.

Bei Iceberg ist es der Katalogzeiger, und der Katalog spricht eine offene REST-Spezifikation. Apache Polaris, seit Februar 2026 ein Top-Level-Projekt mit Version 1.8.0, implementiert sie; Snowflake, AWS S3 Tables, Googles Lakehouse-Katalog und Databricks lesen und schreiben Iceberg-Tabellen darüber (geprüft am 21. Oktober 2026).

Bei Hudi ist es die Zeitleiste im Speicher, nativ gelesen von Spark, Flink, Trino und Presto; andere Plattformen erreichen eine Hudi-Tabelle in der Regel über Metadatenübersetzung.

Die Frage für ein Unternehmen lautet also nicht „welches Format hat die beste Prüfung”. Sie lautet: Auf wessen Infrastruktur läuft der Katalog, welche Engines müssen die Aufzeichnung lesen, und kann die Aufzeichnung mitgenommen werden, wenn der Anbieter wechselt? Hurukans Antwort ist, dass Katalog und Dateien auf Infrastruktur laufen, die das Unternehmen wählt, wie unter Sicherheit und Souveränität beschrieben, und dass das Format aus den Engines folgt, die das Unternehmen schon hat, nicht umgekehrt.

Was bei den Menschen bleibt

Agenten sind gut im mechanischen Teil der Datenschicht: den Verdichtungsplan entwerfen, den Job schreiben, der alte Schnappschüsse ablaufen lässt, eine Partitionsänderung vorschlagen, wenn Abfragen langsamer werden. Jedes davon ist ein Vorschlag im Freigabe-Posteingang mit beigefügter Begründung, und jedes wird bei Freigabe aufgezeichnet. Drei Entscheidungen werden nie delegiert.

Aufbewahrung und Löschung. Wie weit die Zeitreise zurückreicht, ist dieselbe Einstellung wie die, wie lange personenbezogene Daten ein Löschersuchen überdauern. Ein Mensch setzt sie je Tabelle und unterschreibt sie.

Protokollanhebungen. Eine neuere Tabellenfunktion einzuschalten kann eine ältere Engine aussperren, die die Aufzeichnung noch liest. Der Gewinn ist real; der Leser, der dunkel wird, auch. Ein Mensch wägt ab.

Das Format selbst. Es später zu ändern ist möglich, wie der nächste Text dieser Reihe zu XTable und UniForm erklärt, aber es ist ein Projekt, keine Einstellung.

Ein Test, den Sie heute machen können

Nehmen Sie eine Entscheidung aus dem letzten Quartal, nach der ein Prüfer plausibel fragen könnte: ein erhöhtes Kreditlimit, einen freigegebenen Lieferanten, einen gewährten Rabatt. Schreiben Sie allein aus Ihren Systemen auf, was die entscheidende Person in jenem Moment gesehen hat. Zählen Sie die Systeme, die Sie öffnen mussten, und die Stellen, an denen Sie raten mussten. Diese Zahl ist der Abstand zwischen Ihrer heutigen Aufzeichnung und einer, deren Prüfpfad eine Tabelle ist.