Home
topics
Apache Iceberg
Data di pubblicazione: 26 febbraio 2024
Autore: Dave Bergmann
Apache Iceberg è un formato open source ad alte prestazioni per tabelle analitiche di grandi dimensioni, che facilita l'uso di tabelle SQL per i big data e l'integrazione sicura di tali tabelle con motori come Apache Spark, Trino, Flink, Presto, Hive e Impala.
Oltre alle specifiche del formato di tabella aperta, Iceberg comprende anche una serie di API e librerie che consentono ai motori di storage, ai motori di query e ai motori di esecuzione di interagire senza problemi con le tabelle che seguono tale formato.
Il formato di tabella Iceberg è diventato parte integrante dell'ecosistema dei big data, in gran parte grazie alla sua capacità di fornire funzioni tipicamente non disponibili con altri formati di tabella. Utilizzando una serie di metadati conservati su ogni tabella, Iceberg consente l'evoluzione dello schema, l'evoluzione delle partizioni e il rollback della versione della tabella senza la necessità di costose riscritture o migrazioni delle tabelle. È completamente indipendente dal sistema di storage, con supporto per più origini dati e nessuna dipendenza dal file system.
Creato originariamente dai data engineer di Netflix e Apple nel 2017 per colmare le carenze di Apache Hive, Iceberg è stato reso open source e donato alla Apache Software Foundation l'anno successivo. È diventato un progetto Apache di alto livello nel 2020.
La velocità, l'efficienza, l'affidabilità e la facilità d'uso complessive di Apache Iceberg aiutano a semplificare e coordinare l'elaborazione dei dati su qualsiasi scala. Questi punti di forza lo hanno reso il formato di tabella preferito da una serie di importanti data warehouse, data lake e data lakehouse, tra cui IBM® watsonx.data, Netezza e Db2 2.
Uno storage dei dati adatto allo scopo creato su un'architettura open data lakehouse per scalare i workload AI, per tutti i dati, ovunque
Iceberg è uno dei pochi formati di tabella open source che consente transazioni ACID: scambi di dati che preservano l'accuratezza garantendo atomicità, coerenza, isolamento e durata.
La creazione di Iceberg è stata un'iniziativa per risolvere i limiti pratici delle tabelle Apache Hive in un ambiente di data lake di grandi dimensioni. Secondo Ryan Blue, PMC Chair del progetto Apache Iceberg ed (ex) ingegnere senior di Netflix, "molti servizi e motori diversi utilizzavano le tabelle Hive. Ma il problema era che non avevamo una garanzia di correttezza. "Non avevamo transazioni atomiche", ha affermato in una conferenza del 2021. "A volte le modifiche apportate da un sistema facevano sì che un altro sistema ricevesse i dati sbagliati e questo tipo di problema ci ha indotto a non utilizzare mai questi servizi, a non apportare modifiche alle nostre tabelle, solo per essere sicuri".1
Lo stesso Apache Hive è nato come mezzo per far funzionare i cluster Apache Hadoop in modo simile ai database relazionali accessibili da SQL. Sebbene funzioni efficacemente con i dati statici, si adatta male ai set di dati mutevoli: le modifiche devono essere coordinate manualmente tra diverse applicazioni e utenti, altrimenti si rischia il danneggiamento e la conseguente imprecisione di set di dati di grandi dimensioni.
Per garantire precisione in un ambiente dinamico, Iceberg è stato progettato per garantire che qualsiasi transazione di dati presenti tutte e quattro le proprietà ACID:
Tutte le modifiche ai dati vengono eseguite come se si trattasse di un'unica operazione: in altre parole, vengono eseguite tutte le modifiche, o nessuna. Ad esempio, in una transazione di dati finanziari, l'atomicità garantisce che a qualsiasi addebito effettuato da un conto corrisponda un accredito sull'altro conto.
Non ci sono contraddizioni tra lo stato complessivo dei dati prima della transazione e lo stato dei dati dopo la transazione. Continuando con l'esempio della transazione finanziaria, la coerenza garantisce che i fondi combinati esistenti tra i due conti siano gli stessi dopo la transazione e prima della stessa.
Lo stato intermedio di qualsiasi transazione è invisibile alle altre transazioni; le transazioni concorrenti, ovvero transazioni che operano simultaneamente sullo stesso insieme di dati, sono trattate come se fossero serializzate. In questa transazione finanziaria, l'isolamento garantisce che qualsiasi altra transazione possa vedere i fondi trasferiti nel conto addebitato o nel conto accreditato, ma non in entrambi (né in nessuno dei due).
Dopo una transazione riuscita, tutte le modifiche ai dati verranno mantenute anche in caso di guasto del sistema. Nel nostro esempio finanziario, ciò significa che la transazione rimarrà completata anche se subito dopo si verifica un'interruzione di corrente a livello di sistema.
Il formato di tabella Apache Iceberg viene spesso paragonato ad altre due tecnologie di dati open source che offrono transazioni ACID: Delta Lake, un livello di storage ottimizzato originariamente creato da Databricks che estende i file di dati Parquet con un log delle transazioni basato su file e una gestione scalabile dei metadati, e Apache Hudi, abbreviazione di "Hadoop Upserts, Deletes and Incrementals", originariamente sviluppato da Uber nel 2016.
Uno studio del 2022 condotto da Synvert ha generato dati casuali e li ha archiviati in formato JSON in un bucket AWS S3 da utilizzare per il benchmarking delle tre tecnologie. In definitiva, i loro test hanno dimostrato che il formato tabellare ottimizzato di Iceberg ha prodotto prestazioni superiori a quelle di Delta Lake e Apache Hudi in tutte le metriche testate.2
Storage: le dimensioni dei file risultanti delle tabelle Iceberg erano significativamente più piccole rispetto a quelle di Delta Lake o Hudi, il che rappresenta un grande vantaggio per l'ottimizzazione dello storage.
Operazioni di inserimento: per le operazioni di inserimento, Iceberg ha ottenuto anche le prestazioni più veloci, ovvero il tempo di esecuzione più breve. Sia Iceberg che Delta Lake erano significativamente più veloci di Hudi.
Operazioni di aggiornamento: per quanto riguarda le operazioni di aggiornamento, Iceberg si è rivelato drasticamente più veloce sia di Delta Lake che di Hudi. In particolare, a differenza delle sue controparti, il runtime di Iceberg non è aumentato in modo significativo con il numero totale di record: ai workload massimi testati nello studio (500 milioni di record), Iceberg è risultato quasi 10 volte più veloce di Delta Lake.
Operazioni di rimozione: allo stesso modo, Iceberg è stato molto più veloce di entrambe le alternative nelle operazioni di rimozione.
Iceberg implementa una gerarchia a tre strati di file di metadati per garantire la correttezza e il coordinamento dei dati delle tabelle tra diversi formati di file e modifiche costanti.
Scritto in Java e Python e offerto anche su un'API Scala, Iceberg supporta una varietà di formati di file di big data, tra cui Apache Parquet, Apache Avro e Apache ORC. Offre funzionalità simili a quelle delle tabelle SQL nei database tradizionali in modo indipendente dal formato di file e dal fornitore, consentendo a più motori di operare sullo stesso set di dati.
L'architettura di una tabella Iceberg comprende tre livelli: il catalogo Iceberg, lo strato di metadati e lo strato di dati.
Il catalogo Iceberg stesso si trova sopra lo strato di metadati e lo strato di dati, proprio come la punta di un iceberg si trova sopra la superficie dell'acqua. Memorizza i puntatori di metadati aggiornati (o "correnti") che associano il nome di una determinata tabella alla posizione dei suoi file di metadati correnti. Oltre al catalogo integrato, Iceberg supporta altri framework di catalogo come Hive MetaStore o AWS Glue.
Le operazioni a livello di catalogo Iceberg sono atomiche, in quanto ciò è essenziale per garantire la correttezza delle transazioni in corso.
Un motore di query avvia quindi qualsiasi query SELECT nel catalogo Iceberg, che fornisce la posizione del file di metadati corrente per la tabella che il motore di query tenta di leggere.
Lo strato di metadati Iceberg comprende, in ordine decrescente, file di metadati, manifest list e file manifest.
File di metadati
I file di metadati memorizzano i metadati di una tabella, inclusi lo schema della tabella, le informazioni sulla partizione, lo snapshot corrente e gli snapshot degli stati precedenti. Dopo essere stato indirizzato al file di metadati attuale dalla voce della tabella nel catalogo Iceberg, il motore di query utilizza il valore [ current-snapshot-id] per trovare la sua voce nell'array [snapshots]. Da lì, può individuare e aprire la manifest list della tabella.
Manifest list
La manifest list è semplicemente un elenco di file manifest e di informazioni importanti per ogni file di dati in essa contenuto, come la posizione, lo snapshot a cui è associato e le partizioni a cui appartiene. In questa fase sono disponibili alcune ottimizzazioni e funzioni di filtraggio.
File manifest
I file manifest tengono traccia dei file di dati e dei dettagli, dei metadati e delle statistiche associati. Questo determina uno dei vantaggi fondamentali del formato di tabella Iceberg rispetto al formato di tabella Hive: la sua capacità di tenere traccia dei dati a livello di file. In questa fase, i valori [file-path] per ogni oggetto [data-file] possono essere utilizzati per trovare e aprire quel file.
Lo strato di dati, come suggerisce il nome, risiede al di sotto dello strato di metadati e contiene i file finali stessi.
Apache Iceberg offre numerose funzionalità utili per migliorare e semplificare la gestione dei dati.
Partizionamento nascosto
Iceberg gestisce tutti i dettagli del partizionamento e delle query dietro le quinte. Il partizionamento nascosto di Iceberg consente agli utenti di fornire informazioni sul layout delle partizioni durante l'esecuzione di query sulle tabelle. Gli utenti non hanno bisogno di gestire personalmente le colonne di partizione, né di comprendere il layout fisico della tabella, per ottenere risultati di query accurati.
Questa operazione non solo rende il partizionamento di Iceberg molto intuitivo, ma consente anche di modificare nel tempo i layout delle partizioni senza compromettere le query predefinite. Quando le specifiche delle partizioni evolvono, i dati nella tabella (e i relativi metadati) non vengono modificati. Solo i nuovi dati, scritti nella tabella dopo l'evoluzione, vengono partizionati con la nuova specifica e i metadati per questi nuovi dati vengono conservati separatamente.
Evoluzione dello schema
Iceberg fornisce supporto nativo per l'evoluzione degli schemi. Ciò consente agli utenti di modificare gli schemi delle tabelle senza dover effettuare una complessa migrazione dei dati, semplificando notevolmente l'adattamento alle strutture di dati in evoluzione.
Viaggio nel tempo
Iceberg consente agli utenti di viaggiare indietro nel tempo attraverso snapshot dei dati Iceberg in diversi momenti. Questo è importante per una varietà di casi d'uso, tra cui audit, debug e controlli di conformità.
Compattazione e filtraggio dei dati
Iceberg offre una serie di funzionalità di indicizzazione che aiutano a ottimizzare le prestazioni delle query, come le opzioni di compattazione per unire i file più piccoli in quelli più grandi per ridurre il sovraccarico dei metadati e i filtri Bloom per ridurre la lettura non necessaria dei dati durante l'esecuzione delle query.
Accedi ai tuoi dati e ottimizza i workflow costosi con watsonx.data, un data store adatto allo scopo costruito su un'architettura open data lakehouse per scalare i workload di AI, per tutti i tuoi dati, ovunque.
Esegui workload mission-critical di analytics e AI con qualsiasi tipo di dati, ovunque: IBM Db2 Warehouse soddisfa i tuoi obiettivi di prezzo e prestazioni per workload sempre attivi, fornendo un accesso semplice e regolamentato a tutti i tuoi dati ed eliminando i silos di dati nell'hybrid cloud.
Scala l'analytics e l'AI con un data warehouse cloud unificato, regolamentato e conveniente. Con il supporto per formati aperti come Parquet e Apache Iceberg, oltre all'integrazione nativa con il tuo data lake e con il data lake di IBM watsonx.data Netezza consente a data engineer, data scientist e data analyst di eseguire workload complessi senza ulteriori ETL o spostamento dei dati sul cloud object storage.
Potenzia le tue applicazioni, l'analytics e l'AI con qualsiasi dato in un open data lakehouse. A differenza dei data warehouse tradizionali, i data lakehouse possono elaborare video, audio, log, testi, social media, dati di sensori e documenti per alimentare app, analytics e AI. Possono essere sviluppati come parte integrante di un'architettura Data Fabric per fornire i dati giusti, al momento giusto, indipendentemente da dove risiedono.
Scopri di più sul partizionamento in Apache Iceberg ed esplora un esempio di come Iceberg facilita l'evoluzione delle partizioni.
Questa guida, redatta da chief data officer, data leader e altri esperti di IBM e non solo, ti aiuterà a implementare la strategia, le tecnologie e la cultura giuste per dare vita a un'organizzazione basata sui dati e alimentata dall'AI.
In un contesto difficile, caratterizzato dall'aumento dei costi dei dati, dalla proliferazione dei silos di dati e dall'aumento dei requisiti normativi, le aziende avvertono sempre di più l'urgenza di sfruttare l'AI per ottenere un vantaggio competitivo.
Note a piè di pagina
Tutti i link sono esterni a ibm.com.
1 "Apache Iceberg: The Hub of an Emerging Data Service Ecosystem?" (link esterno a ibm.com), Datanami, 8 febbraio 2021
2 "Clash of ACID Data Lakes: Comparing Data Lakehouse Formats" (link esterno a ibm.com), Data Insights, 9 agosto 2022