Apache Iceberg: Das Tabellenformat für Multi-Engine-Architekturen, mit Katalog-Frage und Entscheidungstabelle
Wie Apache Iceberg mehrere Engines gleichzeitig auf denselben Tabellen arbeiten lässt und warum der Katalog die zentrale Entscheidung ist.
Die Kernaussagen auf einen Blick.
- Apache Iceberg ist ein offenes Tabellenformat, das mehrere Engines gleichzeitig und verlässlich auf denselben Tabellen im Objektspeicher arbeiten lässt.
- Snapshot-Metadaten liefern ACID-Garantien, Schema-Änderungen ohne Neuschreiben der Daten und Abfragen auf historische Stände.
- Vor der Format-Entscheidung stehen drei Prüffragen: Welche Engines müssen lesen und schreiben, wer betreibt den Katalog, wer übernimmt die Tabellen-Wartung?
- Mein Vorschlag: Die Katalog-Frage vor der Format-Frage klären und Interop-Pfade wie UniForm als dritte Option neben dem Entweder-oder bewerten.
Inhaltsverzeichnis
Wenn jede Engine ihre eigene Kopie der Daten hält
Ein Unternehmen betreibt Spark-Pipelines für das Data Engineering, ein BI-Team arbeitet auf Snowflake, und ein drittes Team hat Trino für Ad-hoc-Analysen eingeführt. Jede Plattform hält ihre eigene Kopie der zentralen Tabellen. Nachts laufen Synchronisations-Jobs zwischen den Systemen, die Stände weichen regelmäßig voneinander ab, und die Speicherkosten fallen dreifach an. Als das Controlling fragt, welche der drei Umsatztabellen die verbindliche ist, kann niemand die Frage in einem Satz beantworten.
Dieses Bild entsteht überall dort, wo gewachsene Analytics-Landschaften je Plattform ein eigenes Speicherformat mitbringen: Ohne gemeinsamen Tabellenbestand bleibt nur das Kopieren.
Müssen wir wirklich jede Tabelle pro Plattform kopieren? Welches Format können Spark, Snowflake und Trino gemeinsam lesen und schreiben? Was passiert mit unseren Sync-Strecken, wenn eine vierte Engine dazukommt? Und binden wir uns mit der Format-Wahl an einen Anbieter?
Apache Iceberg beantwortet diese Fragen über eine Architektur-Idee: Die Tabellen gehören dem Objektspeicher und einem Katalog, und jede Engine ist nur noch Gast auf demselben Bestand.
Was ist Apache Iceberg?
Apache Iceberg ist ein offenes Tabellenformat für große analytische Datenbestände. Es legt fest, wie aus Dateien im Objektspeicher (Parquet, ORC oder Avro auf S3, ADLS oder Google Cloud Storage) verlässliche Tabellen mit ACID-Transaktionen (atomar, konsistent, isoliert, dauerhaft), Schema-Verwaltung und Versionshistorie werden. Es wird relevant, sobald mehrere Engines denselben Datenbestand lesen und schreiben sollen. Es ersetzt weder Datenmodellierung noch Governance.
Entstanden ist das Format bei Netflix als Antwort auf die Grenzen von Apache Hive. IBM beschreibt die Herkunft so: 2017 von Data Engineers bei Netflix und Apple entwickelt, im Folgejahr an die Apache Software Foundation übergeben und seit 2020 ein Top-Level-Projekt unter neutraler Governance. Damit gehört das Format keinem Anbieter; es wird von einer Community weiterentwickelt, in der unter anderem AWS, Google, Snowflake und Databricks aktiv sind. Produktiv nutzen es Unternehmen wie Airbnb, Adobe, Expedia und LinkedIn.
Iceberg macht sichtbar, was vorher in Dateipfaden und Konventionen versteckt war: welche Dateien zu einer Tabelle gehören, welches Schema gerade gilt und welcher Stand der aktuelle ist. Mehrere Teams können dadurch mit unterschiedlichen Werkzeugen auf einem Bestand arbeiten, und die Plattform-Entscheidung trennt sich von der Speicher-Entscheidung. Was das Format strukturell ausblendet, bleibt trotzdem Arbeit: Datenqualität, fachliche Modellierung und Zugriffsregeln entstehen weiterhin außerhalb des Formats. Wie Speicher, Tabellenformat und Governance zusammen ein Data Lakehouse ergeben, zeigen wir im Überblick zum Lakehouse.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wie verwaltet Apache Iceberg seine Tabellen?
Der Mechanismus hinter Iceberg ist eine Metadaten-Hierarchie. Die Spezifikation des Tabellenformats definiert drei Ebenen: Ein Metadata File beschreibt den Zustand der Tabelle (Schema, Partitionierung, Liste der Versionsstände), Manifest Lists und Manifest Files führen darunter auf, welche Datendateien zu einem Stand gehören, inklusive Statistiken für schnelles Filtern. Abfragen planen über diese Statistiken, welche Dateien sie überhaupt öffnen müssen; irrelevante Dateien werden gar nicht erst gelesen, was Scan-Zeiten verkürzt und Compute-Kosten senkt. Jeder Schreibvorgang erzeugt einen neuen Snapshot, also einen vollständigen, unveränderlichen Versionsstand der Tabelle.
Für das Sync-Szenario von oben hat diese Mechanik unmittelbare Folgen. Bricht ein Lade-Job zur Hälfte ab, wird der neue Snapshot nie aktiv, und alle lesenden Engines sehen weiter den letzten konsistenten Stand. Eine Schema-Änderung wie eine neue oder umbenannte Spalte wird im Metadata File registriert, ohne dass Datendateien neu geschrieben werden (Schema Evolution). Abfragen auf einen früheren Stand laufen gegen einen älteren Snapshot, was Fehleranalysen und Audit-Fragen deutlich verkürzt (Time Travel). Und die Partitionierung verwaltet Iceberg intern über Hidden Partitioning: Die Tabelle weiß selbst, wie ihre Daten organisiert sind, und Abfragen müssen das Partitionsschema nicht kennen. Das Partitionsschema lässt sich später anpassen, ohne Bestandsdaten neu zu schreiben (Partition Evolution); neue Daten folgen dann der geänderten Aufteilung.
Die Management-Folge dieser Mechanik: Korrektheit wird zur Eigenschaft des Formats und ist damit unabhängig von der Ablage-Disziplin einzelner Teams. Niemand legt mehr versehentlich Dateien an der Tabelle vorbei ab oder löscht sie unbemerkt. Dafür entsteht eine neue Betriebsaufgabe, denn Snapshots, Manifeste und viele kleine Dateien sammeln sich an und wollen regelmäßig kompaktiert und aufgeräumt werden. Ein Format mit Versionshistorie bringt einen Wartungsplan mit.
Warum der Katalog die unterschätzte Entscheidung ist
Die Metadaten-Hierarchie lässt eine Frage offen: wo der Zeiger auf das aktuell gültige Metadata File steht. Diese Antwort gibt der Katalog. Er hält pro Tabelle den Zeiger auf den gültigen Zustand und macht Schreibvorgänge atomar, indem er den Zeiger erst nach erfolgreichem Commit umsetzt. Auch parallele Schreibvorgänge laufen über diesen Mechanismus: Schreiben zwei Engines gleichzeitig auf dieselbe Tabelle, gewinnt der zuerst abgeschlossene Commit, und die zweite Engine setzt automatisch auf dem neuen Stand wieder auf. Multi-Engine-Schreiben bleibt dadurch konsistent, ohne dass sich die Plattformen untereinander abstimmen müssen. Der Katalog ist damit Pflichtkomponente, kein optionales Zubehör.
Genau hier liegt die Entscheidung, die in Format-Diskussionen regelmäßig zu kurz kommt. Wer den Katalog betreibt, kontrolliert den Zugang zu allen Tabellen: Berechtigungen, Auditierbarkeit und die Frage, welche Engine überhaupt schreiben darf, laufen über diese Komponente. Eine Format-Wahl ohne Katalog-Strategie verschiebt die Governance-Entscheidung in ein Nebenprodukt des jeweiligen Anbieters.
Die Optionen unterscheiden sich deutlich in Reife und Bindung:
| Katalog-Option | Betreiber | Wofür geeignet |
|---|---|---|
| Hive Metastore | eigenes Team (Legacy-Komponente) | Bestandsumgebungen mit Hadoop-Historie, Übergangsphasen |
| AWS Glue | AWS (verwalteter Dienst) | AWS-zentrierte Landschaften mit Athena, EMR, Redshift |
| Iceberg REST Catalog | je nach Implementierung | herstellerübergreifender Standard-Zugang, Zukunftspfad |
| Apache Polaris | eigenes Team oder Snowflake-Dienst | offener REST-Katalog, von Snowflake initiiert |
| Unity Catalog | Databricks (verwalteter Dienst) | Databricks-zentrierte Plattformen mit Iceberg-Anbindung |
| Snowflake-Katalog | Snowflake (verwalteter Dienst) | Snowflake-zentrierte Plattformen mit Iceberg-Tabellen |
Eine Orientierung gibt die REST-Catalog-Spezifikation: Sie definiert eine einheitliche Schnittstelle, über die Engines mit beliebigen Katalogen sprechen können, und entkoppelt damit die Katalog-Wahl von der Engine-Wahl. Beim Bewerten der Optionen zählt deshalb weniger der Funktionsumfang von heute. Wichtiger ist, ob der Katalog die REST-Schnittstelle sauber bedient und ob das eigene Team ihn betreiben kann oder betreiben lassen will.
Wann ist Apache Iceberg die richtige Wahl?
Die Format-Entscheidung lässt sich an der Engine-Landschaft festmachen. Iceberg ist sinnvoll, wenn mehrere Plattformen denselben Bestand lesen und schreiben müssen. Die Abdeckung reicht dabei über Spark, Trino, Flink und Snowflake hinaus; auch Athena, BigQuery, Dremio und DuckDB arbeiten mit Iceberg-Tabellen. Ein Stack-Default wie Delta Lake passt besser, wenn eine Plattform den Großteil der Workloads trägt und Interop die Ausnahme bleibt.
| Situation | Naheliegende Wahl | Begründung |
|---|---|---|
| Spark, Snowflake und Trino arbeiten auf denselben Kerntabellen | Apache Iceberg | breite Engine-Abdeckung über Plattformgrenzen hinweg, Katalog-Standard über REST |
| Databricks trägt fast alle Workloads, BI liest über die Plattform | Delta Lake | Stack-Default mit geringster Reibung im eigenen Ökosystem |
| Databricks-zentriert, aber externe Engines sollen mitlesen | Interop-Pfad (UniForm) | Delta bleibt führend, Iceberg-Leser kommen trotzdem an die Daten |
| Bestehender Snowflake-Stack soll sich zum offenen Speicher öffnen | Apache Iceberg | von Snowflake als Weg zu externen, offenen Tabellen positioniert |
| Ein Team, eine Engine, kein Multi-Engine-Bedarf absehbar | Stack-Default behalten | Formatwechsel ohne Anlass kostet Quartale ohne Gegenwert |
Eine kurze Heuristik: Wenn mindestens zwei Engines schreiben müssen, führt der Weg zu Iceberg oder zu einem Interop-Pfad. Wenn nur eine Engine schreibt und andere gelegentlich lesen, reicht meist der Stack-Default plus Interop-Schicht. Wenn niemand außerhalb der Hauptplattform zugreift, gibt es keinen Anlass für einen Wechsel.
Neben der Engine-Zahl sprechen bestimmte Workload-Muster für das Format. Iceberg unterstützt Änderungen und Löschungen auf Ebene einzelner Datensätze; damit lassen sich Löschpflichten aus dem Datenschutz umsetzen und nachträgliche Korrekturen wie Retouren in Verkaufsdaten einarbeiten, ohne ganze Tabellen neu zu schreiben. AWS dokumentiert Aktualisierungen auf Datensatzebene und inkrementelle Verarbeitung als typische Einsatzfälle. Auch Streaming-Quellen schreiben über Engines wie Flink direkt in Iceberg-Tabellen.
Beim Prüfen von Anbieter-Aussagen lohnt Genauigkeit, denn hinter dem Etikett Iceberg-Support stecken drei verschiedene Stufen: Lesen, Schreiben und Verwalten. Snowflake dokumentiert beispielsweise Varianten mit eigenem oder externem Katalog, wobei der Funktionsumfang je nach Katalog-Variante unterschiedlich ausfällt. Dieselbe Prüfung gilt für jede Plattform. Architekturen, die diese Fragen offenlassen, sehen auf der Folie fertig aus; im Betrieb tragen sie selten.
Lesen
Kann die Engine Iceberg-Tabellen nur abfragen, ohne selbst zu schreiben?
Schreiben
Kann die Engine committen, oder bleibt sie auf Lesezugriff beschränkt?
Verwalten
Wessen Katalog hält den Zeiger auf den gültigen Stand, und wer kontrolliert damit den Zugriff?
Fällt die Prüfung zugunsten eines Wechsels aus, stehen als Nächstes Bestandsdaten und Pipelines an. Wie sich ein solcher Umstieg in Etappen planen lässt, zeigen wir im Überblick zur Lakehouse-Migration.
Koexistenz im selben Stack
Die Debatte „Delta Lake vs. Iceberg“ hat sich in den letzten Jahren spürbar entschärft. Databricks hat 2024 Tabular übernommen, das Unternehmen der Iceberg-Gründer, und investiert seitdem in beide Formate. Microsoft Learn dokumentiert für Azure Databricks Lese- und Schreibzugriff auf Iceberg-Tabellen über Unity Catalog, inklusive der Iceberg-REST-Schnittstelle für externe Engines. Der Befund für die Plattform-Entscheidung: Beide Formate sind offen, beide werden aktiv weiterentwickelt, und die Hersteller bauen die Brücken selbst.
Der Unterschied zwischen Delta Lake und Iceberg liegt weniger im Funktionsumfang als in der Architektur und im Ökosystem-Schwerpunkt. Delta Lake protokolliert Änderungen in einem Transaktionslog im Storage und ist der Default im Databricks-Umfeld; Iceberg verwaltet Zustände über Snapshot-Metadaten hinter einem Katalog und hat die breitere Engine-Abdeckung außerhalb. Wie das Delta-Transaktionslog arbeitet und welches Betriebsmodell es mitbringt, zeigen wir im Überblick zu Delta Lake. Apache Hudi ergänzt das Feld der offenen Tabellenformate, mit Stärken bei Streaming-Ingestion und inkrementellen Updates; die meisten Format-Entscheidungen verhandeln heute jedoch die Achse aus Delta, Iceberg und Interop-Pfad.
Für Plattformen mit Databricks-Schwerpunkt und externem Lese-Bedarf gibt es einen dritten Weg: UniForm erzeugt Iceberg-Metadaten auf Delta-Tabellen, sodass Iceberg-Clients denselben Bestand lesen können, ohne dass Daten kopiert werden. Wie dieser Brückenschlag funktioniert und wo seine Grenzen liegen, erklären wir in UniForm. Damit wird aus der Glaubensfrage eine Architektur-Aufgabe: führendes Format festlegen, Interop-Richtung definieren, Katalog-Zugang regeln.
Was Apache Iceberg nicht löst
Iceberg schafft eine gemeinsame, transaktionssichere Tabellen-Basis für mehrere Engines. Für eine belastbare Datenplattform reicht das Format allein jedoch nicht aus.
Datenqualität
Iceberg garantiert, dass ein Commit vollständig sichtbar wird oder gar nicht. Ob die geschriebenen Werte fachlich stimmen, ob Pflichtfelder gefüllt sind und Kennzahlen plausibel bleiben, muss die Pipeline davor sicherstellen.
Datenmodellierung
Welche Tabellen es geben soll, wie Schichten aufeinander aufbauen und wo verdichtete, verbindliche Sichten entstehen, bleibt Architekturarbeit.
Zugriffs-Governance
Der Katalog hält Zeiger und kann Berechtigungen durchsetzen, aber wer welche Daten sehen darf, welche Rollen es gibt und wie Audits ablaufen, ist eine Organisations-Entscheidung mit eigenem Regelwerk.
Eigenbetrieb
Kompaktierung kleiner Dateien, das Verfallen alter Snapshots und das Aufräumen verwaister Dateien brauchen geplante Wartungsläufe. Ohne sie wachsen Metadaten und Speicherkosten, und Abfragen werden über Monate langsamer.
Struktur im Lake
Liegt der Bestand heute als lose Dateisammlung ohne Struktur vor, löst ein Tabellenformat die Aufräumarbeit nicht ab.
Wie sich Rohdaten über Schichten zu belastbaren Datenprodukten entwickeln, führen wir im Überblick zur Medallion-Architektur aus. Warum ein Data Lake ohne verbindliche Strukturen kippt, zeigen wir im Überblick zum Data Lake.
Diese Grenzen schmälern den Wert des Formats nicht, sie ordnen ihn ein. Iceberg übernimmt die Tabellen-Schicht zuverlässig und schafft die Voraussetzung dafür, dass Qualitäts-, Modellierungs- und Governance-Arbeit auf einem stabilen Fundament stattfindet.
Sobald mehrere Teams und Engines auf dem Bestand arbeiten, gehören Wartungsläufe, Katalog-Betrieb und Berechtigungsmodell in denselben Plan wie das Format selbst. Eine Format-Entscheidung ohne diesen Betriebsanteil bleibt eine halbe Entscheidung.
Fazit
Apache Iceberg schließt die Lücke zwischen günstigem Objektspeicher und verlässlichen, gemeinsam genutzten Tabellen: ein Bestand, viele Engines, nachvollziehbare Versionsstände.
Die Architektur dahinter ist bewusst katalog-zentriert, und genau daraus folgt die wichtigste Konsequenz für die Entscheidung.
Drei Faktoren bestimmen, ob sich der Einsatz trägt: erstens echter Multi-Engine-Bedarf (mindestens zwei Plattformen müssen denselben Bestand lesen und schreiben), zweitens eine geklärte Katalog-Frage (wer betreibt den Katalog, wer vergibt darüber Rechte), drittens ein eingeplanter Betrieb (Kompaktierung und Snapshot-Pflege laufen regelmäßig und automatisiert).
Trägt eine einzige Plattform fast alle Workloads, ist der Stack-Default die ruhigere Wahl, und Interop-Schichten wie UniForm decken den Rest ab. Ein Formatwechsel ohne konkreten Multi-Engine-Anlass bindet Quartale an ein Projekt, dessen Nutzen erst mit der zweiten schreibenden Engine entsteht.
Mein Vorschlag: Zuerst die Engine-Landschaft der nächsten zwei Jahre aufschreiben, dann die Katalog-Frage beantworten und erst danach das Format festlegen. Wer die Reihenfolge einhält, trifft die Format-Entscheidung an der Stelle, an der sie tatsächlich Wirkung entfaltet: beim gemeinsamen Zugriff.
Zuerst die Engine-Landschaft der nächsten zwei Jahre aufschreiben, dann die Katalog-Frage beantworten und erst danach das Format festlegen.
Bereit für die Iceberg-Entscheidung?
Ob Apache Iceberg eure Plattform-Landschaft vereinfacht oder zusätzliche Komplexität erzeugt, lässt sich in einem ersten Data & AI Assessment gut einordnen.
- welche eurer Workloads und Engines echte Kandidaten für einen gemeinsamen Iceberg-Bestand sind
- welche Katalog-, Governance- und Betriebsrisiken vor der Format-Entscheidung geprüft werden müssen
- welcher Architekturpfad zwischen Iceberg, Delta Lake und Interop für eure Situation trägt
FAQ
Apache Iceberg ist ein offenes Tabellenformat für analytische Daten im Objektspeicher. Es organisiert Parquet-, ORC- oder Avro-Dateien über eine Metadaten-Hierarchie zu Tabellen mit ACID-Transaktionen, Schema Evolution und Time Travel. Mehrere Engines wie Spark, Trino, Flink oder Snowflake können dadurch gleichzeitig und konsistent auf demselben Datenbestand arbeiten.
