Apache Iceberg v3 Table Spec: celebrare il successo della community open source

Il progetto Apache Iceberg™ esemplifica lo spirito open source e mostra cosa è possibile fare quando una community si unisce con un obiettivo comune: portare avanti una tecnologia. Con la missione di portare affidabilità, performance e apertura all’analytics su vasta scala, il progetto Iceberg continua a evolversi e a offrire molti vantaggi grazie alle diverse voci e agli sforzi dei suoi contributori.

L’ultimo traguardo di Iceberg, la ratifica delle Table Spec v3, è più di un semplice aggiornamento tecnico. È il risultato di una progettazione accurata, di discussioni rigorose e della collaborazione tra decine di organizzazioni e centinaia di individui. Le Table Spec v3 riflettono un investimento condiviso nel futuro delle architetture dati aperte e l’impegno a mantenere Iceberg realmente vendor-neutral, flessibile e guidato dalla community.

Questo post evidenzierà le principali funzionalità delle Table Spec v3 e farà luce sul lavoro collettivo che ha dato vita a questa release.

Sviluppo guidato dalla community

Negli ultimi due anni, Iceberg è emerso come uno standard leader per i formati di tabella aperti, consentendo sia agli utenti che ai vendor di concordare una struttura per i propri dati e, quindi, di beneficiare dell’interoperabilità che ne deriva. È solo con il contributo dell’intera community che il progetto Iceberg può veramente prosperare e offrire tutti i vantaggi – apertura, neutralità del vendor e interoperabilità – che lo rendono prezioso.

Con l’open source, chiunque può suggerire una nuova funzionalità, crearla autonomamente e collaborare con altri contributori per integrarla nel progetto. Le funzionalità incorporate nelle più recenti specifiche di tabella Iceberg sono il risultato di numerose discussioni con vendor e singoli, che hanno descritto cosa si aspettavano da Iceberg per continuare a utilizzare o adottare la tecnologia. Ad esempio, i vendor con i propri formati di tabella proprietari potrebbero suggerire di aggiungere determinate funzionalità a Iceberg per coerenza, ma queste verrebbero incorporate solo se l’intera community Iceberg concordasse che tali funzionalità sarebbero vantaggiose per il progetto. Questo è l’open source.

Avere un gran numero di utenti, contributori e vendor che supportano Iceberg significa che le funzionalità suggerite e i miglioramenti proposti offriranno prospettive diverse e le implementazioni risultanti saranno più robuste — il che ci porta alle Table Spec v3.

Panoramica delle Table Spec v3

Le Table Spec v3 rappresentano una pietra miliare per la tecnologia, introducendo una serie di nuove incredibili funzionalità e sbloccando innumerevoli casi d’uso per gli utenti. 

Valori di default

Cosa fa: Con i valori di default, gli utenti Iceberg hanno la possibilità di gestire i valori nulli e mancanti nelle loro tabelle v3. 

Come funziona: I valori di default sono possibili con l’aggiunta di due nuove configurazioni di tabella. Impostando write-default, gli utenti possono controllare come i loro writer gestiscono i valori mancanti dai campi; per flessibilità, questo può essere modificato in qualsiasi momento. D’altra parte, initial-default, che viene impostato una volta per una tabella, fornisce agli utenti un meccanismo per sostituire i valori nulli esistenti con un valore specificato. 

Chi l’ha reso possibile:

• Shenoda Guirguis, proposta di specifica originale

• Limian (Raymond) Zhang, specifica finalizzata

• Implementazione

  • Ryan Blue, Iceberg PMC Chair

  • Walaa Eldin Moustafa

Vettori di eliminazione

Cosa fa: I vettori di eliminazione sono il nuovo meccanismo di default per la gestione delle eliminazioni di posizione in Iceberg. Gli utenti non devono più scendere a compromessi tipicamente associati alla configurazione delle eliminazioni di posizione, ossia scegliendo tra la riduzione del numero di file di piccole dimensioni (abilitando la granularità a livello di partizione) e letture più efficienti (abilitando la granularità a livello di file). 

Come funziona: Una volta implementati, i vettori di eliminazione prenderanno il posto delle eliminazioni di posizione. Il design prevede la memorizzazione di più vettori di eliminazione come roaring bitmap in file Puffin, un tipo di file performante già utilizzato in tutto il progetto Iceberg, dove possono essere acceduti in modo efficiente tramite un indice. È interessante notare che “v2 Iceberg aveva una nozione di [vettori di eliminazione], ma questi erano usati in-memory”, afferma Anton Okolnychyi, membro dell’Iceberg Project Management Committee (PMC) e Senior Staff Software Engineer presso Databricks. “Su disco c’erano file Parquet, in memoria c’erano bitmap. E una volta che abbiamo iniziato a progettare la v3, volevamo vedere cosa si poteva fare di diverso per evitare i costi operativi generali della conversione.” 

La decisione della community di utilizzare i file Puffin rispetto all’implementazione di Parquet esistente offre guadagni in termini di performance per gli utenti e potrebbe essere migliore per i casi d’uso a bassa latenza. In definitiva, i vettori di eliminazione offrono agli utenti il meglio di entrambi i mondi: Le eliminazioni di posizione si applicano a livello di granularità di file per letture più efficienti, ma sono fisicamente memorizzate in file Puffin consolidati per ridurre il numero di file di piccole dimensioni.

Chi l’ha reso possibile:

• Modifiche alle specifiche

  • Renjie Liu, Iceberg PMC Member, proposta originale

  • Anton Okolnychyi, modifiche finalizzate

• Implementazione

  • Amogh Jahagirdar, Iceberg PMC Member

  • Eduard Tudenhoefner, Iceberg PMC Member

Tipi di dati geospaziali

Cosa fa: Iceberg ora supporta due nuovi tipi geospaziali, geometry e geography, allineandosi meglio con altri progetti e offrendo agli utenti la possibilità di sbloccare funzionalità migliori relative a mappatura e dati di localizzazione. 

Secondo Jia Yu, Apache Sedona PMC Chair e co-fondatore di Wherobots, la funzionalità finale è il risultato di un’ampia ricerca della community. Hanno esaminato una serie di progetti e tecnologie con supporto geospaziale, come “Sedona, Databricks, Snowflake, BigQuery, pandas” e altri, che “hanno tutti definizioni diverse di dati geospaziali… tipi diversi… il comportamento di questi tipi è davvero diverso”. 

Come funziona: Oltre a rendere semplicemente accessibili i tipi geospaziali all’interno di Iceberg, la modifica delle specifiche affronta anche problemi complessi come la gestione del partizionamento e del filtraggio dei campi geospaziali e come dovrebbero apparire le metriche a livello di colonna per questi tipi. Predicate pushdown e metriche regolari a livello di colonna sono ancora disponibili per i tipi geospaziali con riquadri di delimitazione descritti da punti geospaziali che fungono da massimi e minimi. 

Chi l’ha reso possibile:

• Modifiche alle specifiche

  • Szehon Ho, Iceberg PMC Member

  • Gang Wu

• Kristin Cowalcijk, implementazione

• Una menzione speciale a tutto il team Wherobots, che ha implementato il supporto geospaziale sulla propria fork di Iceberg prima di offrire la propria expertise alla community Iceberg, fornendo leadership e implementando la funzionalità per il progetto Iceberg.

Trasformazioni multi-argomento

Cosa fa: Le trasformazioni multi-argomento consentono agli utenti di eseguire trasformazioni su più campi ai fini del partizionamento e dell’ordinamento in Iceberg. Prima delle Table Spec v3, era possibile trasformare un solo campo per questi scopi.

Chi l’ha reso possibile:

• 叶先进, modifiche alle specifiche

• Implementazione

  • Fokko Driesprong, Iceberg PMC Member

  • JB Onofré, Membro del consiglio di amministrazione di ASF

Data lineage delle righe

Cosa fa: La data lineage delle righe rende più semplice per gli utenti tracciare come le righe in una tabella Iceberg sono cambiate nel tempo, sbloccando una serie di casi d’uso inclusi flussi di lavoro di Change Data Capture (CDC) migliorati, audit più semplici e una migliore manutenzione delle viste materializzate. In definitiva, l’aggiunta della data lineage delle righe a Iceberg “significa che gli utenti Iceberg saranno in grado di determinare accuratamente la cronologia di qualsiasi riga nelle loro tabelle”, afferma Russell Spitzer, Iceberg PMC Member e Principal Software Engineer presso Snowflake. “Prima potevamo solo ipotizzare in base alle colonne di identità definite dall’utente, ma ora è integrato nel formato stesso!”

Come funziona: Ogni riga di una tabella Iceberg include due campi aggiuntivi, _row_id e _last_updated_sequence_number. La community Iceberg è stata in grado di implementarlo in modo tale che non ogni riga debba memorizzare esplicitamente i valori in questi campi. Invece, per risparmiare spazio, i valori delle colonne sono impliciti fino alla loro materializzazione tramite una query di lettura e solo allora i valori vengono propagati attraverso il layer dei metadati (Metadata.json → Snapshot → Manifest → Datafile → Row).

Chi l’ha reso possibile:

• Modifiche alle specifiche

  • Russell Spitzer

  • Nileema Shingte

  • Attila-Péter Tóth

• Implementazione

  • Russell Spitzer, core 

  • Ryan Blue, core 

  • Amogh Jahagirdar, Spark 

Crittografia della tabella

Cosa fa: L’ultimo aggiornamento sulla crittografia della tabella sblocca la crittografia lato client delle Iceberg Tables, offrendo agli utenti la possibilità di crittografare tutti i propri dati e metadati. Intere tabelle possono essere crittografate con una singola chiave, oppure l’accesso può essere controllato a livello di snapshot. 

Come funziona: Per rendere possibile la crittografia della tabella lato client in Iceberg, gli utenti hanno la possibilità di associare i singoli snapshot della tabella a chiavi di crittografia memorizzate in un key store di terze parti. Per iniziare ad accedere ai dati all’interno di un determinato snapshot, i client devono avere accesso a quel key store e alla chiave di crittografia per decriptare e accedere all’elenco manifest dello snapshot. Da lì, gli elenchi manifest hanno un meccanismo simile per i client per decriptare i file manifest e, infine, i file manifest hanno una chiave di crittografia dei file di dati per i client per accedere ai file di dati. 

Chi l’ha reso possibile:

• Modifiche alle specifiche e implementazione

  • Gidon Gershinsky

  • Russell Spitzer

  • Ryan Blue

Tipo di dati Variant

Cosa fa: I tipi Variant consentono agli utenti di gestire data set semi-strutturati meno regolari, dove determinati campi vengono utilizzati in modo intermittente. Prendiamo, ad esempio, i dati dei sensori: Tutti i sensori possono riportare una posizione e un timestamp, ma alcuni sensori riportano la temperatura, altri l’umidità e così via. Come afferma Aihua Xu, Senior Software Engineer di Snowflake e uno dei contributori al tipo Variant: "L'aggiunta [del tipo Variant] alle specifiche Iceberg v3 è stata fatta per soddisfare le realtà dei dati odierni. Il supporto nativo [del tipo Variant] consente a Iceberg di rappresentare ed elaborare in modo efficiente questo tipo di dati, sbloccando performance e flessibilità senza compromettere la struttura.”

Come funziona: Il tipo di dati Variant consente agli utenti di memorizzare tipi di variabili e campi in tabelle Apache Iceberg™ dove i nomi dei campi e i relativi tipi vengono estratti in metadati e campi di valore e quindi memorizzati come binari. La lettura dei dati comporta la deserializzazione. Per essere più efficienti, una funzionalità aggiuntiva chiamata “shredding” consente di estrarre e memorizzare in Parquet i campi coerenti, come la posizione e il timestamp nell’esempio precedente, e i relativi tipi; i campi rimanenti vengono memorizzati in metadati e campi valore come descritto sopra. 

Chi l’ha reso possibile:

• Modifiche alle specifiche

  • Tyler Akidau, proposta originale 

  • Aihua Xu, modifiche finalizzate

• Implementazione

  • Aihua Xu, implementazione core

  • Ryan Blue, core

  • David Cashman, shredding

  • Gene Peng, codifica e lavoro influente sul tipo di dati Variant in Apache Spark

  • Neil Chao, Apache Arrow 

Dove siamo e cosa ci aspetta

Nessuna delle suddette funzionalità sarebbe stata possibile senza il duro lavoro e la continua collaborazione dell’intera community Iceberg. Il lavoro svolto da tutti per questa ultima specifica è una vera testimonianza dello spirito open source, illustrando come individui, vendor e utenti possano unirsi per far progredire un’intera tecnologia. 

Con ciò, desideriamo estendere un sentito ringraziamento a tutti coloro che hanno contribuito a Iceberg e reso possibile le Table Spec v3 — sia a quelli sopra menzionati che a tutti gli altri.

Attualmente, la diversità del progetto Iceberg, tra individui e aziende, testimonia chiaramente la salute della community e dell’ecosistema. Il suo continuo successo dipenderà dall’ampia adozione delle Table Spec v3 e da un’ampia integrazione con le tecnologie esistenti e nuove. Fortunatamente, questo sta accadendo — con sempre più tecnologie, aziende e vendor che supportano Iceberg ogni giorno.