Narcis Miclaus

10 min di lettura

Architettura di dati e sistemi, dalle fondamenta Lezione 37 / 80

Lakehouse: Delta, Iceberg, Hudi

Transazioni ACID su object storage. Le format wars del 2023-2025 e dove l'industria si è assestata nel 2026.

La lezione precedente ha descritto come si organizzano i dati dentro un lake (bronze, silver, gold). Questa lezione parla invece di cosa è fatto davvero il lake nel 2026. Nello specifico: che file format usano quelle tabelle, e perché usiamo qualcosa di diverso dal semplice Parquet su object storage?

La risposta breve sono i lakehouse table format: Delta Lake, Apache Iceberg e Apache Hudi. Sono il layer che trasforma una cartella di file Parquet su S3 in qualcosa che si comporta come una tabella di database, con transazioni ACID, schema evolution, time travel, e letture e scritture concorrenti. Sono la tecnologia che ha fatto smettere alla parola “lakehouse” di essere un termine di marketing e ha iniziato a renderla un vero pattern architetturale.

I tre format hanno passato gli anni tra il 2019 e il 2025 in una mischia competitiva, con ogni vendor che ne spingeva uno come il futuro. Nel 2026 la polvere si è in gran parte depositata, e questa lezione racconta cos’è ognuno di loro, cosa hanno in comune, e che aspetto ha il quadro nel 2026 per chi oggi deve sceglierne uno.

Perché il semplice Parquet su S3 non basta

Parquet è un file format colonnare. È veloce, compresso, e ben supportato da ogni motore analitico. L’istinto, quando costruisci per la prima volta un data lake, è di scrivere file Parquet su S3 e rileggerli con Spark o Trino o DuckDB. Per un workload single-writer e append-only funziona benissimo.

I problemi iniziano nel momento in cui hai più di un writer, o un qualsiasi update che non sia un append pulito.

  • Niente transazioni. Se due job scrivono sulla stessa partizione nello stesso momento, si sovrascrivono i file a vicenda. Non esiste un’operazione atomica del tipo “aggiungi questi nuovi file e rimuovi quei vecchi”.
  • Niente partition replace atomico. Il pattern “overwrite di questa partizione” (lezione 38) richiede di cancellare i vecchi file e scriverne di nuovi. Se un reader interroga durante la finestra tra la cancellazione e la scrittura, vede una vista parziale dei dati, o nessun dato.
  • Niente delete a livello di riga. Il GDPR ti chiede di cancellare i record di un utente specifico. Con Parquet grezzo devi trovare ogni file che contiene quelle righe, riscriverlo senza le righe cancellate, e fare lo swap. Non c’è alcun meccanismo built-in per niente di tutto questo.
  • Niente schema evolution. Aggiungere una colonna significa riscrivere ogni file della tabella, oppure accettare un casino di schema-on-read in cui alcuni file hanno la colonna e altri no.
  • Niente time travel. “Mostrami la tabella com’era martedì scorso” è una domanda alla quale Parquet grezzo non sa rispondere, a meno che tu non abbia tenuto degli snapshot per conto tuo.
  • Niente statistiche che si aggiornano. Ogni file Parquet ha le sue statistiche, ma non c’è un layer di metadati a livello di tabella che il query engine possa usare per saltare i file in modo pulito.

I lakehouse table format sono il layer che sistema tutto questo. Stanno sopra ai file Parquet (i dati veri sono ancora Parquet), e aggiungono un layer di metadati che registra quali file appartengono alla tabella in quale momento. Le letture consultano i metadati per sapere quali file scansionare. Le scritture aggiornano i metadati in modo atomico. Due writer non si corrompono a vicenda; si mettono in coda al layer di metadati e si serializzano.

L’idea è tutta qui. Le differenze tra Delta, Iceberg e Hudi riguardano come è strutturato il layer di metadati e quali feature espone.

Delta Lake

Delta Lake è stato rilasciato in open source da Databricks nel 2019. Il layer di metadati è un transaction log: una directory di file JSON (con checkpoint Parquet periodici) che registra ogni commit alla tabella. Ogni commit è un’operazione atomica che aggiunge e rimuove file. I reader consultano il log per calcolare l’insieme corrente dei file; i writer fanno append al log per applicare i cambiamenti.

I punti di forza di Delta:

  • Integrazione stretta con Spark. Delta è stato progettato insieme a Spark Structured Streaming, e il percorso da streaming a Delta è il più rifinito dei tre format. Se la tua ingestion è “Kafka in una bronze table via Structured Streaming”, Delta è la strada più semplice.
  • Sintassi MERGE. MERGE INTO ... USING ... ON ... è stata la prima a uscire in Delta ed è ancora l’implementazione più ergonomica. Gli upsert in stile CDC sono first-class.
  • Vacuum e Z-ORDER. Delta ha implementazioni solide di file compaction (OPTIMIZE) e di clustering multidimensionale (ZORDER BY). Per workload Spark, la storia della maintenance è buona.
  • Sostenuto da Databricks. La piattaforma su cui hai più probabilità di girare Delta ha l’integrazione più profonda possibile. Su Databricks “usa Delta” è il percorso di minor resistenza ed è quasi sempre la risposta giusta.

La debolezza storica di Delta era che la versione open source era in ritardo rispetto a quella Databricks, e il supporto dei motori al di fuori di Spark era più sottile rispetto a Iceberg. Entrambi sono migliorati nel 2024 e 2025: la versione open source è più vicina alla parità di feature, e Delta UniForm è un layer di compatibilità che espone le tabelle Delta come leggibili in formato Iceberg, chiudendo in parte il gap cross-engine.

Apache Iceberg

Apache Iceberg è uscito da Netflix nel 2018 ed è stato donato alla Apache Foundation. È stato progettato fin dall’inizio per l’indipendenza dal query engine. Il layer di metadati è più elaborato di quello di Delta: un albero di file di metadati (table metadata, manifest list, manifest) che registra gli snapshot della tabella, gli schemi, le partition spec, e le liste dei file. La struttura è più verbosa del log di Delta, e quella verbosità è il prezzo del supportare in modo pulito una gamma più ampia di operazioni.

I punti di forza di Iceberg:

  • Neutralità rispetto al motore. Iceberg è cittadino di prima classe in Spark, Trino, Flink, Presto, Dremio, Snowflake (dal 2024), BigQuery, AWS Glue e Athena, e DuckDB. Se vuoi leggere la stessa tabella da più motori, Iceberg ha di gran lunga la storia migliore.
  • Partizionamento nascosto. Iceberg ti permette di dichiarare il partizionamento come trasformazioni sulle colonne (days(event_time), bucket(16, user_id)) senza esporle nello schema visibile all’utente. Le query non hanno bisogno di sapere delle colonne di partizione; il motore fa push-down dei filtri attraverso le trasformazioni in automatico. Questa è una delle vittorie ergonomiche più grandi rispetto a Delta.
  • Schema e partition evolution. Iceberg può evolvere la partition spec senza riscrivere i dati vecchi. I file vecchi mantengono il loro vecchio layout, i file nuovi usano il nuovo, e le letture funzionano attraverso il confine. Delta non può fare questa cosa senza riscrivere.
  • Storia di governance forte. L’ecosistema dei catalog (Nessie, Polaris, l’AWS Glue catalog, il supporto Iceberg di Unity Catalog) è maturato attorno a Iceberg. La governance multi-engine è il punto in cui Iceberg è davvero in testa.

La debolezza storica di Iceberg era che la storia delle scritture in streaming era in ritardo rispetto a Delta, e la gestione dei file piccoli richiedeva più cura manuale. Entrambe sono migliorate.

Apache Hudi

Apache Hudi è uscito da Uber nel 2017, il più vecchio dei tre. Il suo centro di design sono gli upsert e l’incremental processing. Hudi è il format costruito attorno a “ho uno stream CDC da un database e voglio una tabella interrogabile che lo specchi, con gli update applicati riga per riga”.

I punti di forza di Hudi:

  • Upsert prima di tutto. Hudi ha due tipi di tabella, Copy-on-Write e Merge-on-Read. Merge-on-Read mantiene un file base più un log di update a livello di riga, con compaction periodica. Per workload con frequenza alta di update sui singoli record (mirror CDC, slowly-changing dimension), questo è più efficiente che riscrivere file interi.
  • Query incrementali. Hudi ha supporto first-class per “dammi le righe che sono cambiate dal timestamp T”, che è la primitiva naturale per le pipeline a valle che vogliono consumare solo i delta.
  • Strumenti di ingestion in streaming. Lo Hudi Streamer (prima DeltaStreamer) è uno strumento di ingestion in streaming pacchettizzato per le sorgenti comuni (Kafka, JDBC CDC), con deduplicazione e semantica di upsert built-in.

La debolezza di Hudi, nel 2026, è che i casi d’uso in cui brilla sono anche quelli in cui Iceberg ha recuperato in modo sostanziale, e fuori da quei casi il supporto dell’ecosistema più ampio è più sottile. Hudi è la scelta giusta per workload streaming-upsert pesanti, soprattutto quando sai già che quel pattern domina. Raramente è la scelta giusta come default general-purpose.

Cosa hanno in comune

Per la decisione architetturale ad alto livello, i tre format si somigliano più di quanto differiscono. Tutti e tre ti danno:

  • Transazioni ACID su object storage. Le scritture concorrenti vengono serializzate attraverso il layer di metadati. I reader vedono uno snapshot consistente.
  • Schema evolution. Aggiungi una colonna. Rinomina una colonna. Cambia il tipo di una colonna dentro famiglie compatibili. Il layer di metadati tiene traccia della storia.
  • Time travel. Interroga la tabella com’era al timestamp T o alla versione V. I metadati conservano gli snapshot vecchi finché non vengono fatti scadere esplicitamente.
  • Semantica MERGE / upsert. Inserisci nuove righe, aggiorna righe esistenti, cancella righe matchate, tutto atomicamente.
  • Letture e scritture concorrenti. Le query a lunga durata vedono uno snapshot stabile mentre le scritture procedono.
  • Delete a livello di riga. GDPR-friendly. Lancia un DELETE FROM table WHERE user_id = ? e il format si occupa delle riscritture dei file.

Se stai scegliendo tra di loro e una qualunque di queste feature fa pendere la bilancia, probabilmente hai letto male la situazione. Le feature sono ormai tavolo di gioco per tutti e tre i format. La decisione si gioca sull’adattamento all’ecosistema, non sulla capability.

Le format wars e dove si sono assestate

Tra il 2022 e il 2025 ogni vendor con un interesse nel lakehouse ha spinto il suo format preferito. Databricks ha spinto Delta. Snowflake, AWS e Confluent hanno spinto Iceberg. Onehouse ha spinto Hudi. I clienti hanno fatto proof of concept su tutti e tre, scritto think-piece, e si sono chiesti se il format sarebbe esistito ancora tra cinque anni.

Nel 2026 il quadro si è chiarito, perlopiù a favore di Iceberg. Le mosse decisive sono state l’integrazione profonda di Iceberg in Snowflake nel 2024 (ora puoi leggere e scrivere tabelle Iceberg direttamente da Snowflake), AWS Glue e Athena che hanno reso Iceberg il format default-friendly, e BigQuery che ha esposto Iceberg come tipo di external table pienamente supportato. La combinazione ha fatto sì che una tabella Iceberg potesse essere interrogata da Spark, Snowflake, BigQuery, Trino, e dagli strumenti AWS-native senza che nessuno dovesse riscrivere i dati. Quella storia cross-engine è proprio la cosa che la gente del lake voleva nel 2018, e Iceberg è il format che l’ha consegnata.

Databricks ha risposto con Delta UniForm, che scrive le tabelle Delta in un modo che le espone come leggibili come Iceberg agli altri motori. La scommessa è che “Delta su Databricks, leggibile come Iceberg dall’esterno” basti per il caso d’uso cross-engine senza abbandonare le feature first-party di Delta. A partire dal 2026 funziona abbastanza bene per la maggior parte degli scenari di lettura, meno bene per le scritture, e la traiettoria è positiva.

Hudi resta la scelta migliore per il workload streaming-upsert per cui è stato costruito, e un ecosistema più piccolo per il resto.

flowchart LR
    K[Kafka, CDC, files] --> I[Bronze: Iceberg or Delta]
    I --> SP[Spark transforms]
    SP --> S[Silver: Iceberg or Delta]
    S --> DBT[dbt models]
    DBT --> G[Gold: Iceberg or Delta]
    G --> Q1[Spark]
    G --> Q2[Trino]
    G --> Q3[Snowflake]
    G --> Q4[BigQuery]
    G --> Q5[DuckDB]

Dove si colloca ognuno nel 2026

Una guida pratica per il 2026:

  • Sei su Databricks. Usa Delta. L’integrazione è eccellente, ogni feature di Databricks assume Delta, e UniForm ti dà la leggibilità esterna in stile Iceberg quando ti serve.
  • Stai partendo con un nuovo lakehouse, multi-engine o vendor-neutral. Usa Iceberg. È il default più sicuro, il supporto motore più ampio, e la migliore storia di governance a lungo termine. La scelta “default dei default”.
  • Il tuo workload dominante sono mirror CDC ad alta frequenza con tanti upsert. Guarda bene Hudi. Fai un benchmark sul tuo workload reale prima di impegnarti.
  • Hai già Delta o Iceberg che funziona. Non cambiare per il gusto di stare sul format “vincente”. Le migrazioni sono lavoro vero di engineering e le differenze non sono abbastanza grandi da giustificarle a meno che una feature specifica non ti stia bloccando.

Il corso di PySpark, nel modulo 8, ha una lezione hands-on che attraversa Delta, Iceberg e Hudi con il codice: setup delle tabelle, esecuzione di MERGE, time travel, confronto dei layout dei metadati. Se vuoi lavorare con i format invece che limitarti a sceglierne uno, quella lezione è la prossima tappa dopo questa.

La prossima lezione parla di una proprietà che tutti e tre i format rendono più facile che mai: rendere idempotenti i job batch.

Cerca