Apache Iceberg 1.12.0 ist erschienen. Das Projektmanagement-Komitee des offenen Tabellenformats hat den Release am 5. Oktober im Projektblog vorgestellt: 777 Commits von 142 Mitwirkenden seit Version 1.11.0. Iceberg ist kein Programm, das man einmal installiert und dann vergisst, sondern eine Spezifikation samt Referenzimplementierung. Sie liegt zwischen den Dateien im Objektspeicher und den Abfrage-Engines darüber. Der Vergleich mit einem Bibliothekskatalog passt: Die Bücher stehen längst im Regal, aber erst der Zettelkasten sagt, welches Buch wo steht, welche Ausgabe gilt und was aussortiert wurde.
Release 1.12.0 arbeitet an mehreren Stellen dieses Zettelkastens gleichzeitig. Die wichtigsten Punkte: Die neueren Datentypen Variant und Geodaten werden alltagstauglicher, Flink bekommt eine Wartungsaufgabe für Löschungen aus Streaming-Pipelines, Spark ein neues Sortierverfahren, und die Spezifikation wächst um Leseschranken, die allerdings noch kein Leser umsetzt. Dazu kommen Sicherheitskorrekturen und eine Liste von Änderungen, die vor einem Upgrade gelesen werden sollten.
Variant und Geodaten: neue Datentypen werden alltagstauglicher
Variant ist der Datentyp für halbstrukturierte Daten, etwa JSON-artige Felder mit wechselndem Inhalt. Das Lesen von Variant-Daten, die nicht in eigene Spalten zerlegt sind, geht in Spark 4.0 und 4.1 jetzt schneller, weil es über den vektorisierten Parquet-Leser läuft statt Zeile für Zeile. Strenger wird das sogenannte Shredding, also das Zerlegen eines Variant-Felds in typisierte Spalten: Ein Feld wird nur noch dann zerlegt, wenn alle seine Werte zu einer einzigen Typfamilie gehören. Bisher genügte eine Mehrheit, sodass eine typisierte Spalte unter Umständen nur einen Bruchteil der Zeilen abdeckte. Jetzt deckt jede typisierte Spalte ihr Feld vollständig ab; gemischte Felder bleiben im untypisierten Rest.
Zerlegtes Variant schreiben konnte bisher nur Spark. Mit 1.12.0 können das auch Flink, die Kafka-Connect-Senke und der generische Record-Writer, sodass Daten aus diesen Wegen beim Lesen dieselben Filtervorteile bekommen. Dazu kommen Korrekturen bei Wertgrenzen für die Dateiauswahl, bei Dezimalzahlen mit mehr als 18 Stellen und beim Einlesen fehlerhafter Binärdaten.
Die Geodatentypen geometry und geography lassen sich jetzt lesen und schreiben, gespeichert als Well-Known Binary in Avro und Parquet. Spark 4.1 ist die erste Engine mit einem durchgehenden Weg: Sie liest und schreibt beide Typen und unterstützt DELETE, UPDATE und MERGE auf Tabellen mit Geodaten. Die Grenzen nennt das Projekt selbst: nur Spark 4.1, nicht Spark 3.5 oder 4.0, nicht Flink und nicht ORC; gelesen wird zeilenweise; räumliche Filter gibt es noch nicht.
Löschungen aus Streaming-Pipelines: Flink räumt einmal auf statt bei jeder Abfrage
Streaming-Pipelines, die Datensätze in Iceberg aktualisieren, schreiben sogenannte Equality Deletes. Das sind Markierungen der Art „entferne jede Zeile, deren Schlüssel diesen Werten entspricht“. Sie sind billig zu schreiben, aber teuer zu lesen, weil jede Abfrage Datendateien erneut öffnen und Werte vergleichen muss, um herauszufinden, welche Zeilen noch gelten.
Die neue Flink-Wartungsaufgabe ConvertEqualityDeletes löst diese Markierungen einmal auf und wandelt sie in positionsbasierte Deletion Vectors um, die neben den Datendateien festgeschrieben werden. Danach wenden Leser Löschungen über die Position an, statt Werte zu vergleichen. Die Aufgabe arbeitet mit dem IcebergSink zusammen, der neue Daten und Löschmarkierungen auf einem Quellzweig ablegt; der Konverter schreibt das Ergebnis auf den Zielzweig oder wandelt direkt um. Weil Deletion Vectors zum Tabellenformat Version 3 gehören, setzt die Aufgabe Version 3 voraus und läuft auf Flink 1.20, 2.1, 2.2 und 2.3. Eine Korrektur stellt sicher, dass gelöschte Zeilen nach einem fehlgeschlagenen Umwandlungslauf nicht wieder auftauchen.
Datenlayout und Leistung: Hilbert-Kurve neben Z-Order
Für Spark 4.1 bekommt die Prozedur rewrite_data_files ein neues Sortierverfahren: Hilbert-Clustering, zusätzlich zum bekannten Z-Order. Beide bilden mehrere Spalten auf eine einzige raumfüllende Kurve ab, damit Zeilen mit ähnlichen Werten nebeneinander gespeichert werden und Abfragen mit Filtern auf mehrere Spalten mehr Dateien überspringen können. Die Hilbert-Kurve vermeidet dabei die großen Sprünge durch den Wertebereich, die Z-Order macht. Ausgewählt wird sie über die Sortierreihenfolge, im Beispiel des Projekts mit sort_order => 'hilbert(c1, c2)'.
Daneben definiert der Release eine Schnittstelle RepairTable, mit der sich Statistiken in Manifesten reparieren lassen, die nicht mehr zu den beschriebenen Dateien passen. Für schnellere Planung werden Manifest-Listen jetzt zwischengespeichert, Parquet bekommt adaptiv bemessene Bloom-Filter und Wörterbuchkodierung pro Spalte. Der vektorisierte Parquet-Leser erhält eine Reihe von Korrekturen, darunter einen Absturz bei der Typerweiterung von int auf long und ein Speicherleck. Auch die Dateiauswahl wird genauer: Filter auf Zeitstempel mit Nanosekunden funktionieren in Parquet und ORC wieder, und notStartsWith überspringt keine Zeilengruppen mit Nullwerten mehr.
REST-Katalog und Spezifikation: Leseschranken vorerst nur auf dem Papier
Das REST-Katalogprotokoll kann Variant-Spalten jetzt in Schemas übertragen. Neu sind Endpunkte zum Auflisten und Laden von Funktionen, ein Endpunkt, der eine Tabelle aus einem Katalog austrägt, ohne Daten oder Metadaten zu löschen, eine formalisierte Konfiguration für entferntes Signieren und Labels für Katalog-Metadaten.
In der Spezifikation stehen zwei Neuerungen, die man genau lesen sollte. Erstens ist eine formale, engine-unabhängige Definition von Filterausdrücken übernommen. Zweitens kann ein Katalog beim Laden einer Tabelle künftig Leseschranken mitliefern: Spalten, die maskiert werden müssen, etwa nur die letzten vier Zeichen zeigen, auf null setzen oder hashen, und einen Zeilenfilter. Ein Leser, der das unterstützt, muss alle Vorgaben vollständig anwenden oder die Abfrage abbrechen. Das Projekt betont aber: Das ist bisher nur ein Vertrag in Spezifikation und Schnittstelle. Kein Iceberg-Leser wendet Leseschranken in 1.12.0 an, ein Katalog, der sie heute zurückgibt, wird von jedem Verbraucher stillschweigend ignoriert. Für Zugriffsschutz taugt die Funktion also noch nicht.
Auch am Tabellenformat Version 4 wird weitergearbeitet, aber nur als Fundament. Version 4 ist nicht verabschiedet, und Iceberg 1.12.0 kann V4-Tabellen weder lesen noch schreiben. Neu sind Leser und Schreiber für V4-Manifeste in Parquet und Avro, relative Pfade in Metadaten als Schritt zu verschiebbaren Tabellen und eine nur lesende Implementierung des komprimierten Bitmap-Formats Mumbling, das auf Roaring Bitmap aufbaut.
Sicherheit und Engines: Jackson-Lücken, neue Flink-Versionen
Der Release behebt zwei als hoch eingestufte Schwachstellen in jackson-databind, CVE-2026-54512 und CVE-2026-54513, indem die Jackson-Versionen über alle Laufzeiten und Pakete angeglichen werden; ein weiteres Update schließt GHSA-r7wm-3cxj-wff9. Drei Jackson-Befunde bleiben in der Kafka-Connect-Laufzeit bestehen, weil sie aus der in parquet-jackson eingebetteten Kopie stammen, die sich nicht unabhängig von Apache Parquet aktualisieren lässt.
Spark wird in den Versionen 3.5, 4.0 und 4.1 unterstützt, Spark 3.4 fällt weg. Neu sind unter anderem die Möglichkeit, DROP TABLE … PURGE an REST-Kataloge zu delegieren, eine tolerante Migration, die fehlende Dateien überspringen kann, und Manifest-Umschreibungen nach Sortierschlüssel. Wer Spark-Abfragen auf Iceberg zusätzlich beschleunigen will, findet einen anderen Ansatz in unserem Beitrag über DataFusion Comet und Iceberg Rust. Flink wird in den Versionen 1.20, 2.1, 2.2 und 2.3 unterstützt; 2.2 und 2.3 sind neu, 2.0 fällt weg. Flink kann außerdem Iceberg-Views lesen, anlegen, löschen und umbenennen. Die Kafka-Connect-Senke meldet Commit-Fehler jetzt, statt sie zu verschlucken, versucht vorübergehende Fehler begrenzt erneut und behandelt Offsets robuster.
Was vor dem Upgrade zu prüfen ist
Das Projekt bittet ausdrücklich darum, die inkompatiblen Änderungen vor einem Upgrade von 1.11.0 durchzugehen. Neben dem Wegfall von Spark 3.4 und Flink 2.0 betrifft das das Schreiben von Position-Delete-Dateien mit Zeilendaten, das entfernt wurde, passend zum Wechsel auf Deletion Vectors in Version 3. Entfernt wurden außerdem DataReader zugunsten von PlannedDataReader und eine Reihe von APIs, die bereits als veraltet markiert waren, etwa in den Spark-, AWS- und Kafka-Connect-Modulen.
Bei den Verhaltensänderungen ist eine für AWS-Nutzer wichtig: Der Standard-HTTP-Client des AWS SDK ist auf Apache HttpClient 5 umgestellt. Wer iceberg-aws direkt einbindet statt des Pakets iceberg-aws-bundle und seinen AWS-SDK-Klassenpfad selbst verwaltet, muss von software.amazon.awssdk:apache-client auf apache5-client wechseln. Außerdem wiederholt der REST-Client POST-Anfragen mit Idempotency-Key jetzt bei vorübergehenden Fehlern (408, 500, 502, 503, 504), und die Textdarstellung der Geodatentypen enthält das Koordinatensystem. Bei den Abhängigkeiten steigen unter anderem das AWS SDK auf 2.54.17, Jackson auf 2.22.2 und Netty auf 4.2.18.
Unterm Strich ist 1.12.0 kein Bruch, sondern ein breiter Pflegerelease mit einigen echten Neuerungen. Wer Streaming-Upserts mit Flink betreibt, bekommt mit der Umwandlung der Equality Deletes den spürbarsten Gewinn, setzt dafür aber Format Version 3 voraus. Wer Geodaten nutzen will, ist vorerst auf Spark 4.1 festgelegt. Und wer auf die neuen Leseschranken für Datenschutz hofft, muss warten, bis die Leser sie tatsächlich umsetzen. Die vollständige Liste der Änderungen steht in den Release Notes des Projekts.
Quelle: iceberg.apache.org
