Delta Lake vs Apache Iceberg 2026: Lakehouse-Architektur und Interview-Fragen

Delta Lake und Apache Iceberg haben sich 2026 als die beiden führenden offenen Tabellenformate für moderne Data Lakehouses etabliert. Beide Technologien lösen das gleiche fundamentale Problem – ACID-Transaktionen, Schema-Evolution und Time Travel auf Cloud-Objektspeichern – verfolgen dabei jedoch unterschiedliche architektonische Ansätze mit praktischen Auswirkungen auf Produktionsworkloads.

Delta Lake vs Iceberg: Kernarchitektur-Unterschiede

Beide Formate speichern Daten als Parquet-Dateien auf Objektspeichern, unterscheiden sich jedoch erheblich in ihren Metadaten-Schichten.

Delta Lake verwendet ein Transaktionslog (_delta_log/), das JSON-Dateien enthält, die jede Änderung protokollieren. Jeder Commit erstellt eine neue JSON-Datei, und periodische Checkpoints konsolidieren diese in Parquet für schnellere Lesezugriffe. Die Delta Lake Protocol Specification definiert versionierte Reader/Writer-Features für Vorwärtskompatibilität.

Apache Iceberg pflegt eine Hierarchie von Metadaten-Dateien: Eine Metadata-JSON-Datei verweist auf Manifest-Listen, die wiederum auf Manifeste mit Datei-Level-Statistiken verweisen. Dieses Design ermöglicht Predicate Pushdown bereits in der Planungsphase – die Query-Engine überspringt ganze Dateien, bevor sie Daten liest.

| Feature | Delta Lake | Apache Iceberg | |---------|------------|----------------| | Transaktionslog | JSON + Parquet Checkpoints | Metadata JSON + Manifest-Dateien | | Partition Evolution | Erfordert Neuschreiben | In-Place ohne Neuschreiben | | Engine-Support | Spark, Trino, Flink | Spark, Trino, Flink, Dremio, Athena | | Time Travel | Versionsbasiert | Snapshot-basiert mit Branch/Tag | | Schema-Evolution | Spalten hinzufügen/umbenennen | Spalten hinzufügen/umbenennen/umordnen/erweitern |

Hidden Partitions: Icebergs entscheidender Vorteil

Traditionelle Hive-Style-Partitionierung exponiert Partitionsspalten in Queries (WHERE year=2026 AND month=7) und koppelt damit physisches Layout an SQL-Syntax. Icebergs Hidden Partitions entkoppeln diese Belange.

# iceberg_partition_example.py
from pyiceberg.catalog import load_catalog
from pyiceberg.schema import Schema
from pyiceberg.types import StringType, TimestampType, LongType, NestedField
from pyiceberg.partitioning import PartitionSpec, PartitionField
from pyiceberg.transforms import MonthTransform

# Schema definieren
schema = Schema(
    NestedField(1, "event_id", LongType(), required=True),
    NestedField(2, "event_time", TimestampType(), required=True),
    NestedField(3, "user_id", StringType(), required=True),
    NestedField(4, "event_type", StringType(), required=False),
)

# Hidden Partition auf Monat extrahiert aus event_time
partition_spec = PartitionSpec(
    PartitionField(
        source_id=2,  # event_time Feld
        field_id=1000,
        transform=MonthTransform(),
        name="event_month"
    )
)

catalog = load_catalog("glue", **{"type": "glue"})
catalog.create_table(
    identifier="analytics.events",
    schema=schema,
    partition_spec=partition_spec
)

Queries filtern direkt auf event_time – die Engine wendet automatisch Partition Pruning an, ohne die Partitionsspalte in der WHERE-Klausel zu exponieren. Partition Evolution erlaubt den Wechsel von monatlicher zu täglicher Partitionierung ohne Neuschreiben bestehender Daten.

Delta Lake ACID-Transaktionen und Optimistic Concurrency

Delta Lake implementiert serializable Isolation durch optimistic Concurrency Control. Writer prüfen das Transaktionslog vor dem Commit, um Konflikte zu erkennen.

# delta_concurrent_writes.py
from delta import DeltaTable
from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
    .config("spark.sql.catalog.spark_catalog", 
            "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
    .getOrCreate()

# Concurrent MERGE Operation mit automatischer Konfliktauflösung
delta_table = DeltaTable.forPath(spark, "s3://bucket/events")

# Eingehende Batch-Daten mit bestehenden Daten mergen
delta_table.alias("target").merge(
    source=incoming_df.alias("source"),
    condition="target.event_id = source.event_id"
).whenMatchedUpdateAll() \
 .whenNotMatchedInsertAll() \
 .execute()

# Konflikterkennung erfolgt automatisch während des Commits
# Fehlgeschlagene Transaktionen werden mit aktualisiertem Snapshot wiederholt

Delta Lakes Konfliktauflösungsregeln erlauben parallele Appends, während konfligierende Updates auf dieselbe Partition serialisiert werden.

Time Travel und Daten-Versionierung im Vergleich

Beide Formate unterstützen Time Travel, jedoch mit unterschiedlicher Semantik.

-- Delta Lake: Query nach Versionsnummer
SELECT * FROM events VERSION AS OF 42;

-- Delta Lake: Query nach Timestamp
SELECT * FROM events TIMESTAMP AS OF '2026-07-15 10:00:00';

-- Iceberg: Query nach Snapshot ID
SELECT * FROM analytics.events FOR SYSTEM_VERSION AS OF 8823749234;

-- Iceberg: Query nach Timestamp
SELECT * FROM analytics.events FOR SYSTEM_TIME AS OF TIMESTAMP '2026-07-15 10:00:00';

Iceberg 1.5+ fügt Branching und Tagging hinzu – benannte Branches für isolierte Experimente erstellen, dann mergen oder verwerfen. Delta Lake erreicht ähnliche Workflows durch Shallow Clones.

-- Iceberg: Branch für Tests erstellen
ALTER TABLE analytics.events CREATE BRANCH experiment;

-- In Branch schreiben ohne Main zu beeinflussen
INSERT INTO analytics.events.branch_experiment 
SELECT * FROM staging.events WHERE event_type = 'test';

-- Branch zu Main mergen
CALL system.fast_forward('analytics.events', 'main', 'experiment');

Query-Engine-Kompatibilitätsmatrix

Engine-Kompatibilität bestimmt die Formatwahl für viele Organisationen.

| Engine | Delta Lake Support | Iceberg Support | |--------|-------------------|------------------| | Apache Spark | Nativ (Databricks, OSS) | Nativ | | Trino/Presto | Connector | Nativ | | Apache Flink | Connector | Nativ (1.16+) | | Dremio | Nur Lesen | Nativ | | AWS Athena | Eingeschränkt | Nativ | | Snowflake | External Tables | Nativ (Iceberg Tables) | | BigQuery | External Tables | BigLake Iceberg |

Für reine Spark-Umgebungen bietet Delta Lakes engere Integration bessere Performance. Multi-Engine-Architekturen profitieren von Icebergs breiterer Kompatibilität – der Iceberg REST Catalog bietet eine herstellerneutrale API für Catalog-Operationen.

Performance-Optimierungstechniken

Beide Formate erfordern Wartungsoperationen für optimale Query-Performance.

# delta_optimize.py
from delta import DeltaTable

delta_table = DeltaTable.forPath(spark, "s3://bucket/events")

# Kleine Dateien kompaktieren (Bin-Packing)
delta_table.optimize().executeCompaction()

# Z-Order für Multi-Column Prädikate
delta_table.optimize().executeZOrderBy("user_id", "event_time")

# Alte Versionen entfernen (Vacuum)
delta_table.vacuum(retentionHours=168)  # 7 Tage behalten

-- Iceberg: Datendateien für Kompaktierung neu schreiben
CALL catalog.system.rewrite_data_files(
  table => 'analytics.events',
  strategy => 'binpack',
  options => map('target-file-size-bytes', '134217728')
);

-- Iceberg: Alte Snapshots ablaufen lassen
CALL catalog.system.expire_snapshots(
  table => 'analytics.events',
  older_than => TIMESTAMP '2026-07-01 00:00:00',
  retain_last => 10
);

Z-Ordering clustert verwandte Daten zusammen und verbessert die Effektivität von Predicate Pushdown. Beide Formate profitieren von File Compaction beim Ingesten vieler kleiner Dateien aus Streaming-Quellen.

Häufige Data-Lakehouse-Interview-Fragen

Diese Fragen werden regelmäßig in Data-Engineering-Interviews gestellt.

Frage: Wann sollte Iceberg gegenüber Delta Lake bevorzugt werden?

Iceberg passt besser, wenn: (1) mehrere Query-Engines auf dieselben Tabellen zugreifen (Spark, Trino, Flink), (2) Partitionsschemas sich ohne Datenneuschreiben entwickeln müssen, (3) die Organisation herstellerneutrale offene Standards bevorzugt. Delta Lake überzeugt in Databricks-zentrierten Architekturen oder reinen Spark-Umgebungen, wo Unity Catalog Governance bietet.

Frage: Wie erreicht Iceberg Partition Evolution ohne Datenneuschreiben?

Iceberg speichert Partitionsspezifikationen als Metadaten. Bei Änderung der Spezifikation verwenden neue Daten die neue Partitionierung, während bestehende Daten ihr ursprüngliches Layout behalten. Der Query-Planner liest alle Partitionsspezifikationen und wendet die korrekte Pruning-Logik für jede Dateigruppe an.

Frage: Erklären Sie Delta Lakes Checkpoint-Mechanismus.

Delta Lake erstellt standardmäßig alle 10 Commits Checkpoint-Dateien. Ein Checkpoint konsolidiert das Transaktionslog in eine einzelne Parquet-Datei für schnellere Lesezugriffe. Die _last_checkpoint-Datei verweist auf den neuesten Checkpoint, und Reader rekonstruieren den Zustand durch Lesen des Checkpoints plus nachfolgender JSON-Commits.

Frage: Was ist Copy-on-Write vs Merge-on-Read?

Copy-on-Write (COW) schreibt ganze Dateien bei Updates neu – höhere Schreibkosten, aber schnellere Lesezugriffe. Merge-on-Read (MOR) schreibt Deltas separat und merged bei Query-Zeit – geringere Schreiblatenz, aber Lese-Overhead. Iceberg unterstützt beide Ansätze; Delta Lake verwendet primär COW mit Deletion Vectors für Soft Deletes in neueren Versionen.

Üben Sie diese Konzepte mit SharpSkills Data-Engineering-Interview-Fragen, um Ihr Verständnis vor Interviews zu festigen.

Migrationspfad: Konvertierung zwischen Formaten

Organisationen müssen manchmal zwischen Formaten migrieren. Beide bieten Konvertierungswerkzeuge.

# Delta zu Iceberg mit Spark konvertieren
spark.sql("""
    CALL catalog.system.snapshot(
        source_table => 'delta.`s3://bucket/delta_events`',
        table => 'analytics.events_iceberg'
    )
""")

# Iceberg zu Delta konvertieren
from delta.tables import DeltaTable

iceberg_df = spark.read.format("iceberg").load("catalog.analytics.events")
iceberg_df.write.format("delta").save("s3://bucket/delta_events")

Eine vollständige Migration erfordert sorgfältige Validierung von Schema-Typen, Partitionierungssemantik und Downstream-Consumer-Kompatibilität.

Fazit

• Delta Lake eignet sich für Spark-native Workloads, Databricks-Umgebungen und wenn Unity Catalog Governance den organisatorischen Anforderungen entspricht
• Iceberg ist die bessere Wahl für Multi-Engine-Architekturen, Partition-Evolution-Anforderungen und Cloud-agnostische Deployments
• Beide Formate liefern ACID-Transaktionen, Time Travel und Schema-Evolution – die richtige Wahl hängt von bestehender Infrastruktur und Query-Engine-Vielfalt ab
• Interview-Vorbereitung sollte Transaktionslog-Interna, Partition-Pruning-Optimierung und COW vs MOR Tradeoffs abdecken
• File Compaction und Snapshot Expiration bleiben kritische Wartungsaufgaben unabhängig von der Formatwahl