![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/prima-immagine-Lorenzo-Pasco.png\")
<\/figure>\n\n\n\nApproccio Git-like in ambito Data<\/h2>\n\n\n\n
Sarebbe interessante portare gli stessi concetti anche in ambito Data: prelevare i dati con la pipeline dalle sorgenti, inserirli in un branch dedicato e a seguito dell’esecuzione positiva di alcuni test effettuare il merge dei dati aggiornati sul branch principale cos\u00ec da poter essere acceduti in produzione. E se dovessimo accorgerci di alcune incongruenze quando ormai \u00e8 stato fatto il merge? Ci comportiamo come nello sviluppo: con un rollback al commit precedente, o comunque all’ultimo momento in cui i dati erano corretti.<\/p>\n\n\n\n
Proviamo dunque a vedere come raggiungere questo scopo sfruttando soluzioni open source. Come primo tassello occorrer\u00e0 il sistema su cui salvare fisicamente i dati. In questo caso utilizziamo MinIO, un object storage che espone le API di S3 e altamente performante. <\/p>\n\n\n\n
Per ottenere le funzionalit\u00e0 git-like occorrer\u00e0 effettuare transazioni ACID sull’object storage, che di sua natura non offre, e questo viene fornito grazie ad un table format che attraverso la gestione dei metadati consente di garantire questa propriet\u00e0. In questo caso il table format scelto \u00e8 Apache Iceberg, anch’esso open source. Un table format, tuttavia, mantiene le informazioni sulla singola tabella. Per avere una vera esperienza git-like vorremmo poter gestire pi\u00f9 tabelle contemporaneamente. Questo viene garantito grazie ad un table repository, che riesce ad avere contezza di tutte le tabelle da gestire e che mantiene il puntatore all’ultima versione dei metadati su cui debbano avvenire scritture o letture. Ecco che corre in nostro soccorso Project Nessie, un table repository open source che offre un’esperienza git-like sui dati. <\/p>\n\n\n\n
Infine, occorre uno strumento con il quale poter accedere i dati presenti nel data lakehouse e dal quale poter creare delle viste utili per gli scopi finali, come ad esempio Dremio. Andiamo dunque a vedere nel dettaglio ogni singolo layer descritto in precedenza che comporr\u00e0 il Data Lakehouse con funzionalit\u00e0 git.<\/p>\n\n\n\n
Object Storage<\/h3>\n\n\n\n
L’object storage \u00e8 il sistema che permette di salvare grandi quantit\u00e0 di dati non strutturati al suo interno. Corrisponde in questo caso al data lake, ed i dati vi sono salvati sottoforma di oggetti. Il data lake offre la possibilit\u00e0 di immagazzinare grandi quantit\u00e0 di dati non strutturati, a differenza del data warehouse nel quale i dati salvati hanno una struttura ben definita. Tuttavia la caratteristica di salvare dati non strutturati pu\u00f2 rivelarsi anche uno svantaggio in quanto le performance di ricerca sono inferiori. Inoltre, l’object storage non supporta le transazioni ACID che invece sono presenti nei database relazionali tradizionali e che permettono di effettuare delle validazioni sullo schema e sulla consistenza in fase di ingestion dei dati anzich\u00e9 in fase di lettura. Oltre a questo, permettono di garantire la consistenza dei dati quando vi sono pi\u00f9 scrittori\/lettori in contemporanea su una stessa tabella.<\/p>\n\n\n\n
Table format<\/h3>\n\n\n\n
Per ovviare all’assenza delle transazioni ACID, e per far diventare il data lake, un data lakehouse, \u00e8 fondamentale il table format. Esso crea un livello di astrazione sopra l’object storage che migliora le performance ed abilita le transazioni ACID direttamente sul data lake.<\/p>\n\n\n\n
Il table format altro non \u00e8 che un metodo per strutturare ed unificare i dati presenti nell’object storage come un’unica tabella. Risponde alla domanda “quali dati ci sono nella tabella?” e lo fa grazie a come vengono organizzati e gestiti i metadati. Questo permette agli utenti ed ai tool che interagiscono con la tabella, di farlo in maniera pi\u00f9 efficiente.<\/p>\n\n\n\n
Table repository<\/h3>\n\n\n\n
Il catalogo di Iceberg mantiene il puntatore all’ultimo metadata file da poter utilizzare per le scritture e per le letture. Esso \u00e8 relativo alla sola tabella di indagine. Il table repository \u00e8 il luogo in cui vengono salvati i cataloghi Iceberg per tutte le tabelle. In questo modo, gli utenti o gli strumenti che interagiscono con le tabelle presenti nel catalogo sanno di leggere o scrivere la versione corretta.<\/p>\n\n\n\n
Data access<\/h3>\n\n\n\n
Il Data Access funge da ponte tra gli utenti e le sorgenti dati presenti nell’infrastruttura. La sua funzione principale \u00e8 quella di fornire un’interfaccia unificata per l’accesso ai dati, spesso utilizzando linguaggi standard come SQL. Questo permette agli utenti di eseguire query e analisi sui dati senza la necessit\u00e0 di conoscere i dettagli di implementazione delle varie sorgenti dati. Infine, il Data Access permette di gestire le autorizzazioni degli utenti in maniera granulare, garantendo l’accesso ai dati sensibili solo a coloro che hanno i permessi necessari per farlo.<\/p>\n\n\n\n
Tecnologie utilizzate<\/h2>\n\n\n\n
Adesso che abbiamo chiarito cosa serve per abilitare l\u2019esperienza git-like nel data lakehouse, descriveremo pi\u00f9 nel dettaglio le tecnologie scelte per ogni singolo layer visto in precedenza.<\/p>\n\n\n\n
MinIO \u2013 Object Storage<\/h3>\n\n\n\n
MinIO \u00e8 un object storage che fornisce compatibilit\u00e0 alle API Amazon Web Services S3, e supporta tutte le sue funzionalit\u00e0 core. MinIO \u00e8 nativamente \u00e8 compatibile per l\u2019installazione su Kubernetes, tuttavia pu\u00f2 essere installato qualsiasi modo: reti pubbliche o private, bare metal, in ambienti orchestrati o infrastrutture edge.<\/p>\n\n\n\n
Le funzionalit\u00e0 core di MinIO sono:<\/p>\n\n\n\n
- \n
- Scalabilit\u00e0<\/strong>: Minio \u00e8 un sistema distribuito che pu\u00f2 essere scalato orizzontalmente aggiungendo nodi<\/li>\n\n\n\n
- Disponibilit\u00e0<\/strong>: Al fine di garantire l’alta affidabilit\u00e0, Minio replica i dati su pi\u00f9 nodi, in modo tale da persistere i dati, anche in caso di perdita di uno o pi\u00f9 nodi<\/li>\n\n\n\n
- Sicurezza<\/strong>: Vengono offerte una serie di funzionalit\u00e0 sulla sicurezza, tra cui autenticazione, controllo degli accessi e crittografia dei dati salvati<\/li>\n\n\n\n
- Velocit\u00e0<\/strong>: MinIO \u00e8 molto performante per la lettura e scrittura dei dati su S3<\/li>\n\n\n\n
- Compatibilit\u00e0<\/strong> con API S3<\/strong>: Viene fornita la compatibilit\u00e0 con il protocollo S3, il che lo rende facile da usare con applicazioni che gi\u00e0 utilizzano questa tipologia di protocollo<\/li>\n<\/ul>\n\n\n\n
Apache Iceberg \u2013 Table format<\/h3>\n\n\n\n
Apache Iceberg \u00e8 un Table Format open source molto performante, che tramite query SQL-like permette l’analisi di grandi quantit\u00e0 di dati. Permette a pi\u00f9 engine in contemporanea di operare su uno stesso dataset senza creare problemi di consistenza. Tra le caratteristiche principali sono presenti:<\/p>\n\n\n\n
– Transazioni ACID<\/strong>: attraverso la sua architettura, Apache Iceberg abilita le transazioni ACID garantendo la concorrenza ottimistica in situazioni in cui pi\u00f9 scrittori o lettori vogliono accedere ad una determinata risorsa.<\/p>\n\n\n\n
– Dinamicit\u00e0 nelle partizioni<\/strong>: nel Data Lake, senza Iceberg, se volevamo cambiare il partizionamento di una tabella, dovevamo riscriverla interamente. Con Iceberg, invece, il partizionamento diventa dinamico e pu\u00f2 cambiare in ogni momento.<\/p>\n\n\n\n
– Hidden partitioning<\/strong>: Iceberg produce i valori per le partizioni e le utilizza nelle query in maniera trasparente a chi scrive o legge.<\/p>\n\n\n\n
– Time travel<\/strong>: grazie a degli snapshot immutabili sui dati, \u00e8 possibile effettuare delle query su degli snapshot antecedenti temporalmente, evitando la duplicazione dei dati.<\/p>\n\n\n\n
– Version rollback<\/strong>: grazie alla propriet\u00e0 citata sopra, \u00e8 possibile anche effettuare un vero e proprio rollback su versioni precedenti dei dati.<\/p>\n\n\n\n
– Evoluzione dello schema<\/strong>: Iceberg supporta anche i cambiamenti che possono avvenire sullo schema di una tabella.<\/p>\n\n\n\n
Utilizzare un Table Format open source permette di non avere lock-in nella scelta delle tecnologie con cui interagisce. Ad esempio, Apache Iceberg \u00e8 supportato da Dremio per la lettura e la scrittura dei metadati su sorgenti di tipo S3, come ad esempio MinIO. Apache Iceberg organizza i metadati in una struttura gerarchica e ci\u00f2 consente agli engine con cui interagisce di apportare modifiche rapide ed efficienti alle tabelle senza ridefinire tutti i file del set di dati, garantendo cos\u00ec prestazioni ottimali quando si lavora su scala di Data Lake.<\/p>\n\n\n\n
<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/immagine-2-Pasco-982x1024.png\")
Figura 1 – Struttura di gestione gerarchica di Apache Iceberg<\/strong><\/figcaption><\/figure>\n\n\n\n <\/div>\n\n\n\nCome radice dell\u2019albero in figura vi \u00e8 l\u2019Iceberg Catalog, che nel nostro caso \u00e8 Project Nessie come vedremo successivamente, ossia il Table Repository che tiene traccia dell’attuale puntatore ai metadati. Il metadata layer \u00e8 composto da tre livelli:<\/p>\n\n\n\n
- \n
- Metadata file<\/strong>: include informazioni sullo schema della tabella, informazioni sulle partizioni, sugli snapshot e circa lo snapshot attuale.<\/li>\n\n\n\n
- Manifest list<\/strong>: contiene una lista di manifest file assieme alle informazioni dei manifest file che hanno effettuato uno snapshot.<\/li>\n\n\n\n
- Manifest file<\/strong>: tracciano i data file oltre che avere altri dettagli e statistiche per ogni file<\/li>\n<\/ul>\n\n\n\n
Il data layer contiene i data files veri e propri. Tutta questa struttura illustrata fino ad ora, dall’Icebrg Catalog fino al Data Layer pu\u00f2 risiedere su un Object Storage di tipo S3, come MinIO. Inoltre pu\u00f2 interagire senza problemi con Dremio, abilitando di fatto a quello che \u00e8 a tutti gli effetti un Data Lakehouse.<\/p>\n\n\n\n
Project Nessie \u2013 Table Repository<\/h3>\n\n\n\n
Project Nessie \u00e8 un catalogo transazionale open source utilizzato nei Data Lake. Oltre ad assumere il ruolo di Table Repository per le tabelle Iceberg, come visto nel paragrafo precedente, \u00e8 molto utile perch\u00e8 abilita le funzionalit\u00e0 Git-like nel Data Lake. Per questo motivo abbiamo individuato questa tecnologia come Table Repository, dato che non si limita al solo ruolo di catalogo transazionale. \u00c8 possibile abilitare il versionamento non solo su una tabella alla volta come permetteva Iceberg, ma anche su pi\u00f9 tabelle contemporaneamente. Consente, dunque, la creazione di branch sui quali apportare modifiche, mantenendo consistenti i dati e permettendo di fare un merge quando siamo certi che le modifiche effettuate siano corrette. Project Nessie, quando gestisce pi\u00f9 versioni di una tabella in diversi branch, non applica una copia dei dati ma si limita a gestire i metadata file<\/em> delle tabelle Iceberg. Un altro fattore che ci ha portato a scegliere questa tecnologia, \u00e8 il fatto che \u00e8 supportata da Dremio come Metadata Catalog e come storage supporta Object Storage di tipo S3 come, ad esempio, MinIO.<\/p>\n\n\n\n
Alcuni dei concetti fondamentali in Project Nessie sono:<\/p>\n\n\n\n
– Commit<\/strong>: cambiamento atomico che avviene al set dei dati ed \u00e8 il cambiamento minimo possibile in Nessie. In altre parole, rappresenta uno snapshot dei dati ad un certo punto nel tempo. Nel caso in cui dovessimo effettuare dei rollback baster\u00e0 puntare ad un commit precedente.<\/p>\n\n\n\n
– Branches<\/strong>: un branch referenzia l’ultimo commit presente in una catena di commit. Branch diversi possono puntare ad uno stesso commit o a commit diversi, ed \u00e8 in questo modo che Nessie gestisce la concorrenza di job verso uno stesso data set.<\/p>\n\n\n\n
– Merge<\/strong>: \u00e8 possibile inserire i cambiamenti apportati su un branch verso un altro branch target.<\/p>\n\n\n\n
Dremio \u2013 Data Access<\/h3>\n\n\n\n
Dremio \u00e8 una piattaforma che abilita le analitiche self-service su un data lakehouse. Offre un’ampia gamma di sorgenti dalle quali attingere dati e grazie alle ottimizzazioni utilizzate (Apache Arrow e Reflections tra le altre) consente di accedere velocemente ai dati presenti nel data lake. Tra le varie sorgenti presenti vi \u00e8 anche proprio Project Nessie ed inoltre supporta la scrittura in Apache Iceberg. Dremio<\/a> nella nostra infrastruttura, implementa lo strato di data access. E’ in grado di fornire una modalit\u00e0 unificata per l’interrogazione e la modellazione dei dati presenti nell’architettura, tramite linguaggio SQL. Dremio offre la possibilit\u00e0 anche di virtualizzare i dati, in quanto permette l\u2019aggregazione dei dati provenienti da sorgenti diverse. Infine, si integra con diversi tool di BI come ad esempio PowerBI, Superset e Tableau.<\/p>\n\n\n\n
<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Banner-vari-eventi-e-altro-7-1024x300.png\")
<\/a><\/figure>\n\n\n\n<\/div>\n\n\n\nArchitettura finale<\/h2>\n\n\n\n
Riassumendo, Project Nessie sar\u00e0 il catalogo per le tabelle Apache Iceberg, che ovviamente dovranno essere scritte in un data lake, MinIO nel nostro caso. Utilizzando Dremio, \u00e8 possibile promuovere una sorgente Project Nessie con la quale effettuare operazioni git-like<\/a> direttamente da interfaccia o tramite query SQL-like.<\/p>\n\n\n\n
L\u2019immagine seguente ci aiuta a razionalizzare le diverse tecnologie e ci fa capire la loro interazione:<\/p>\n\n\n\n
<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/terza-immagine-Pasco-681x1024.png\")
Figura 2 – Open Data Lakehouse<\/strong><\/figcaption><\/figure>\n\n\n\n <\/div>\n\n\n\nSpecifichiamo che il table format descritto \u00e8 semplificato visto che dal metadata pointer passiamo direttamente al data layer, questo perch\u00e8 l\u2019intento dell\u2019immagine \u00e8 quella di far vedere che diverse tabelle sono gestite dal table repository e che il table format alla fine gestisce dei file raw che vengono salvati sull\u2019object storage.<\/p>\n\n\n\n
Installazione delle componenti<\/h2>\n\n\n\n
L\u2019installazione delle componenti utilizzate per questo tutorial \u00e8 molto semplice. Ad esempio, facciamo riferimento ad una installazione on-prem utilizzando i pacchetti precompilati e un servizio standalone.<\/p>\n\n\n\n
Per l\u2019installazione di MinIO per un ambiente di test, \u00e8 possibile effettuarne una Single Node Single Drive, seguendo gli step definiti nella guida ufficiale<\/u><\/a>.<\/p>\n\n\n\n
Per quanto riguarda l\u2019installazione di Project Nessie \u00e8 sufficiente scaricare il servizio standalone ed eseguirlo, come specificato nella documentazione ufficiale<\/u><\/a>.<\/p>\n\n\n\n
Anche l\u2019installazione di Dremio \u00e8 molto semplice, se utilizziamo una macchina che supporta l\u2019installazione di pacchetti rpm<\/em> basta seguire questa documentazione<\/u><\/a>, altrimenti \u00e8 possibile utilizzare i Tarball<\/u><\/a>.<\/p>\n\n\n\n
<\/div>\n\n\n\nPromuovere una sorgente Project Nessie<\/h2>\n\n\n\n
Da interfaccia, cliccando su Sources \u00e8 possibile scegliere la sorgente da utilizzare, in questo caso useremo il Nessie:<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-1-1024x447.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\nTra le varie configurazioni, dovremmo settare un nome e l\u2019endpoint sul quale \u00e8 in ascolto, oltre un eventuale metodo di autenticazione:<\/p>\n\n\n\n
<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-2-1024x447.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\n
Dovremmo specificare poi lo storage da utilizzare, come anticipato utilizzeremo MinIO per cui dovremmo specificare il bucket, l\u2019access key e la secret key:<\/p>\n\n\n\n<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/essie-3-1024x447.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\nAllo stesso modo di come avviene se dovessimo promuovere come sorgente MinIO, dobbiamo specificare anche l\u2019endpoint ed altre propriet\u00e0:<\/p>\n\n\n\n
<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Screenshot-2024-05-03-at-12-36-07-@admin-Dremio-1024x447.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\nCreazione di una tabella Iceberg<\/h2>\n\n\n\n
Vi \u00e8 la possibilit\u00e0 di creare una tabella Iceberg specificando il catalogo creato, il cui nome in questo esempio sar\u00e0 nessie<\/em>:<\/p>\n\n\n
create<\/span>\u00a0table<\/span> nessie<\/span>.user_table<\/span> (id<\/span> integer<\/span>, name<\/span> varchar<\/span>, surname<\/span> varchar<\/span>, address<\/span> varchar<\/span>)<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\nA questo punto verr\u00e0 creata una tabella vuota all\u2019interno di Project Nessie ed \u00e8 possibile visualizzare lo schema della stessa:<\/p>\n\n\n\n
<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-5-1024x447.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\nA questo punto, dal query engine di Dremio, potremmo inserire dei record all\u2019interno della tabella:<\/p>\n\n\n
INSERT INTO nessie.user_table VALUES (1<\/span>, 'Ned'<\/span>, 'Stark'<\/span>, 'The North'<\/span>);\nINSERT INTO nessie.user_table VALUES (2<\/span>, 'Robert'<\/span>, 'Baratheon'<\/span>, 'The Stormlands'<\/span>);\nINSERT INTO nessie.user_table VALUES (3<\/span>, 'Jamie'<\/span>, 'Lannister'<\/span>, 'The Westerlands'<\/span>);\nINSERT INTO nessie.user_table VALUES (4<\/span>, 'Daenerys'<\/span>, 'Targaryen'<\/span>, 'The Crownlands'<\/span>);<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Possiamo quindi visualizzarli su Dremio:<\/p>\n\n\n\n<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-6-1024x461.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\nCreazione di un nuovo branch<\/h3>\n\n\n\n
A questo punto, proviamo a creare un nuovo branch con una query SQL-like sempre da Dremio:<\/p>\n\n\n
CREATE BRANCH \"scrittura_user_table\"<\/span> IN nessie;<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nE da UI possiamo vedere che effettivamente il branch \u00e8 stato creato correttamente:<\/p>\n\n\n\n
<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-7-1024x447.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\n
Adesso proviamo a scrivere dei nuovi record sul nuovo branch. Il branch pu\u00f2 essere indicato in fase di inserimento delle nuove righe:<\/p>\n\n\nINSERT INTO nessie.user_table AT BRANCH \"scrittura_user_table\"<\/span> VALUES (5<\/span>, 'Tony'<\/span>, 'Soprano'<\/span>, 'New Jersey'<\/span>);\nINSERT INTO nessie.user_table AT BRANCH \"scrittura_user_table\"<\/span> VALUES (6<\/span>, 'Don'<\/span>, 'Draper'<\/span>, 'New York'<\/span>);<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nA questo punto possiamo notare la differenza tra i due branch:<\/p>\n\n\n\n
<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-8-1024x461.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-9-1024x461.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\nOperazione di merge in un branch<\/h3>\n\n\n\n
Possiamo dunque effettuare una merge del branch creato verso il main:<\/p>\n\n\n
MERGE BRANCH \"scrittura_user_table\"<\/span> INTO \"main\"<\/span> IN nessie;<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nE a questo punto effettuando una query sul main branch vedremo che i risultati sono presenti:<\/p>\n\n\n\n
<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-10-1024x461.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\n
Il branch sorgente non \u00e8 stato eliminato, ed \u00e8 possibile avere una lista di tutti i commit effettuati:<\/p>\n\n\n\n<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-11-1024x461.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\nRollback ad una versione precedente<\/h3>\n\n\n\n
A questo punto, ci siamo resi conto che le nuove righe aggiunte non sono consistenti. Possiamo fare dunque rollback alla versione precedente (specificando un commit oppure un istante nel tempo). In questo caso decido di tornare al commit precedente, prendendo l\u2019identificativo direttamente da interfaccia:<\/p>\n\n\n
ALTER BRANCH \"main\"<\/span> ASSIGN COMMIT \n\"dea98a368953af01c9bc0b42398851e1851966bc791926debae2ff883eeb671f\"<\/span> IN nessie;<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Ed effettuando una query \u00e8 possibile notare che siamo tornati alla situazione di partenza:<\/p>\n\n\n\n<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-12-1024x461.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\nRollback Apache Iceberg VS Rollback Project Nessie<\/h3>\n\n\n\n
In realt\u00e0, \u00e8 possibile effettuare il rollback anche di una singola tabella Iceberg specificando o uno snapshot ID o un timestamp. Ad esempio, con il comando seguente, saremmo tornati alla versione delle ore 12.50 che non conteneva le nuove righe aggiunte:<\/p>\n\n\n
ROLLBACK TABLE nessie.user_table TO TIMESTAMP '2024-05-03 12:50:00'<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nMentre il rollback con Apache Iceberg \u00e8 relativo alle singole tabelle, quello eseguibile con Project Nessie spostando il puntatore ad un commit precedente, \u00e8 relativo a tutte le tabelle presenti nel catalogo, ripristinando quindi il contenuto di tutte le tabelle che avevano sub\u00ecto delle modifiche.<\/p>\n\n\n\n
Come descritto anche in precedenza, dunque, la differenza sta nel fatto che con Apache Iceberg \u00e8 possibile gestire il versionamento di una singola tabella, mentre con Project Nessie \u00e8 possibile gestirlo di pi\u00f9 tabelle contemporaneamente.<\/p>\n\n\n\n
<\/div>\n\n\n\nEliminazione di un branch<\/h3>\n\n\n\n
Per evitare ulteriori danni, \u00e8 possibile anche eliminare il branch nuovo che avevamo creato:<\/p>\n\n\n
DROP BRANCH \"scrittura_user_table\"<\/span> FORCE IN nessie;<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nEffettivamente anche da UI non \u00e8 pi\u00f9 presente:<\/p>\n\n\n\n
<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-13-1024x461.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\nCreazione tabella Iceberg a partire da una VDS<\/h3>\n\n\n\n
Vi sono molti modi per creare una tabella Iceberg, partendo da un CSV o da un JSON, oppure anche a partire da una VDS. Ad esempio, per creare una tabella Iceberg nel catalogo Nessie a partire da una VDS, nella query dovremmo specificare il catalogo, il nome della tabella e il nome della VDS da cui essa ha origine:<\/p>\n\n\n
create table nessie.\"pd_incidents\"<\/span> as<\/span> select * from<\/span> \"@admin\"<\/span>.\"police_incidents\"<\/span>;<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
A questo punto \u00e8 disponibile nel catalogo Nessie e pu\u00f2 subire le medesime operazioni viste in precedenza:<\/p>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/Nessie-14-1024x461.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/09\/template-5.png\")
<\/figure><\/div><\/div>Lorenzo Pasco – Data Engineer @Seac<\/a>om<\/a><\/h2>
<\/p>
Laureato in Artificial Intelligence and Data Engineering a Pisa, attualmente occupo la posizione di Data Engineer presso Seacom. Fin da giovane, ho alimentato la mia passione per l\u2019informatica e i videogiochi, unendo la tecnologia alla mia vita quotidiana. Al di l\u00e0 del digitale, il mio cuore batte per lo sport, in particolare il calcio, e sperimento la creativit\u00e0 in cucina. La mia vita \u00e8 un connubio di dati, tecnologia, sport e sapore.<\/div> - Manifest list<\/strong>: contiene una lista di manifest file assieme alle informazioni dei manifest file che hanno effettuato uno snapshot.<\/li>\n\n\n\n
- Disponibilit\u00e0<\/strong>: Al fine di garantire l’alta affidabilit\u00e0, Minio replica i dati su pi\u00f9 nodi, in modo tale da persistere i dati, anche in caso di perdita di uno o pi\u00f9 nodi<\/li>\n\n\n\n