Delta Lake vs Apache Iceberg 2026: Lakehouse Architectuur en Sollicitatievragen

Delta Lake en Apache Iceberg vertegenwoordigen de twee dominante open tabelformaten die moderne data lakehouses aandrijven in 2026. Beide technologieën lossen hetzelfde fundamentele probleem op – ACID-transacties, schema-evolutie en time travel naar cloud object storage brengen – maar volgen verschillende architecturale benaderingen die significant impact hebben op productie-workloads.

Delta Lake vs Iceberg: Fundamentele Architectuurverschillen

Beide formaten slaan data op als Parquet-bestanden op object storage, maar hun metadata-lagen verschillen aanzienlijk.

Delta Lake gebruikt een transactielogboek (_delta_log/) met JSON-bestanden die elke wijziging vastleggen. Elke commit creëert een nieuw JSON-bestand, en periodieke checkpoints consolideren deze naar Parquet voor snellere reads. De Delta Lake Protocol specificatie definieert geversieneerde reader/writer features voor forward-compatibiliteit.

Apache Iceberg onderhoudt een hiërarchie van metadata-bestanden: een metadata JSON-bestand dat verwijst naar manifest lists, die op hun beurt verwijzen naar manifests met file-level statistieken. Dit ontwerp maakt predicate pushdown mogelijk in de planningsfase – de query engine slaat hele bestanden over voordat er data wordt gelezen.

| Feature | Delta Lake | Apache Iceberg | |---------|------------|----------------| | Transactielogboek | JSON + Parquet checkpoints | Metadata JSON + manifest bestanden | | Partitie-evolutie | Vereist herschrijven | In-place zonder herschrijven | | Engine Support | Spark, Trino, Flink | Spark, Trino, Flink, Dremio, Athena | | Time Travel | Versie-gebaseerd | Snapshot-gebaseerd met branch/tag | | Schema-evolutie | Kolommen toevoegen/hernoemen | Kolommen toevoegen/hernoemen/herordenen/verbreden |

Hidden Partitions: Het Belangrijkste Voordeel van Iceberg

Traditionele Hive-stijl partitionering exposeert partitiekolommen in queries (WHERE year=2026 AND month=7), wat fysieke layout koppelt aan SQL-syntax. Icebergs hidden partitions ontkoppelen deze aspecten.

# 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 definiëren
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 op maand geëxtraheerd uit event_time
partition_spec = PartitionSpec(
    PartitionField(
        source_id=2,  # event_time veld
        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 filteren direct op event_time – de engine past automatisch partition pruning toe zonder de partitiekolom in de WHERE-clausule te exposeren. Partitie-evolutie maakt het mogelijk om van maandelijkse naar dagelijkse partitionering over te stappen zonder bestaande data te herschrijven.

Delta Lake ACID-Transacties en Optimistic Concurrency

Delta Lake implementeert serializable isolation met optimistic concurrency control. Writers controleren het transactielogboek voor commit om conflicten te detecteren.

# 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 operatie met automatische conflictresolutie
delta_table = DeltaTable.forPath(spark, "s3://bucket/events")

# Inkomende batch mergen met bestaande data
delta_table.alias("target").merge(
    source=incoming_df.alias("source"),
    condition="target.event_id = source.event_id"
).whenMatchedUpdateAll() \
 .whenNotMatchedInsertAll() \
 .execute()

# Conflictdetectie gebeurt automatisch tijdens commit
# Gefaalde transacties worden opnieuw geprobeerd met bijgewerkte snapshot

Delta Lakes conflictresolutieregels staan gelijktijdige appends toe terwijl conflicterende updates naar dezelfde partitie worden geserialiseerd.

Time Travel en Data Versioning Vergeleken

Beide formaten ondersteunen time travel, maar met verschillende semantiek.

-- Delta Lake: Query op versienummer
SELECT * FROM events VERSION AS OF 42;

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

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

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

Iceberg 1.5+ voegt branching en tagging toe – maak benoemde branches voor geïsoleerde experimenten, merge of verwerp daarna. Delta Lake bereikt vergelijkbare workflows door shallow clones.

-- Iceberg: Branch aanmaken voor tests
ALTER TABLE analytics.events CREATE BRANCH experiment;

-- Schrijven naar branch zonder main te beïnvloeden
INSERT INTO analytics.events.branch_experiment 
SELECT * FROM staging.events WHERE event_type = 'test';

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

Query Engine Compatibiliteitsmatrix

Engine-compatibiliteit stuurt de formaatkeuze voor veel organisaties.

| Engine | Delta Lake Support | Iceberg Support | |--------|-------------------|------------------| | Apache Spark | Native (Databricks, OSS) | Native | | Trino/Presto | Connector | Native | | Apache Flink | Connector | Native (1.16+) | | Dremio | Alleen lezen | Native | | AWS Athena | Beperkt | Native | | Snowflake | External tables | Native (Iceberg tables) | | BigQuery | External tables | BigLake Iceberg |

Voor Spark-only omgevingen biedt Delta Lakes nauwere integratie betere performance. Multi-engine architecturen profiteren van Icebergs bredere compatibiliteit – de Iceberg REST Catalog biedt een vendor-neutrale API voor catalog-operaties.

Performance Optimalisatietechnieken

Beide formaten vereisen onderhoudsoperaties voor optimale query-performance.

# delta_optimize.py
from delta import DeltaTable

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

# Kleine bestanden compacteren (bin-packing)
delta_table.optimize().executeCompaction()

# Z-order voor multi-kolom predicaten
delta_table.optimize().executeZOrderBy("user_id", "event_time")

# Oude versies verwijderen (vacuum)
delta_table.vacuum(retentionHours=168)  # 7 dagen bewaren

-- Iceberg: Databestanden herschrijven voor compactie
CALL catalog.system.rewrite_data_files(
  table => 'analytics.events',
  strategy => 'binpack',
  options => map('target-file-size-bytes', '134217728')
);

-- Iceberg: Oude snapshots laten verlopen
CALL catalog.system.expire_snapshots(
  table => 'analytics.events',
  older_than => TIMESTAMP '2026-07-01 00:00:00',
  retain_last => 10
);

Z-ordering clustert gerelateerde data samen, wat de effectiviteit van predicate pushdown verbetert. Beide formaten profiteren van bestandscompactie bij het ingestenten van veel kleine bestanden uit streaming bronnen.

Veelvoorkomende Data Lakehouse Sollicitatievragen

Deze vragen worden regelmatig gesteld in data engineering interviews.

Vraag: Wanneer kies je Iceberg boven Delta Lake?

Iceberg past beter wanneer: (1) meerdere query engines dezelfde tabellen benaderen (Spark, Trino, Flink), (2) partitieschema's moeten evolueren zonder data herschrijven, (3) de organisatie vendor-neutrale open standaarden prefereert. Delta Lake excelleert in Databricks-centrische architecturen of pure Spark-omgevingen waar Unity Catalog governance biedt.

Vraag: Hoe bereikt Iceberg partitie-evolutie zonder data herschrijven?

Iceberg slaat partitiespecificaties op als metadata. Wanneer de specificatie wijzigt, gebruiken nieuwe data de nieuwe partitionering terwijl bestaande data hun oorspronkelijke layout behouden. De query planner leest alle partitiespecificaties en past de correcte pruning-logica toe voor elke bestandsgroep.

Vraag: Leg het checkpoint-mechanisme van Delta Lake uit.

Delta Lake maakt standaard elke 10 commits checkpoint-bestanden. Een checkpoint consolideert het transactielogboek naar een enkel Parquet-bestand voor snellere reads. Het _last_checkpoint bestand verwijst naar de laatste checkpoint, en readers reconstrueren de state door de checkpoint plus eventuele volgende JSON commits te lezen.

Vraag: Wat is copy-on-write vs merge-on-read?

Copy-on-write (COW) herschrijft hele bestanden bij updates – hogere schrijfkosten maar snellere reads. Merge-on-read (MOR) schrijft delta's apart en merged bij query-tijd – lagere schrijflatentie maar read overhead. Iceberg ondersteunt beide; Delta Lake gebruikt primair COW met deletion vectors voor soft deletes in recente versies.

Oefen deze patronen op SharpSkills data engineering sollicitatievragen om begrip te consolideren voor interviews.

Migratiepad: Converteren tussen Formaten

Organisaties moeten soms migreren tussen formaten. Beide ondersteunen conversie-utilities.

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

# Iceberg naar Delta converteren
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")

Volledige migratie vereist zorgvuldige validatie van schematypen, partitioneringssemantiek en downstream consumer compatibiliteit.

Conclusie

• Kies Delta Lake voor Spark-native workloads, Databricks-omgevingen en wanneer Unity Catalog governance past bij organisatiebehoeften
• Kies Iceberg voor multi-engine architecturen, partitie-evolutie vereisten en cloud-agnostische deployments
• Beide formaten leveren ACID-transacties, time travel en schema-evolutie – de juiste keuze hangt af van bestaande infrastructuur en query engine diversiteit
• Sollicitatievoorbereiding moet transactielogboek internals, partition pruning optimalisatie en COW vs MOR trade-offs dekken
• Bestandscompactie en snapshot expiration blijven kritieke onderhoudstaken ongeacht formaatkeuze