Delta Lake: ACID su data lake

Nel binario ml-tabellare il nostro lavoro è trasformare file sparsi in tabelle di cui fidarsi. Un data lake di soli file Parquet fatica a gestire update, rollback, concorrenza e correzioni storiche. Delta Lake aggiunge un transaction log, il versioning e garanzie ACID che trasformano file distribuiti in tabelle affidabili: serve quando devi correggere dati, garantire letture coerenti e ricostruire versioni passate senza interventi manuali rischiosi.

Di cosa stiamo parlando

Delta Lake aggiunge ai file Parquet del lake un registro transazionale con garanzie ACID, viaggio nel tempo e controllo dello schema. In pratica trasforma una cartella di file in una tabella con le stesse promesse di un database.

Il percorso di lavoro, in sei passi

1. Identifica le tabelle con correzioni tardive, cancellazioni o scritture concorrenti.
2. Converti la tabella in formato Delta e verifica letture coerenti durante le scritture.
3. Implementa gli upsert con merge su chiave e controlla duplicati e righe perse.
4. Configura il controllo dello schema decidendo quando far fallire le scritture impreviste.
5. Pianifica compaction periodica con OPTIMIZE e Z-ordering sulle chiavi di filtro reali.
6. Prova time travel e rollback su una versione nota prima di dichiarare pronta la tabella.

Delta contro Iceberg: la domanda che sentirete sempre

La domanda pratica più frequente è quale dei due table format adottare. La differenza principale è l’ecosistema: Delta nasce dentro Databricks e Spark, Iceberg è pensato per più motori. La tabella di confronto riassume i punti che contano davvero:

	Delta Lake	Iceberg
Creatore	Databricks	Netflix → Apache
Ecosistema primario	Spark, Databricks	Multi-engine (Trino, Presto, Flink, Spark)
Compaction	OPTIMIZE command	Manuale o via tool esterni
Z-ordering	Sì (multi-dimensionale)	No nativo
Change Data Feed	Sì	Sì (via snapshot diffs)

Se lavori in Databricks, Delta Lake è la scelta naturale. Se sei multi-cloud o multi-engine, Iceberg è più portabile. Verdetto: su Databricks usa Delta Lake, in ambienti multi-motore o multi-cloud usa Iceberg.

Le tre operazioni che fanno il lavoro quotidiano

Tre operazioni coprono la maggior parte del lavoro quotidiano: l’upsert via merge, il time travel per leggere uno stato passato e l’OPTIMIZE con Z-ordering per tenere i file compatti e veloci da scansionare. Ecco come si scrivono:

# Scrittura con merge (upsert)
from delta.tables import DeltaTable
delta_table = DeltaTable.forPath(spark, "s3://lake/orders")
delta_table.alias("t").merge(
    new_orders.alias("s"), "t.order_id = s.order_id"
).whenMatchedUpdateAll().whenNotMatchedInsertAll().execute()

# Time travel: leggi tabella com'era 7 giorni fa
df = spark.read.format("delta").option("versionAsOf", 7).load("s3://lake/orders")

# Compaction e Z-ordering
spark.sql("OPTIMIZE orders ZORDER BY (customer_id, order_date)")

Schema evolution: lasciare cambiare o bloccare?

Delta Lake gestisce sia l’evoluzione automatica dello schema, per esempio l’aggiunta di colonne, sia lo schema enforcement, che blocca le scritture con colonne non previste. Il comportamento si configura con mergeSchema: lascialo attivo quando una sorgente legittima cambia spesso, tienilo spento quando vuoi che uno schema imprevisto fallisca subito invece di corrompere silenziosamente la tabella.

Gli errori che si ripetono

Il primo errore è adottare Delta per moda quando il contesto è multi-engine: in quel caso Iceberg evita un lock-in che pagheresti caro più avanti. Il secondo è disattivare lo schema enforcement per comodità, lasciando che scritture impreviste corrompano la tabella senza che nessuno se ne accorga. Il terzo è dimenticare la compaction: senza OPTIMIZE periodico la tabella si frammenta in tanti piccoli file e le query rallentano.

Il caso che ha detto la parola “lakehouse”: Databricks, 2019

Databricks nasce nel 2013 dai creatori di Apache Spark a Berkeley e porta Spark in produzione come piattaforma gestita. Nel 2019 rende Delta Lake open source e lo affida alla Linux Foundation: un registro transazionale sopra i file Parquet con atomicità, viaggio nel tempo e controllo dello schema. La mossa risponde a un dolore misurato sul campo, con pipeline che riscrivono intere partizioni per correggere poche righe e letture concorrenti che vedono tabelle a metà. Il fatto che nello stesso periodo anche Iceberg di Netflix del 2018 spinga nella stessa direzione conferma una sola cosa: il lakehouse nasce quando il formato dei file smette di essere un dettaglio.

Domande per fissare i concetti

1. Quale operazione di correzione diventa sicura con il merge su chiave invece della riscrittura manuale?
2. Quando il time travel su una versione sostituisce la ricostruzione di uno stato passato?
3. Quale impostazione del controllo dello schema fa fallire subito una scrittura imprevista?
4. Quando la mancanza di compaction periodica segnala che la tabella si sta frammentando?