Apache Iceberg v3 Table Spec: gemeinsamer Erfolg der Open-Source-Community

Das Projekt Apache Iceberg™ verkörpert den Geist von Open Source und zeigt, was möglich ist, wenn eine Community mit einem gemeinsamen Ziel zusammenkommt: eine Technologie voranzubringen. Das Iceberg-Projekt hat es sich zur Aufgabe gemacht, Zuverlässigkeit, Performance und Offenheit für umfangreiche Analysen zu schaffen. Deshalb entwickelt es sich weiter und bietet viele Vorteile dank der vielfältigen Stimmen und Bemühungen seiner Mitwirkenden.

Icebergs jüngster Meilenstein, die Ratifizierung der v3-Tabellenspezifikation, ist mehr als nur ein technisches Update. Sie ist das Ergebnis durchdachten Designs, intensiver Diskussionen und Kollaboration zwischen Dutzenden Unternehmen und Hunderten von Personen. Die v3-Tabellenspezifikation spiegelt eine gemeinsame Investition in die Zukunft von Open-Data-Architekturen und die Verpflichtung wider, Iceberg wirklich anbieterneutral, flexibel und communityorientiert zu halten.

Dieser Beitrag stellt die Hauptmerkmale der v3-Tabellenspezifikation vor und beleuchtet die kollektive Arbeit, die dieses Release zum Leben erweckt hat.

Community-getriebene Entwicklung

Iceberg hat sich in den letzten zwei Jahren zu einem führenden Standard für offene Tabellenformate entwickelt, mit dem Benutzer und Anbieter sich auf eine Struktur für ihre Daten einigen können und somit von der Interoperabilität profitieren können. Nur mit den Beiträgen der gesamten Community kann das Iceberg-Projekt wirklich erfolgreich sein und alle Vorteile bieten, die es wertvoll machen: Offenheit, Anbieterneutralität und Interoperabilität.

Mit Open Source kann jeder eine neue Funktion vorschlagen, sie selbst entwickeln und mit anderen Mitwirkenden zusammenarbeiten, um sie in das Projekt einzubringen. Die Funktionen, die in die neueste Iceberg-Tabellenspezifikation integriert wurden, sind das Ergebnis zahlreicher Gespräche mit Anbietern und Einzelpersonen, die beschrieben haben, was sie von Iceberg benötigten, um die Technologie weiter zu nutzen oder zu implementieren. So könnten beispielsweise Anbieter mit ihren eigenen proprietären Tabellenformaten vorschlagen, Iceberg aus Gründen der Einheitlichkeit um bestimmte Funktionen zu ergänzen. Diese würden jedoch nur dann integriert, wenn die gesamte Iceberg-Community zustimmt, dass diese Funktionen für das Projekt von Vorteil sind. Das ist Open Source.

Da eine große Anzahl von Benutzern, Mitwirkenden und Anbietern Iceberg unterstützt, bieten die vorgeschlagenen Funktionen und Verbesserungen vielfältige Perspektiven und die daraus resultierenden Implementierungen werden robuster – was uns zur v3-Tabellenspezifikation bringt.

Die v3-Tabellenspezifikation im Überblick

Die v3-Tabellenspezifikation ist ein wichtiger Meilenstein für die Technologie, da sie eine Reihe unglaublicher neuer Funktionen mit sich bringt und unzählige Anwendungsfälle für Benutzer:innen erschließt. 

Standardwerte

Zweck: Mit Standardwerten (default values) können Iceberg-Benutzende Nullen und fehlende Werte in ihren v3-Tabellen verarbeiten. 

So funktioniert es: Durch Hinzufügen von zwei neuen Tabellenkonfigurationen sind Standardwerte möglich. Durch die Einstellung write-default können Benutzer steuern, wie ihre Schreiber mit fehlenden Werten aus Feldern umgehen. Zur Flexibilität kann dies jederzeit geändert werden. Andererseits gibt initial-default, das einmal für eine Tabelle festgelegt wird, Anwender:innen einen Mechanismus an die Hand, um vorhandene Nullen durch einen bestimmten Wert zu ersetzen. 

Wer hat es ermöglicht:

• Shenoda Guirguis, originaler Spezifikationenvorschlag

• Limian (Raymond) Zhang, fertige Spezifikationen

• Implementierung

  • Ryan Blue, Iceberg PMC Chair

  • Walaa Eldin Moustafa

Löschvektoren

Zweck: Löschvektoren (deletion vectors) sind der neue Standardmechanismus für die Verarbeitung von Positionslöschungen in Iceberg. Benutzer:innen müssen keine Kompromisse mehr eingehen, die in der Regel mit der Konfiguration von Positionslöschungen einhergehen.z. B. Sie haben die Wahl zwischen einer Reduzierung der Anzahl kleiner Dateien (durch Ermöglichung der Granularität auf Partitionsebene) und effizienteren Lesevorgängen (durch Ermöglichung der Granularität auf Dateiebene). 

So funktioniert es: Nach der Implementierung werden Löschvektoren die Positionslöschungen ersetzen. Das Design sieht vor, dass mehrere Löschvektoren als Roaring Bitmaps in Puffin-Dateien gespeichert werden. Puffin ist ein performanter Dateityp, der bereits im gesamten Iceberg-Projekt verwendet wird und einen effizienten Zugriff über einen Index ermöglicht. Interessanterweise hatte v2 Iceberg eine Vorstellung von [deletion vectors], aber diese wurden im Arbeitsspeicher verwendet“, erklärt Anton Okolnychyi, Mitglied des Iceberg Project Management Committee (PMC) und Senior Staff Software Engineer bei Databricks. „Auf dem Datenträger befanden sich Parquet-Dateien, im Arbeitsspeicher Bitmaps. Und als wir mit dem Design von v3 fertig waren, wollten wir sehen, was man anders machen könnte, um den Aufwand für die Konvertierung zu vermeiden.“ 

Die Entscheidung der Community, Puffin-Dateien gegenüber der bestehenden Parquet-Implementierung zu verwenden, bietet Nutzenden Performance-Steigerungen und ist für Anwendungsfälle mit niedriger Latenz möglicherweise besser geeignet. Löschvektoren bieten Nutzenden das Beste aus beiden Welten: Positionslöschungen werden auf Dateiebene angewendet, um effizientere Lesevorgänge zu ermöglichen. Sie werden jedoch physisch in konsolidierten Puffin-Dateien gespeichert, um die Anzahl kleiner Dateien zu reduzieren.

Wer hat es ermöglicht:

• Spezifikationsänderungen

  • Renjie Liu, Iceberg PMC Mitglied, ursprünglicher Vorschlag

  • Anton Okolnychyi, abgeschlossene Änderungen

• Implementierung

  • Amogh Jahagirdar, Iceberg PMC Mitglied

  • Eduard Tudenhoefner, Iceberg PMC Mitglied

Geospatial Data Types

Zweck: Iceberg unterstützt nun zwei neue Geodatentypen, Geometrie und Geographie, die sich besser an andere Projekte anpassen lassen und Benutzer:innen die Möglichkeit geben, bessere Funktionen rund um Mapping und Standortdaten zu nutzen. 

Laut Jia Yu, Apache Sedona PMC Chair und Mitgründer von Wherobots, ist die endgültige Funktionalität das Ergebnis einer Menge Community-Forschung. Sie überprüften eine Reihe von Projekten und Technologien mit Geodaten-Unterstützung, darunter „Sedona, Databricks, Snowflake, BigQuery, pandas“ und weitere. Dabei stellten sie fest, dass diese „alle unterschiedliche Definitionen von Geodaten, verschiedene Typen und ein wirklich unterschiedliches Verhalten dieser Typen aufweisen.“ 

So funktioniert es: Neben der einfachen Bereitstellung von Geodatentypen in Iceberg adressiert die Spezifikationsänderung auch komplexe Fragen wie den Umgang mit der Partitionierung und Filterung von Geodatenfeldern sowie den Metriken auf Spaltenebene für diese Typen. Predicate Pushdown und reguläre spaltenbasierte Metriken sind weiterhin für die Geodaten-Typen verfügbar, wobei Begrenzungsrahmen, die durch Geodatenpunkte beschrieben werden, als Maximal- und Minimalwerte dienen. 

Wer hat es ermöglicht:

• Spezifikationsänderungen

  • Szehon Ho, Iceberg PMC Mitglied

  • Gang Wu

• Kristin Cowalcijk, Implementierung

• Eine besondere Erwähnung an das gesamte Wherobots-Team, das seine Geodaten auf seiner eigenen Gabelung des Iceberg implementiert hat, bevor es der Iceberg-Community sein Fachwissen anbot, die Führung übernahm und die Funktion für das Iceberg-Projekt implementierte.

Multi-Argument-Transformationen

Zweck: Multi-Argument-Transformationen geben Benutzer:innen die Möglichkeit, Transformationen über mehrere Felder hinweg zum Zwecke der Partitionierung und Sortierung in Iceberg durchzuführen. Vor der v3-Tabellenspezifikation konnte für diese Zwecke nur ein einziges Feld umgewandelt werden.

Wer hat es ermöglicht:

• 叶先忛, Spezifikationsänderungen

• Implementierung

  • Fokko Driesprong, Iceberg PMC Mitglied

  • JB Onofré, ASF-Vorstand

Zeilenverlauf (Row Lineage)

Zweck: Row Lineage erleichtert es Anwender:innen, nachzuvollziehen, wie sich Zeilen in einer Iceberg-Tabelle im Laufe der Zeit verändert haben, und ermöglicht eine Reihe von Anwendungsfällen, darunter verbesserte CDC-Workflows (Change Data Capture), einfachere Audits und eine bessere Materialized View Maintenance. Letztendlich bedeutet die Hinzufügung von Row Lineage zu Iceberg, „dass Iceberg-Nutzende die Historie jeder Zeile in ihren Tabellen genau bestimmen können“, so Russell Spitzer, Iceberg PMC Member und Principal Software Engineer bei Snowflake. „Früher konnten wir nur anhand von benutzerdefinierten Identitätsspalten raten, jetzt ist es in das Format selbst integriert!“

So funktioniert es: Jede Zeile in einer Iceberg-Tabelle enthält zwei zusätzliche Felder, _row_id und _last_updated_sequence_number. Die Iceberg-Community konnte dies so umsetzen, dass nicht jede Zeile explizit Werte in diesen Feldern speichern muss. Stattdessen werden die Spaltenwerte bis zur Materialisierung durch eine Leseabfrage impliziert und erst dann durch die Metadatenebene übertragen (Metadata.json → Snapshot → Manifest → Datafile → Row).

Wer hat es ermöglicht:

• Spezifikationsänderungen

  • Russell Spitzer

  • Nileema Shingte

  • Attila-Péter Tóth

• Implementierung

  • Russell Spitzer, core 

  • Ryan Blue, core 

  • Amogh Jahagirdar, Spark 

Tabellenverschlüsselung

Zweck: Das neueste Update rund um die Tabellenverschlüsselung ermöglicht die clientseitige Verschlüsselung von Iceberg-Tabellen, sodass Benutzer:innen alle ihre Daten und Metadaten verschlüsseln können. Ganze Tabellen können mit einem einzigen Schlüssel verschlüsselt oder der Zugriff auf Snapshot-Ebene kontrolliert werden. 

So funktioniert es: Damit die clientseitige Tabellenverschlüsselung in Iceberg möglich ist, können Benutzer einzelne Tabellen-Snapshots mit Verschlüsselungsschlüsseln verknüpfen, die in einem Drittanbieter-Schlüsselspeicher gespeichert sind. Um mit dem Zugriff auf Daten innerhalb eines bestimmten Snapshots zu beginnen, müssen Clients auf diesen Schlüsselspeicher und den Verschlüsselungsschlüssel zugreifen können, um die Manifestliste des Snapshots zu entschlüsseln und darauf zuzugreifen. Von dort ausgehend haben Manifestlisten einen ähnlichen Mechanismus für Clients, um die Manifestdateien zu entschlüsseln, und schließlich haben Manifestdateien einen Datendateiverschlüsselungsschlüssel, damit Clients auf die Datendateien zugreifen können. 

Wer hat es ermöglicht:

• Spezifikationsänderungen und Implementierung

  • Gidon Gershinsky

  • Russell Spitzer

  • Ryan Blue

Variantendatentyp

Zweck: Variantentypen ermöglichen es Anwender:innen, weniger reguläre, semistrukturierte Datasets zu verarbeiten, bei denen bestimmte Felder intermittierend verwendet werden. Nehmen wir als Beispiel Sensordaten: Alle Sensoren können einen Standort und Zeitstempel melden, aber einige Sensoren melden Temperatur, andere Feuchtigkeit usw. Aihua Xu, Senior Software Engineer bei Snowflake, ist einer der Mitwirkenden dieses Variantentyps: „Bei der Ergänzung der Iceberg v3-Spezifikation ging es darum, die Realitäten heutiger Daten zu erfüllen. Dank der nativen [variant] Unterstützung kann Iceberg diese Art von Daten effizient darstellen und verarbeiten, ohne Kompromisse bei der Struktur einzugehen.“

So funktioniert es: Der Variantendatentyp ermöglicht es Anwender:innen, variable Typen und Felder in Apache Iceberg™-Tabellen zu speichern, in denen die Feldnamen und ihre Typen in Metadaten und Wertfelder extrahiert und dann als binär gespeichert werden. Das Lesen der Daten beinhaltet Deserialisierung. Um die Effizienz zu steigern, können die konsistenten Felder, wie der Speicherort und der Zeitstempel im vorherigen Beispiel, und ihre Typen in Parquet extrahiert und gespeichert werden. Die übrigen Felder werden wie oben beschrieben in Metadaten und Wertfeldern gespeichert. 

Wer hat es ermöglicht:

• Spezifikationsänderungen

  • Tyler Akidau, ursprünglicher Vorschlag 

  • Aihua Xu, abgeschlossene Änderungen

• Implementierung

  • Aihua Xu, Kernimplementierung

  • Ryan Blue, core

  • David Cashman, shredding

  • Gene Peng, Coding und einflussreiche Arbeit am Variantendatentyp in Apache Spark

  • Neil Chao, Apache Arrow 

Wo wir sind und was kommt

All die oben genannten Funktionen wären ohne die harte Arbeit und die kontinuierliche Zusammenarbeit in der gesamten Iceberg-Community nicht möglich gewesen. Die Arbeit, die alle für diese neueste Spezifikation geleistet haben, ist ein echter Beweis für den Open-Source-Geist und zeigt, wie Personen, Anbieter und Benutzer zusammenkommen können, um eine ganze Technologie voranzubringen. 

Damit möchten wir den Beteiligten, die an Iceberg beteiligt sind und die v3-Tabellenspezifikation möglich gemacht haben, ein herzliches Dankeschön aussprechen – sowohl den oben genannten als auch allen anderen.

Die Vielfalt des Iceberg-Projekts – über Einzelpersonen und Unternehmen hinweg – spricht derzeit viel für die Gesundheit der Gemeinde und des Ökosystems. Der anhaltende Erfolg wird von der breiten Akzeptanz der v3-Tabellenspezifikation und der breiten Integration mit bestehenden und neuen Technologien abhängen. Glücklicherweise geschieht das – und Iceberg wird täglich von mehr Technologien, Unternehmen und Anbietern unterstützt.