Wat is Apache Iceberg?
Apache Iceberg is een open-source table format voor grote analytische datasets in de cloud. Oorspronkelijk ontwikkeld door Netflix en Apple, en inmiddels een Apache top-level project met steun van alle grote cloud vendors.
De kernbelofte van Iceberg
Iceberg lost het fundamentele probleem van data lakes op: hoe beheer je miljoenen bestanden op S3 of ADLS als één coherente, betrouwbare tabel — zonder lock-in aan één query engine?
- ACID transactions: Veilige gelijktijdige reads en writes
- Time travel: Query data op elk historisch moment
- Schema evolution: Voeg kolommen toe zonder data te herschrijven
- Partition evolution: Verander partitionering zonder migratie
- Multi-engine: Gebruik Spark, Flink, Trino en Snowflake tegelijk op dezelfde data
In 2026 is Iceberg niet meer "nieuw" — het is de industriestandaard geworden. AWS Athena, Google BigQuery, Snowflake en Databricks ondersteunen het allemaal native. Als je nu een nieuw data platform opzet, is Iceberg de logische keuze.
Hoe Werkt Apache Iceberg van Binnen?
Iceberg slaat data op als gewone Parquet (of ORC/Avro) bestanden, maar voegt een metadata-laag bovenop toe die alles bijhoudt.
Data Files
De eigenlijke data: Parquet, ORC of Avro bestanden op S3, ADLS of GCS. Iceberg schrijft deze zelf niet anders op — het is gewoon cloud storage.
Manifest Files
Lijsten van data files met statistieken (min/max per kolom). Query engines gebruiken dit voor data pruning — bestanden overslaan die niet relevant zijn.
Manifest List
Een snapshot van de tabel op een bepaald moment: welke manifest files horen bij deze versie? Dit maakt time travel mogelijk.
Metadata File
Het hoofdbestand: schema, partitionering, snapshot history, statistieken. Dit is het startpunt voor elke query engine.
Snapshot-gebaseerde Architectuur
Elke write (INSERT, UPDATE, DELETE) maakt een nieuwe snapshot aan. Oude snapshots blijven bewaard totdat je ze expliciet verwijdert met expire_snapshots(). Dit geeft je:
- Atomaire commits: Een write slaagt volledig of helemaal niet
- Concurrent reads: Readers zien altijd een consistente snapshot
- Time travel: Query elke historische snapshot
- Rollback: Gooi een slechte write terug in één commando
Apache Iceberg vs Delta Lake vs Apache Hudi
Er zijn drie grote open table formats. Hier is de eerlijke vergelijking:
| Feature | Apache Iceberg | Delta Lake | Apache Hudi |
|---|---|---|---|
| Oorsprong | Netflix / Apple | Databricks | Uber |
| ACID transactions | ✅ Ja | ✅ Ja | ✅ Ja |
| Time travel | ✅ Ja (snapshots) | ✅ Ja (versies) | ⚠️ Beperkt |
| Multi-engine support | ✅ Beste (Spark, Flink, Trino, Snowflake, BigQuery) | ⚠️ Groeiend (via UniForm) | ⚠️ Spark-gericht |
| Partition evolution | ✅ Ja (zonder migratie) | ❌ Nee | ❌ Nee |
| Schema evolution | ✅ Volledig | ✅ Volledig | ✅ Beperkt |
| Vendor neutraliteit | ✅ Maximaal | ⚠️ Databricks-voorkeur | ✅ Goed |
| AWS native support | ✅ Athena, Glue, EMR | ⚠️ Via Databricks/EMR | ✅ EMR |
| Snowflake support | ✅ Native | ⚠️ Via UniForm (beperkt) | ❌ Geen |
De Winnaar in 2026?
Voor multi-cloud of multi-engine omgevingen is Iceberg de duidelijke winnaar vanwege de brede adoptie. Als je volledig op Databricks zit, is Delta Lake nog steeds prima. Hudi is sterk voor high-frequency upserts (CDC use cases).
De Krachtigste Iceberg Features Uitgelegd
Partition Evolution — Uniek voor Iceberg
Dit is de feature die Iceberg onderscheidt. Bij Delta Lake en Hudi moet je bij een partitioneringswijziging de volledige tabel herschrijven. Bij Iceberg kun je de partitioneringsstrategie aanpassen zonder één byte data te verplaatsen.
-- Begin met partitionering per dag
CREATE TABLE orders (
order_id BIGINT,
customer_id BIGINT,
amount DECIMAL(10,2),
order_date TIMESTAMP
)
USING iceberg
PARTITIONED BY (days(order_date));
-- Later groeien naar per uur (zonder tabel te herschrijven!)
ALTER TABLE orders
ADD PARTITION FIELD hours(order_date);
-- Iceberg schrijft nieuwe data in de nieuwe partitiestructuur,
-- oude data blijft ongewijzigd. Query engines begrijpen beide.
Time Travel & Rollback
Query historische data of herstel per ongeluk gewiste records:
-- Query de tabel van gisteren (Spark SQL)
SELECT * FROM orders
TIMESTAMP AS OF '2026-03-20 09:00:00';
-- Query specifieke snapshot
SELECT * FROM orders VERSION AS OF 4521;
-- Rollback naar vorige snapshot
CALL catalog.system.rollback_to_snapshot('db.orders', 4521);
-- Bekijk snapshot history
SELECT * FROM orders.snapshots;
Schema Evolution zonder Downtime
Voeg kolommen toe, hernoem of verwijder ze — veilig en zonder data te herschrijven:
-- Kolom toevoegen (werkt direct, geen rewrite)
ALTER TABLE orders ADD COLUMN discount DECIMAL(5,2);
-- Kolom hernoemen
ALTER TABLE orders RENAME COLUMN amount TO order_amount;
-- Kolom verplaatsen
ALTER TABLE orders ALTER COLUMN discount AFTER order_amount;
-- Kolom verwijderen (data blijft, maar wordt niet meer gelezen)
ALTER TABLE orders DROP COLUMN legacy_flag;
Row-level Deletes & Updates (Copy-on-Write vs Merge-on-Read)
Iceberg ondersteunt twee strategieën voor updates en deletes:
-- Copy-on-Write (CoW): herschrijft bestanden bij elke update
-- → Sneller lezen, langzamer schrijven
-- Goed voor: batch updates, rapportage-tables
-- Merge-on-Read (MoR): slaat delete/update markers op
-- → Sneller schrijven, lezen vereist merge
-- Goed voor: frequente CDC / streaming updates
-- MERGE INTO (upsert) — werkt in Spark, Trino, Flink
MERGE INTO orders t
USING updates s ON t.order_id = s.order_id
WHEN MATCHED AND s.status = 'cancelled' THEN DELETE
WHEN MATCHED THEN UPDATE SET t.amount = s.amount, t.status = s.status
WHEN NOT MATCHED THEN INSERT *;
Multi-engine: De Grootste Troef van Iceberg
Het grootste voordeel van Iceberg ten opzichte van de alternatieven is dat meerdere engines tegelijk dezelfde tabel kunnen lezen en schrijven zonder coördinatie:
AWS Stack
- AWS Glue: ETL jobs op Iceberg tabellen
- Amazon Athena: SQL queries zonder cluster
- Amazon EMR: Spark/Hive/Flink op Iceberg
- AWS Lake Formation: Governance + Iceberg
- Amazon Redshift: Spectrum op Iceberg tables
Azure / Microsoft
- Azure Databricks: Native Iceberg support
- Microsoft Fabric: OneLake + Iceberg
- Azure HDInsight: Spark op Iceberg
- Azure Synapse: Via Spark pools
Google Cloud
- BigQuery: Native Iceberg tables (BigLake)
- Dataproc: Spark + Iceberg
- Dataflow: Beam pipeline op Iceberg
Open Source Engines
- Apache Spark: Beste integratie
- Apache Flink: Streaming naar Iceberg
- Trino / Presto: Ad-hoc SQL
- DuckDB: Lokale queries op Iceberg
- Dremio: BI-acceleration op Iceberg
Praktijkscenario: Netflix's Iceberg Setup
Netflix, de uitvinder van Iceberg, gebruikt het op deze manier:
- Flink: Real-time streaming schrijft events naar Iceberg (miljoenen per seconde)
- Spark: Batch ETL transformaties en compaction jobs
- Trino: Data analisten querien de data ad-hoc via SQL
- Dezelfde S3 tabellen — geen data kopiëren of synchroniseren
Resultaat: één platform voor streaming én batch, met volle SQL-ondersteuning en geen vendor lock-in.
Aan de Slag met Apache Iceberg
Lokaal testen met Spark + Iceberg
# pip install pyspark
# Download Iceberg Spark runtime JAR
from pyspark.sql import SparkSession
spark = SparkSession.builder \
.appName("IcebergDemo") \
.config("spark.jars.packages",
"org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.5.0") \
.config("spark.sql.extensions",
"org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \
.config("spark.sql.catalog.local", "org.apache.iceberg.spark.SparkCatalog") \
.config("spark.sql.catalog.local.type", "hadoop") \
.config("spark.sql.catalog.local.warehouse", "/tmp/iceberg-warehouse") \
.getOrCreate()
# Tabel aanmaken
spark.sql("""
CREATE TABLE local.db.orders (
order_id BIGINT,
customer_id BIGINT,
amount DECIMAL(10,2),
order_date DATE
)
USING iceberg
PARTITIONED BY (months(order_date))
""")
# Data invoegen
spark.sql("""
INSERT INTO local.db.orders VALUES
(1, 101, 99.95, DATE '2026-03-01'),
(2, 102, 249.00, DATE '2026-03-15'),
(3, 101, 59.99, DATE '2026-03-20')
""")
# Query met time travel
spark.sql("SELECT * FROM local.db.orders.snapshots").show()
spark.sql("SELECT * FROM local.db.orders").show()
Iceberg op AWS: Glue + Athena
-- In AWS Glue Data Catalog / Athena:
-- Tabel aanmaken als Iceberg
CREATE TABLE orders (
order_id BIGINT,
customer_id BIGINT,
amount DOUBLE,
order_date DATE
)
LOCATION 's3://mijn-datalake/orders/'
TBLPROPERTIES (
'table_type' = 'ICEBERG',
'format' = 'parquet',
'write_compression' = 'snappy'
);
-- Data invoegen (geen S3 copy nodig!)
INSERT INTO orders VALUES (1, 101, 99.95, DATE '2026-03-21');
-- UPDATE (Athena engine v3 + Iceberg)
UPDATE orders
SET amount = 89.95
WHERE order_id = 1;
-- DELETE
DELETE FROM orders WHERE order_id = 1;
-- Time travel
SELECT * FROM orders
FOR SYSTEM_TIME AS OF TIMESTAMP '2026-03-20 12:00:00';
Migratie van Parquet naar Iceberg (in-place)
-- Bestaande Parquet tabel migreren naar Iceberg
-- ZONDER data te kopiëren (alleen metadata aanmaken)
-- In Spark:
from pyspark.sql import SparkSession
# Migreer bestaande Parquet tabel
spark.sql("""
CALL catalog.system.migrate(
'db.bestaande_parquet_tabel'
)
""")
-- Of via snapshot (veiliger: origineel blijft intact)
spark.sql("""
CALL catalog.system.snapshot(
source_table => 'parquet.db.orders',
table => 'iceberg.db.orders'
)
""")
-- Valideer de migratie
spark.sql("SELECT COUNT(*) FROM iceberg.db.orders").show()
spark.sql("SELECT * FROM iceberg.db.orders.snapshots").show()
Tabel Onderhoud: Compaction & Cleanup
-- Kleine bestanden samenvoegen (compaction)
CALL catalog.system.rewrite_data_files(
table => 'db.orders',
strategy => 'sort',
sort_order => 'order_date ASC'
);
-- Verouderde snapshots verwijderen (data cleanup)
CALL catalog.system.expire_snapshots(
table => 'db.orders',
older_than => TIMESTAMP '2026-03-01 00:00:00',
retain_last => 5
);
-- Verwijder ongebruikte metadata en orphan files
CALL catalog.system.remove_orphan_files(
table => 'db.orders',
older_than => TIMESTAMP '2026-03-01 00:00:00'
);
-- Bekijk tabel statistieken
SELECT * FROM db.orders.files LIMIT 20;
SELECT * FROM db.orders.partitions;
Iceberg Catalogs: Het Centrale Punt
Een catalog is hoe Iceberg bijhoudt welke tabellen bestaan en waar hun metadata staat. De keuze van catalog is cruciaal voor je architectuur:
| Catalog Type | Wanneer gebruiken | Voorbeelden | Governance |
|---|---|---|---|
| AWS Glue Catalog | AWS-omgevingen | Athena, EMR, Glue Jobs | Lake Formation |
| Hive Metastore | On-premise of migratie | Spark, Hive, Trino | Ranger / Kerberos |
| Nessie | Git-achtige data versioning | Dremio, Spark | Branch-gebaseerd |
| REST Catalog | Multi-cloud / vendor-neutraal | Tabular, Snowflake Open Catalog | API-gebaseerd |
| Unity Catalog | Databricks ecosysteem | Databricks, Delta/Iceberg via UniForm | Column-level |
Aanbeveling: REST Catalog als Toekomststrategie
De industrie beweegt richting een open REST Catalog API (de Apache Iceberg REST spec). Dit geeft maximale portabiliteit: wissel van query engine of cloud provider zonder je catalog te migreren. Snowflake Open Catalog (gebaseerd op Polaris) en Tabular zijn hier de koplopers.
Best Practices voor Productie
Partitioneringsstrategie
- Gebruik hidden partitioning: Iceberg voegt partition transforms toe (days, months, hours, bucket, truncate)
- Start conservatief: liever te grote dan te kleine partities
- Vermijd hoge-kardinaliteit kolommen als partition key
- Gebruik
bucket(N, id)voor evenly-distributed data
File Size Management
- Target bestandsgrootte: 128MB – 512MB per Parquet file
- Plan dagelijkse compaction jobs buiten piekuren
- Gebruik
rewrite_data_filesmet sort voor betere query performance - Monitor
db.tabel.filesvoor file count trends
Snapshot Retentie
- Bewaar snapshots minimaal 7 dagen voor herstelbare fouten
- Stel
history.expire.min-snapshots-to-keep = 5in - Automatiseer
expire_snapshotsenremove_orphan_files - Monitor S3-kosten: oude snapshots tellen mee
Query Performance
- Gebruik Z-ordering (sort order) op kolommen die je filtert
- Activeer bloom filter indexes voor hoge-kardinaliteit lookups
- Schrijf metadata toe via
write.metadata.metrics.column - Gebruik positional deletes boven equality deletes (snellere reads)
Conclusie: Wanneer Kies Je voor Apache Iceberg?
Perfect voor Iceberg als...
✅ Kiezen voor Iceberg
- Je gebruikt meerdere query engines (Spark + Trino + Athena)
- Je wil geen vendor lock-in (bijv. niet puur Databricks)
- Je zit op AWS en gebruikt Glue/Athena
- Je wil Snowflake en Spark op dezelfde data
- Je bouwt een nieuw platform vanaf nul
- Je hebt partition evolution nodig (groeiende data)
⚠️ Blijf bij Delta Lake als...
- Je volledig op Databricks zit en tevreden bent
- Je Delta Live Tables (DLT) gebruikt
- Je team al diep in het Delta-ecosysteem zit
- Je Unity Catalog met fine-grained access control nodig hebt
🚀 De Toekomst
- Databricks UniForm: Delta én Iceberg tegelijk
- Open REST Catalog: universele interoperabiliteit
- Apache XTable: automatisch format-bridging
- Alle grote vendors bewegen richting Iceberg-compatibiliteit
Apache Iceberg is niet langer een niche keuze — het is de veiligste long-term investering voor je data platform in 2026. De brede vendor-adoptie garandeert dat je altijd de beste tools kunt inzetten zonder opnieuw data te migreren.
Apache Iceberg Implementeren?
Zoek je een Data Engineer met Iceberg-ervaring, of wil je advies over de juiste open table strategy?