Apache Iceberg: Leitfaden zum offenen Tabellenformat

Apache Iceberg ist ein offenes Tabellenformat für große analytische Datenbestände, entworfen als Antwort auf die Grenzen der Tabellenverwaltung im Hive-Stil auf Objektspeicher in der Cloud. Ursprünglich bei Netflix entwickelt und an die Apache Software Foundation übergeben, bietet Iceberg ACID-Transaktionen, Schema-Evolution, verborgene Partitionierung und Time Travel auf Basis der üblichen Dateiformate wie Parquet, ORC und Avro. Es ist zu einem der vorherrschenden offenen Tabellenformate im Umfeld des Data Lakehouse geworden, mit breiter Verbreitung über Snowflake, Databricks, AWS, Google Cloud und Apache Flink.

Was ist Apache Iceberg?

Das grundlegende Problem, das Iceberg löst: Objektspeicher in der Cloud, also Amazon S3, Azure Data Lake Storage oder Google Cloud Storage, ist ein hervorragender Ort, um große Datenmengen günstig abzulegen, war aber nie als Datenbank gedacht. Herkömmliche Wege, Daten auf Objektspeicher abzufragen, allen voran Apache Hive, stützten sich auf Verzeichnisstrukturen und Namenskonventionen für Partitionen, die im großen Maßstab erhebliche Probleme bei Zuverlässigkeit und Leistung erzeugten. Iceberg ersetzt diesen Ansatz über Verzeichnisse durch eine echte Ebene aus Tabellen-Metadaten, die genau festhält, welche Dateien zu einem Snapshot der Tabelle gehören, und ermöglicht damit zuverlässigen, leistungsfähigen und nebenläufigen Zugriff ohne die Grenzen des Hive-Metastore.

Das „offen“ im offenen Tabellenformat wiegt so schwer wie die technischen Fähigkeiten. Anders als proprietäre Formate der Warehouse-Anbieter lassen sich Iceberg-Tabellen von jeder verträglichen Engine lesen und schreiben. Dieser von der Engine unabhängige Entwurf bedeutet, dass Organisationen nicht an einen einzigen Hersteller gebunden sind: Spark, Trino, Flink, Dremio, StarRocks, Snowflake und BigQuery greifen alle unmittelbar auf dieselben Iceberg-Tabellen zu. Die Verträglichkeit mit mehreren Engines ist der bestimmende Vorteil des offenen Tabellenformats gegenüber geschlossenen Alternativen und stützt unmittelbar die Verfolgung der Data Lineage über heterogene Verarbeitungsumgebungen hinweg.

Warum offene Tabellenformate zählen

Vor den offenen Tabellenformaten hatten Data Lakes eine grundlegende Schwäche: Sie waren Systeme, in die einmal geschrieben und vielfach gelesen wird. Dateien ließen sich hinzufügen, einzelne Datensätze aber nicht wirtschaftlich ändern oder löschen. ACID-Transaktionen, also die Zusage, dass Schreibvorgänge entweder ganz gelingen oder ganz scheitern und dass Lesende nie einen halben Schreibvorgang sehen, blieben relationalen Datenbanken und dem Data Warehouse vorbehalten. Data Lakes waren schnell und günstig, für Lasten mit Anspruch auf eine konsistente Sicht aber unzuverlässig.

Offene Tabellenformate wie Apache Iceberg bringen die Zuverlässigkeit einer Datenbank auf Objektspeicher in der Cloud, ohne die Flexibilität und die Kostenvorteile des Modells vom Data Lake aufzugeben. Sie tun das über eine eigene Ebene aus Metadaten, nämlich eine Reihe von Manifest-Dateien und eine JSON-Datei mit den Metadaten der Tabelle, die festhält, welche Datendateien zum aktuellen Snapshot der Tabelle gehören. Diese Ebene aus Metadaten ist es, die ACID-Transaktionen ermöglicht: Ein Schreibvorgang erzeugt atomar einen neuen Snapshot, und Lesende sehen stets einen konsistenten Snapshot, gleich welche Schreibvorgänge nebenher laufen.

Für Umsetzungen der Medallion-Architektur sind offene Tabellenformate unverzichtbar. Die Schichten Bronze, Silver und Gold verlangen jeweils andere Schreibmuster, nämlich hohen Durchsatz beim Anhängen in Bronze, CDC-Upserts in Silver sowie Aggregation und Überschreiben in Gold, und offene Tabellenformate bedienen all diese Muster zuverlässig in einer einzigen Schicht der Speicherung.

Die wichtigsten Funktionen von Apache Iceberg

ACID-Transaktionen. Iceberg unterstützt ACID-Transaktionen vollständig über die Isolation von Snapshots. Jeder Schreibvorgang, ob INSERT, UPDATE, DELETE oder MERGE, erzeugt einen neuen Snapshot der Tabelle, indem er eine neue Datei mit Metadaten anlegt, die auf eine neue Menge von Datendateien zeigt. Der vorherige Snapshot bleibt unversehrt und für Lesende sichtbar, bis diese sich auf einen neueren Snapshot festlegen. Dieses optimistische Modell der Nebenläufigkeit erlaubt viele gleichzeitig Lesende und Schreibende ohne Sperren, was für analytische Lasten im großen Maßstab wesentlich ist und über Löschungen auf Zeilenebene die Compliance mit dem Recht auf Löschung nach der DSGVO ermöglicht.

Schema-Evolution. Eine der praktisch wertvollsten Eigenschaften von Iceberg ist die Unterstützung für Schema-Evolution, ohne vorhandene Daten neu zu schreiben. In Tabellen lassen sich Spalten hinzufügen, umbenennen, umordnen oder entfernen, ohne die darunterliegenden Parquet-Dateien anzufassen. Iceberg verfolgt die Identität einer Spalte über stabile ganzzahlige Spalten-IDs statt über Spaltennamen, sodass das Umbenennen einer Spalte bereits vorher geschriebene Dateien nicht bricht. Das ist ein deutlicher Fortschritt gegenüber Tabellen im Hive-Stil, bei denen Änderungen am Schema oft ein teures vollständiges Neuschreiben der Tabelle verlangten.

Verborgene Partitionierung. Herkömmliche Partitionierung im Hive-Stil verlangt, dass Nutzer das Partitionierungsschema einer Tabelle kennen und die Partitionsspalten in ihre Abfragen aufnehmen, um vollständige Scans der Tabelle zu vermeiden. Iceberg führt die verborgene Partitionierung ein, die das logische Schema der Tabelle vom physischen Aufbau der Partitionen entkoppelt. Partitionen werden als Transformationsfunktionen auf Tabellenspalten festgelegt, etwa die Partitionierung nach dem Monat aus einer Spalte mit Zeitstempel, und die Engine für die Abfrage nutzt den Aufbau der Partitionen selbsttätig zum Aussortieren von Dateien, ohne dass Nutzer ausdrücklich nach der Partitionsspalte filtern müssen. Muss sich die Strategie der Partitionierung ändern, unterstützt Iceberg die Evolution der Partitionierung, ohne alte Dateien neu zu schreiben.

Time Travel und Verlauf der Snapshots. Iceberg bewahrt den vollständigen Verlauf der Snapshots einer Tabelle und ermöglicht damit Abfragen per Time Travel, die den Zustand einer Tabelle zu einem beliebigen Zeitpunkt ihres Verlaufs lesen. Das ist unbezahlbar für die Fehlersuche bei Problemen mit der Datenqualität, die Prüfung historischer Werte, das Nachstellen früherer Ergebnisse und die Umsetzung langsam veränderlicher Dimensionen. Time Travel wird entweder über die ID des Snapshots oder über einen Zeitstempel angesprochen, in SQL etwa mit SELECT * FROM table FOR SYSTEM_TIME AS OF '2025-01-01'.

Operationen auf Zeilenebene. Iceberg unterstützt DELETE, UPDATE und MERGE auf Zeilenebene über zwei Strategien der Speicherung. Copy-on-Write (CoW) schreibt betroffene Datendateien vollständig neu und erzeugt saubere, für die Leseleistung optimierte Dateien. Merge-on-Read (MoR) schreibt kleine Dateien mit Löschungen neben die ursprünglichen Datendateien und führt sie beim Lesen zusammen, was schnellere Schreibvorgänge bei etwas aufwendigerem Lesen bietet. Welche der beiden Strategien passt, hängt vom Verhältnis zwischen Lesen und Schreiben in der jeweiligen Last ab.

Apache Iceberg, Delta Lake und Apache Hudi

Die drei vorherrschenden offenen Tabellenformate, Apache Iceberg, Delta Lake und Apache Hudi, verfolgen dasselbe Ziel, haben aber verschiedene Entwurfsphilosophien und Stärken.

Delta Lake, von Databricks entwickelt, war das erste breit eingesetzte offene Tabellenformat und hat das Konzept des Lakehouse geprägt. Es ist eng mit Apache Spark und der Plattform von Databricks verzahnt. Die wesentlichen Stärken von Delta Lake sind die ausgereifte Anbindung an Spark, das Clustering per Z-Ordering und die breite Verbreitung im Umfeld von Databricks. Seine wichtigste Grenze gegenüber Iceberg: Es war historisch stärker an eine Engine gebunden. Delta Lake hat die Spezifikation seines Formats zwar geöffnet und Unterstützung für Engines jenseits von Spark ergänzt, doch Iceberg hat die längere Erfahrung mit echtem Betrieb über mehrere Engines.

Apache Hudi, ursprünglich bei Uber entwickelt, ist stark bei Lasten mit häufigen Upserts. Sein Speichermodell Merge-on-Read und die Indizierung auf Satzebene machen es besonders geeignet für CDC-Strecken, die laufend einzelne Datensätze aus operativen Datenbanken übernehmen. Die Mechanismen der Indizierung in Hudi liefern für diese Lasten schnellere Upserts als Iceberg oder Delta Lake, zum Preis größerer betrieblicher Komplexität.

Die wesentlichen Vorteile von Iceberg sind die echte Offenheit, die überlegene Verträglichkeit mit mehreren Engines und die klare Trennung zwischen der Spezifikation des Tabellenformats und der Umsetzung in einer bestimmten Engine. Die Spezifikation von Iceberg wird unabhängig von der Apache Software Foundation verwaltet, was sie zur herstellerneutralsten Wahl macht. Für Organisationen mit heterogenen Umgebungen, die Spark, Trino, Flink und ein Data Warehouse in der Cloud verbinden, ist Iceberg meist die praktischste Wahl.

Kataloge von Iceberg und die Anbindung der Metadaten

Die Metadaten einer Iceberg-Tabelle müssen in einem Katalog geführt werden, der festhält, wo die aktuelle Datei mit den Metadaten jeder Tabelle liegt. Dafür stehen mehrere Umsetzungen zur Verfügung, jede mit eigenen Abwägungen.

Der Hive Metastore ist der am weitesten verbreitete Katalog für Iceberg-Tabellen in bestehenden Umgebungen mit Hadoop und Spark. Der AWS Glue Data Catalog ist eine vollständig verwaltete Alternative, verbreitet in Stacks rund um AWS, mit serverlosem Betrieb und enger Anbindung an Athena, EMR und Lake Formation.

Project Nessie ist ein quelloffener Katalog von Dremio, der für Iceberg-Tabellen eine Semantik von Branches und Tags nach dem Vorbild der Versionsverwaltung bietet. Mit Nessie können Datenteams isolierte Branches ihres Data Lake anlegen, um Änderungen am Schema zu erproben oder versuchsweise Transformationen laufen zu lassen, und diese Änderungen anschließend in den Hauptzweig überführen, eine Möglichkeit, für die es in herkömmlichen Umgebungen mit Data Warehouse keine Entsprechung gibt.

Die Spezifikation des REST-Katalogs ist ein aufkommender Standard, der eine herstellerneutrale API über HTTP für die Operationen am Katalog von Iceberg festlegt. Zu den REST-verträglichen Katalogen zählen der Polaris Catalog, von Snowflake quelloffen gestellt, und der Unity Catalog. Die Verbreitung der REST-Spezifikation beschleunigt das Zusammenspiel von Iceberg über Cloud-Anbieter und Hersteller hinweg.

Verbreitung in der Branche

Apache Iceberg hat eine bemerkenswerte Breite an Verbreitung erreicht, bei Cloud-Anbietern ebenso wie bei Anbietern von Datenplattformen. Snowflake hat Iceberg über die Iceberg Tables zum erstklassigen Bürger gemacht: Snowflake liest und schreibt Iceberg-Tabellen, die in kundeneigenem S3 oder ADLS liegen, was echte Portabilität der Daten ohne Bindung an einen Hersteller ermöglicht. Databricks hat Lesen und Schreiben von Iceberg über die Funktion UniForm ergänzt, die Tabellen von Delta Lake schreibt, die zugleich gültige Iceberg-Tabellen sind, und so beide Formate verbindet. AWS unterstützt Iceberg nativ über S3 Tables, Athena, EMR und Glue. Google BigQuery unterstützt BigLake-Tabellen auf Iceberg, und Apache Flink bietet erstklassige Unterstützung für Iceberg als Senke in Strecken für Streaming.

Diese Breite der Verbreitung über Hersteller hinweg ist für ein Datenformat beispiellos und spiegelt die Einsicht der Branche, dass Portabilität der Daten, also die Möglichkeit, Lasten ohne Umformatierung zwischen Engines und Plattformen zu verschieben, für große Organisationen strategisch geboten ist.

Für Teams, die bestehende Lakes auf Basis von Hive oder Parquet nach Iceberg überführen, ist der übliche Einstieg der Iceberg-Konnektor von Apache Spark, der bestehende Tabellen mit der Prozedur CALL catalog.system.migrate() an Ort und Stelle umstellt und dabei die Metadaten der Tabelle neu schreibt, ohne Datendateien zu kopieren. So lässt sich Iceberg schrittweise einführen, ohne die Umstellung auf einen Schlag zu verlangen.

Data Governance auf Basis von Apache Iceberg

Die reichhaltige Ebene der Metadaten von Apache Iceberg schafft eine ausgezeichnete Grundlage für Data Governance. Jeder Snapshot einer Tabelle wird mit Zeitstempel festgehalten, dazu die Operation, die ihn erzeugt hat, und die Identität des Prozesses, der geschrieben hat. Dieser Verlauf für die Prüfung ist unmittelbar über die Tabellen mit Metadaten von Iceberg zugänglich, nämlich snapshots, history, manifests und files, die sich mit gewöhnlichem SQL abfragen lassen, um zu beantworten, was sich wann und wie geändert hat.

Für Organisationen, die eine Plattform für die Verwaltung von Metadaten wie Dawiso einsetzen, ist die Ebene der Metadaten von Iceberg eine reiche Quelle für technische Lineage und Signale zur Datenqualität. Dawiso kann die Metadaten der Tabellen aus Iceberg-Katalogen einsammeln, also Spaltennamen, Typen, Spezifikationen der Partitionierung und den Verlauf der Snapshots, und sie im Datenkatalog neben den Definitionen aus dem Business Glossary, den Einträgen zur Verantwortung und den Bewertungen der Qualität zeigen. Lineage auf Spaltenebene über Iceberg-Tabellen hinweg, die von Strecken aus Spark oder dbt befüllt werden, lässt sich in Dawiso verfolgen, sodass Analyseteams eine Kennzahl aus einer Gold-Tabelle für das Berichtswesen bis zu den rohen Quelldateien in der Bronze-Schicht einer Medallion-Architektur zurückverfolgen können.

Die Zugriffskontrolle für Iceberg-Tabellen wird üblicherweise auf der Ebene des Katalogs umgesetzt. Apache Ranger, AWS Lake Formation und der Unity Catalog bieten für Iceberg-Tabellen Sicherheit auf Zeilen- und auf Spaltenebene, sodass Regeln der Data Governance, die in einer zentralen Plattform für Governance festgelegt sind, auf der Ebene der Speicherung durchgesetzt werden, ohne in den Anwendungen filtern zu müssen.

Die Verwaltung der Dateien (File Management) ist ein wichtiger Aspekt des Betriebs. Das Snapshot-Modell von Iceberg behält alte Datendateien, bis sie ausdrücklich verfallen, sodass die Kosten der Speicherung ohne aktive Pflege wachsen. Die Wartungsprozeduren expire_snapshots und rewrite_data_files sollten regelmäßig laufen, um verwaiste Dateien zu entfernen und die vielen kleinen Dateien aus häufigen Schreibvorgängen im Streaming zu verdichten.