Apache Iceberg™ v3: Das Ökosystem in Richtung Vereinheitlichung bewegen

Apache Iceberg™ v3, das jetzt von der Apache Iceberg^™ Community genehmigt wurde, führt fortschrittliche neue Funktionen und Datentypen ein. Iceberg v3 umfasst wichtige Verbesserungen wie Löschvektoren, Zeilenherkunft und neue Typen für semistrukturierte Daten und Geodaten-Anwendungsfälle. Diese Funktionen ermöglichen es Kunden, Daten effizient zu verarbeiten und abzufragen. Darüber hinaus sind diese Verbesserungen über Delta Lake, Apache Parquet und Apache Spark^™ hinweg konsistent, sodass Kunden zwischen Delta und Apache Iceberg^™ interagieren können, ohne Daten oder Löschdateien auf Zeilenebene neu schreiben zu müssen.

In diesem Blog-Beitrag werden die neuesten Entwicklungen in Iceberg v3 behandelt:

• Löschvektoren
• Zeilenherkunft
• Semistrukturierte Daten und Geodaten-Typen
• Interoperabilität zwischen Delta Lake, Apache Parquet und Apache Spark

Löschvektoren

Iceberg v3 führt ein neues Format für Löschvorgänge auf Zeilenebene ein, um die Leseleistung zu verbessern: Löschvektoren. Löschvorgänge auf Zeilenebene reduzieren die Schreibverstärkung erheblich, indem sie die Art und Weise optimieren, wie gelöschte Zeilen gespeichert und verfolgt werden – was zu schnelleren ETL- und Erfassungsprozessen führt. In Iceberg v2 waren Engines nicht verpflichtet, Löschdateien während des Schreibens zusammenzufassen. Es war beabsichtigt, dass Kunden die asynchrone Wartung nutzen. Viele Kunden haben jedoch keine Wartungsdienste geplant, sodass ihre Tabellen zu viele nicht gewartete Löschdateien enthielten. Dies führte zu einer langsamen Leseleistung, wenn Engines viele Löschdateien auf Zeilenebene beim Lesen zusammenführen mussten.

Iceberg v3 führt ein neues Löschvektorformat und neue Komprimierungsanforderungen für Löschdateien ein. Dieses neue Format vermeidet die Übersetzung zwischen Parquet-Dateien und In-Memory-Darstellungen, die zum Anwenden der Löschvorgänge verwendet werden. Darüber hinaus müssen Engines zur Schreibzeit einen einzelnen Löschvektor pro Datei verwalten. Diese Anforderung verbessert die Leistung und die Statistiken zu Datendateien. Dies erleichtert auch den Vergleich von vorherigen und aktuellen Löschvorgängen, was die Verarbeitung der Änderungen auf Zeilenebene einer Tabelle als Stream vereinfacht.

Zeilenherkunft

Ein weiteres wichtiges Feature von Iceberg v3 ist die Zeilenherkunft, die zur Vereinfachung der inkrementellen Verarbeitung verwendet wird. Mit der Zeilenherkunft finden Engines Änderungen auf Zeilenebene, indem sie Versionen von Zeilen über Commits hinweg abgleichen.

Iceberg v3 führt die Zeilenherkunft mithilfe von Metadaten auf Zeilenebene ein: eine Zeilen-ID und die Sequenznummer, als die Zeile zuletzt geändert oder hinzugefügt wurde. Die IDs identifizieren dieselbe Zeile über verschiedene Versionen hinweg. Sequenznummern geben an, wann Zeilen zuletzt geändert wurden – nicht nur zwischen Dateien verschoben. Dies ermöglicht es Engines, Änderungen selektiv zu verarbeiten, was Downstream-Aktualisierungen mit schnelleren und kostengünstigeren Workflows vereinfacht.

Zeilen-ID-Informationen sind besonders vorteilhaft in Kombination mit inkrementellen Verarbeitungsobjekten wie materialisierten Sichten. Diese Objekte sind so optimiert, dass sie nur neue oder geänderte Daten seit dem letzten Verarbeitungszyklus berechnen.

Semistrukturierte Daten und Geodaten-Typen

Iceberg v3 fügt auch neue Datentypen für semistrukturierte Daten und Geodaten hinzu.

Semistrukturierte Daten sind schwer zu speichern, da sie unterschiedliche Schemas aufweisen, die nicht in strukturierte Tabellenspalten passen. Eine Möglichkeit ist, einzelne Felder aus diesen Daten in ein strukturiertes Format zu extrahieren. Dies führt jedoch zu extrem breiten Tabellen mit vielen Spalten und NULL-Werten aufgrund inkonsistenter Schemas. Eine andere Alternative ist das Speichern von JSON in Zeichenfolgenspalten. Dies führt jedoch zu einer schlechten Leseleistung, da Engines Daten aus diesen Zeichenfolgen parsen müssen. Ohne semistrukturierte Datentypen können Engines keine Filter nach unten verschieben, sodass sie jede Zeile in jeder Datendatei lesen müssen. Iceberg v3 führt VARIANT ein, um semistrukturierte Daten effizient darzustellen. VARIANT kodiert die Struktur der Daten, um die Leistung zu verbessern und gleichzeitig die Schemaflexibilität zu erhalten.

In ähnlicher Weise sind Geodaten – Informationen, die mit Standorten auf der Erdoberfläche wie Straßen, Parks oder Stadtgrenzen verbunden sind – ebenfalls schwer zu verarbeiten und effizient abzufragen. Ohne Geodaten-Typen mussten Kunden binäre Spalten verwenden, um Geodaten-Standorte zu speichern. Diese Darstellung unterstützte jedoch keine geografische Suche, da binäre Spalten nicht gefiltert werden können, um Objekte innerhalb eines bestimmten Bereichs zu finden. Iceberg v3 löst dieses Problem, indem es neue Geometrie- und Geografie-Datentypen einführt. Geometrie-Typen sind für planare räumliche Daten, während Geografie-Typen für globale Daten sind, die die Krümmung der Erde berücksichtigen. Mit diesen Typen können Kunden Daten einfach mithilfe von Begrenzungsrahmen finden, die geografische Regionen darstellen, und Geodaten-Objekte effizient lokalisieren.

Interoperabilität mit Delta Lake, Apache Parquet und Apache Spark^™

Die neuen Funktionen und Datentypen von Iceberg v3 erweitern die Funktionalität und verbessern die Leistung. Diese Apache Iceberg-Funktionen sind auch deshalb wichtig, weil sie die Interoperabilität zwischen Lakehouse-Formaten fördern.

In der Vergangenheit waren Kunden gezwungen, zwischen zwei der beliebtesten Lakehouse-Formate zu wählen: Delta Lake und Apache Iceberg. Dies liegt daran, dass die meisten Plattformen nur ein Format unterstützen. Das Neuschreiben von Daten kann kostspielig und in großem Maßstab unpraktisch sein, was diese Wahl langfristig macht. Die Formate sind sehr ähnlich: Beide sind Metadatenebenen auf Parquet-Datendateien, um Tabellensemantik bereitzustellen. Kleine Unterschiede in den Tabellenformaten verursachen jedoch Probleme für Kunden.

Iceberg v3 vereinheitlicht die Datenebene über Formate hinweg. Mit der Datenvereinheitlichung können Kunden zwischen Delta und Iceberg interagieren, ohne Daten neu schreiben oder Dateien löschen zu müssen. Dies liegt daran, dass die Funktionen von Iceberg v3 kompatible Implementierungen über Delta Lake, Apache Parquet und Apache Spark aufweisen:

• Löschvektoren verwenden die gleichen binären Kodierungen über Tabellenformate hinweg.
• Die Zeilenherkunft in Iceberg v3 ist mit der Zeilenverfolgung in Delta Lake kompatibel.
• VARIANT- und Geodaten-Typen werden in den Upstream-Communities von Apache Parquet und Apache Spark™ entwickelt, was sich auf Apache Iceberg und Delta Lake erstreckt.

Durch die Verwendung kompatibler Funktionen über Open-Source-Projekte hinweg vermeidet Iceberg v3, dass Kunden gezwungen werden, ein Format auszuwählen. Stattdessen können Kunden frei zwischen Formaten auf einer Kopie ihrer Daten interagieren.

Erfahren Sie mehr über Iceberg v3

Iceberg v3 bringt die gesamte Branche in eine leistungsfähigere, fähigere und interoperablere Welt voran. Wir integrieren Iceberg v3 in die Databricks Data Intelligence Platform und freuen uns darauf, dass andere Anbieter Iceberg v3 übernehmen. Open Source ist ein zentraler Wert bei Databricks, wo wir aktiv Funktionen wie Löschvektoren zu Iceberg v3 beitragen. Um eine florierende Open-Source-Community zu fördern, unterstützen wir und fördern Beiträge zu Apache Iceberg. Für neue Mitwirkende empfehlen wir, mit einem „good first issue“ zu beginnen.

Um mehr darüber zu erfahren, wie wir planen, Iceberg v3-Funktionen in unser Managed-Table-Angebot zu integrieren, und über die Zukunft offener Tabellenformate, registrieren Sie sich für den Data and AI Summit vom 9. bis 12. Juni 2025.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag