Apache Iceberg: Definition, Funktionsweise, Abgrenzung

Apache Iceberg ist ein offenes Tabellenformat für sehr große Datenmengen auf günstigem Cloud-Speicher (Objekt-Speicher wie Amazon S3). Es macht aus einer Menge einzelner Daten-Dateien eine echte, verwaltbare Datenbank-Tabelle, indem es eine zusätzliche Verzeichnis-Schicht (Metadaten) darüberlegt. Diese Schicht liefert Eigenschaften, die man sonst nur aus klassischen Datenbanken kennt: sichere Änderungen ohne halbe Zustände (ACID, also Atomicity, Consistency, Isolation, Durability), nachträgliches Umbauen der Tabellen-Struktur sowie den Blick auf frühere Stände einer Tabelle (Time Travel). Das Format wurde 2017 bei Netflix entwickelt, 2018 an die Apache Software Foundation gespendet und ist dort seit 2020 Top-Level-Projekt unter Apache-2.0-Lizenz.

Was ist Apache Iceberg?

Apache Iceberg ist ein Tabellenformat: eine Vereinbarung, wie viele einzelne Daten-Dateien so organisiert werden, dass sich das Ganze wie eine einzelne Datenbank-Tabelle nutzen lässt. Iceberg setzt dazu auf einem bestehenden Cloud-Speicher auf (Objekt-Speicher wie Amazon S3, Azure Data Lake Storage oder Google Cloud Storage; dort werden Dateien günstig und in beliebiger Menge abgelegt). Eine Iceberg-Tabelle besteht aus zwei Teilen: den Daten-Dateien in gängigen Analyse-Formaten (Parquet, ORC oder Avro; Standard-Formate für große Analyse-Datenmengen) und einer Metadaten-Schicht, also einem mehrstufigen Verzeichnis, das festhält, welche Dateien aktuell zur Tabelle gehören, welches Schema sie hat und wie sie geschnitten ist. Ein Katalog (ein Verzeichnis-Dienst wie Hive Metastore, AWS Glue, ein REST-Catalog, Nessie oder Unity Catalog) merkt sich, welche Metadaten-Datei aktuell gilt; das Umstellen dieses Zeigers ist der eigentliche Commit, der Punkt, an dem eine Änderung für alle Leser sichtbar wird.

Der Ausgangspunkt des Formats war die Beobachtung bei Netflix, dass das ältere Hive-Tabellenformat auf Objekt-Speicher an konkrete Grenzen stößt: teures Directory-Listing, keine Atomicity über mehrere Partitionen hinweg, ein Partition-Layout, das im Schema eingebrannt ist und nachträglich kaum geändert werden kann. Ryan Blue und Daniel Weeks veröffentlichten 2017 das Design; Netflix spendete das Projekt 2018 an die Apache Software Foundation, seit 2020 ist Iceberg Apache Top-Level-Projekt.

Die Metadaten sind dreistufig aufgebaut. Auf oberster Ebene liegt eine metadata.json mit Schema, Partition-Spec, Snapshot-Historie und der Referenz auf den aktuellen Snapshot. Darunter listet eine Manifest-Liste (snap-*.avro) alle Manifest-Files eines Snapshots, jedes Manifest-File wiederum die konkreten Daten-Dateien inklusive Statistiken. Über diese Statistiken plant eine Query-Engine, welche Dateien überhaupt gelesen werden müssen; irrelevante Dateien werden übersprungen.

Zu den Kern-Eigenschaften zählen ACID-Transaktionen mit Snapshot-Isolation über Optimistic Concurrency, Schema-Evolution ohne Rewrite (Spalten hinzufügen, umbenennen, löschen, Typen erweitern), Partition-Evolution (Partition-Spec darf sich ändern, ohne die Tabelle neu zu schreiben), Hidden Partitioning (Partitionierung im Schema hinterlegt, nicht in der Query nötig), Time Travel über Snapshot-ID oder Zeitstempel, Row-Level-Operationen (Copy-on-Write und Merge-on-Read über Delete-Files bzw. seit v3 Deletion Vectors) sowie Branching und Tagging von Snapshots. Die Format-Versionen v1 (2020), v2 (2021, Merge-on-Read) und v3 (2024, Deletion Vectors, Row Lineage) markieren die zentralen Erweiterungen.

Abgrenzung zu Delta Lake, Apache Hudi, Parquet und Data Lakehouse

Apache Iceberg wird in Praxis-Diskussionen häufig mit verwandten Konzepten vermischt, die entweder ein anderes Tabellenformat oder eine andere Ebene des Storage-Stacks bezeichnen.

Begriff	Achse	Kernunterschied
Delta Lake	Alternatives Tabellenformat	2019 von Databricks initiiertes Format mit einem geordneten Transaktions-Log (_delta_log/) und Parquet-Checkpoints statt Snapshot-Manifest-Baum. Über Delta UniForm lesbar auch als Iceberg-Tabelle.
Apache Hudi	Alternatives Tabellenformat	2016 von Uber initiiertes Format mit Fokus auf CDC und Streaming-Ingestion. Zwei Tabellen-Typen (Copy-on-Write, Merge-on-Read) und eine eigene Timeline-Struktur mit inkrementellen Indizes.
Parquet, ORC, Avro	Dateiformat vs. Tabellenformat	Reine Dateiformate für die Persistenz einzelner Datei-Blöcke. Iceberg legt darüber eine mehrstufige Metadaten-Schicht mit Katalog-Verweis, die viele Dateien zu einer transaktionalen Tabelle bündelt.
Hive-Tabellenformat	Vorgänger	Älteres Format, das Iceberg im analytischen Stack ablöst. Hive kennt Tabellen als Directory-Listing im Hive Metastore mit Partition-Werten im Pfad; Iceberg trennt logisches Schema, physisches Layout und Katalog.
Data Lakehouse	Architekturmuster	Muster, in dem ein transaktionales Tabellenformat auf einem Data Lake läuft. Iceberg ist eine Umsetzung der Lakehouse-Schicht; Delta Lake und Hudi sind die Alternativen.

Die häufigste Abgrenzung verläuft zwischen Apache Iceberg und Delta Lake, weil beide Formate denselben Anwendungsfall (transaktionales Tabellenformat auf Objekt-Speicher) mit unterschiedlichen Metadaten-Mechaniken adressieren. Iceberg arbeitet mit versionierten Snapshot-Manifesten und einer verpflichtenden Katalog-Anbindung, Delta mit einem geordneten Commit-Log plus Checkpoints im Storage selbst. Iceberg unterstützt Partition-Evolution ohne Rewrite; Delta setzt hier auf Liquid Clustering statt auf eine änderbare Partition-Spec. Über Delta UniForm sind Delta-Tabellen zusätzlich als Iceberg-Tabellen lesbar; ab Iceberg v3 nähern sich beide Formate im Row-Level-Delete-Mechanismus über Deletion Vectors an.

Parquet, Iceberg und Lakehouse liegen auf drei Ebenen: Parquet (oder ORC, Avro) ist das Dateiformat, Iceberg das Tabellenformat darüber, das Lakehouse die Architektur, in der beide zusammen mit einem Katalog laufen. Die drei Begriffe werden im Sprachgebrauch häufig gleichbedeutend verwendet.

Beispiel: Iceberg als Multi-Engine-Tabellenschicht in einem Medienkonzern

Ein Medienkonzern betreibt seine Bronze-, Silver- und Gold-Schichten auf Amazon S3 mit Apache Iceberg und AWS Glue als Katalog. Klick- und Streaming-Events landen als Parquet-Dateien in Bronze und werden über Apache Spark in Silver-Iceberg-Tabellen zusammengeführt. Analytics-Teams fragen dieselben Tabellen aus Snowflake, Trino und Amazon Athena ab; ein Data-Science-Team liest sie aus einem Databricks-Workspace über Unity Catalog Managed Iceberg. Der REST-Catalog macht diese Multi-Engine-Konstellation überhaupt erst konsistent.

Als das Reporting eine neue Kampagnen-Dimension braucht, wird eine Spalte per ALTER TABLE … ADD COLUMN hinzugefügt (Schema-Evolution ohne Rewrite). Als die Partitionierung von event_date auf event_hour umgestellt wird, greift Partition-Evolution: Bestandsdaten bleiben in der ursprünglichen tagesbasierten Aufteilung, neue Daten schreiben stundengenau, ohne Backfill. Ohne das Iceberg-Format wären dieselben Parquet-Dateien ein reiner Data Lake ohne Transaktionen, ohne Schema-Kontrolle und ohne verlässliche Multi-Engine-Konsistenz.