Die Datenwelt, meine Freunde, befindet sich in einem faszinierenden Zustand des Wandels. Seit Jahren jagen wir die schwer fassbare "Single Source of Truth", kämpfen mit Datensilos und ringen mit den inhärenten Kompromissen zwischen der Flexibilität von Data Lakes und der robusten Governance von Data Warehouses. Aber aktuelle Entwicklungen, insbesondere im Bereich der offenen Tabellenformate und der Plattformen, die diese nutzen, erzählen eine überzeugende Geschichte: Die Lakehouse-Vision kommt nicht nur in den Fokus, sondern wird zu einer tiefgreifenden, stabilen Realität.
Nach unzähligen Stunden der Recherche in den neuesten Iterationen, dem Testen der Grenzen und ja, gelegentlichem Kopfschütteln, bin ich wirklich begeistert davon, wo wir stehen. Es geht hier nicht um Marketing-Blabla; es geht um greifbare technische Fortschritte, die grundlegend verändern, wie wir Datenplattformen aufbauen und betreiben. Tauchen wir tief ein in das, was die Open Data Stack im Moment wirklich prägt.
Der Lakehouse-Paradigmenwechsel: Von Vision zur Produktionsrealität
Der konzeptionelle Reiz des Lakehouse war schon immer stark: die riesige, kostengünstige Speicherung von Data Lakes mit den ACID-Transaktionen, Schema-Durchsetzung und Governance-Funktionen von Data Warehouses zu kombinieren. Lange Zeit war dies leichter gesagt als getan. Aber die Reifung offener Tabellenformate, insbesondere Apache Iceberg, war der Dreh- und Angelpunkt, um dieses Architekturmuster nicht nur realisierbar, sondern effizient und wirklich praktisch für Produktions-Workloads zu machen.
Das Kernproblem, das offene Tabellenformate lösen, besteht darin, die Transaktionsintegrität und die Metadatenintelligenz zu Dateien zu bringen, die in Cloud-Objektspeichern gespeichert sind. Ohne sie ist Ihr Data Lake, nun ja, nur ein Haufen Dateien. Es ist ein Wild West voller Ad-hoc-Schemaänderungen, inkonsistenter Reads und manueller Datenmanagement-Albträume. Iceberg, Delta Lake und Hudi haben dies durch die Einführung einer reichhaltigen Metadatenebene transformiert, die Dateimanifeste, Snapshots und Schema-Evolutionen verfolgt und so atomare, konsistente, isolierte und dauerhafte (ACID) Eigenschaften direkt auf Ihren S3-, ADLS- oder GCS-Buckets ermöglicht. Das ist wirklich beeindruckend, denn es bedeutet, dass wir Daten nicht mehr zwischen Systemen für verschiedene Workloads verschieben müssen; dieselben Daten können Batch-Analysen, Echtzeit-Dashboards und Machine-Learning-Modelle mit konsistenten Semantiken und starken Datenqualitätsgarantien versorgen.
Apache Icebergs Aufstieg: Performance und Spezifikationsentwicklung
Apache Iceberg setzt seinen unerbittlichen Marsch fort, um das offene Tabellenformat zu werden. Der Fokus des Projekts in den späten Jahren 2025 und frühen 2026 lag auf der Festigung seiner Kernfunktionen, der Verbesserung der Leistung und der Erweiterung seiner Spezifikation, um zunehmend komplexe Datentypen und Workloads zu bewältigen. Wir haben erhebliche Fortschritte darin gesehen, wie Iceberg zugrunde liegende Datendateien verwaltet, um die Abfrageleistung zu optimieren, und sind über die grundlegende Partitionierung hinaus zu ausgefeilteren Techniken übergegangen. Dies ist eine Schlüsselkomponente des DuckDB, Arrow und Parquet: Der ultimative Analyse-Stack für 2026, den viele Teams einführen.
Eine der bemerkenswertesten jüngsten Entwicklungen ist die Einführung von Deletion Vectors in Iceberg Format Version 3. Das ist ein großer Schritt für mutable Daten. Zuvor erforderten zeilenweise Löschungen oder Aktualisierungen oft das Umschreiben ganzer Datendateien, was ressourcenintensiv sein und zu Write Amplification führen konnte, insbesondere in Szenarien mit hoher Änderungsrate. Mit Deletion Vectors kann Iceberg gelöschte Zeilen verfolgen, ohne die Basisdatendateien sofort neu zu schreiben. Stattdessen verwaltet es eine separate, kleine Datei (den Deletion Vector), die bestimmte Zeilenpositionen als gelöscht markiert. Query Engines wenden diese Deletion Vectors dann zur Laufzeit an. Dieser Mechanismus verbessert die Effizienz von DELETE- und UPDATE-Operationen erheblich und macht Iceberg-Tabellen viel leistungsfähiger für transaktionale Workloads, die Datensätze häufig ändern.
Darüber hinaus hat Version 3 auch die Typunterstützung erweitert, insbesondere um einen VARIANT-Typ für halbstrukturierte Daten und GEOSPATIAL-Typen. Dies ist entscheidend für die Verarbeitung der zunehmend vielfältigen Datennutzlasten, die wir begegnen, insbesondere aus Streaming-Quellen oder API-Integrationen.
Scan Planning via REST Catalog: Ein Game Changer für Interoperabilität
Darauf habe ich gewartet: Die Weiterentwicklung der Iceberg REST Catalog-Spezifikation um einen Scan Planning Endpoint. Dies ist eine grundlegende Veränderung in der Art und Weise, wie Query Engines mit Iceberg-Tabellen interagieren, und verspricht, die Interoperabilität und Leistung im gesamten Ökosystem drastisch zu verbessern.
Mit dem Scan Planning Endpoint kann die Verantwortung für die Generierung der zu scannenden Dateiliste an den Katalog selbst delegiert werden. Dies eröffnet unglaubliche Möglichkeiten:
- Optimiertes Scan Planning mit Caching: Der Katalog kann häufig abgerufene Scanpläne zwischenspeichern und so redundante Metadaten-Reads reduzieren.
- Verbesserte Interoperabilität: Durch die Zentralisierung des Scan Planning kann der Katalog potenziell verschiedene Tabellenformate überbrücken.
- Entkopplung: Es entkoppelt die Query Engine weiter von den Feinheiten des physischen Layouts des Tabellenformats.
Snowflakes Hybrid-Ansatz: Unistore und First-Class Iceberg Tables
Snowflake, eine traditionelle Data-Warehouse-Powerhouse, hat beeindruckende Schritte unternommen, um das Open Lakehouse zu nutzen. Zunächst bestand Snowflakes Unterstützung für Iceberg hauptsächlich über externe Tabellen. Das hat sich jedoch deutlich geändert. In einer wichtigen Entwicklung kündigte Snowflake die vollständige DML-Unterstützung (INSERT, UPDATE, DELETE, MERGE) für extern verwaltete Iceberg-Tabellen über katalogverknüpfte Datenbanken und den Iceberg REST Catalog an.
Aber der eigentliche Knaller ist die Einführung von Hybrid Tables als Teil ihrer Unistore-Initiative. Das ist wirklich beeindruckend, denn es verwischt die Grenzen zwischen OLTP und OLAP innerhalb einer einzigen Plattform. Hybrid-Tabellen sind optimiert für sowohl latenzarme, hochdurchsatzstarke Transaktions-Workloads als auch für analytische Abfragen.
Die technische Nuance liegt hier in ihrer Dual-Storage-Architektur:
- Row-based Storage: Hauptsächlich für Transaktionsanwendungen verwendet, die eine schnelle Abfrage und Änderung einzelner Zeilen bieten.
- Columnar Storage: Für analytische Abfragen verwendet, optimiert für Datenaggregation und große Scans.
Um sich in externe Iceberg zu integrieren, verwendet Snowflake neue konto-weite Objekte: EXTERNAL VOLUME und CATALOG INTEGRATION. Obwohl diese Integration robust ist, bleibt ein kleiner Kritikpunkt: Für extern verwaltete Iceberg-Tabellen müssen Sie die Metadaten-Aktualisierungen sorgfältig verwalten, wenn Snowflake nicht der primäre Katalog ist.
Databricks und das Open Lakehouse: Unity Catalogs Iceberg Embrace
Databricks, der Erfinder von Delta Lake, hat erhebliche Fortschritte bei der Nutzung von Apache Iceberg gemacht, insbesondere über seinen Unity Catalog. Es geht hier nicht nur um Koexistenz; es geht um tiefe Integration und die Bereitstellung einer einheitlichen Governance-Schicht über Formate hinweg.
Eine wichtige Ankündigung war die Public Preview der vollständigen Apache Iceberg-Unterstützung in Databricks, die Lese- und Schreiboperationen für Managed Iceberg-Tabellen über Unity Catalogs Implementierung der Iceberg REST Catalog API ermöglicht. Wenn Sie Ihre Katalogeigenschaften konfigurieren, können Sie diesen JSON to YAML Konverter verwenden, um sicherzustellen, dass Ihre Konfigurationsdateien für verschiedene Bereitstellungsumgebungen korrekt formatiert sind.
Die Konfiguration zum Verbinden eines Spark-Clients mit Unity Catalog als Iceberg REST Catalog umfasst typischerweise das Festlegen von Spark-Eigenschaften wie:
spark.sql.catalog.<catalog-name> = org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.<catalog-name>.catalog-impl = org.apache.iceberg.rest.RESTCatalog
spark.sql.catalog.<catalog-name>.uri = <databricks-workspace-url>/api/2.1/unity-catalog/iceberg-rest
spark.sql.catalog.<catalog-name>.credential = <oauth_client_id>:<oauth_client_secret>
spark.sql.catalog.<catalog-name>.warehouse = <path-to-uc-managed-storage>
Databricks' UniForm und Cross-Format Realität
Databricks' Engagement für Interoperabilität zeigt sich auch in UniForm, einer Funktion, die es ermöglicht, Delta Lake-Tabellen als Iceberg- oder Hudi-Tabellen zu lesen, ohne Daten zu duplizieren. UniForm generiert im Wesentlichen Iceberg- (oder Hudi-) Metadaten für eine vorhandene Delta Lake-Tabelle, sodass Engines, die hauptsächlich Iceberg sprechen, Delta-Tabellen abfragen können.
Obwohl UniForm eine praktische Lösung ist, um die Lesbarkeit zu ermöglichen, ist es wichtig, die Kompromisse zu erkennen. Es fungiert als Metadaten-Übersetzungsschicht, ändert aber nicht grundlegend die zugrunde liegende Datenorganisation. Beispielsweise können fortschrittliche Iceberg-spezifische Optimierungen oder Deletion-Vector-Funktionen möglicherweise nicht vollständig genutzt werden, wenn eine UniForm-aktivierte Delta-Tabelle als Iceberg gelesen wird.
Die unsichtbare Kraft: Erweiterte Indizierung und Query Optimizer
Über die Tabellenformate selbst hinaus verschieben die großen Cloud-Datenplattformen unaufhörlich die Grenzen der Abfrageleistung. Für Apache Iceberg erforscht die Community aktiv erweiterte Indizierungsfunktionen. Während die Metadaten von Iceberg bereits Dateiebene-Statistiken für eine leistungsstarke Pruning-Funktion bereitstellen, ist die Hinzufügung von Funktionen wie Bloom Filtern für Spalten mit hoher Kardinalität ein wichtiger Entwicklungsbereich.
Snowflakes Query Engine wird erweitert, um nahtlos mit Iceberg-Tabellen zu arbeiten, und nutzt deren vorhandenen Search Optimization Service und Query Acceleration Service. Auch Databricks verfügt über eine Reihe von Query-Optimierungstechniken, darunter:
- Cost-Based Optimizer (CBO): Nutzt Tabellenstatistiken für effiziente Ausführungspläne.
- Dynamic File Pruning (DFP): Überspringt irrelevante Datendateien während der Abfrageausführung basierend auf Laufzeitfiltern.
- Auto Optimize: Beinhaltet Optimized Writes und Auto Compaction zur Verwaltung der Dateigrößen.
Schema Evolution und Datenverträge: Navigieren Sie mit Zuversicht durch Veränderungen
Eine der gefeierten Funktionen von Iceberg ist seine robuste und sichere Schema-Evolution. Iceberg ermöglicht es Ihnen, Spalten hinzuzufügen, zu löschen, umzubenennen und Typen auf Metadatenebene zu aktualisieren, was keine teuren, vollständigen Tabellen-Rewrites erfordert. Anstatt Parquet-Dateien manuell zu ändern, geben Sie einfache SQL DDL-Befehle aus:
ALTER TABLE my_iceberg_table
ADD COLUMN event_timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP();
Diese Änderungen sind transaktional und sofort verfügbar. Mit großer Flexibilität geht jedoch die Notwendigkeit einer starken Governance einher. Best Practices umfassen die Planung für zukünftiges Wachstum, die Verwendung aussagekräftiger Standardwerte und die Pflege einer Versionskontrolle für Auditing und Rollback.
Experten-Einblick: Die konvergierende Metadatenebene und die Streaming-First-Zukunft
Mit Blick auf 2026 und darüber hinaus ist meine Expertenvorhersage, dass das Open-Data-Ökosystem zunehmend zu einer konvergierenden Metadatenebene tendieren wird. Projekte wie Apache Polaris (derzeit in der Inkubation) stehen an der Spitze dieses Trends. Polaris zielt darauf ab, ein gemeinsamer Katalog und eine gemeinsame Governance-Schicht für Iceberg-Tabellen über mehrere Query Engines hinweg zu sein.
Darüber hinaus ist der Wandel hin zu "Streaming-First"-Lakehouses unbestreitbar. Wir bewegen uns weg davon, Streaming als nachträglichen Gedanken zu behandeln, hin zu kontinuierlicher Aufnahme, Verarbeitung und Abfragebereitstellung als Standard. Dies erfordert robuste, inkrementelle Commits und ein effizientes Changelog-Management.
Reality Check: Der Weg nach vorn und verbleibende Eigenheiten
Obwohl die Fortschritte aufregend sind, ist es wichtig, einen Reality Check durchzuführen. Der Weg zu einem wirklich nahtlosen Open Lakehouse hat noch seine rauen Kanten:
- Interoperabilitäts-Kompromisse: Grundlegende Unterschiede zwischen Formaten bedeuten, dass eine perfekte, Feature-für-Feature-Interoperabilität nicht immer gegeben ist.
- Operationelle Komplexität: Die Verwaltung von Compaction und das Verfallen von Snapshots erfordert immer noch sorgfältige Planung.
- Snowflake Iceberg Einschränkungen: Snowflake-verwaltete Iceberg-Tabellen haben immer noch Einschränkungen im Vergleich zu extern verwalteten.
- Katalog-Fragmentierung: Es gibt immer noch mehrere Kataloge, was eine zusätzliche Konfigurationskomplexität mit sich bringt.
Praktische Anleitung: Automatisierung der Iceberg-Tabellenwartung (Compaction)
Einer der kritischsten Aspekte der Aufrechterhaltung der Iceberg-Tabellenleistung ist eine effektive Dateicompaction. Wir verwenden die RewriteDataFiles-Aktion von Spark, um kleine Dateien in größere zu konsolidieren.
-- Unter der Annahme, dass ein Katalog namens 'spark_catalog' für Iceberg konfiguriert ist
USE spark_catalog.my_db;
-- Führen Sie die Compaction für kalte Partitionen aus
-- Ziel-Dateigröße ist auf 512 MB eingestellt
ALTER TABLE event_logs
EXECUTE REWRITE DATA FILES
WHERE event_hour < date_trunc('hour', current_timestamp() - INTERVAL '2 HOURS')
OPTIONS (
'target-file-size-bytes' = '536870912',
'strategy' = 'binpack'
);
Dieser ALTER TABLE ... EXECUTE REWRITE DATA FILES-Befehl ist eine transaktionale Operation. Er liest die angegebenen Datendateien, schreibt neue, größere Dateien und committet dann atomar einen neuen Snapshot in die Metadaten der Tabelle. Nach einer erfolgreichen Compaction sollten Sie möglicherweise auch REMOVE ORPHAN FILES ausführen, um Speicherplatz freizugeben. Der Open Data Stack ist nicht mehr nur ein Versprechen; er ist eine sich schnell entwickelnde Realität.
Quellen
Dieser Artikel wurde vom DataFormatHub Editorial Team veröffentlicht, einer Gruppe von Entwicklern und Datenbegeisterten, die sich dafür einsetzen, Datentransformationen zugänglich und privat zu machen. Unser Ziel ist es, hochwertige technische Einblicke neben unserer Suite von datenschutzorientierten Entwicklertools bereitzustellen.
🛠️ Verwandte Tools
Entdecken Sie diese DataFormatHub-Tools, die sich auf dieses Thema beziehen:
- CSV to SQL - Bereiten Sie Daten für Lakehouses vor
- JSON to YAML - Formatieren Sie Schema-Definitionen