Apache Iceberg™ v3: Spostare l'ecosistema verso l'unificazione

Apache Iceberg™ v3, ora approvato dalla community di Apache Iceberg^™, introduce nuove funzionalità avanzate e tipi di dati. Iceberg v3 include importanti miglioramenti come i vettori di eliminazione, la derivazione delle righe e nuovi tipi per i casi d'uso di dati semi-strutturati e geospaziali. Queste funzionalità consentono ai clienti di elaborare ed eseguire query sui dati in modo efficiente. Inoltre, questi miglioramenti sono coerenti tra Delta Lake, Apache Parquet e Apache Spark^™, in modo che i clienti possano interagire tra Delta e Apache Iceberg^™ senza riscrivere i dati o i file di eliminazione a livello di riga.

In questo post del blog, tratteremo gli sviluppi più recenti di Iceberg v3:

• Vettori di eliminazione
• Derivazione delle righe
• Dati semi-strutturati e tipi geospaziali
• Interoperabilità tra Delta Lake, Apache Parquet e Apache Spark

Vettori di eliminazione

Iceberg v3 introduce un nuovo formato per le eliminazioni a livello di riga per migliorare le prestazioni di lettura: i vettori di eliminazione. Le eliminazioni a livello di riga riducono significativamente l'amplificazione della scrittura ottimizzando il modo in cui le righe eliminate vengono archiviate e tracciate, il che porta a ETL e ingestione più veloci. In Iceberg v2, i motori non erano tenuti a compattare insieme i file di eliminazione durante le scritture. L'intento era che i clienti utilizzassero la manutenzione asincrona. Tuttavia, molti clienti non hanno pianificato i servizi di manutenzione, quindi le loro tabelle avevano troppi file di eliminazione non gestiti. Ciò ha portato a prestazioni di lettura lente quando i motori dovevano unire molti file di eliminazione a livello di riga in lettura.

Iceberg v3 introduce un nuovo formato di vettore di eliminazione e nuovi requisiti di compattazione per i file di eliminazione. Questo nuovo formato evita la traduzione tra i file Parquet e le rappresentazioni in memoria utilizzate per applicare le eliminazioni. Inoltre, i motori devono mantenere un singolo vettore di eliminazione per file al momento della scrittura. Questo requisito migliora le prestazioni e le statistiche sui file di dati. Ciò semplifica anche il confronto tra le eliminazioni precedenti e quelle correnti, il che semplifica l'elaborazione delle modifiche a livello di riga di una tabella come flusso.

Derivazione delle righe

Un'altra importante funzionalità di Iceberg v3 è la derivazione delle righe, utilizzata per semplificare l'elaborazione incrementale. Con la derivazione delle righe, i motori trovano le modifiche a livello di riga confrontando le versioni delle righe tra i commit.

Iceberg v3 introduce la derivazione delle righe utilizzando i metadati a livello di riga: un ID di riga e il numero di sequenza quando la riga è stata modificata o aggiunta l'ultima volta. Gli ID identificano la stessa riga tra le versioni. I numeri di sequenza annotano quando le righe sono state modificate l'ultima volta, non solo riposizionate tra i file. Ciò consente ai motori di elaborare le modifiche in modo selettivo, semplificando gli aggiornamenti a valle con flussi di lavoro più rapidi ed economici.

Le informazioni sull'ID di riga sono particolarmente utili se combinate con oggetti di elaborazione incrementale come le viste materializzate. Questi oggetti sono ottimizzati per calcolare solo i dati nuovi o modificati dall'ultimo ciclo di elaborazione.

Dati semi-strutturati e tipi geospaziali

Iceberg v3 aggiunge anche nuovi tipi di dati per dati semi-strutturati e dati geospaziali.

I dati semi-strutturati sono difficili da archiviare perché hanno schemi variabili, che non rientrano nelle colonne di tabelle strutturate. Una soluzione alternativa consiste nell'estrarre singoli campi da questi dati in un formato strutturato. Tuttavia, questo crea tabelle estremamente ampie con molte colonne e valori NULL a causa di schemi incoerenti. Un'altra alternativa è archiviare JSON in colonne stringa. Sfortunatamente, ciò si traduce in scarse prestazioni di lettura perché i motori devono analizzare i dati da queste stringhe. Senza tipi di dati semi-strutturati, i motori non possono eseguire il push-down dei filtri, quindi devono leggere ogni riga in ogni file di dati. Iceberg v3 introduce VARIANT per rappresentare i dati semi-strutturati in modo efficiente. VARIANT codifica la struttura dei dati per migliorare le prestazioni mantenendo la flessibilità dello schema.

Allo stesso modo, i dati geospaziali, ovvero le informazioni associate alle posizioni sulla superficie terrestre come strade, parchi o confini della città, sono anche difficili da utilizzare ed eseguire query in modo efficiente. Senza tipi geospaziali, i clienti dovevano utilizzare colonne binarie per archiviare le posizioni dei geodati. Tuttavia, questa rappresentazione non supportava la ricerca geografica, poiché le colonne binarie non possono essere filtrate per trovare oggetti all'interno di un'area specificata. Iceberg v3 risolve questo problema introducendo nuovi tipi di dati di geometria e geografia. I tipi di geometria sono per i dati spaziali planari, mentre i tipi di geografia sono per i dati globali che tengono conto della curvatura della terra. Con questi tipi, i clienti possono trovare facilmente i dati utilizzando i riquadri di delimitazione che rappresentano le regioni geografiche e individuare in modo efficiente gli oggetti geospaziali.

Interoperabilità con Delta Lake, Apache Parquet e Apache Spark^™

Le nuove funzionalità e i tipi di dati di Iceberg v3 ampliano la funzionalità e migliorano le prestazioni. Queste funzionalità di Apache Iceberg sono importanti anche perché promuovono l'interoperabilità tra i formati lakehouse.

Storicamente, i clienti sono stati costretti a scegliere tra due dei formati lakehouse più diffusi: Delta Lake e Apache Iceberg. Questo perché la maggior parte delle piattaforme supporta solo un formato. La riscrittura dei dati può essere costosa e impraticabile su larga scala, rendendo questa scelta a lungo termine. I formati sono molto simili: entrambi sono livelli di metadati sopra i file di dati Parquet per fornire la semantica della tabella. Tuttavia, piccole differenze nei formati della tabella causano problemi ai clienti.

Iceberg v3 unifica il livello dati tra i formati. Con l'unificazione dei dati, i clienti possono interagire tra Delta e Iceberg senza dover riscrivere i dati o eliminare i file. Questo perché le funzionalità di Iceberg v3 hanno implementazioni compatibili tra Delta Lake, Apache Parquet e Apache Spark:

• I vettori di eliminazione utilizzano le stesse codifiche binarie tra i formati di tabella
• La derivazione a livello di riga in Iceberg v3 è compatibile con il tracciamento delle righe in Delta Lake
• I tipi VARIANT e geodata sono in fase di sviluppo nelle community upstream di Apache Parquet e Apache Spark™, che si estende ad Apache Iceberg e Delta Lake

Avendo funzionalità compatibili tra progetti open source, Iceberg v3 evita di costringere i clienti a scegliere un formato. Invece, i clienti possono interagire liberamente tra i formati su una copia dei propri dati.

Ulteriori informazioni su Iceberg v3

Iceberg v3 spinge l'intero settore verso un mondo più performante, capace e interoperabile. Stiamo integrando Iceberg v3 nella Databricks Data Intelligence Platform e non vediamo l'ora che altri fornitori adottino Iceberg v3. L'open source è un valore fondamentale di Databricks, dove contribuiamo attivamente con funzionalità come i vettori di eliminazione a Iceberg v3. Per promuovere una fiorente community open source, supportiamo e incoraggiamo i contributi ad Apache Iceberg. Per i nuovi contributori, consigliamo di iniziare con un "good first issue".

Per informazioni su come prevediamo di integrare le funzionalità di Iceberg v3 nella nostra offerta di tabelle gestite e sul futuro dei formati di tabella aperti, registrati al Data and AI Summit dal 9 al 12 giugno 2025.

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