Apache Iceberg Adoptuj

data-platform mlops orchestration data-lakehouse table-format analytics governance open-table-format rest-catalog interoperability

Mai 2026

Überblick

Apache Iceberg ist ein offenes Tabellenformat für große analytische Datensätze, das SQL-Tabellen-Zuverlässigkeit in Data Lakes bringt und mehreren Engines gleichzeitige sichere Arbeit an denselben Tabellen erlaubt. Das Apache-Projekt beschreibt Iceberg als High-Performance-Format für riesige analytische Tabellen mit Engines wie Spark, Trino, Flink, Presto, Hive und Impala auf denselben Tabellen (Apache Iceberg). Der Kernwert trennt Tabellen-Semantik von einer einzelnen Compute Engine oder einem Warehouse, damit gemeinsame analytische Data Products offen, versioniert und reproduzierbar bleiben.

Die Tabellen-Spezifikation ist reif genug für Adoption. Versionen 1, 2 und 3 der Spec sind abgeschlossen und community-adoptiert; Version 4 ist in aktiver Entwicklung und noch nicht formal adoptiert (Apache Iceberg Spec). Die Spec definiert snapshot-basierte Metadaten, optimistische Commits, serialisierbare Isolationsziele, Schema Evolution, Partition Evolution, Position- und Equality Deletes, Deletion Vectors in v3 und Kompatibilitätsregeln über Format-Versionen (Apache Iceberg Spec).

Der stärkste Adoptionstreiber ist offene Lakehouse-Interoperabilität. Die Iceberg REST-Catalog-Spezifikation definiert eine gemeinsame OpenAPI-basierte API für jeden Iceberg Catalog und ermöglicht neuen Sprachen und Engines Support mit einer Client-Implementierung, inklusive sicherem Tabellenteilen über Credential Vending oder Remote Signing (Apache Iceberg REST Catalog Spec). Iceberg ist besonders relevant für Data Platforms mit governed Zugriff aus mehreren Engines, Warehouses und ML/AI-Workloads ohne Datensatz-Kopien pro Plattform.

Adoptionssignale

Die neueste gelistete Iceberg-Release ist 1.11.0; das Projekt stellt, dass Iceberg 1.0.0 API-Stabilität offiziell garantiert, nachdem die API bereits in viele Processing Engines integriert war (Apache Iceberg Releases).
Snowflake unterstützt Iceberg-Tabellen in allen Accounts, Cloud-Plattformen und Regionen mit Read/Write, Snowflake-managed und externen Catalog-Optionen, Snowflake Open Catalog und Support für Iceberg Spec 1, 2 und 3 mit Einschränkungen (Snowflake Documentation).
Databricks kündigte Public Preview für managed Iceberg-Tabellen in Unity Catalog an, inklusive Read/Write von Databricks und externen Iceberg-Engines über Unity Catalogs Iceberg REST Catalog API sowie Governance für Iceberg-Tabellen in fremden Catalogs wie AWS Glue, Hive Metastores und Snowflake Horizon Catalog (Databricks).
AWS Prescriptive Guidance beschreibt native Iceberg-Unterstützung in Amazon EMR, AWS Glue, Amazon Athena und Amazon Redshift für transaktionale Data Lakes auf Amazon S3; das nächste Amazon-SageMaker-Lakehouse ist vollständig Iceberg-kompatibel und kann Daten per Iceberg REST API in place abfragen (AWS Prescriptive Guidance).
Der REST Catalog ist Interoperabilitäts-Fokus: Snowflake unterstützt remote Iceberg REST Catalogs inklusive AWS Glue und Snowflake Open Catalog; Databricks exponiert Unity Catalog über Iceberg REST Catalog APIs für Clients wie Spark, Flink, Trino, PyIceberg, Kafka Connect und Redpanda (Snowflake Documentation, Databricks).

Risiken

Operative Wartung ist Pflicht. Iceberg empfiehlt Snapshot Expiration, Entfernen alter Metadaten, Löschen verwaister Dateien und optional Compaction von Data Files und Rewrite von Manifests; sonst sammeln sich Metadaten, kleine Dateien, veraltete Snapshots und unreferenzierte Objekte an und verschlechtern Performance und Storage-Kosten (Apache Iceberg Maintenance).
Wartung kann bei Fehlkonfiguration gefährlich sein. Iceberg warnt, dass Orphan-File-Löschung mit kürzerem Retention-Intervall als erwartete Schreibdauer Tabellen korrumpieren kann; Path-String-Mismatches auf manchen Dateisystemen können beim Orphan-File-Removal zu Datenverlust führen (Apache Iceberg Maintenance).
Catalog-Strategie ist Plattementscheidung. Snowflake unterscheidet Snowflake-managed Iceberg mit voller Plattformunterstützung und extern managed Iceberg mit eingeschränkter Unterstützung; Snowflake synchronisiert Remote-Catalog-Access-Control für User und Rollen in catalog-linked Databases nicht (Snowflake Documentation).
Engine-Support ist ungleich. Snowflake unterstützt manche Iceberg-v2/v3-Features, aber keine Equality-Delete-Dateien, hat Einschränkungen bei Writes externer Query Engines und dokumentiert zahlreiche Caveats für externe Catalogs, Row-Level Deletes, private Connectivity, Metadata Consistency, Replication, Streams und feingranulare Access-Control-Policies (Snowflake Documentation).
Offenes Format bedeutet nicht automatisch offene Governance. Teams brauchen gewählten Catalog, Access-Control-Modell, Lineage, Data-Quality-Checks, Lifecycle-Policies, Kostenkontrollen und Ownership-Konventionen über Engines; sonst wird Iceberg ein weiteres ungoverned Data-Lake-Layout statt Fundament für Data Products.

Vorteile & Nachteile

Vorteile

Bietet ein offenes, engine-neutrales Tabellenformat für große analytische Datensätze auf Object Storage.
Unterstützt ACID-ähnliche Tabellen-Updates, Schema Evolution, Partition Evolution, Hidden Partitioning, Snapshots, Time Travel, Rollback und Row-Level Deletes.
Verbessert Interoperabilität über Spark, Flink, Trino, Presto, Hive, Impala, Cloud Warehouses, Catalogs und Lakehouse-Plattformen.

Nachteile

Erfordert operative Ownership für Compaction, Snapshot Expiration, Metadata Cleanup, Orphan-File-Removal und Manifest Maintenance.
Catalog-Wahl kann Governance-, Interoperabilitäts- und Lock-in-Trade-offs schaffen, auch wenn das Tabellenformat offen ist.
Feature-Support unterscheidet sich je Engine, besonders bei Writes, Equality Deletes, v3-Features, externen Catalogs und feingranularen Access Policies.

Empfehlung

Adoptieren Sie Apache Iceberg als Standard-Open-Table-Format für gemeinsame analytische Datensätze mit offenem Storage, Multi-Engine-Zugriff, Reproduzierbarkeit, Governance und langfristiger Interoperabilität. Es ist besonders relevant für KI- und ML-Datenfundamente, weil Feature Pipelines, RAG-Ingestion, Analytics, Model Evaluation, Lineage und Backtesting von konsistenten, versionierten, hochwertigen Daten abhängen, die verschiedene Engines ohne Storage-Duplikation nutzen können.

Adoption sollte plattformgeführt sein, nicht projektweise. Standardisieren Sie Catalog-Strategie, Tabellennamen, Ownership, Access-Control-Integration, Snapshot Retention, Compaction, Orphan-File-Cleanup, Metadata Cleanup, Branch/Tag-Nutzung, Schema-Evolution-Regeln und Kompatibilitätserwartungen über Engines. Behandeln Sie den Iceberg REST Catalog als zentrale Architekturgrenze und testen Sie Read/Write-Interoperabilität der relevanten Engines, bevor Sie eine Tabelle als „offen“ deklarieren.

Nutzen Sie managed Table Services, wo sie operative Last senken, behalten Sie aber Ownership des Portabilitätsvertrags. Validieren Sie, welche Engine oder welcher Catalog für Writes autoritativ ist, welche Plattform Wartung ausführt, wie Access Policies über Engines durchgesetzt werden und welches Feature-Subset produktionssicher ist. Migrieren Sie Workloads zu Iceberg, wenn Data Products Cross-Engine-Nutzung brauchen; vermeiden Sie Adoption nur als Dateilayout-Wechsel ohne Governance und Wartungsautomatisierung.