Apache Iceberg and table formats for data lakes

Nel binario ml-tabellare incontriamo ora il pezzo che tiene insieme storage e motori. Quando una tabella del lakehouse cresce, non basta più sapere dove sono i file. Servono metadata affidabili, schema evolution, partition evolution e time travel. I table format sono il contratto tra lo storage a oggetti e i query engine moderni: ti lasciano evolvere schema e partizioni senza rompere query, cataloghi e processi a valle.

L’idea centrale della lezione

Apache Iceberg è il formato tabellare che porta transazioni, viaggio nel tempo ed evoluzione di schema e partizioni sui file del data lake. È il punto in cui un insieme di file diventa una vera tabella con una vita propria.

La strada, in sei passi

1. Scegli la tabella con schema instabile o partizioni destinate a cambiare.
2. Crea la tabella Iceberg sul lake e registra metadata, schema e partizionamento nel catalogo.
3. Fai evolvere una colonna o una partizione senza riscrivere i dati e verifica che le query esistenti funzionino.
4. Leggi uno snapshot passato per provare il time travel su un caso reale.
5. Pianifica compattazione e pulizia degli snapshot obsoleti con una cadenza scritta.
6. Confronta prima e dopo su latenza, costo di scansione e numero di file piccoli.

Cosa fa Iceberg, concretamente

Iceberg porta sul lake quattro proprietà che prima richiedevano un warehouse. Le transazioni ACID rendono atomici INSERT, UPDATE e DELETE su file Parquet via snapshot isolation, così non corrompi mai i dati. Il time travel ti lascia leggere la tabella com’era in un istante passato. La schema evolution permette di aggiungere, rinominare o riordinare colonne senza riscrivere i dati. L’hidden partitioning evita di specificare la partizione nella clausola di filtro, perché Iceberg sa come sono partizionati i dati e applica il filtro da solo. Infine, compaction e garbage collection compattano i file piccoli in background e cancellano gli snapshot obsoleti.

Iceberg, Delta Lake e Hudi a confronto

Tre formati, tre storie diverse, e una scelta che dipende dall’ecosistema in cui lavori. La tabella qui sotto è la sintesi che serve in una discussione di architettura:

	Iceberg	Delta Lake	Hudi
Creator	Netflix → Apache	Databricks	Uber → Apache
Ecosystem	Multi-engine (Spark, Trino, Flink, Presto)	Strong on Spark/Databricks	Strong on Spark
Time travel	Yes	Yes	Yes
Maturity	High, adopted by Netflix, Apple, Airbnb	Very high, adopted by Databricks clients	High, adopted by Uber, Amazon
When to Use	Multi-tool, cloud-agnostic environments	On Databricks	Pipelines with frequent upserts

Per un’azienda che non è su Databricks, Iceberg è la scelta più flessibile, perché funziona con Athena, Trino, Spark, Flink e Snowflake. Verdetto: su Databricks usa Delta Lake, per upsert continui valuta Hudi, in tutti gli altri casi multi-motore usa Iceberg.

References:

• Iceberg. (2024). “Apache Iceberg Documentation.” iceberg.apache.org.
• Netflix. (2021). “Iceberg at Netflix.” Netflix Tech Blog.

Gli errori tipici di chi inizia

Il primo errore è scegliere il table format per moda invece che per ecosistema: adottare Delta in un contesto multi-motore crea un lock-in che paghi caro più avanti. Il secondo è evolvere schema e partizioni senza avvisare i consumatori a valle, perché le query esistenti possono rompersi anche se il formato lo permette. Il terzo è dimenticare manutenzione di compattazione e pulizia snapshot: senza una cadenza scritta il lake si frammenta in file piccoli e le query rallentano.

La storia che spiega tutto: Netflix e il 2018

Netflix gestisce tabelle di eventi su S3 lette da più motori e incontra i limiti dei file semplici quando schema e layout delle partizioni cambiano. Nel 2018 rende pubblico Iceberg, con metadata transazionali, evoluzione di schema e partizionamento nascosto che applica i filtri senza riscrivere le query. Il progetto entra poi in Apache e viene adottato da altri operatori su larga scala. Da allora la regola è stabile: fuori dall’ecosistema Databricks, Iceberg è il formato più portabile tra i motori.

Domande per ripassare

1. Quale limite dei file semplici rende necessario un formato con metadata transazionali?
2. Quando l’evoluzione delle partizioni evita la riscrittura manuale del lake?
3. Quale caratteristica di Iceberg mantiene la tabella leggibile da Spark, Trino e Flink senza duplicarla?
4. Quando il time travel sostituisce la ricostruzione di uno snapshot passato?