Open Table Formats

Executive summary

Quando un'organizzazione accumula grandi volumi di dati su sistemi di archiviazione distribuiti, garantire che le operazioni di lettura e scrittura non producano risultati incoerenti o corrotti diventa una sfida concreta. Questo articolo analizza i tre principali sistemi progettati per risolvere questo problema, confrontandone le architetture, i meccanismi di gestione delle modifiche alla struttura dei dati e le strategie per accedere a versioni precedenti delle informazioni. Dall'analisi emerge che, nonostante i tre sistemi risolvano lo stesso problema di fondo, le scelte progettuali divergono in modo significativo, con conseguenze pratiche sulla velocità di lettura, sulla flessibilità nell'organizzazione dei dati e sulla compatibilità tra strumenti diversi, e che il settore si sta orientando verso una convergenza guidata dall'interoperabilità tra formati.

Background

L'architettura data lake, archiviazione di dati eterogenei su object store distribuiti come Amazon S3, Google Cloud Storage o Azure Blob Storage, ha risolto il problema della scalabilità e del costo per petabyte, ma ha introdotto una classe di problemi che i database relazionali avevano risolto decenni prima: assenza di transazioni atomiche, nessuna garanzia di isolamento tra lettori e scrittori concorrenti, e metadati basati su listing di directory con costi O(n) sul numero di file. Il formato Apache Hive, dominante per oltre un decennio, traccia partizioni come directory nel filesystem e delega la consistenza a un metastore centralizzato (Hive Metastore) che non offre garanzie transazionali a livello di tabella [1].

Il paradigma lakehouse, formalizzato da Armbrust et al. [1], propone di superare questa dicotomia implementando funzionalità tipiche dei data warehouse, transazioni ACID, schema enforcement, governance, direttamente sullo storage a basso costo del data lake. L'elemento abilitante sono gli open table format: layer di metadati che si interpongono tra i file di dati (tipicamente Apache Parquet) e i motori di query, fornendo un transaction log che traccia ogni modifica atomica alla tabella. I tre formati principali, Apache Iceberg, Delta Lake e Apache Hudi, sono emersi tra il 2016 e il 2018 da esigenze operative concrete: Hudi da Uber per l'upsert incrementale su HDFS [2], Delta Lake da Databricks per le transazioni ACID su Spark [3], e Iceberg da Netflix per la gestione di tabelle con decine di migliaia di partizioni [4].

Jain et al. [5], nel primo confronto sistematico pubblicato a CIDR 2023, hanno analizzato le tre architetture sotto assi di design omogenei, dimostrando che le differenze non sono cosmetiche: le scelte su granularità del tracking (file-level vs. record-level), struttura dei metadati (log lineare vs. albero gerarchico) e formato del transaction log (JSON vs. Avro vs. Parquet) producono profili di performance, costi di manutenzione e gradi di interoperabilità sostanzialmente diversi. Questa analisi comparativa riprende e approfondisce tali assi, integrandoli con le evoluzioni architetturali successive al 2023.

Criteri di confronto

Per strutturare un confronto rigoroso tra i tre formati, è necessario definire gli assi di analisi che catturano le differenze architetturali con impatto operativo. I criteri selezionati riflettono le dimensioni che determinano la scelta del formato in contesti di produzione su larga scala.

Il primo asse è il modello transazionale: come ciascun formato implementa le garanzie ACID su uno storage che non le supporta nativamente. Object store come S3 offrono consistenza strong read-after-write per singoli oggetti, ma nessuna primitiva di transazione multi-oggetto [3]. Il formato deve quindi costruire atomicità e isolamento attraverso il proprio layer di metadati, e il design di questo layer determina il grado di concorrenza supportato, la latenza del commit e la complessità del conflict resolution.

Il secondo asse è la struttura dei metadati: l'organizzazione fisica e logica delle informazioni che descrivono lo stato della tabella. La granularità con cui i metadati tracciano i file di dati, e la struttura con cui vengono organizzati (log piatto, albero gerarchico, timeline), ha conseguenze dirette sul costo del query planning: un motore che deve leggere l'intero transaction log per determinare lo stato corrente della tabella scala diversamente da uno che può navigare un albero di manifest con pruning basato su statistiche [5].

Il terzo asse è la schema evolution: la capacità di modificare la struttura della tabella (aggiungere colonne, modificare tipi, rinominare campi) senza riscrivere i file esistenti. La differenza critica è tra sistemi che tracciano le colonne per nome e sistemi che le tracciano per identificatore univoco, una scelta di design che determina la sicurezza delle operazioni di rename e drop [6].

Il quarto asse è la partition evolution: la possibilità di modificare lo schema di partizionamento senza riscrivere lo storico. Questo è l'asse su cui le differenze architetturali sono più marcate, perché richiede che il formato disaccoppi la struttura fisica dei dati dalla semantica logica delle query [6].

Il quinto asse è il time travel: i meccanismi che consentono di interrogare la tabella a uno stato precedente, con le relative implicazioni su retention dei metadati, costo di storage e granularità temporale.

Analisi comparativa

Apache Iceberg

Apache Iceberg implementa un modello di metadati ad albero gerarchico a tre livelli: metadata file, manifest list e manifest file [4, 6]. Il metadata file, in formato JSON (spec v1-v2) o Avro (spec v3), è il punto di ingresso e contiene il riferimento allo snapshot corrente, lo schema della tabella, la specifica di partizionamento e le proprietà. Ogni snapshot punta a un manifest list, un file Avro che elenca i manifest file attivi e le relative statistiche aggregate (range di valori per colonna, conteggio record, dimensione). Ciascun manifest file, a sua volta in formato Avro, descrive un sottoinsieme dei data file con statistiche a livello di colonna (min, max, null count, distinct count) per ogni file tracciato [6].

Questa architettura a tre livelli è la differenza strutturale più significativa rispetto ai formati concorrenti. Il query planning può operare per pruning progressivo: il motore legge il manifest list, scarta i manifest file il cui range di valori non interseca i predicati della query, e solo per i manifest rimanenti legge i dettagli dei singoli data file [5, 6]. Su tabelle con decine di migliaia di partizioni, lo scenario originale di Netflix che ha motivato il progetto, questo design riduce di ordini di grandezza il numero di operazioni di listing rispetto all'approccio Hive-style, dove il query planner deve enumerare l'intera struttura di directory [4].

Il modello transazionale si basa su optimistic concurrency control (OCC): ogni operazione di scrittura genera un nuovo metadata file e tenta un commit atomico aggiornando il puntatore nel catalog. Se un commit concorrente ha modificato il puntatore nel frattempo, l'operazione deve verificare la compatibilità dei cambiamenti e ritentare, un meccanismo che funziona efficacemente con scrittori concorrenti limitati, ma che sotto alta contesa può generare retry ripetuti [5]. La scelta del catalog (Hive Metastore, AWS Glue, Nessie, REST catalog) determina la primitiva di commit atomico disponibile: compare-and-swap per Nessie e REST catalog, lock-based per Hive Metastore [6].

La schema evolution di Iceberg traccia ogni colonna con un identificatore numerico univoco, assegnato monotonicamente e mai riutilizzato [6]. Questa scelta, apparentemente minore, ha conseguenze architetturali profonde: un'operazione di rename modifica solo il mapping nome-ID nel metadata file, senza alterare i data file esistenti che continuano a referenziare l'ID numerico. Un drop contrassegna l'ID come obsoleto, e una successiva aggiunta di colonna con lo stesso nome riceve un nuovo ID, eliminando il rischio di conflitto tra dati vecchi e nuovi. La specifica garantisce esplicitamente che le operazioni di schema evolution sono indipendenti e prive di effetti collaterali: l'aggiunta di una colonna non altera i valori letti da altre colonne, e una modifica di tipo è consentita solo per promozioni sicure (int → long, float → double) [6].

La partition evolution è il differenziatore tecnico più distintivo di Iceberg. Il formato introduce il concetto di hidden partitioning: le partizioni non sono colonne visibili nella tabella, ma trasformazioni applicate a colonne esistenti (year, month, day, hour, bucket, truncate) definite nella partition spec [6]. Poiché le query non referenziano mai direttamente i valori di partizione, il motore applica il partition pruning automaticamente analizzando i predicati sulla colonna sorgente, è possibile modificare lo schema di partizionamento senza invalidare le query esistenti e senza riscrivere i dati storici. Ogni data file è associato al partition spec attivo al momento della scrittura, e il motore gestisce trasparentemente query che attraversano file con spec diverse [6]. In un contesto pratico, questo consente di evolvere da una partizione mensile a una giornaliera man mano che il volume cresce, senza il costo operativo di una migrazione completa.

Per il time travel, Iceberg mantiene una catena di snapshot immutabili, ciascuno identificato da un ID univoco e un timestamp. Una query può referenziare un snapshot specifico per ID o per timestamp, e il motore ricostruisce lo stato della tabella navigando l'albero di metadati a partire da quello snapshot [6]. La retention degli snapshot è configurabile: la procedura di expire_snapshots rimuove i metadata (e opzionalmente i data file) degli snapshot anteriori a una soglia, bilanciando il costo di storage con la profondità di time travel disponibile.

La specifica v3, introdotta nelle release 1.8.0-1.10.0 (2025), ha aggiunto deletion vector binari per operazioni di delete e update più efficienti, il tipo Variant per dati semi-strutturati, supporto per tipi geospaziali e timestamp con precisione al nanosecondo, e row lineage per tracciare le modifiche a livello di riga tra commit successivi [6].

Delta Lake

Delta Lake adotta un'architettura di metadati radicalmente diversa: un transaction log lineare, denominato _delta_log, composto da file JSON numerati sequenzialmente (uno per ogni commit) e periodicamente consolidati in checkpoint Parquet [3]. Ogni file JSON contiene una sequenza di action: add (aggiunta di un data file), remove (rimozione logica di un data file), metaData (modifica dello schema o delle proprietà), protocol (aggiornamento della versione del protocollo), txn (tracciamento di transazioni idempotenti per Structured Streaming) e commitInfo (metadati sul commit) [3, 7].

Per ricostruire lo stato corrente della tabella, un motore legge l'ultimo checkpoint Parquet e applica incrementalmente tutti i file JSON successivi. I checkpoint vengono generati ogni N commit (configurabile, default 10) e contengono lo stato completo, l'elenco di tutti i file attivi, eliminando la necessità di rileggere l'intero log [3]. Su tabelle con storico lungo, questa strategia è più economica di un full log replay ma meno efficiente del pruning gerarchico di Iceberg per il query planning: il checkpoint contiene l'elenco completo dei file senza le statistiche aggregate per manifest che consentono il pruning a livello intermedio [5]. Delta Lake compensa parzialmente includendo statistiche per colonna (min, max, null count) nel campo stats di ogni action add, ma queste devono essere valutate file per file dal motore senza il livello di aggregazione intermedio offerto dai manifest list [5].

Il modello transazionale di Delta Lake implementa anch'esso optimistic concurrency, ma con una primitiva di commit diversa: il commit è un'operazione di put-if-absent sullo storage, il file JSON del commit N+1 viene scritto con semantica create-only, e se un file con lo stesso numero esiste già, il commit fallisce e deve essere ritentato [3]. Per i conflitti, Delta Lake definisce regole di risoluzione specifiche per tipo di operazione: due append concorrenti sono sempre compatibili; un append concorrente con un delete richiede la verifica che i file aggiunti non intersechino i predicati del delete [7]. Questo modello, formalizzato nel protocollo aperto delta.io, è più restrittivo dell'OCC generico di Iceberg ma offre semantiche di conflict resolution più prevedibili.

La schema evolution di Delta Lake traccia le colonne per nome, non per identificatore univoco [5, 7]. Questa scelta semplifica l'implementazione e la leggibilità del log, ma ha conseguenze sulla sicurezza delle operazioni di rename: rinominare una colonna è funzionalmente equivalente a un drop seguito da un add, e il formato deve gestire esplicitamente la compatibilità tra file scritti con lo schema precedente e query che utilizzano il nuovo nome. Le operazioni supportate includono l'aggiunta di colonne (nullable), la rimozione, il rename e la modifica di tipo con promozioni sicure, ma la risoluzione delle colonne per nome anziché per ID introduce un accoppiamento più stretto tra i data file e lo schema corrente [5].

Il partizionamento in Delta Lake segue il modello Hive-style: le partizioni sono directory fisiche il cui valore è parte del path [3]. Questo significa che una modifica dello schema di partizionamento richiede la riscrittura dei dati, un'operazione costosa e potenzialmente distruttiva su tabelle di grandi dimensioni. La mancanza di un equivalente al hidden partitioning di Iceberg è una limitazione architetturale riconosciuta, che il team Delta ha affrontato indirettamente con ottimizzazioni come Z-ordering e liquid clustering piuttosto che con un meccanismo di partition evolution [7]. Liquid clustering, introdotto nelle release recenti, consente di ridefinire le chiavi di clustering senza riscrivere l'intera tabella, ma opera a livello di layout fisico dei dati piuttosto che di specifica di partizionamento logica.

Il time travel in Delta Lake è implementato nativamente attraverso il transaction log: ogni versione della tabella corrisponde a un commit nel log, e una query può specificare VERSION AS OF N o TIMESTAMP AS OF T per accedere a uno stato precedente [7]. La retention è governata dal parametro logRetentionDuration (default 30 giorni) per i file del transaction log e da deletedFileRetentionDuration per i data file rimossi. L'operazione VACUUM elimina i file di dati non più referenziati da alcun commit nel periodo di retention, liberando spazio ma rendendo irrecuperabili le versioni precedenti.

Delta Lake Universal Format (UniForm), rilasciato in GA nel 2024, rappresenta la strategia di convergenza del progetto: UniForm genera automaticamente metadati Iceberg (e opzionalmente Hudi) accanto ai metadati Delta, mantenendo una singola copia dei file Parquet [8]. Questo consente a motori che supportano solo Iceberg (come Snowflake o BigQuery) di leggere tabelle Delta senza conversione, realizzando un modello write-once-read-anywhere. L'acquisizione di Tabular, la società fondata dai creatori di Iceberg, da parte di Databricks nel giugno 2024 segnala che la convergenza tra i due formati è una direzione strategica, non solo tecnica [8].

Apache Hudi

Apache Hudi si differenzia architetturalmente dagli altri due formati per un focus esplicito sul workload di upsert incrementale, operazioni di inserimento, aggiornamento e cancellazione a livello di record, non solo di file [2, 9]. Questa scelta di design si riflette in ogni aspetto dell'architettura, a partire dalla struttura di metadati.

Il modello di metadati di Hudi è organizzato attorno a una timeline: una sequenza ordinata di instant, ciascuno identificato da un timestamp monotono e caratterizzato da un tipo di azione (commit, delta_commit, compaction, clean, rollback) e uno stato (requested, inflight, completed) [9]. La timeline è persistita nella directory .hoodie e, a partire da Hudi 1.x, utilizza un design basato su LSM-tree che compatta i metadati in file progressivamente più grandi, migliorando significativamente le performance su tabelle con migliaia di commit [9]. Il metadata table, una tabella Hudi interna, mantiene partizioni ausiliarie per file listing, statistiche per colonna e bloom filter, eliminando la necessità di operazioni di listing sul filesystem per il query planning [9].

La distinzione architetturale più significativa di Hudi è la presenza di due tipi di tabella: Copy-on-Write (CoW) e Merge-on-Read (MoR) [9]. In una tabella CoW, ogni operazione di scrittura produce nuovi file base completi in formato Parquet: un update riscrive l'intero file che contiene i record modificati. Questo ottimizza le performance di lettura, ogni query legge solo file Parquet senza merge runtime, ma rende le scritture più costose, proporzionalmente alla dimensione dei file coinvolti. In una tabella MoR, gli update vengono scritti come log file incrementali in formato Avro, che vengono periodicamente compattati nei file base attraverso un processo di compaction asincrono [9]. Le query possono operare in due modalità: read-optimized (solo file base, senza merge, con dati potenzialmente non aggiornati) e snapshot (merge runtime dei log file con i file base, con dati aggiornati ma latenza di lettura superiore).

Questa dualità CoW/MoR non ha un equivalente diretto in Iceberg e Delta Lake, che storicamente operano con un modello di riscrittura completa del file al momento dell'update, sebbene entrambi abbiano introdotto deletion vector per mitigare parzialmente questo limite. Hudi eccelle negli scenari CDC (Change Data Capture) e nei workload con alta frequenza di update su sottoinsiemi ristretti della tabella, lo scenario operativo originale di Uber [2]. Jain et al. [5] hanno tuttavia dimostrato che questa ottimizzazione ha un costo: su workload di bulk ingestion (TPC-DS data load), Hudi risulta quasi 10 volte più lento rispetto a Delta Lake, perché il processo di scrittura include controlli di unicità delle chiavi e redistribuzione dei record per file group, operazioni inutili per un caricamento iniziale senza duplicati.

Il modello transazionale di Hudi utilizza un approccio basato su file group e timeline piuttosto che su OCC puro. Ogni file group è l'unità atomica di update: un commit nella timeline registra l'insieme dei file group modificati, e la visibilità è determinata dallo stato dell'instant nella timeline (solo gli instant completed sono visibili ai lettori) [9]. Questo design supporta nativamente il multi-table transaction attraverso il meccanismo di marker file, che traccia i file in fase di scrittura e consente il rollback automatico in caso di failure parziale.

La schema evolution in Hudi supporta l'aggiunta, la rimozione e il rename di colonne. La versione 1.x ha introdotto una re-architettura significativa del modello interno: l'adozione dell'internal schema con identificatori univoci per colonna, che allinea Hudi al design di Iceberg e supera le limitazioni della risoluzione per nome delle versioni precedenti [9]. Questa re-architettura ha incluso anche il passaggio alla timeline LSM-based e un metadata table unificato, segnando una transizione da framework di ingestion a piattaforma completa di gestione tabellare. La partition evolution è tuttavia limitata rispetto a Iceberg: Hudi non supporta hidden partitioning né la modifica trasparente dello schema di partizionamento su dati esistenti. Le partizioni restano directory fisiche, e una ripartizionatura richiede la riscrittura dei dati.

Il time travel in Hudi è implementato attraverso la timeline: ogni instant rappresenta uno stato della tabella, e le query possono specificare un timestamp per accedere a uno stato precedente. La granularità del time travel è determinata dalla frequenza dei commit nella timeline e dalla policy di archiviazione: gli instant più vecchi vengono archiviati (spostati in una directory .hoodie/archived) dopo un numero configurabile di commit, riducendo il costo di startup del metadata loading ma limitando la profondità di time travel senza accesso all'archivio [9].

Uber ha documentato l'evoluzione operativa di Hudi su scala trilionaria: la re-architettura delle pipeline basata su Hudi ha ridotto i tempi di esecuzione da 20 a 4 ore, con una riduzione dei costi del 60% [2]. Questo caso d'uso illustra il vantaggio specifico di Hudi nei contesti in cui il workload dominante è l'aggiornamento incrementale di dataset molto grandi con chiave primaria, uno scenario dove i meccanismi nativi di indexing e upsert di Hudi compensano il maggiore overhead infrastrutturale.

Discussione e raccomandazioni

Sintesi comparativa

La tabella seguente riassume le differenze architetturali lungo i cinque assi di confronto definiti.

Trade-off architetturali

Le differenze nella struttura dei metadati si traducono in profili di performance distinti per il query planning. Jain et al. [5] hanno misurato che su TPC-DS, Delta Lake risulta 1.4× più veloce di Hudi e 1.7× più veloce di Iceberg, ma la causa della differenza tra Iceberg e Delta non risiede nel design dei metadati, bensì nel reader Parquet: Iceberg utilizza un reader custom in Spark per supportare le operazioni di schema evolution (rename, drop), significativamente più lento del reader nativo di Spark usato da Delta e Hudi [5]. Questo risultato illustra un principio generale: il benchmark misura l'implementazione, non necessariamente il design, e le performance relative possono cambiare radicalmente con l'evoluzione dei motori di query.

L'architettura CoW/MoR di Hudi introduce un grado di libertà assente negli altri formati: la possibilità di bilanciare esplicitamente il costo di scrittura contro il costo di lettura, con una granularità che arriva al singolo file group [9]. In contesti CDC dove la percentuale di record aggiornati per commit è bassa (1-5% della tabella), questo design produce un vantaggio significativo: l'update in modalità MoR scrive solo un log file incrementale, mentre un equivalente update in Iceberg o Delta riscrive l'intero data file contenente i record modificati. La specifica v3 di Iceberg ha introdotto deletion vector per mitigare questo gap [6], e Delta Lake supporta deletion vector dalla versione 2.4, ma il meccanismo di log file + compaction di Hudi rimane più maturo per workload con update ad alta frequenza.

La partition evolution è l'asse su cui la differenza architetturale è più netta e più difficile da colmare. L'hidden partitioning di Iceberg non è un'ottimizzazione incrementale ma una scelta di design fondamentale: il disaccoppiamento tra schema logico e layout fisico è intrinseco alla specifica, non un layer aggiunto successivamente [6]. Per Delta Lake e Hudi, raggiungere un livello equivalente di flessibilità richiederebbe una modifica strutturale alla relazione tra partizioni e query, un cambiamento che liquid clustering in Delta affronta parzialmente ma non completamente, operando sul layout fisico piuttosto che sull'astrazione logica delle partizioni.

Convergenza e interoperabilità

Il panorama degli open table format è attraversato da una tensione tra competizione e convergenza. Da un lato, ogni formato evolve indipendentemente, aggiungendo funzionalità che erano originariamente differenziatori dei concorrenti (deletion vector in Iceberg e Delta, schema evolution migliorata in Hudi). Dall'altro, l'industria riconosce che la frammentazione dei formati genera costi operativi significativi: organizzazioni con ecosistemi multi-engine si trovano costrette a mantenere copie della stessa tabella in formati diversi o a limitare la scelta dei motori di query.

Due approcci alla convergenza sono emersi. Delta Lake UniForm [8] adotta la strategia del formato dominante con compatibilità in lettura: una tabella Delta genera automaticamente metadati Iceberg, consentendo la lettura da motori Iceberg-only senza conversione. Apache XTable (incubating) [10], precedentemente noto come OneTable, adotta la strategia della traduzione bidirezionale: un layer di conversione che traduce i metadati tra Delta, Iceberg e Hudi senza duplicare i data file. XTable opera come processo di sincronizzazione che legge i metadati nel formato sorgente e genera i metadati equivalenti nel formato target, un approccio che preserva la flessibilità di scelta ma introduce un componente infrastrutturale aggiuntivo da operare e monitorare [10].

La convergenza de facto verso Iceberg come formato di interscambio è supportata da segnali di mercato significativi: l'adozione nativa da parte di Snowflake, BigQuery, Redshift, Athena, Trino e Spark, e l'acquisizione di Tabular da parte di Databricks, suggeriscono che Iceberg sta emergendo come il formato su cui l'industria sta standardizzando la lettura, indipendentemente dal formato di scrittura preferito [8]. Questo non implica l'obsolescenza di Delta o Hudi, i rispettivi punti di forza architetturali restano validi per i workload specifici, ma indica che il costo di adozione di Iceberg come formato di interoperabilità è percepito come inferiore rispetto alle alternative.

Raccomandazioni operative

La scelta del formato in contesti di produzione dovrebbe essere guidata dal workload dominante e dall'ecosistema di motori in uso, non da classifiche di benchmark generiche. Per workload analitici su larga scala con requisiti di multi-engine access, Iceberg offre il design di metadati più scalabile e la partition evolution più flessibile. Per ecosistemi fortemente integrati con Spark e Databricks, Delta Lake fornisce l'integrazione più matura e la convergenza con Iceberg tramite UniForm riduce il rischio di lock-in. Per workload dominati da upsert incrementali ad alta frequenza con chiave primaria, Hudi offre meccanismi nativi (CoW/MoR, indexing, compaction) che gli altri formati stanno convergendo a replicare ma non hanno ancora raggiunto in maturità operativa.

Sul piano delle alternative emergenti, Apache Paimon si sta posizionando come formato ottimizzato per workload di streaming con aggiornamento incrementale delle materialized view, mentre DuckLake esplora un approccio che delega la gestione dei metadati a un database relazionale anziché a file su object store. Nessuno dei due ha raggiunto la maturità e l'adozione dei tre formati analizzati, ma la loro esistenza conferma che lo spazio di design degli open table format non è chiuso.

In sintesi, operare un data lake di produzione senza un open table format, affidandosi a directory Hive-style e metastore tradizionali, implica rinunciare a transazioni ACID, time travel, schema evolution sicura e partition pruning efficiente. Queste funzionalità rappresentano oggi requisiti architetturali di base, non differenziatori opzionali.

Riferimenti

[1] M. Armbrust et al., "Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics," in Proc. CIDR, 2021. https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

[2] Uber Engineering, "Apache Hudi at Uber: Engineering for Trillion-Record-Scale Data Lake Operations," Uber Engineering Blog, 2024. https://www.uber.com/us/en/blog/apache-hudi-at-uber/

[3] M. Armbrust et al., "Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores," in Proc. VLDB Endowment, vol. 13, no. 12, 2020. https://www.vldb.org/pvldb/vol13/p3411-armbrust.pdf

[4] Apache Software Foundation, "Apache Iceberg — Table Format for Huge Analytic Datasets," 2025. https://iceberg.apache.org/

[5] P. Jain et al., "Analyzing and Comparing Lakehouse Storage Systems," in Proc. CIDR, 2023. https://www.cidrdb.org/cidr2023/papers/p92-jain.pdf

[6] Apache Software Foundation, "Apache Iceberg Table Spec," 2025. https://iceberg.apache.org/spec/

[7] Delta Lake Project, "Delta Lake Protocol Specification," GitHub, 2025. https://github.com/delta-io/delta/blob/master/PROTOCOL.md

[8] Databricks, "Delta Lake Universal Format (UniForm) for Iceberg Compatibility," Databricks Blog, 2024. https://www.databricks.com/blog/delta-lake-universal-format-uniform-iceberg-compatibility-now-ga

[9] Apache Software Foundation, "Apache Hudi Documentation — Table & Query Types," 2025. https://hudi.apache.org/docs/table_types/

[10] Apache Software Foundation, "Apache XTable (Incubating)," 2025. https://xtable.apache.org/