Apache Iceberg im Data Lakehouse: ein Einstieg

Apache Iceberg: Architektur, Funktion und Relevanz

Eine Iceberg-Tabelle besteht aus mehreren klar getrennten Schichten:

• Katalog. Er dient als zentrales Verzeichnis für Tabellen. Der Katalog enthält Pfade zur jeweils neuesten Metadatendatei und ermöglicht so die Lokalisierung der Tabellenstruktur. Gängige Katalogimplementierungen sind Hive Metastore, AWS Glue, JDBC-Datenbanken oder der offene REST-Katalog. Auch eine Nutzung ohne dedizierten Katalog über das Dateisystem ist möglich, wird jedoch in produktiven Szenarien wegen fehlender ACID-Garantien und mangelnder Sperrmechanismen nicht empfohlen.
• Metadatendateien. Sie enthalten globale Informationen zu einer Iceberg-Tabelle: aktuelle und historische Schemas, Partitionierungsspezifikationen, Snapshot-IDs, Tabelleneigenschaften und die Referenz zur Manifestliste des aktuellen Snapshots. Jeder neue Snapshot erzeugt eine neue Metadatendatei. Da vergangene Versionen gespeichert bleiben, ermöglicht Iceberg Time Travel sowie vollständige Auditierbarkeit.
• Manifestlisten. Auf dieser Ebene werden alle Manifeste eines Snapshots aufgelistet. Jedes Manifest repräsentiert eine Gruppe von Datendateien. Metadaten über Partitionen, Dateiänderungen und Zugehörigkeit zu Snapshots dienen hier als Filterbasis, um große Dateisegmente frühzeitig auszuschließen.
• Manifeste. Jedes Manifest listet konkrete Datendateien inklusive Format, Speicherort, Partitionierungsinformationen, Spaltenstatistiken, Dateigröße und Anzahl der enthaltenen Records. Dadurch ermöglicht Iceberg selektives Lesen auf Datei- und sogar Spaltenniveau.
• Datendateien. Die eigentlichen Nutzdaten werden in Spaltenformaten wie Parquet, Avro oder ORC gespeichert. Iceberg macht keine Vorgaben zum Speicherort, solange die Dateien durch Manifeststrukturen referenziert sind.

Diese Struktur ermöglicht eine besonders effiziente Prädikat-Pushdown-Logik: Bereits auf Manifestebene lassen sich Partitionen oder Dateigruppen ausschließen, bevor einzelne Dateien geöffnet werden müssen. Auf Dateiebene erlauben Min/Max-Statistiken weitere Präzisierung.

Transaktionale Integrität, Versionierung und Branching

Iceberg verfolgt ein streng versioniertes Datenmodell. Jede Änderung an einer Tabelle erzeugt einen neuen Snapshot. Die Snapshot-Historie ist in den Metadatendateien enthalten und erlaubt Features wie Time Travel, Rewrites, Abgleiche und Restore-Szenarien.

Neben der reinen Snapshot-Verwaltung erlaubt Iceberg auch Branching und Tagging. Branches stellen alternative Entwicklungslinien einer Tabelle dar, zum Beispiel zur Validierung neuer Pipelines oder Simulation historischer Abläufe. Tags erfassen explizit gekennzeichnete Zeitpunkte der Tabellenentwicklung. In Kombination mit dem Projekt Nessie können sogar versionierte Kataloge gepflegt werden, wodurch transaktionale Operationen über mehrere Tabellen hinweg möglich werden.

Schemata und versteckte Partitionierung

Das System verwaltet Schema-IDs und Partitionierungsspezifikationen als separate, versionierte Objekte. Dadurch kann jede Datei eindeutig einem Schema zugeordnet werden. Tabellen können jederzeit erweitert, Spalten umbenannt, gelöscht oder in der Reihenfolge verändert werden. Iceberg erlaubt diese Operationen ohne Rewrite der kompletten Tabelle. Gleiches gilt für die Partitionierung.

Die Hidden Partitioning ermöglicht, Partitionierungsspalten vom Nutzer zu verbergen. SQL-Engines dürfen auf logischer Ebene filtern, ohne sich um die physische Partitionierung zu kümmern. Diese Abstraktion vermeidet Fehlerquellen und macht Queries intuitiver.

SQL-Semantik und Performance-Optimierungen

Iceberg unterstützt eine Vielzahl von SQL-Operationen, darunter MERGE INTO, UPDATE, DELETE und INSERT. Die Kombination mit Prädikaten und Filterbedingungen auf Partitionsebene oder Spaltenstatistiken erlaubt hocheffizientes Query Planning. Metadaten enthalten unter anderem Spaltenstatistiken wie Null-Counts, Value Bounds oder Record Counts, was Engines zur Laufzeit nutzen können, um Pläne zu optimieren.

Ein zentrales Feature ist zudem die native Unterstützung für Kompaktionen. Während viele Systeme durch eine wachsende Anzahl kleiner Dateien an Performance verlieren, bietet Iceberg eingebaute Rewrite-Strategien wie Bin-Packing oder Sortierung, um die physische Dateistruktur zu optimieren.

Integration, Engines und Nutzungsszenarien

Iceberg lässt sich in diverse Verarbeitungssysteme integrieren: Spark, Flink, Trino, Hive, Dremio und DuckDB können Iceberg-Tabellen lesen. Schreiboperationen erfordern teils weitergehende Implementierungen. Insbesondere mit Flink lassen sich Streaming-Workloads direkt in Iceberg persistieren.

Typische Einsatzszenarien umfassen Echtzeit-Analysen, Batch-orientierte ETL-Prozesse, explorative Abfragen und historisierte Berichte. Der modulare Aufbau erlaubt es, dieselben Daten für maschinelles Lernen, Reporting und Auditing zu nutzen, ohne physische Replikationen vorzunehmen.

Vergleich zu Delta Lake und Apache Hudi

Apache Hudi wurde primär für schnelle Datenänderungen in Hadoop-Umgebungen entwickelt. Es bietet Copy-on-Write- und Merge-on-Read-Modi, wodurch hohe Flexibilität bei Upserts entsteht. Allerdings führt dies zu komplexeren Abläufen und Performance-Trade-offs.

Delta Lake wiederum wurde stark an die Databricks-Plattform gekoppelt und nutzt einen Transaktionslog (Delta Log), um ACID-Garantien umzusetzen. Zwar bietet Delta gute Unterstützung für Streaming und Batch, bleibt jedoch hinsichtlich Schema-Evolution und Engine-Kompatibilität hinter Iceberg zurück. Iceberg punktet mit einem offenen Standard, einer klaren Trennung von Metadatenebenen, granularer Filterung sowie nativer Unterstützung für Branching und mehrstufiger Versionierung.