Snowflake Managed Iceberg Tables und Dynamic Tables Replication sind allgemein verfügbar
trending_up Trend: news

Snowflake Managed Iceberg Tables und Dynamic Tables Replication sind allgemein verfügbar

calendar_month 29. Juni 2026

Zusammenfassung

Snowflake hat die allgemeine Verfügbarkeit (General Availability, GA) von zwei zentralen Features für offene Tabellenformate bekannt gegeben: die verwalteten Apache Iceberg-Tabellen (Snowflake-managed Iceberg Tables) sowie die Replikation und Ausfallsicherung dynamischer Iceberg-Tabellen (dynamic Iceberg table replication). Mit diesen Updates etabliert Snowflake eine vollständig verwaltete, offene Data-Lakehouse-Architektur. Unternehmen können nun von offenen Speicherformaten wie Apache Iceberg profitieren, ohne die administrative Komplexität externer Cloud-Speicher verwalten zu müssen.

Was ist passiert?

  • GA von Snowflake-managed Iceberg Tables (Juni 2026): Snowflake übernimmt ab sofort die vollständige Verwaltung, Verschlüsselung und Wartung der physischen Parquet- und Metadatendateien für Apache Iceberg. Die manuelle Einrichtung und Verwaltung von externen Cloud-Speicher-Buckets (wie AWS S3 oder Azure ADLS Gen2) und komplexen IAM-Richtlinien entfällt.
  • GA von Dynamic Iceberg Table Replication (29. Juni 2026): Dynamische Iceberg-Tabellen, die ihre Ausgabe im Iceberg-Format auf externen Volumes speichern, können nun nahtlos in datenbankweite Replikations- und Failover-Gruppen aufgenommen werden. Zuvor wurden diese Objekte beim Replizieren übersprungen.
  • Plattform-Verfügbarkeit: Die Features stehen für Snowflake-konten auf Amazon Web Services (AWS) und Microsoft Azure zur Verfügung (ausgenommen Regierungsregionen und China).

Warum es wichtig ist

Das Lakehouse-Versprechen verspricht offene Standards bei hoher Performance. Die Realität war jedoch oft von hoher Komplexität geprägt. Die neuen GA-Releases lösen dieses Problem:

  • Zero-Management Data Lake: Entwickler erhalten ein „Just-Works“-Erlebnis wie bei nativen Snowflake-Tabellen, behalten aber gleichzeitig die vollständige Interoperabilität offener Speicherformate.
  • Disaster Recovery für Open Data: Mit der Replikation dynamischer Tabellen können kritische Data-Pipelines, die auf offenen Standards basieren, über Regionen hinweg repliziert werden, um Ausfallsicherheit im Katastrophenfall zu garantieren.
  • Kosteneffizienz und Interoperabilität: Unternehmen vermeiden Datensilos und hohe Egress-Kosten, da externe Query-Engines (wie Spark oder Trino) direkt und ohne Umwege auf die von Snowflake verwalteten Daten zugreifen können.

Beweise

  • Releases von Snowflake (Juni 2026): Offizielle Veröffentlichung der Features in den Release Notes für Version 8.2x von Snowflake.
  • Technische Dokumentation: Die Einführung des Befehls SYSTEM$VERIFY_EXTERNAL_VOLUME zur Überprüfung der Berechtigungen für replizierte Volumes auf Sekundärkonten.
  • Community-Diskussionen: Data Engineers diskutieren auf Tech-Plattformen über den Wegfall des Overheads zur Einrichtung von S3-Buckets für Iceberg-Architekturen.

Analyse

Dieser Schritt verdeutlicht Snowflakes Strategiewechsel hin zu einer offenen Datenarchitektur, um sich gegenüber dem Hauptkonkurrenten Databricks und dessen Delta Lake-Ökosystem zu positionieren. Indem Snowflake die Speicherung von Iceberg-Dateien selbst übernimmt, entzieht es Databricks das Argument der administrativen Überlegenheit. Die Erweiterung um Replikation und Failover für dynamische Iceberg-Tabellen zeigt, dass Snowflake offene Formate nicht mehr nur als Nischen-Feature, sondern als Kernbestandteil seiner unternehmenskritischen Cloud-Architektur ansieht.

Praktische Erkenntnisse

  1. Speicherkomplexität eliminieren: Nutzen Sie Snowflake-managed Iceberg-Tabellen für neue Projekte, bei denen Sie die Interoperabilität von Iceberg benötigen, aber keine Ressourcen für die Verwaltung eigener S3/Azure-Buckets aufwenden wollen.
  2. Replikation prüfen: Stellen Sie sicher, dass beim Replizieren dynamischer Iceberg-Tabellen die zugehörigen externen Volumes im Ziel-Sekundärkonto identisch konfiguriert und erreichbar sind.
  3. Validierung nutzen: Verwenden Sie die Funktion SYSTEM$VERIFY_EXTERNAL_VOLUME vor dem finalen Failover, um Zugriffskonflikte und Replikationsabbrüche im Sekundärkonto zu verhindern.
  4. Schreibzugriffe beachten: Denken Sie daran, dass replizierte dynamische Tabellen auf dem Sekundärkonto schreibgeschützt (read-only) sind und erst nach einem Failover-Event aktualisiert oder überschrieben werden können.

Offene Fragen

  • Wird Snowflake dieses verwaltete Speichermodell zukünftig auch auf die Google Cloud Platform (GCP) ausweiten?
  • Wie verhalten sich die Speichergebühren von Snowflake-managed Iceberg-Tabellen im direkten Vergleich zu selbst verwalteten Cloud-Buckets unter Berücksichtigung von Datentransfer- und API-Aufrufkosten?

Quellen

  1. Snowflake Documentation: Managed Iceberg Tables Overview
  2. Snowflake Release Notes: Dynamic Table Replication General Availability
  3. Snowflake Blog: Open Data Interoperability with Apache Iceberg