Open-Table-Formate erklärt: Iceberg vs. Delta vs. Hudi

Open-Table-Formate sind Metadatenschichten, die auf Datendateien im Objektspeicher aufsetzen. Sie erweitern in einem Data Lake gespeicherte Daten um ACID-Transaktionen, Schema-Evolution und Time Travel. Apache Iceberg, Delta Lake und Apache Hudi sind die drei wichtigsten Open-Table-Formate, die heute in der Praxis eingesetzt werden. Jedes von ihnen verwandelt eine Sammlung von Parquet- oder ORC-Dateien in eine Tabelle, die sich wie eine Datenbank verhält: Lesende sehen konsistente Ergebnisse, Schreibende können Zeilen sicher aktualisieren sowie löschen, und jede Änderung wird nachverfolgt, sodass frühere Versionen abfragbar bleiben.

Diese Übersicht erklärt, wie die wichtigsten Open-Table-Formate funktionieren, wie sie bei der Unterstützung von ACID-Transaktionen und der Schema-Evolution abschneiden und wie sie in Beziehung zur Data-Lakehouse-Architektur stehen. Dabei werden Innovationen auf der Speicherebene wie katalogkoordinierte Transaktionen, Row Lineage und einheitliche Metadaten herangezogen, um zu zeigen, wo Delta Lake und Apache Iceberg konvergieren.

Was ist ein Data Lake und warum sind Open-Table-Formate wichtig?

Ein Data Lake ist ein zentrales Repository auf kostengünstigem Objektspeicher – wie Amazon S3, Azure Data Lake Storage oder Google Cloud Storage –, das strukturierte, semistrukturierte und unstrukturierte Daten in ihrer rohen, nativen Form speichert. Unternehmen haben sich für Data Lakes entschieden, weil Objektspeicher kostengünstig skaliert und Speicher von Rechenleistung (Compute) trennt, sodass jede Query-Engine dieselben Daten lesen kann. Objektspeicher wurde jedoch nie dafür entwickelt, Konsistenz zu garantieren: Er besitzt kein natives Konzept für Tabellen, Schemata oder Transaktionen.

Ein Data Lakehouse bringt tabellenähnliche Strukturen, Governance und Performance auf diesen Rohspeicher und kombiniert die geringen Kosten eines Data Lakes mit der Zuverlässigkeit eines Data Warehouses. Die Brücke zwischen beiden ist das Open-Table-Format: Es verwandelt lose Dateien im Objektspeicher in verwaltete, abfragbare Tabellen, ohne dass Daten in ein proprietäres Warehouse kopiert werden müssen.

Bevor es Open-Table-Formate gab, führte die Durchführung von Analysen auf herkömmlichen Data Lakes zu dauerhaften Problemen: Gleichzeitige Schreibzugriffe konnten Daten während des Schreibvorgangs beschädigen, Aktualisierungen und Löschungen erforderten das Umschreiben ganzer Partitionen, und es gab keine verlässliche Methode, um festzustellen, welche Dateien den aktuellen, korrekten Zustand einer Tabelle darstellten. Open-Table-Formate verwalten Metadaten für Datendateien im Objektspeicher und verfolgen genau, welche Dateien zu einer Tabelle gehören – eine Standardisierung, die es Data Lakes schließlich ermöglichte, datenbankähnliche Funktionen wie Aktualisierungen auf Datensatzebene zu unterstützen.

Die Open-Table-Formate und Dateiformate, die Sie kennen sollten

Apache Iceberg

Apache Iceberg wurde ursprünglich von Netflix entwickelt und ist heute ein Projekt der Apache Software Foundation. Es wurde entworfen, um riesige, sich langsam ändernde Tabellen schnell abfragbar zu machen und sicher weiterzuentwickeln. Apache Iceberg nutzt eine Baumstruktur für ein effizientes Metadatenmanagement: Manifest-Dateien und Manifest-Listen erfassen jede Datendatei in einer Tabelle, sodass Query-Engines irrelevante Daten bereits vor dem Start eines Scans ausschließen können. Iceberg-Tabellen unterstützen Schema-Evolution und Partition-Evolution, ohne dass die zugrunde liegenden Dateien neu geschrieben werden müssen.

Delta Lake

Delta Lake wurde von Databricks entwickelt, als Open Source veröffentlicht und brachte ACID-Transaktionen über ein Write-Ahead-Transaktionsprotokoll in Apache Spark-Workloads. Delta Lake stammt von Databricks und ist nativ in Spark integriert, unterstützt mittlerweile jedoch eine Vielzahl von Engines über unabhängige Connectoren. Delta Lake-Tabellen zeichnen jeden Schreibvorgang als geordneten, atomaren Protokolleintrag auf, sodass Lesende selbst während des Schreibens neuer Daten eine konsistente Sicht erhalten.

Apache Hudi

Apache Hudi, kurz für Hadoop Upserts Deletes and Incrementals, ist auf schnelle, häufige Aktualisierungen auf Datensatzebene ausgelegt. Apache Hudi optimiert für häufige Updates und Streaming-Daten, indem es Indizes pflegt, die genau die Datei lokalisieren, die einen bestimmten Datensatz enthält. Dies ermöglicht effiziente Aktualisierungen auf Datensatzebene ohne einen vollständigen Tabellenscan. Dieses Design macht Hudi zu einer beliebten Wahl für Change-Data-Capture-Pipelines und die Erfassung in Fast-Echtzeit.

Parquet und ORC

Parquet und ORC sind spaltenorientierte Dateiformate, keine Tabellenformate: Sie definieren, wie einzelne Datendateien organisiert sind, und nicht, wie Dateien zu einer verwalteten Tabelle werden. Iceberg, Delta Lake und Hudi basieren alle auf Parquet-Dateien – Iceberg und Hudi unterstützen auch ORC – und nutzen die von Parquet gespeicherten Statistiken auf Dateiebene, um Daten auszuschließen, bevor eine Query-Engine sie liest. Diese Unterscheidung zwischen Dateiformat und Tabellenformat beseitigt die meisten Unklarheiten in Unternehmen darüber, wo die Zuständigkeiten der einzelnen Schichten beginnen.

Iceberg vs. Delta Lake vs. Hudi: Schneller Vergleich

Die drei wichtigsten Open-Table-Formate weisen inzwischen mehr Gemeinsamkeiten als Unterschiede auf, aber die folgende Tabelle zeigt, wo sich die jeweilige Designgeschichte immer noch bemerkbar macht.

Ein Blick in Apache Iceberg: Tabellen und Metadaten

Der Iceberg-Metadatenbaum

Eine Iceberg-Tabelle wird durch einen Metadatenbaum definiert, nicht durch eine einzelne Datei: Eine Metadatendatei verweist auf eine Manifest-Liste, die wiederum auf Manifest-Dateien verweist, welche die tatsächlichen Datendateien eines Snapshots auflisten. Diese mehrschichtige Struktur ermöglicht es einer Query-Engine, irrelevante Manifeste und Datendateien mithilfe gespeicherter Spaltenstatistiken auszuschließen, ohne eine einzige Datei öffnen zu müssen. Dies verbessert die Abfrageleistung bei Tabellen mit Millionen von Dateien.

Snapshots und Time Travel

Jeder Schreibvorgang in eine Iceberg-Tabelle erstellt einen neuen Snapshot – eine unveränderliche Aufzeichnung darüber, welche Datendateien zu diesem Zeitpunkt existierten – und der Metadatenbaum speichert den Verlauf früherer Snapshots. Dies ermöglicht Time Travel: Engines können eine Tabelle so abfragen, wie sie zu einer bestimmten Snapshot-ID oder zu einem bestimmten Zeitstempel existierte. Das unterstützt Audits, reproduzierbare ML-Trainingsdatensätze und das Zurücksetzen auf den letzten stabilen Zustand nach einem fehlerhaften Schreibvorgang.

Partition-Evolution

Iceberg entkoppelt die physische Partitionierung einer Tabelle von ihren Abfragemustern durch Partition-Evolution. So können Teams die Partitionierung neuer Daten ändern, ohne bestehende Dateien neu schreiben zu müssen oder Abfragen gegen das alte Schema zu beeinträchtigen. Durch verdeckte Partitionierung (Hidden Partitioning) müssen Analysten physische Partitionierungsspalten nicht direkt referenzieren, um von Partition Pruning zu profitieren.

Iceberg-Tabellen-Internals und Wartung

Da jeder Schreibvorgang einen neuen Snapshot mit einer eigenen Manifest-Liste erzeugt, kann eine aktiv beschriebene Iceberg-Tabelle ohne Verwaltung Tausende von kleinen Manifest- und Datendateien anhäufen. Da Query-Engines dennoch jede relevante Manifest-Datei öffnen und auswerten müssen, beeinträchtigt diese Manifest-Flut die Abfrageleistung, für deren Verbesserung der Metadatenbaum eigentlich entwickelt wurde.

Die Standardlösung ist eine geplante Kompaktierung (Compaction): Ein Wartungsjob, der kleine Datendateien in weniger, größere Dateien umschreibt und Manifeste konsolidiert. Dieser wird je nach Ingestion-Volumen nächtlich oder stündlich ausgeführt. Die Kombination aus Kompaktierung und regelmäßigem Ablauf von Snapshots (Snapshot-Ablauf) – also dem Entfernen von Metadaten außerhalb eines Aufbewahrungsfensters – hält die Speicher- und Metadatengröße unter Kontrolle, ohne einzuschränken, wie weit Time Travel zurückreichen kann.

Delta Lake und ACID-Transaktionen

Das Delta Lake-Transaktionsprotokoll

Delta Lake-Tabellen speichern ein geordnetes, nur anhängbares (Append-only) Transaktionsprotokoll – eine Sequenz von JSON-Einträgen, die jedes Hinzufügen, Entfernen und jede Metadatenänderung aufzeichnen – zusammen mit regelmäßigen Checkpoint-Dateien, die das Protokoll für schnelleres Lesen zusammenfassen. Historisch gesehen fungierte das Dateisystem selbst als Commit-Koordinator, was bedeutete, dass jeder Client mit Zugriff auf Dateiebene direkt in eine Delta-Tabelle schreiben konnte, ohne einen übergeordneten Katalog zu nutzen.

Wie ACID-Transaktionen in Delta Lake funktionieren

ACID-Transaktionen gewährleisten die Datenkonsistenz bei gleichzeitigen Schreibvorgängen, indem sie von jedem Schreibenden verlangen, die aktuelle Protokollversion zu prüfen, einen neuen Eintrag zu erstellen und diesen nur dann zu committen, wenn in der Zwischenzeit keine widersprüchliche Änderung aufgetreten ist. Wird ein Konflikt erkannt, versucht es der Schreibende erneut. Die ACID-Konformität verhindert Datenbeschädigungen, da ein Lesender eine Delta Lake-Tabelle niemals in einem teilweise geschriebenen Zustand sieht. Zudem ermöglichen ACID-Transaktionen komplexe Datenoperationen ohne Konflikte über überschneidende Partitionen hinweg.

Vom Spark-nativen Support zur Multi-Engine-Unterstützung

Da das ursprüngliche Commit-Modell von Delta Lake auf dem Zugriff auf das Dateisystem basierte, mussten Drittanbieter-Engines außerhalb von Apache Spark über statische Dateipfade auf Tabellen zugreifen, anstatt einen übergeordneten Katalog zu nutzen. Dadurch blieben diese Zugriffe unreguliert und konnten Schema-Beziehungen unbemerkt beschädigen. Databricks hat dies mit Katalog-Commits gelöst, einem offenen Standard, der es einem Katalog wie dem Unity Catalog ermöglicht, als Commit-Koordinator zu fungieren, sodass jeder Lese-, Schreib- und Erkennungsaufruf zentral autorisiert wird. Katalog-Commits sind jetzt allgemein verfügbar, wodurch Delta Lake an den katalogorientierten Ansatz angepasst wird, den Iceberg von Anfang an verwendet hat, und Multi-Table-Transaktionen ermöglicht werden.

Grundlagen der Dateiformate: Wie Parquet Data Skipping ermöglicht

Eine Parquet-Datei organisiert tabellarische Daten nach Spalten statt nach Zeilen und gruppiert Werte aus derselben Spalte in zusammenhängenden Blöcken, den sogenannten Zeilengruppen (Row Groups). Die spaltenbasierte Speicherung ermöglicht es einer Query-Engine, nur die Spalten zu lesen, auf die sich eine Abfrage bezieht, und den Rest zu überspringen – ein Hauptgrund, warum Parquet bei scanintensiven Workloads besser abschneidet als zeilenorientierte Formate.

Jede Zeilengruppe enthält Statistiken – Minimal- und Maximalwerte, Anzahl der Nullwerte und Wertverteilungen pro Spalte –, die in den Metadaten-Footer der Datei geschrieben werden. Diese Statistiken ermöglichen es einer Engine, ohne Dekomprimierung von Daten festzustellen, ob eine Zeilengruppe mit dem Filter einer Abfrage übereinstimmen könnte.

Offene Tabellenformate erweitern dieses Prinzip um eine Ebene: Die Manifestdateien von Iceberg und das Transaktionsprotokoll von Delta Lake rufen Statistiken auf Parquet-Ebene in der Metadatenschicht ab und speichern sie im Cache, sodass eine Engine ganze Datendateien überspringen kann, bevor sie aus dem Objektspeicher aufgelistet werden. Dieses zweistufige Überspringen von Daten trägt wesentlich zur verbesserten Abfrageleistung bei großen Tabellen bei. Databricks hat das Modell außerdem um den Datentyp Variant erweitert – der jetzt Teil von Parquet, Delta Lake und Iceberg ist. Er speichert semistrukturierte Payloads in typisierter binärer Form anstelle von unformatiertem JSON, sodass Engines verschachtelte Felder ohne aufwendiges Parsen extrahieren können.

Datenversionierung, Time Travel und inkrementelle Verarbeitung

Datenversionierung ist die Fähigkeit eines offenen Tabellenformats, eine Aufzeichnung jedes vorherigen Tabellenzustands zu behalten, anstatt Daten direkt zu überschreiben. Time Travel liest jede dieser vorherigen Versionen anhand der Versionsnummer, der Snapshot-ID oder des Zeitstempels. Offene Tabellenformate ermöglichen Time Travel und die Versionierung von Datensätzen von Haus aus, da jeder Schreibvorgang bereits einen neuen, unabhängig adressierbaren Snapshot oder Protokolleintrag erstellt.

Die inkrementelle Verarbeitung liest nur die Zeilen, die sich seit der letzten Verarbeitung einer Tabelle geändert haben, anstatt einen gesamten Datensatz neu zu scannen – das Muster hinter Change Data Capture (CDC), bei dem Pipelines nur die Einfügungen, Aktualisierungen und Löschungen verarbeiten, die auf eine Quelltabelle angewendet wurden. Row Lineage und Deletion Vectors, die in Delta Lake eingeführt und über Iceberg v3 auf Iceberg übertragen wurden, machten dies kostengünstiger: Row Lineage verfolgt, welche Zeilen sich seit dem letzten Scannen einer Tabelle geändert haben, und Deletion Vectors stellen gelöschte Zeilen als kompakte Bitmap dar, anstatt Datendateien neu zu schreiben.

Das unbegrenzte Aufbewahren jeder historischen Version ist teuer. Daher kombinieren offene Tabellenformate die Versionierung mit Aufbewahrungsrichtlinien (Retention Policies) und einer Vacuum- oder Expire-Snapshots-Operation, die Daten entfernt, auf die innerhalb des Aufbewahrungsfensters nicht mehr verwiesen wird. Ein zu aggressives Ausführen von Vacuum kann Time-Travel-Abfragen beschädigen, die sich noch auf ältere Versionen beziehen. Daher werden die Fenster so eingestellt, dass sie der am längsten laufenden Abfrage entsprechen, die ein solches Fenster benötigen könnte.

Ein sinnvoller Rhythmus für Produktionstabellen kombiniert die inkrementelle Verarbeitung in Intervallen, die an die Datenaufnahme angepasst sind – oft alle 5 bis 15 Minuten für die Streaming-Datenaufnahme –, mit Vacuum und dem Ablauf von Snapshots, die täglich außerhalb der Hauptabfragezeiten ausgeführt werden.

Metadatenmanagement und Leistungsoptimierung

Offene Tabellenformate verbessern die Abfrageleistung durch ein in Schichten organisiertes Metadatenmanagement: Manifestdateien oder Protokolleinträge beschreiben einzelne Datendateien, Snapshots oder Protokollversionen beschreiben den Tabellenzustand zu einem bestimmten Zeitpunkt, und ein Katalog verfolgt, welche Version derzeit maßgeblich ist. Unity Catalog verwaltet heute mehr als 17 Exabyte an Daten in offenen Tabellenformaten über Unternehmensbereitstellungen hinweg – ein Beweis dafür, wie viele Metadaten ein moderner Lakehouse-Katalog mittlerweile verwaltet.

Wenn Tabellen wachsen, können Manifestdateien und Checkpoints von Transaktionsprotokollen selbst die Abfrageplanung verlangsamen. Daher sollte die Wartung das Umschreiben von Manifesten in weniger, größere Dateien und das Anpassen der Checkpoint-Intervalle an die Schreibhäufigkeit umfassen. Databricks und die Open-Source-Community entwickeln eine einheitliche Metadatenstruktur für Delta Lake und Iceberg, die voraussichtlich im dritten Quartal als Preview verfügbar sein wird und das Fast-Write-Protokoll von Delta Lake mit dem Fast-Read-Manifestbaum von Iceberg kombiniert.

Metadaten-Caching – das Vorhalten von kürzlich aufgerufenen Manifesten, Checkpoints oder Katalogantworten im Arbeitsspeicher – verkürzt die Latenz bei wiederholten Abfragen, da bei jeder Anfrage ein vollständiger Durchlauf des Metadatenbaums vermieden wird. Dies ist besonders wichtig für BI-Workloads, die viele kleine Abfragen auf denselben großen Tabellen ausführen.

ACID-Transaktionen und Nebenläufigkeitskontrolle

Apache Iceberg, Delta Lake und Apache Hudi garantieren alle eine serialisierbare Isolation oder Snapshot-Isolation für Schreibvorgänge auf einzelnen Tabellen, sodass gleichzeitige Leser immer eine vollständige, konsistente Version und niemals einen unvollständigen Schreibvorgang sehen. Sie unterscheiden sich in der Koordination: Iceberg hat den Katalog schon immer als Source of Truth genutzt, Hudi verwendet seinen eigenen Timeline-Service und Delta Lake verließ sich auf die Atomarität des Dateisystems, bevor Catalog Commits es an das katalogkoordinierte Modell anpassten.

Alle drei Formate verwenden die optimistische Nebenläufigkeitskontrolle (Optimistic Concurrency Control): Anstatt eine Tabelle vor dem Schreiben zu sperren, liest ein Writer die aktuelle Version, bereitet seine Änderung vor und führt den Commit nur durch, wenn in der Zwischenzeit kein anderer Writer eine widersprüchliche Änderung committet hat. Wenn ein Konflikt erkannt wird, schlägt die Transaktion sicher fehl und wird entweder für die neuere Version wiederholt oder abgebrochen, sodass die Tabelle niemals in einem inkonsistenten Zustand verbleibt.

Der effektivste Weg, Schreibkonflikte (Write Contention) zu reduzieren, besteht darin, die Überschneidung zwischen gleichzeitigen Writern zu verringern: Partitionieren Sie Ingestion-Jobs so, dass verschiedene Pipelines in unterschiedliche Partitionen schreiben, fassen Sie kleine Schreibvorgänge in weniger, größere Commits zusammen und beschränken Sie Merge-Operationen auf die Partitionen, die sie betreffen. Katalog-Commits helfen auch hier, da Transaktionen über mehrere Tabellen hinweg es ermöglichen, zusammenhängende Aktualisierungen gemeinsam zu committen, anstatt als separate Schreibvorgänge aus mehreren Prozessen miteinander zu konkurrieren.

Auswahl eines Tabellenformats für Ihren Data Lake

Apache Iceberg eignet sich meist am besten, wenn der Lesezugriff über mehrere Engines hinweg im Vordergrund steht – also für Unternehmen, die dieselben Tabellen parallel über Trino, Snowflake, Flink und Spark abfragen. Delta Lake eignet sich am besten für Spark-zentrierte Pipelines, die Transaktionen über mehrere Tabellen hinweg und eine feingranulare Governance erfordern. Apache Hudi eignet sich am besten für hochfrequente Upsert-Workloads auf Datensatzebene wie die CDC-Replikation, bei denen die speziell entwickelte Indizierung die Leistung allgemeiner Merge-Operationen übertrifft.

Die Engine-Kompatibilität sollte anhand der bereits in der Produktion befindlichen Query-Engines bewertet werden, nicht nur anhand einer Feature-Liste – ein technisch überlegenes Format, dem ein ausgereifter Connector für die primäre Engine eines Teams fehlt, birgt mehr Risiken, als es beseitigt. Delta Kernel, eine Open-Source-Bibliothek in Java und Rust, ist zu einer gängigen Methode geworden, mit der Engines Unterstützung für Delta Lake hinzufügen, ohne das Protokoll neu implementieren zu müssen. Sie bildet bereits die Basis für DuckDB- und ClickHouse-Integrationen, und die beiden Implementierungen laufen auf einen gemeinsamen Rust-Kern hinaus.

Bevor Sie sich auf ein Format festlegen, sollten Sie einen Proof of Concept mit einer repräsentativen, mäßig unstrukturierten Produktionstabelle durchführen: Messen Sie die Schreiblatenz unter gleichzeitiger Last, stellen Sie sicher, dass die Ziel-Engines das Format nativ und nicht über einen langsamen Connector lesen, und überprüfen Sie, ob sich Schema-Evolution und Time Travel wie erwartet verhalten.

Interoperabilität, Kataloge und Anbieterüberlegungen

Katalogoptionen und formatübergreifende Interoperabilität

Ein Katalog ist das System of Record, das nachverfolgt, welche Tabellen existieren, wo ihre Daten liegen und welcher Snapshot maßgeblich ist. Zu den Optionen gehören der ursprüngliche Hive Metastore, AWS Glue Data Catalog und Unity Catalog, der Delta Lake- und Apache Iceberg-Tabellen gemeinsam unter einheitlichen Zugriffsrichtlinien verwaltet. Delta Lake UniForm geht noch weiter und ermöglicht es, eine einzige Kopie von Delta Lake-Daten nativ als Iceberg-Tabelle zu lesen, ohne den Speicher zu duplizieren. Dies löst das Problem des Format-Lock-ins, das Teams oft dazu veranlasst, die Standardisierung aufzuschieben.

Risiken des Vendor-Lock-ins und wie man sie minimiert

Der sicherste Weg, das Risiko eines Vendor-Lock-ins zu minimieren, besteht darin, ein Format mit mehr als einer unabhängigen Engine-Implementierung zu wählen und sicherzustellen, dass der Katalogzugriff – nicht nur der Dateizugriff – über Plattformen hinweg portabel ist, die ein Team später benötigen könnte. Da Iceberg und Delta Lake Open-Source sind, bindet das Speichern von Daten in einem der beiden Formate ein Unternehmen an sich nicht an eine bestimmte Verarbeitungs-Engine, auch wenn die darauf aufgebauten Governance-Schichten in ihrer Portabilität variieren können.

Betrieb, Überwachung und Best Practices

Die Tabellenwartung sollte als Runbook kodifiziert werden und keine Ad-hoc-Aufgabe sein: Definieren Sie, welche Tabellen eine Komprimierung (Compaction) benötigen und ab welchem Dateigrößen-Schwellenwert, legen Sie Aufbewahrungsfenster für Vacuum und den Ablauf von Snapshots basierend darauf fest, wie weit zurückliegend Jobs Daten abfragen, und planen Sie beides außerhalb der Hauptabfragezeiten.

Die Überwachung des Tabellenzustands sollte die Anzahl der Dateien und die durchschnittliche Dateigröße pro Tabelle, die Commit-Fehlerraten und das Alter der ältesten Datendatei im Verhältnis zu einem Komprimierungszeitplan verfolgen und Warnmeldungen ausgeben, wenn die Anzahl kleiner Dateien oder die Konfliktraten sprunghaft ansteigen. Diese Metriken erfassen Metadaten-Bloat und Schreibkonflikte (Write Contention), bevor sie sich in Form von langsamen Abfragen bemerkbar machen.

Da offene Tabellenformate die Schema-Evolution unterstützen, ohne bestehende Abfragen zu beeinträchtigen, werden Schemaänderungen oft direkt auf Produktionstabellen angewendet – doch diese Einfachheit verleitet dazu, Tests zu überspringen. Teams sollten Änderungen anhand repräsentativer Downstream-Abfragen validieren und regelmäßig ein Rollback auf einen vorherigen Snapshot proben, damit die Wiederherstellung nach einer fehlerhaften Änderung ein eingespieltes Verfahren ist und kein erster Versuch unter Druck.

Fazit: Abwägungen bei offenen Tabellenformaten und nächste Schritte

Apache Iceberg, Delta Lake und Apache Hudi lösen dasselbe Kernproblem – sie bringen ACID-Transaktionen, Schema-Evolution und Time Travel für Daten, die in kostengünstigen Objektspeichern gespeichert sind. Dies geschieht durch Metadaten-Designs, die durch ihren jeweiligen Ursprung geprägt sind: Multi-Engine-Analytics für Iceberg, Spark-native Pipelines für Delta Lake und hochfrequente Upserts für Hudi. Parquet bleibt das gemeinsame zugrunde liegende Dateiformat für alle drei, und neuere Innovationen – Deletion Vectors, Row Lineage, Variant und katalogkoordinierte Commits – nähern sich formatübergreifend an, anstatt isoliert zu bleiben.

Der praktische nächste Schritt für die meisten Teams ist ein Proof of Concept mit klarem Fokus: Wählen Sie das Format, das zu Ihrem bestehenden Engine-Stack passt, testen Sie es mit realen Produktionsdatenmengen und stellen Sie sicher, dass der verwaltende Katalog später auf ein zweites Format erweitert werden kann. Das offene, formatunabhängige Lakehouse-Storage von Databricks ermöglicht es Teams, Daten einmal zu speichern und sie nativ als Delta Lake oder Apache Iceberg abzufragen – verwaltet unter einem einzigen Katalog, ohne Daten zu duplizieren oder sich an ein einzelnes Format zu binden.

Häufig gestellte Fragen zu offenen Tabellenformaten

Was ist ein offenes Tabellenformat?

Ein offenes Tabellenformat ist eine Open-Source-Metadatenschicht, die auf Datendateien im Objektspeicher aufsetzt und einem Data Lake datenbankähnliche Funktionen wie ACID-Transaktionen, Schema-Evolution und Time Travel hinzufügt. Apache Iceberg, Delta Lake und Apache Hudi sind die drei wichtigsten offenen Tabellenformate im produktiven Einsatz. Jedes von ihnen verwandelt eine Sammlung von Parquet- oder ORC-Dateien in eine Tabelle, die von jeder unterstützten Engine sicher gelesen und geschrieben werden kann.

Was ist der Unterschied zwischen einem Tabellenformat und einem Dateiformat?

Ein Dateiformat wie Parquet oder ORC definiert, wie eine einzelne Datendatei auf dem Datenträger komprimiert und organisiert ist, während ein Tabellenformat wie Apache Iceberg oder Delta Lake definiert, wie viele dieser Dateien zusammen eine konsistente, abfragbare Tabelle bilden. Offene Tabellenformate bauen auf Dateiformaten auf und fügen die Metadatenschicht hinzu – Manifeste, Transaktionsprotokolle und Kataloge –, die Dateiformate allein nicht bieten.

Können Delta Lake- und Apache Iceberg-Tabellen zusammenarbeiten?

Ja. Mit Delta Lake UniForm kann eine einzige Kopie von Delta Lake-Tabellendaten nativ als Apache Iceberg-Tabelle gelesen werden, ohne dass Speicherplatz dupliziert werden muss. Kataloge wie Unity Catalog können beide Formate nebeneinander unter einheitlichen Zugriffsrichtlinien verwalten. Diese Interoperabilität ermöglicht es Unternehmen, sich auf eine gemeinsame Governance zu einigen, ohne jede Engine auf dasselbe Tabellenformat zwingen zu müssen.

Welches offene Tabellenformat sollte ich wählen?

Das beste offene Tabellenformat hängt von den Abfrage-Engines und Workloads ab, die bereits in der Produktion eingesetzt werden: Apache Iceberg eignet sich für Multi-Engine-Analysen über Tools wie Trino und Snowflake hinweg, Delta Lake eignet sich für Spark-zentrierte Pipelines, die Multi-Tabellen-Transaktionen erfordern, und Apache Hudi eignet sich für hochfrequente Upsert-Workloads auf Datensatzebene wie die CDC-Replikation. Ein Proof of Concept mit realen Produktionsdaten bestätigt die richtige Entscheidung.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag