🔄 Update — 30. Juni 2026: Snowflake Apache Iceberg Tables GA & Databricks Lakehouse Monitoring

Snowflake hat die allgemeine Verfügbarkeit (General Availability) von Apache Iceberg Tables bekannt gegeben, was direkte Abfragen auf externen Data Lakes ermöglicht. Gleichzeitig hat Databricks neue Lakehouse Monitoring-Funktionen veröffentlicht. Diese Entwicklungen verdeutlichen die Zusammenführung der Standards von Lakehouses und traditionellen Data Warehouses.

Was ist neu?

• Snowflake Iceberg Tables GA: Apache Iceberg-Tabellen sind nun allgemein verfügbar und erlauben direkte Hochleistungsabfragen auf externen Data Lakes.
• Databricks Lakehouse Monitoring: Einführung neuer Überwachungs- und Analysefunktionen zur Qualitäts- und Integritätskontrolle im Lakehouse.

Warum es den Artikel ergänzt

Dieses Update zeigt die fortschreitende Etablierung offener Tabellenformate im Produktiveinsatz bei Snowflake und die zeitgleiche Reaktion von Databricks zur Stärkung seiner Lakehouse-Plattform.

---

Snowflake Interoperabilität: Apache Iceberg v3 Support ist jetzt allgemein verfügbar

Zusammenfassung

Snowflake hat die allgemeine Verfügbarkeit (General Availability, GA) von Apache Iceberg v3 bekannt gegeben. Dieses Release stellt einen wichtigen Meilenstein für die Interoperabilität von Multi-Engine Lakehouses dar. Zu den Neuerungen gehören die native Zeilenverfolgung (Row Lineage), die Verarbeitung halbstrukturierter Daten durch VARIANT-Data-Shredding, O(1) Deletion Vectors für schnellere Schreibzugriffe und die offene Datenfreigabe über den Horizon Catalog. Diese Funktionen ermöglichen eine leistungsstarke Datenverarbeitung direkt auf offenen Tabellenformaten ohne Datenvervielfältigung.

Was ist passiert?

• Bekanntgabe der GA: Am 7. Mai 2026 hat Snowflake die offizielle Unterstützung für Apache Iceberg v3 im produktiven Betrieb freigegeben.
• VARIANT Shredding: Die native Unterstützung des Datentyps VARIANT in Iceberg v3 erlaubt es Snowflake, eine eigene Shredding-Technik auf offene Parquet-Dateien anzuwenden. Verschachtelte JSON-Felder werden in stark typisierte Unterspalten zerlegt, was schnelle spaltenbasierte Scans ermöglicht.
• Row-Lineage-Verfolgung: Iceberg v3 führt Metadatenspalten auf Zeilenebene ein (z. B. _row_id und _last_updated_sequence_number), wodurch Change Data Capture (CDC) und Audit-Trails erheblich vereinfacht werden.
• Deletion Vectors: Dieses Feature ersetzt positionelle Löschdateien durch binäre Bitmaps, was O(1)-Lookups bei Lesezugriffen für DML-Operationen (UPDATE, DELETE, MERGE) ermöglicht.
• Horizon Catalog Integration: Über den Horizon Catalog können externe Query-Engines wie Apache Spark oder Trino bidirektional auf die von Snowflake verwalteten Iceberg-Tabellen zugreifen.

Warum es wichtig ist

Bislang mussten sich Unternehmen oft zwischen offenen Formaten (zur Vermeidung von Vendor-Lock-in) und hoher Performance proprietärer Plattformen entscheiden. Mit Iceberg v3 in Snowflake wird diese Lücke geschlossen:

• Zero-Copy-Interoperabilität: Unterschiedliche Engines (z. B. Snowflake, Spark, Trino) können dieselben Datendateien gleichzeitig abfragen.
• Performante halbstrukturierte Daten: Dank des VARIANT-Shreddings ist das Abfragen großer JSON-Strukturen kein I/O-Flaschenhals mehr, da nur noch die benötigten Unterfelder geladen werden.
• Einheitliche Governance: Horizon Catalog bietet eine Governance-Schicht, die konsistente Zugriffskontrollen (RBAC) über verschiedene Tools hinweg erzwingt.

Beweise

• Offizielle Pressemitteilung: Pressemeldung von Snowflake über ein neues offenes Framework für interoperable Unternehmensdaten und KI.
• Entwickler-Benchmarks: Erste Messergebnisse zeigen bis zu 10-mal schnellere DML-Operationen (UPDATE und DELETE) dank des Einsatzes von Deletion Vectors.
• Community-Feedback: Diskussionen auf Reddit (r/snowflake) und LinkedIn zeigen, dass Entwickler die neuen Features unmittelbar nach der GA-Ankündigung implementierten.

Analyse

Die GA von Iceberg v3 in Snowflake ist mehr als nur ein einfaches Versionsupdate; es ist ein strategischer Schachzug. Der Fokus von Databricks auf Delta Lake und den Unity Catalog hat Snowflake unter Zugzwang gesetzt. Mit Iceberg v3 zieht Snowflake bei den Features (wie Deletion Vectors und Row Lineage) mit Delta Lake gleich und sichert sich gleichzeitig durch den Horizon Catalog einen Governance-Vorteil. Besonders das VARIANT-Shredding ist wichtig, da halbstrukturierte Daten in offenen Tabellenformaten historisch schwer performant abzufragen waren.

Praktische Erkenntnisse

1. Tabellenerstellung vorausschauend planen: Der Standard für neue Iceberg-Tabellen in Snowflake bleibt v2. Um v3 zu nutzen, muss der Parameter ICEBERG_VERSION_DEFAULT konfiguriert oder die Version beim Erstellen der Tabelle explizit angegeben werden.
2. Achtung vor Irreversibilität: Das Upgrade einer Tabelle von v2 auf v3 kann nicht rückgängig gemacht werden. Zudem können ältere v2-Reader keine v3-Tabellen lesen, weshalb die gesamte Toolchain vorab auf Kompatibilität geprüft werden sollte.
3. Deletion Vectors nutzen: Aktivieren Sie Deletion Vectors für Tabellen mit hoher Schreibaktivität (häufige Updates/Deletes), um den Compaction-Overhead zu minimieren.
4. Halbstrukturierte Workloads migrieren: Nutzen Sie den VARIANT-Datentyp für JSON-Spalten, um von dem effizienten Parquet-Shredding zu profitieren.

Offene Fragen

• Wie schnell werden nachgelagerte Open-Source-Engines (wie Presto oder ältere Flink-Versionen) alle v3-Features nativ und fehlerfrei unterstützen?
• Führt die Verwaltung von bidirektionalen Schreibvorgängen über den Horizon Catalog in komplexen Multi-Cloud-Szenarien zu Synchronisationsverzögerungen?

Quellen

1. Snowflake Pioneers New Open Framework for Interoperable Enterprise Data and AI
2. Snowflake Summit 2026: Summary of New Features
3. Snowflake Now Supports Apache Iceberg v3 (General availability)
4. Snowflake Summit 2026: Context, Custom Model Training & Iceberg v3
5. Reddit: Newly Launched Snowflake Summit Features
6. LinkedIn: Analytics India Magazine Post on Data Interoperability