Apache Iceberg im eigenen Rechenzentrum: was das Tabellenformat wirklich löst

Wer Parquet-Dateien in einen Objektspeicher legt und darüber eine Query-Engine stellt, hat noch kein Warehouse. Es fehlt alles, was Datenbanken selbstverständlich mitbringen: die Gewissheit, dass eine Abfrage einen konsistenten Zustand sieht, dass ein abgebrochener Schreibvorgang keine halben Ergebnisse hinterlässt, und dass eine Spaltenumbenennung nicht alle Berichte bricht.

Genau diese Lücke schließt Apache Iceberg. Nicht durch ein neues Dateiformat – darunter liegt weiterhin Parquet oder ORC –, sondern durch eine Metadatenschicht, die festhält, welche Dateien zu welchem Zeitpunkt zu einer Tabelle gehörten.

Snapshots statt Verzeichnisse

Die zentrale Idee ist der Snapshot. Jeder Schreibvorgang erzeugt eine neue Metadatendatei, die die vollständige Liste der zugehörigen Datendateien enthält. Eine Abfrage liest zuerst diese Liste und dann die Dateien – nie das Verzeichnis.

Daraus folgt fast alles Übrige. Ein Schreibvorgang wird sichtbar, wenn der Zeiger auf den neuen Snapshot umgesetzt wird, und vorher nicht: das ist die Atomarität. Alte Snapshots bleiben eine Zeit lang stehen: das ist Time Travel. Und weil die Dateiliste explizit ist, muss niemand ein Verzeichnis auflisten – bei Millionen Dateien auf einem Objektspeicher ist das der Unterschied zwischen Sekunden und Minuten.

-- Stand von heute
SELECT sum(betrag) FROM lakehouse.sales.orders;

-- Stand vom Monatsabschluss, ohne Kopie, ohne Backup
SELECT sum(betrag) FROM lakehouse.sales.orders
  FOR TIMESTAMP AS OF '2026-06-30 23:59:59';

-- Was hat sich seither geaendert?
SELECT count(*) FROM lakehouse.sales.orders
  FOR TIMESTAMP AS OF '2026-06-30 23:59:59';

Für Meldewesen und Revision ist der zweite Fall der wichtigere. Die Frage „wie sah die Zahl am Stichtag aus“ wird sonst mit Monatskopien beantwortet, die Speicher kosten und auseinanderlaufen.

Schemaänderungen ohne Umschreiben

Iceberg identifiziert Spalten über stabile IDs, nicht über Namen oder Positionen. Eine Umbenennung ist deshalb eine Metadatenoperation, keine Datenoperation. Dasselbe gilt für das Hinzufügen, Entfernen und Umsortieren von Spalten und für Änderungen an der Partitionierung.

Partitionierung ist in Iceberg eine Eigenschaft der Tabelle, nicht des Dateipfads. Wer sie ändert, muss alte Daten nicht neu schreiben.

Das klingt technisch und entscheidet in der Praxis darüber, ob eine Modellierung revidierbar ist. Wo eine Partitionsänderung ein mehrtägiges Umschreiben bedeutet, wird sie nicht gemacht – und die Tabelle bleibt für immer falsch geschnitten.

Der Catalog ist die eigentliche Abhängigkeit

Hier wird es unangenehm. Iceberg selbst ist offen und spezifiziert. Aber irgendetwas muss wissen, welche Metadatendatei der aktuelle Snapshot einer Tabelle ist, und diese Umsetzung muss atomar sein. Diese Rolle hat der Catalog.

Und Catalogs sind der Ort, an dem Anbieterbindung zurückkommt. Wer einen proprietären Catalog eines Cloud-Anbieters nutzt, hat offene Tabellen in einem geschlossenen Verzeichnis. Die Daten sind lesbar, aber welche Version gilt, weiß nur ein Dienst, den man nicht mitnehmen kann.

Wer Unabhängigkeit als Ziel hat, prüft deshalb nicht, ob Iceberg unterstützt wird, sondern welcher Catalog verwendet wird und ob er sich betreiben lässt. Das ist die Frage, die in Ausschreibungen fast immer fehlt.

Was Iceberg nicht löst

• Geschwindigkeit. Iceberg beschleunigt die Metadatenauflösung, nicht die Abfrage. Dafür sorgt die Engine mit Caching, Vektorisierung und Statistiken.
• Kleine Dateien. Häufiges Streaming-Schreiben erzeugt viele kleine Dateien; Verdichtung muss geplant werden und läuft nicht von selbst.
• Rechte. Iceberg kennt keine Nutzer. Zeilen- und Spaltenrechte gehören in die Engine oder den Semantic Layer.
• Alte Snapshots. Time Travel kostet Speicher. Ohne Aufräumregel wächst eine Tabelle, die nie größer wird.

Das ist keine Kritik, sondern eine Abgrenzung. Iceberg löst die Buchhaltung. Alles andere bleibt Arbeit – nur nicht mehr die Arbeit, aus Dateien eine Tabelle zu machen.