Come Iceberg + AIStor alimenta il moderno data lakehouse multi-engine

Inizialmente incubato su Netflix da Ryan Blue (anche di , ora la fama di Databricks), è stato infine trasmesso alla Apache Software Foundation dove risiede attualmente. Al suo nucleo, è un formato di tabella aperta per i set di dati su scala (pensare a centinaia di TB a centinaia di PB). Con l'intelligenza artificiale che raccoglie enormi quantità di dati per la creazione di modelli, il tuning e la inferenza in tempo reale, la necessità di questa tecnologia è aumentata solo dal suo sviluppo iniziale. Il ghiacciaio Apache Tabellone Il ghiacciaio Apache Tabellone Iceberg è un formato compatibile a più motori. Ciò significa che Spark, Trino, Flink, Presto, Snowflake e Dremio possono tutti operare indipendentemente e contemporaneamente sullo stesso set di dati. Iceberg supporta SQL, il linguaggio universale dell'analisi dei dati, e fornisce funzionalità avanzate come transazioni atomiche, evoluzione schema, evoluzione delle partizioni, viaggi nel tempo, rollback e ramificazione a copia zero. Questo post esamina come le caratteristiche e il design di Iceberg, in combinazione con il livello di archiviazione ad alte prestazioni di AIStor, offrono la flessibilità e l'affidabilità necessarie per costruire data lakehouses. connessi : Data Lakehouse Solutions di Minio Data Lakehouse Solutions di Minio Obiettivi per un formato di tavolo aperto moderno La promessa di un laghetto risiede nella sua capacità di unificare il meglio dei laghi di dati e dei magazzini. I laghi di dati memorizzati sullo storage oggetto sono stati progettati per memorizzare enormi quantità di dati crudi nel suo formato nativo, offrendo scalabilità, facilità d'uso e efficienza di costo. Tuttavia, i laghi di dati da soli hanno lottato con problemi come la governance dei dati e la capacità di interrogare in modo efficiente i dati memorizzati in essi. Iceberg e altri formati di tabella aperta come Apache Hudi e Delta Lake rappresentano un salto in avanti. Questi formati fanno sì che i laghi di dati si comportino come magazzini, pur mantenendo la flessibilità e la scalabilità iniziali dello storage degli oggetti. Questo nuovo stack di formati di tabella aperta e di storage aperto può supportare carichi di lavoro diversi come l'IA, l'apprendimento automatico, l'analisi avanzata e la visualizzazione in tempo reale. Iceberg si distingue per il suo approccio SQL-first e si concentra sulla compatibilità multi-engine. Ecco un'occhiata a come potrebbe funzionare questa infrastruttura. I motori di query possono sedersi direttamente sopra lo spazio di archiviazione dell'oggetto nel tuo stack e interrogare i dati all'interno senza migrazione. Il vecchio paradigma di migrazione dei dati in un'archiviazione di database d non è più rilevante. Invece, puoi e dovresti essere in grado di interrogare le tabelle di Iceberg da qualsiasi luogo. Gli strumenti di analisi e le visualizzazioni possono spesso connettersi direttamente al tuo storage dove sono memorizzate le tue tabelle Iceberg, ma più tipicamente interfaccia con il tuo motore di query per un'esperienza utente più semplificata. Infine, AI/ML ha lo stesso principio di progettazione dei motori di query.Questi strumenti AI/ML utilizzeranno le tabelle di Iceberg direttamente nell'archiviazione di oggetti senza migrazione.Mentre non tutti gli strumenti AI/ML utilizzano Iceberg in questo momento, c'è un interesse crescente nell'utilizzare Iceberg per l'IA/ , in particolare per la loro capacità di mantenere versioni multiple di modelli e set di dati senza difficoltà. ML carichi di lavoro ML carichi di lavoro Cosa c’è di speciale nell’Iceberg Apache Iceberg si distingue attraverso una combinazione di caratteristiche e principi di design che lo distinguono da alternative come Apache Hudi e Delta Lake. Iceberg offre un supporto completo per l'evoluzione dello schema, consentendo agli utenti di aggiungere, abbandonare, aggiornare o rinominare colonne senza richiedere una ristampa completa dei dati esistenti. Schema Evolution Iceberg supporta l'evoluzione delle partizioni, consentendo modifiche agli schemi di partizione nel tempo senza richiedere la riscrittura dei dati.Questa capacità consente l'ottimizzazione dinamica del layout dei dati a causa del cambiamento dei modelli di accesso. Partition Evolution Iceberg utilizza una struttura di metadati gerarchica, tra cui file manifesti, elenchi manifesti e file metadati. Questo design migliora la pianificazione e l'ottimizzazione delle query fornendo informazioni dettagliate sui file dati, facilitando l'accesso e la gestione efficienti dei dati. Metadata Management Progettato con apertura in mente, Iceberg è compatibile con vari motori di elaborazione come Apache Spark, Flink, Trino e Presto. Questa interoperabilità offre alle organizzazioni la flessibilità di scegliere gli strumenti che meglio si adattano alle loro esigenze ed efficacemente ridurre i prezzi e incoraggiare l'innovazione in questi prodotti. Multi-Engine Compatibility Motori di query Motori di query Come con tutti i formati di tavolo aperto, Iceberg beneficia di una comunità diversificata e attiva, contribuendo alla sua robustezza e al suo continuo miglioramento”. Open Source Community Storage oggetto e iceberg Lo storage oggetto costituisce la base delle moderne architetture del lago, fornendo la scalabilità, la durabilità e l'efficienza di costo necessaria per gestire enormi set di dati in molti ambienti.In un'architettura del lago, il livello di archiviazione svolge un ruolo critico nel garantire la durabilità e la disponibilità dei dati, mentre un formato di tabella aperta come Iceberg gestisce i metadati. è particolarmente adatto a questi requisiti. ad esempio, per i carichi di lavoro ad alta efficienza come la formazione dei modelli, il supporto di AIStor per S3 su RDMA assicura l'accesso a bassa latenza ai dati. Questa caratteristica rende la combinazione delle due tecnologie una soluzione molto efficace, in particolare per le pipeline AI e di analisi su larga scala. Aiuto Aiuto Prova da solo: i requisiti Dovrai installare Docker e Docker Compose. Quando sono necessari entrambi, è spesso più facile da installare Scarica e installa Docker Desktop dal sito ufficiale di Docker. Segui le istruzioni di installazione fornite nel programma di installazione per il tuo sistema operativo. Desktop di Docker Desktop di Docker Se preferisci, puoi anche verificare l'installazione di Docker e Docker Compose aprendo un terminale e eseguendo: docker --version docker-compose --version Iceberg Tutoriale Questa sezione dimostra come integrare Iceberg e AIStor per una robusta architettura del lago. per creare il nostro ambiente iniziale: Apache Iceberg Spark in fase di avvio rapido Apache Iceberg Spark in fase di avvio rapido Step 1: Setup with Docker Compose Passo 1: Impostazione con Docker Compose Segui il per lanciare un ambiente containerizzato con Spark e Iceberg pre-configurato. Il primo passo nella guida è quello di copiare le informazioni di seguito in un file e salvare come un file chiamato docker-compose.yml: Apache Iceberg Spark Guida rapida Apache Iceberg Spark Guida rapida version: "3" services: spark-iceberg: image: tabulario/spark-iceberg container_name: spark-iceberg build: spark/ networks: iceberg_net: depends_on: - rest - minio volumes: - ./warehouse:/home/iceberg/warehouse - ./notebooks:/home/iceberg/notebooks/notebooks environment: - AWS_ACCESS_KEY_ID=admin - AWS_SECRET_ACCESS_KEY=password - AWS_REGION=us-east-1 ports: - 8888:8888 - 8080:8080 - 10000:10000 - 10001:10001 rest: image: apache/iceberg-rest-fixture container_name: iceberg-rest networks: iceberg_net: ports: - 8181:8181 environment: - AWS_ACCESS_KEY_ID=admin - AWS_SECRET_ACCESS_KEY=password - AWS_REGION=us-east-1 - CATALOG_WAREHOUSE=s3://warehouse/ - CATALOG_IO__IMPL=org.apache.iceberg.aws.s3.S3FileIO - CATALOG_S3_ENDPOINT=http://minio:9000 minio: image: minio/minio container_name: minio environment: - MINIO_ROOT_USER=admin - MINIO_ROOT_PASSWORD=password - MINIO_DOMAIN=minio networks: iceberg_net: aliases: - warehouse.minio ports: - 9001:9001 - 9000:9000 command: ["server", "/data", "--console-address", ":9001"] mc: depends_on: - minio image: minio/mc container_name: mc networks: iceberg_net: environment: - AWS_ACCESS_KEY_ID=admin - AWS_SECRET_ACCESS_KEY=password - AWS_REGION=us-east-1 entrypoint: > /bin/sh -c " until (/usr/bin/mc config host add minio http://minio:9000 admin password) do echo '...waiting...' && sleep 1; done; /usr/bin/mc rm -r --force minio/warehouse; /usr/bin/mc mb minio/warehouse; /usr/bin/mc policy set public minio/warehouse; tail -f /dev/null " networks: iceberg_net: Successivamente, in una finestra terminale, passare al luogo in cui è stato salvato il file .yml e avviare i contenitori docker con questo comando: docker-compose up Puoi quindi eseguire i seguenti comandi per avviare una sessione Spark-SQL. Docker esec -it spark-iceberg spark-sql per il computer Step 2: Create a Table Passo 2: Creare un tavolo Apri una shell Spark e crea una tabella: CREATE TABLE my_catalog.my_table ( id BIGINT, data STRING, category STRING ) USING iceberg PARTITIONED BY (category); Controlla la console MinIO navigando verso e accedere con le credenziali del .yml: AWS_ACCESS_KEY_ID=admin, AWS_SECRET_ACCESS_KEY=password http://127.0.0.1:9001 http://127.0.0.1:9001 Qui, osservate il percorso iceberg/my_table/metadata creato per la tabella. Inizialmente, non esistono file di dati, solo i metadati che definiscono lo schema e le partizioni. Step 3: Insert Data Passo 3: Inserire i dati Inserisci alcuni dati mock: INSERT INTO my_catalog.my_table VALUES (1, 'a', 'music'), (2, 'b', 'music'), (3, 'c', 'video'); Questa operazione crea file di dati nelle partizioni appropriate (my_table/data/category=...) e aggiorna i metadati. Step 4: Query the Data Passo 4: Richiedi i dati Eseguire una query di base per convalidare: SELECT COUNT(1) AS count, data FROM my_catalog.my_table GROUP BY data; La tua uscita dovrebbe sembrare qualcosa del seguente: spark-sql ()> SELECT COUNT(1) AS count, data > FROM my_catalog.my_table > GROUP BY data; 1 c 1 b 1 a Time taken: 0.575 seconds, Fetched 3 row(s) Test delle caratteristiche chiave di Iceberg Ora che hai stabilito un laghetto di dati di base con dati che puoi manipolare, vediamo le caratteristiche che rendono Iceberg unico: Schema Evolution e Partition Evolution. Schema Evolution Schema di evoluzione Schema evolution è una delle funzioni più potenti e definitive di Apache Iceberg, che affronta un significativo punto di dolore nei sistemi di magazzino tradizionali. consente di modificare lo schema di una tabella senza richiedere ripetizioni di dati costose e di lunga durata, il che è particolarmente vantaggioso per i grandi set di dati. Questa capacità consente alle organizzazioni di adattare i loro modelli di dati man mano che le esigenze aziendali evolvono senza interrompere le query o le operazioni in corso. In Iceberg, le modifiche dello schema vengono gestite puramente a livello di metadati. a ogni colonna in una tabella viene assegnato un ID univoco, garantendo che le modifiche allo schema non influenzino i file di dati sottostanti. Ad esempio, se viene aggiunta una nuova colonna, Iceberg assegna un nuovo ID senza reinterpretare o riscrivere i dati esistenti. Ecco un esempio di come funziona in pratica l'evoluzione dello schema. Supponiamo di dover aggiungere una nuova colonna, acquirente, per memorizzare ulteriori informazioni sulle transazioni. Puoi eseguire il seguente comando SQL: ALTER TABLE my_catalog.my_table ADD COLUMN buyer STRING; Questa operazione aggiorna i metadati della tabella, consentendo ai nuovi file di dati di includere la colonna dell'acquirente. I file di dati più vecchi rimangono intatti e le query possono essere scritte per gestire sia i dati nuovi che quelli vecchi senza problemi. Allo stesso modo, se una colonna non è più necessaria, è possibile rimuoverla senza influenzare i dati memorizzati: ALTER TABLE my_catalog.my_table DROP COLUMN buyer; Questa azione aggiorna lo schema per escludere la colonna categoria. Iceberg assicura che tutti i metadati associati siano puliti mantenendo l'integrità delle query storiche che potrebbero ancora fare riferimento a versioni precedenti dei dati. L'evoluzione dello schema di Iceberg supporta anche il rinominamento delle colonne, il cambiamento dei tipi di colonna e il riordinamento dell'ordine delle colonne, tutto attraverso operazioni efficienti basate solo sui metadati.Queste modifiche vengono effettuate senza modificare i file dati, rendendo le modifiche dello schema istantanee ed economiche. Questo approccio è particolarmente vantaggioso in ambienti con frequenti cambiamenti di schema, come quelli guidati da esperimenti AI / ML, logica aziendale dinamica o esigenze normative in evoluzione. Partition Evolution Evoluzione delle partizioni Iceberg supporta l'evoluzione delle partizioni che può gestire i compiti noiosi e inclini agli errori di produrre valori di partizione per le righe in una tabella. Gli utenti si concentrano sull'aggiunta di filtri alle query che risolvono i problemi aziendali e non si preoccupano di come la tabella è partizionata. Iceberg gestisce le complessità della partizione e del cambiamento dello schema di partizione di una tabella per te, semplificando notevolmente il processo per gli utenti finali. Puoi definire la partizione o lasciare che Iceberg si prenda cura di te. Iceberg ama la partizione su un timestamp, come il tempo degli eventi. Le partizioni sono tracciate da snapshots nei manifesti. Le query non dipendono più dal layout fisico di una tabella. A causa di questa separazione tra tabelle fisiche e logiche, le tabelle di Iceberg possono evolvere le partizioni nel tempo man mano che vengono aggiunti più dati. ALTER TABLE my_catalog.my_table ADD COLUMN month int AFTER buyer; ALTER TABLE my_catalog.my_table ADD PARTITION FIELD month; Ora abbiamo due schemi di partizione per la stessa tabella. Da ora in poi, i piani di query sono divisi, utilizzando il vecchio schema di partizione per interrogare i vecchi dati, e il nuovo schema di partizione per interrogare i nuovi dati. Iceberg si prende cura di questo per voi - le persone che interrogano la tabella non hanno bisogno di sapere che i dati sono memorizzati utilizzando due schemi di partizione. Iceberg fa questo attraverso una combinazione di clausole WHERE dietro le quinte e filtri di partizione che eliminano i file di dati senza corrispondenze. Time Travel and Rollback Viaggi nel tempo e rollback Ogni scrittura alle tabelle di Iceberg crea nuovi snapshots. Snapshots sono come le versioni e possono essere utilizzati per viaggiare nel tempo e tornare indietro proprio come facciamo con le funzionalità di versione AIStor. Il modo in cui vengono gestiti gli snapshots è impostando scadeSnapshot in modo che il sistema sia ben mantenuto. Time travel consente query riproducibili che utilizzano esattamente lo stesso snapshot della tabella, o consente agli utenti di esaminare facilmente i cambiamenti. As tables are changed, Iceberg tracks each version as a snapshot and then provides the ability to time travel to any snapshot when querying the table. This can be very useful if you want to run historical queries or reproduce the results of previous queries, perhaps for reporting. Time travel can also be helpful when testing new code changes because you can test new code with a query of known results. Per visualizzare gli snapshots salvati per una tabella eseguire la seguente query: SELECT * FROM my_catalog.my_table.snapshots; La tua uscita dovrebbe sembrare una cosa del genere: 2025-01-10 00:35:03.35 4613228935063023150 NULL append s3://warehouse/my_catalog/my_table/metadata/snap-4613228935063023150-1-083e4483-566f-4f5c-ab47-6717577948cb.avro {"added-data-files":"2","added-files-size":"1796","added-records":"3","changed-partition-count":"2","spark.app.id":"local-1736469268719","total-data-files":"2","total-delete-files":"0","total-equality-deletes":"0","total-files-size":"1796","total-position-deletes":"0","total-records":"3"} Time taken: 0.109 seconds, Fetched 1 row(s) Alcuni esempi : -- time travel to October 26, 1986 at 01:21:00 SELECT * FROM my_catalog.my_table TIMESTAMP AS OF '1986-10-26 01:21:00'; -- time travel to snapshot with id 10963874102873 SELECT * FROM prod.db.table VERSION AS OF 10963874102873; È possibile eseguire letture incrementali utilizzando snapshots, ma è necessario utilizzare Spark, non Spark-SQL. scala> spark.read() .format(“iceberg”) .option(“start-snapshot-id”, “10963874102873”) .option(“end-snapshot-id”, “10963874102994”) .load(“s3://iceberg/my_table”) You can also roll back the table to a point in time or to a specific snapshot, as in these two examples CALL my_catalog.system.rollback_to_timestamp(‘my_table’, TIMESTAMP ‘2022-07-25 12:15:00.000’); CALL my_catalog.system.rollback_to_snapshot(‘my_table’, 527713811620162549); Espressione SQL Iceberg supporta tutti i comandi SQL espressivi come la rimozione a livello di riga, la fusione e l'aggiornamento, e la cosa più importante da evidenziare è che Iceberg supporta sia le strategie Eager che le strategie pigre. Possiamo codificare tutte le cose che abbiamo bisogno di eliminare (ad esempio, GDPR o CCPA), ma non ri-scrivere tutti quei file di dati immediatamente, possiamo raccogliere la spazzatura come necessario e questo aiuta nell'efficienza sulle grandi tabelle supportate da Iceberg. Ad esempio, è possibile eliminare tutti i record in una tabella che corrispondono a un predicato specifico. DELETE FROM my_catalog.my_table WHERE category = 'video'; In alternativa, è possibile utilizzare CREATE TABLE AS SELECT o REPLACE TABLE AS SELECT per realizzare questo: CREATE TABLE my_catalog.my_table_music AS SELECT * FROM my_catalog.my_table WHERE category = 'music'; Puoi combinare due tavole molto facilmente: MERGE INTO my_catalog.my_data pt USING (SELECT * FROM my_catalog.my_data_new) st ON pt.id = st.id WHEN NOT MATCHED THEN INSERT *; Ingegneria dei dati Iceberg è la base per lo standard di tabella analitica aperta e utilizza il comportamento SQL e applica i fondamenti del data warehouse per risolvere i problemi prima di saperlo.Con l'ingegneria dei dati dichiarativi possiamo configurare le tabelle e non preoccuparci di cambiare ogni motore per soddisfare le esigenze dei dati. Questo sblocca l'ottimizzazione automatica e le raccomandazioni. Per esaminare la cronologia di una tabella, snapshot e altri metadati, Iceberg supporta la querying metadata. le tabelle dei metadati vengono identificate aggiungendo il nome della tabella dei metadati (ad esempio, storia) dopo il nome della tabella originale nella query. Per visualizzare i file dati di una tabella: SELECT * FROM my_catalog.my_table.files; Per mostrare i manifesti: SELECT * FROM my_catalog.my_table.manifests; Mostra la storia della tavola SELECT * FROM my_catalog.my_table.history; Per visualizzare snapshots SELECT * FROM my_catalog.my_table.snapshots; Puoi anche unire gli snapshot e la storia della tabella per vedere l'applicazione che ha scritto ogni snapshot select h.made_current_at, s.operation, h.snapshot_id, h.is_current_ancestor, s.summary['spark.app.id'] from my_catalog.my_table.history h join my_catalog.my_table.snapshots s on h.snapshot_id = s.snapshot_id order by made_current_at; Ora che hai imparato le basi, carica alcuni dei tuoi dati in Iceberg, quindi impara di più dal . Iceberg documentazione Integrazioni Diversi motori di query e di esecuzione hanno implementato connettori Iceberg, rendendo facile la creazione e la gestione delle tabelle Iceberg. di di di di di E la lista sta crescendo. Spark Ottimo Presto Trino sogno Snowflake Questo ampio panorama di integrazione assicura che le organizzazioni possano adottare Apache Iceberg senza restringersi a un singolo motore di elaborazione, promuovendo la flessibilità e nella loro infrastruttura di dati. interoperabilità interoperabilità catalogo It would be remiss in any definitive guide not to mention catalogs. Iceberg catalogs are central to managing table metadata and facilitating connections between datasets and query engines. These catalogs maintain critical information such as table schemas, snapshots, and partition layouts, enabling Iceberg’s advanced features like time travel, schema evolution, and atomic updates. Several catalog implementations are available to meet diverse operational needs. For instance, Polaris offers a scalable, cloud-native cataloging solution tailored to modern data infrastructures, while Dremio Nessie introduces versioning with Git-like semantics, enabling teams to track changes to data and metadata with precision. Traditional solutions like Hive Metastore are still widely used, particularly for backward compatibility with legacy systems. È cool costruire laghi di dati con Iceberg e AIStor La crescente comunità open source e il crescente numero di integrazioni da più provider cloud e framework applicativi significa che è il momento di prendere Iceberg sul serio e iniziare a sperimentare, imparare e pianificare l'integrazione con l'architettura del data lake esistente. Come si inizia con Iceberg e AIStor, si prega di raggiungere e condividere le vostre esperienze o porre domande attraverso . our Slack channel