Formati di tabella aperti spiegati: Iceberg vs. Delta vs. Hudi

I formati di tabella aperti sono livelli di metadati che si sovrappongono ai file di dati nell'object storage, aggiungendo transazioni ACID, evoluzione dello schema e time travel ai dati archiviati in un data lake. Apache Iceberg, Delta Lake e Apache Hudi sono i tre principali formati di tabella aperti attualmente utilizzati in produzione, e ciascuno trasforma una raccolta di file Parquet o ORC in una tabella che si comporta come un database: i lettori vedono risultati coerenti, gli scrittori possono aggiornare ed eliminare righe in modo sicuro e ogni modifica viene tracciata in modo che le versioni precedenti rimangano interrogabili.

Questa panoramica spiega come funzionano i principali formati di tabella aperti, come si confrontano sul supporto delle transazioni ACID e sull'evoluzione dello schema, e come si collegano all'architettura data lakehouse, attingendo a innovazioni a livello di storage come le transazioni coordinate dal catalogo, la lineage a livello di riga e i metadati unificati per mostrare dove Delta Lake e Apache Iceberg stanno convergendo.

Cos'è un data lake e perché i formati di tabella aperti sono importanti?

Un data lake è un repository centralizzato basato su object storage a basso costo — Amazon S3, Azure Data Lake Storage o Google Cloud Storage — che conserva dati strutturati, semistrutturati e non strutturati in forma grezza e nativa. Le organizzazioni hanno adottato i data lake perché l'object storage offre una scalabilità economica e separa lo storage dal compute, consentendo a qualsiasi motore di query di leggere gli stessi dati. Tuttavia, l'object storage non è mai stato progettato per garantire la coerenza: non ha un concetto nativo di tabella, schema o transazione.

Un data lakehouse sovrappone una struttura simile a una tabella, la governance e le prestazioni a quell'archiviazione grezza, unendo il basso costo di un data lake con l'affidabilità di un data warehouse. Il ponte tra i due è il formato di tabella aperto: trasforma i file sparsi nell'object storage in tabelle governate e interrogabili senza copiare i dati in un data warehouse proprietario.

Prima dell'esistenza dei formati di tabella aperti, l'esecuzione di analisi sui data lake tradizionali causava continui problemi: gli scrittori simultanei potevano corrompere i dati a metà scrittura, gli aggiornamenti e le eliminazioni richiedevano la riscrittura di intere partizioni e non c'era un modo affidabile per sapere quali file rappresentassero lo stato corrente e corretto di una tabella. I formati di tabella aperti gestiscono i metadati per i file di dati nell'object storage, tracciando esattamente quali file appartengono a una tabella: questa standardizzazione ha permesso ai data lake di supportare finalmente funzionalità simili a quelle dei database, come gli aggiornamenti a livello di record.

I formati di tabella e i formati di file aperti che devi conoscere

Apache Iceberg

Apache Iceberg, originariamente sviluppato da Netflix e ora progetto della Apache Software Foundation, è stato progettato per rendere le tabelle enormi e a lenta variazione rapide da interrogare e sicure da far evolvere. Apache Iceberg utilizza una struttura ad albero per una gestione efficiente dei metadati: i file manifest e le manifest list tracciano ogni file di dati in una tabella, consentendo ai motori di query di escludere i dati non rilevanti prima dell'inizio di una scansione. Le tabelle Iceberg supportano l'evoluzione dello schema e l'evoluzione delle partizioni senza riscrivere i file sottostanti.

Delta Lake

Delta Lake, creato da Databricks e rilasciato come open source, ha introdotto le transazioni ACID nei carichi di lavoro Apache Spark attraverso un registro delle transazioni write-ahead. Delta Lake ha avuto origine presso Databricks e si integra nativamente con Spark, anche se ora supporta un'ampia gamma di motori tramite connettori indipendenti. Le tabelle Delta Lake registrano ogni scrittura come una voce di registro ordinata e atomica, offrendo ai lettori una vista coerente anche mentre vengono scritti nuovi dati.

Apache Hudi

Apache Hudi, acronimo di Hadoop Upserts Deletes and Incrementals, è progettato per aggiornamenti rapidi e frequenti a livello di record. Apache Hudi si ottimizza per aggiornamenti frequenti e dati in streaming mantenendo indici che individuano l'esatto file contenente un determinato record, consentendo aggiornamenti efficienti a livello di record senza una scansione completa della tabella.

Parquet e ORC

Parquet e ORC sono formati di file colonnari, non formati di tabella: definiscono come sono organizzati i singoli file di dati, non come i file diventano una tabella governata. Iceberg, Delta Lake e Hudi sono tutti basati su file Parquet — Iceberg e Hudi supportano anche ORC — utilizzando le statistiche a livello di file memorizzate da Parquet per escludere i dati prima che un motore di query li legga. Questa distinzione, formato di file rispetto a formato di tabella, chiarisce la maggior parte dei dubbi aziendali su dove inizino le responsabilità di ciascun livello.

Iceberg vs Delta Lake vs Hudi: un rapido confronto

I tre principali formati di tabella aperti ora condividono più funzionalità di quante ne differiscano, ma la tabella seguente evidenzia dove la storia del design si fa ancora sentire.

Dentro Apache Iceberg: tabelle e metadati

L'albero dei metadati di Iceberg

Una tabella Iceberg è definita da un albero dei metadati, non da un singolo file: un file di metadati punta a una manifest list, che a sua volta punta a file manifest che elencano i file di dati effettivi che compongono uno snapshot. Questa struttura a livelli consente a un motore di query di escludere i manifest e i file di dati non rilevanti utilizzando le statistiche memorizzate sulle colonne senza aprire un singolo file, migliorando le prestazioni delle query su tabelle con milioni di file.

Snapshot e time travel

Ogni scrittura su una tabella Iceberg crea un nuovo snapshot — un record immutabile di quali file di dati esistevano in quel momento — e l'albero dei metadati conserva una cronologia degli snapshot precedenti. Ciò consente il time travel: i motori possono interrogare una tabella così com'era in uno specifico ID snapshot o timestamp, supportando l'auditing, set di addestramento ML riproducibili e il rollback all'ultimo stato stabile dopo una scrittura errata.

Evoluzione delle partizioni

Iceberg disaccoppia il partizionamento fisico di una tabella dai suoi pattern di query attraverso l'evoluzione delle partizioni, consentendo ai team di modificare il modo in cui i nuovi dati vengono partizionati senza riscrivere i file esistenti o interrompere le query sul vecchio schema. Il partizionamento nascosto (hidden partitioning) significa che gli analisti non devono fare riferimento direttamente alle colonne di partizione fisica per ottenere l'esclusione delle partizioni.

Funzionamento interno e manutenzione delle tabelle Iceberg

Poiché ogni scrittura produce un nuovo snapshot con la propria manifest list, una tabella Iceberg scritta attivamente può accumulare migliaia di piccoli file manifest e di dati se non viene gestita. I motori di query devono comunque aprire e valutare ogni file manifest pertinente, quindi la proliferazione dei manifest riduce i vantaggi in termini di prestazioni delle query per cui l'albero dei metadati è stato creato.

Il rimedio standard è la compattazione pianificata: un processo di manutenzione che riscrive piccoli file di dati in un numero inferiore di file più grandi e consolida i manifest, eseguito ogni notte o ogni ora a seconda del volume di ingestione. L'associazione della compattazione con la scadenza regolare degli snapshot — rimuovendo i metadati oltre una finestra di conservazione — mantiene sotto controllo le dimensioni dello storage e dei metadati senza limitare quanto indietro possa arrivare il time travel.

Delta Lake e le transazioni ACID

Il registro delle transazioni di Delta Lake

Le tabelle Delta Lake memorizzano un registro delle transazioni ordinato e di tipo append-only — una sequenza di voci JSON che registrano ogni aggiunta, rimozione e modifica dei metadati — insieme a file di checkpoint periodici che riassumono il registro per letture più rapide. Storicamente, il file system stesso fungeva da coordinatore dei commit, il che significa che qualsiasi client con accesso a livello di file poteva scrivere direttamente in una tabella Delta, senza passare attraverso un catalogo di governance.

Come si comportano le transazioni ACID in Delta Lake

Le transazioni ACID garantiscono la coerenza dei dati durante le scritture simultanee richiedendo a ogni scrittore di verificare la versione corrente del registro, generare una nuova voce e farne il commit solo se nel frattempo non si è verificata alcuna modifica in conflitto; se viene rilevato un conflitto, lo scrittore riprova. La conformità ACID previene la corruzione dei dati perché un lettore non vede mai una tabella Delta Lake in uno stato parzialmente scritto, e le transazioni ACID consentono operazioni sui dati complesse senza conflitti tra partizioni sovrapposte.

Dal supporto nativo per Spark al supporto multi-motore

Poiché il modello di commit originale di Delta Lake dipendeva dall'accesso al file system, i motori di terze parti esterni ad Apache Spark dovevano raggiungere le tabelle tramite percorsi di file statici anziché attraverso un catalogo di governance, lasciando tali accessi non governati e in grado di interrompere silenziosamente le relazioni dello schema. Databricks ha affrontato questo problema con i commit del catalogo, uno standard aperto che consente a un catalogo come Unity Catalog di fungere da coordinatore dei commit, in modo che ogni richiesta di lettura, scrittura e individuazione sia autorizzata centralmente. I commit del catalogo sono ora generalmente disponibili, allineando Delta Lake all'approccio orientato al catalogo che Iceberg utilizza fin dall'inizio e sbloccando le transazioni multi-tabella.

Fondamenti dei formati di file: come Parquet consente il data skipping

Un file Parquet organizza i dati tabulari per colonna anziché per riga, raggruppando i valori della stessa colonna in blocchi contigui chiamati row group. L'archiviazione colonnare consente a un motore di query di leggere solo le colonne a cui fa riferimento una query, saltando il resto: uno dei motivi principali per cui Parquet supera i formati orientati alle righe per i carichi di lavoro ad alta intensità di scansione.

Ogni row group contiene statistiche (valori minimi e massimi, conteggi dei valori null e distribuzioni dei valori per colonna) scritte nel footer dei metadati del file. Queste statistiche consentono a un motore di determinare, senza decomprimere alcun dato, se un row group possa corrispondere al filtro di una query.

I formati di tabella aperti estendono questo principio a un livello superiore: i file manifest di Iceberg e il registro delle transazioni di Delta Lake memorizzano nella cache le statistiche a livello di Parquet nel livello dei metadati, in modo che un motore possa saltare interi file di dati prima di elencarli dallo storage a oggetti. Questo data skipping a due livelli contribuisce in modo significativo a migliorare le prestazioni delle query su tabelle di grandi dimensioni. Databricks ha inoltre esteso il modello con il tipo di dati Variant (ora parte di Parquet, Delta Lake e Iceberg), che memorizza payload semistrutturati in formato binario tipizzato anziché in JSON non elaborato, consentendo ai motori di estrarre i campi nidificati senza costose operazioni di parsing.

Controllo delle versioni dei dati, Time Travel ed elaborazione incrementale

Il controllo delle versioni dei dati è la capacità di un formato di tabella aperto di conservare un record di ogni stato precedente della tabella anziché sovrascrivere i dati in loco, e il time travel legge una qualsiasi di queste versioni precedenti tramite numero di versione, ID snapshot o timestamp. I formati di tabella aperti consentono il time travel e il controllo delle versioni dei dataset fin dalla progettazione, poiché ogni scrittura crea già un nuovo snapshot o una voce di registro indirizzabile in modo indipendente.

L'elaborazione incrementale legge solo le righe modificate dall'ultima elaborazione della tabella anziché eseguire nuovamente la scansione di un intero dataset: il pattern alla base del Change Data Capture (CDC), in cui le pipeline consumano solo gli inserimenti, gli aggiornamenti e le eliminazioni applicati a una tabella di origine. La row lineage e i vettori di eliminazione (deletion vectors), introdotti in Delta Lake e portati in Iceberg tramite Iceberg v3, hanno reso questo processo più economico: la row lineage tiene traccia di quali righe sono cambiate dall'ultima scansione di una tabella, e i vettori di eliminazione rappresentano le righe eliminate come una bitmap compatta invece di riscrivere i file di dati.

Conservare ogni versione storica a tempo indeterminato è costoso, quindi i formati di tabella aperti associano il controllo delle versioni a criteri di conservazione e a un'operazione di vacuum o di scadenza degli snapshot che rimuove i dati a cui non si fa più riferimento all'interno della finestra di conservazione. L'esecuzione di vacuum in modo troppo aggressivo può interrompere le query di time travel che fanno ancora riferimento a versioni precedenti, quindi le finestre sono impostate per corrispondere alla query con il tempo di esecuzione più lungo che potrebbe averne bisogno.

Una cadenza ragionevole per le tabelle di produzione associa l'elaborazione incrementale a intervalli corrispondenti all'ingestione (spesso ogni 5-15 minuti per l'ingestione dei dati in streaming) con l'esecuzione giornaliera di vacuum e della scadenza degli snapshot, al di fuori delle ore di picco delle query.

Gestione dei metadati e ottimizzazione delle prestazioni

I formati di tabella aperti migliorano le prestazioni delle query attraverso una gestione dei metadati organizzata in livelli: i file manifest o le voci di registro descrivono i singoli file di dati, gli snapshot o le versioni di registro descrivono lo stato della tabella in un determinato momento e un catalogo tiene traccia di quale versione sia attualmente autorevole. Unity Catalog gestisce oggi oltre 17 exabyte di dati in formati di tabella aperti nelle distribuzioni aziendali: questo dà un'idea di quanti metadati gestisca attualmente un moderno catalogo lakehouse.

Man mano che le tabelle crescono, i file manifest e i checkpoint del registro delle transazioni possono rallentare la pianificazione delle query, quindi la manutenzione dovrebbe includere la riscrittura dei manifest in un numero inferiore di file di dimensioni maggiori e la sintonizzazione degli intervalli di checkpoint in base alla frequenza di scrittura. Databricks e la community open source stanno sviluppando una struttura di metadati unificata tra Delta Lake e Iceberg, prevista in anteprima nel terzo trimestre, che combina il registro di scrittura rapida di Delta Lake con l'albero dei manifest a lettura rapida di Iceberg.

La memorizzazione nella cache dei metadati (ovvero il mantenimento in memoria di manifest, checkpoint o risposte del catalogo a cui si è effettuato l'accesso di recente) riduce la latenza delle query ripetute evitando una scansione completa dell'albero dei metadati a ogni richiesta, il che è particolarmente importante per i carichi di lavoro BI che inviano molte piccole query alle stesse tabelle di grandi dimensioni.

Transazioni ACID e controllo della concorrenza

Apache Iceberg, Delta Lake e Apache Hudi garantiscono tutti l'isolamento serializzabile o snapshot per le scritture su singola tabella, in modo che i lettori simultanei vedano sempre una versione completa e coerente e mai una scrittura parziale. Ciò in cui differiscono è il coordinamento: Iceberg ha sempre utilizzato il catalogo come unica fonte di verità, Hudi utilizza il proprio servizio di timeline e Delta Lake si affidava all'atomicità del file system prima che i commit del catalogo lo allineassero al modello coordinato dal catalogo.

Tutti e tre i formati utilizzano il controllo ottimistico della concorrenza: anziché bloccare una tabella prima di scrivere, un writer legge la versione corrente, prepara la modifica e ne esegue il commit solo se nel frattempo nessun altro writer ha eseguito il commit di una modifica in conflitto. Se viene rilevato un conflitto, la transazione fallisce in modo sicuro e riprova con la versione più recente o si interrompe, senza mai lasciare la tabella in uno stato incoerente.

Il modo più efficace per ridurre i conflitti di scrittura consiste nel ridurre la sovrapposizione tra writer simultanei: partizionare i processi di ingestione in modo che pipeline diverse scrivano su partizioni diverse, raggruppare le piccole scritture in un numero inferiore di commit più grandi e limitare l'ambito delle operazioni di merge alle sole partizioni interessate. Anche i commit del catalogo sono utili in questo caso, poiché le transazioni multitabella consentono di eseguire il commit degli aggiornamenti correlati insieme, anziché competere come scritture separate da processi multipli.

Scegliere un formato di tabella per il proprio data lake

Apache Iceberg tende a essere la soluzione migliore laddove l'accesso in lettura multimotore è fondamentale, ad esempio per le organizzazioni che interrogano le stesse tabelle contemporaneamente da Trino, Snowflake, Flink e Spark. Delta Lake è ideale per le pipeline incentrate su Spark che richiedono transazioni multitabella e una governance granulare. Apache Hudi è più adatto per carichi di lavoro di upsert a livello di record ad alta frequenza, come la replica CDC, dove la sua indicizzazione creata ad hoc supera le prestazioni delle operazioni di merge generiche.

La compatibilità del motore deve essere valutata rispetto ai motori di query già in produzione, non solo in base a un elenco di funzionalità: un formato tecnicamente superiore che non dispone di un connettore maturo per il motore principale di un team aggiunge più rischi di quanti ne rimuova. Delta Kernel, una libreria open source in Java e Rust, è diventata un modo comune con cui i motori aggiungono il supporto a Delta Lake senza dover reimplementare il protocollo; alimenta già le integrazioni di DuckDB e ClickHouse, e le due implementazioni stanno convergendo su un core Rust condiviso.

Prima di standardizzare su un formato, esegui un proof of concept su una tabella di produzione rappresentativa e moderatamente disordinata: misura la latenza di scrittura sotto carico simultaneo, conferma che i motori di destinazione leggano il formato in modo nativo anziché tramite un connettore lento e convalida che l'evoluzione dello schema e il time travel si comportino come previsto.

Interoperabilità, cataloghi e considerazioni sui vendor

Opzioni di catalogo e interoperabilità tra formati

Un catalogo è il sistema di registrazione che tiene traccia di quali tabelle esistono, dove risiedono i loro dati e quale snapshot è autorevole; le opzioni includono l'originale Hive Metastore, AWS Glue Data Catalog e Unity Catalog, che gestisce le tabelle Delta Lake e Apache Iceberg insieme sotto un unico set di criteri di accesso. Delta Lake UniForm va oltre, consentendo di leggere una singola copia dei dati Delta Lake in modo nativo come tabella Iceberg senza duplicare lo storage, risolvendo il problema del lock-in del formato che spinge i team a ritardare la standardizzazione.

Rischi di vendor lock-in e come mitigarli

Il modo più chiaro per mitigare il rischio di vendor lock-in consiste nello scegliere un formato con più di un'implementazione indipendente del motore e confermare che l'accesso al catalogo (e non solo l'accesso ai file) sia portabile su piattaforme di cui un team potrebbe aver bisogno in seguito. Poiché Iceberg e Delta Lake sono open source, l'archiviazione dei dati in uno dei due non vincola di per sé un'organizzazione a un unico motore di elaborazione, sebbene i livelli di governance integrati sopra possano variare in termini di portabilità.

Operazioni, monitoraggio e best practice

La manutenzione delle tabelle dovrebbe essere codificata come un runbook, non come un'attività ad hoc: definisci quali tabelle necessitano di compattazione e a quale soglia di dimensione del file, imposta le finestre di conservazione per il vacuum e la scadenza degli snapshot in base a quanto indietro nel tempo i job interrogano i dati, e pianifica entrambi al di fuori delle finestre di picco delle query.

Il monitoraggio dello stato delle tabelle dovrebbe tenere traccia del numero di file e della dimensione media dei file per tabella, dei tassi di errore dei commit e dell'età del file di dati più vecchio rispetto a una pianificazione di compattazione, inviando avvisi quando il numero di file di piccole dimensioni o i tassi di conflitto aumentano notevolmente. Queste metriche rilevano l'accumulo di metadati e i conflitti di scrittura prima che si manifestino sotto forma di query lente.

Poiché i formati di tabella aperti supportano l'evoluzione dello schema senza interrompere le query esistenti, le modifiche allo schema vengono spesso applicate direttamente alle tabelle di produzione, ma questa facilità rende semplice saltare i test. I team dovrebbero convalidare le modifiche rispetto a query downstream rappresentative e provare periodicamente un rollback a uno snapshot precedente, in modo che il ripristino da una modifica errata sia una procedura collaudata e non un primo tentativo sotto pressione.

Conclusione: compromessi dei formati di tabella aperti e passaggi successivi

Apache Iceberg, Delta Lake e Apache Hudi risolvono lo stesso problema di fondo (portare transazioni ACID, evoluzione dello schema e time travel sui dati archiviati in uno storage a oggetti economico) attraverso progetti di metadati modellati in base al punto di partenza di ciascuno: analisi multimotore per Iceberg, pipeline native di Spark per Delta Lake, upsert ad alta frequenza per Hudi. Parquet rimane il formato di file comune alla base di tutti e tre, e le recenti innovazioni (vettori di eliminazione, row lineage, Variant e commit coordinati dal catalogo) stanno convergendo tra i vari formati anziché rimanere isolate.

Il passo successivo più pratico per la maggior parte dei team è un proof of concept mirato: scegliere il formato corrispondente a uno stack di motori esistente, testarlo a fronte di volumi di dati di produzione reali e confermare che il catalogo che lo gestisce possa estendersi a un secondo formato in un secondo momento. Lo storage lakehouse aperto e indipendente dal formato di Databricks consente ai team di archiviare i dati una sola volta e di interrogarli in modo nativo come Delta Lake o Apache Iceberg, gestiti sotto un unico catalogo, senza duplicare i dati o vincolarsi a un singolo formato.

Domande frequenti sui formati di tabella aperti

Che cos'è un formato di tabella aperto?

Un formato di tabella aperto è un livello di metadati open source che si colloca al di sopra dei file di dati nello storage a oggetti e aggiunge funzionalità simili a quelle di un database — transazioni ACID, evoluzione dello schema e time travel — a un data lake. Apache Iceberg, Delta Lake e Apache Hudi sono i tre principali formati di tabella aperti utilizzati in produzione, e ciascuno trasforma una raccolta di file Parquet o ORC in una tabella che qualsiasi motore supportato può leggere e scrivere in modo sicuro.

Qual è la differenza tra un formato di tabella e un formato di file?

Un formato di file come Parquet o ORC definisce il modo in cui un singolo file di dati viene compresso e organizzato su disco, mentre un formato di tabella come Apache Iceberg o Delta Lake definisce come molti di questi file formano insieme una tabella coerente e interrogabile. I formati di tabella aperti sono basati sui formati di file, aggiungendo il livello di metadati — manifest, log delle transazioni e cataloghi — che i soli formati di file non forniscono.

Le tabelle Delta Lake e Apache Iceberg possono funzionare insieme?

Sì. Delta Lake UniForm consente di leggere una singola copia dei dati della tabella Delta Lake in modo nativo come tabella Apache Iceberg senza duplicare lo storage, e cataloghi come Unity Catalog possono gestire entrambi i formati fianco a fianco in base a un unico set di criteri di accesso. Questa interoperabilità consente alle organizzazioni di standardizzare su una governance condivisa senza costringere ogni motore a utilizzare lo stesso formato di tabella.

Quale formato di tabella aperto dovrei scegliere?

Il miglior formato di tabella aperto dipende dai motori di query e dal carico di lavoro già in produzione: Apache Iceberg è adatto per l'analisi multi-motore su strumenti come Trino e Snowflake, Delta Lake è ideale per le pipeline incentrate su Spark che richiedono transazioni multi-tabella, e Apache Hudi è indicato per carichi di lavoro di upsert ad alta frequenza a livello di record, come la replica CDC. Un proof of concept con dati di produzione reali confermerà la scelta più adatta.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale