Cos'è un open lakehouse? Gli standard di dati aperti, spiegati.

Un open lakehouse è un data lakehouse in cui ogni livello (archiviazione, formato di tabella, motore, catalogo e gli strumenti di ML e AI sovrastanti) è basato su standard aperti, in modo che nessun livello sia vincolato a un singolo fornitore.

Un data lakehouse unisce l'archiviazione scalabile e a basso costo di un data lake con le funzionalità di gestione e le garanzie transazionali di un data warehouse. Un open lakehouse aggiunge un'ulteriore condizione: ogni livello dell'architettura è basato su standard aperti. I dati, i motori che li elaborano, il catalogo che li gestisce e gli strumenti per creare modelli e applicazioni sovrastanti sono tutti open source, quindi nessuno di essi dipende da un singolo fornitore.

La parola "open" viene usata molto spesso, e non sempre in modo onesto. Ecco perché vale la pena fare chiarezza. Un formato può essere definito aperto e tuttavia essere utilizzabile all'atto pratico solo tramite un unico motore. Un catalogo può essere definito aperto e comunque essere vincolato a una sola piattaforma. L'archiviazione rimane portabile solo fino a quando i costi di trasferimento dei dati in uscita non ne rendono costoso lo spostamento. Un open lakehouse è ciò che si ottiene quando questi vincoli vengono rimossi a ogni livello. Più di recente, questa stessa apertura si è estesa ai carichi di lavoro di AI e agenti che vengono ora creati sui dati.

In cosa un open lakehouse si differenzia da un data lake e da un data warehouse?

Un open lakehouse unisce l'affidabilità di un data warehouse e l'archiviazione a basso costo di un data lake in un'unica architettura, aggiungendo poi una regola che manca agli altri due: ogni livello deve essere aperto e intercambiabile. Un data warehouse contiene tabelle pulite e strutturate per la reportistica, con una governance solida ma costi elevati e poco spazio per i dati non strutturati. Un data lake conserva tutto il resto, come file grezzi, log e immagini, in modo economico e su scala, ma senza transazioni, garanzie sugli schemi o una governance significativa.

Il lakehouse non è nato dal nulla. Per anni, i team hanno affiancato i due sistemi, copiando i dati tra l'uno e l'altro e riconciliando due diverse versioni della verità. Il data lakehouse li ha uniti: gestione e transazioni in stile data warehouse applicate direttamente all'archiviazione economica del lake. L'open lakehouse rappresenta l'evoluzione successiva di questa idea. Mantiene l'architettura combinata e aggiunge la regola sopra indicata, in modo che l'affidabilità di un warehouse e la convenienza economica di un lake siano garantite senza vincolare alcun livello a un singolo fornitore.

Lakehouse open vs. proprietario: qual è la differenza?

La differenza tra un lakehouse open e uno proprietario si riduce a una sola domanda: chi può leggere i tuoi dati e quali motori possono essere eseguiti su di essi. Un lakehouse proprietario archivia i dati in formati che solo un fornitore può leggere, quindi cambiare strumenti può richiedere la riscrittura o la riesportazione di tutti i dati. Un open lakehouse archivia i dati in formati aperti che qualsiasi motore compatibile può leggere, consentendo di aggiungere, sostituire o rimuovere un motore di query senza dover riscrivere i dati.

Cosa rende aperto un lakehouse?

Tre elementi distinguono un open lakehouse da uno proprietario: formati aperti, motori aperti e una governance unificata.

Iniziamo dai formati aperti. I dati risiedono in formati di tabella aperti, Delta Lake e Apache Iceberg®, basati su formati di file aperti come Apache Parquet®. Le specifiche sono pubbliche, quindi qualsiasi motore che le implementi può leggere e scrivere i dati, non solo il runtime di un singolo fornitore.

Poi ci sono i motori aperti: anche i sistemi che eseguono l'elaborazione sono open source. Apache Spark® copre batch, streaming, SQL e machine learning in un unico runtime e, poiché le tabelle sottostanti sono aperte, motori come DuckDB, Trino o PyIceberg possono lavorare sugli stessi dati senza bisogno di una seconda copia.

La governance unificata è la parte che i team spesso sottovalutano. Un unico catalogo gestisce il controllo degli accessi, la lineage e l'auditing per ogni formato e motore, in modo che la governance sia associata ai dati stessi anziché dover essere ricreata all'interno di ogni strumento che li utilizza. Unity Catalog svolge questo ruolo in questo contesto.

Unendo tutti questi elementi, il risultato è aperto dal livello di archiviazione a quello di fruizione (serving): object storage alla base, un formato di tabella aperto sopra di esso, un motore di elaborazione aperto, un catalogo aperto per la governance e strumenti aperti per analytics, machine learning e applicazioni di AI in cima.

Il termine "open" equivale a open source?

Non proprio, e la differenza è importante. Open source descrive la licenza del codice di un progetto. L'apertura (open), nel contesto del lakehouse, è un concetto più ampio: copre formati di file e tabelle aperti, API aperte e modalità standard di connessione per gli strumenti, oltre a un ecosistema in cui molti motori lavorano sui medesimi dati. Una piattaforma può essere costruita a partire da progetti open source e comunque bloccare i tuoi dati, ad esempio archiviandoli in un layout che solo il proprio motore è in grado di leggere correttamente. La vera prova di apertura è semplice: poter leggere i dati con qualsiasi strumento compatibile e passare da uno strumento all'altro senza doverli riscrivere.

Formato di tabella aperto vs. open lakehouse: qual è la differenza?

Questi due termini vengono spesso usati come sinonimi, ma non dovrebbero esserlo. Un formato di tabella aperto è un singolo livello: aggiunge funzionalità simili a quelle di un database (aggiornamenti affidabili, modifiche dello schema e cronologia) sopra i file nell'object storage. Un open lakehouse è tutto ciò che circonda quel livello: l'archiviazione sottostante e l'elaborazione (compute), il catalogo e la governance sovrastanti. Il formato di tabella è un componente. Il lakehouse è l'intero stack.

Due termini della tabella: ACID significa che le modifiche ai dati vengono completate in modo affidabile senza corrompere la tabella, mentre time travel significa che è possibile visualizzare o ripristinare i dati così come apparivano in un momento precedente.

Quali standard aperti alimentano un open lakehouse?

Questa architettura di riferimento è basata su cinque standard open source, ciascuno gestito da una fondazione neutrale (la Apache Software Foundation o la Linux Foundation) e ciascuno relativo a un livello diverso dello stack. Un open lakehouse è affidabile solo quanto i progetti su cui si basa, e non si tratta di progetti di nicchia: sono standard su cui si appoggia già gran parte del settore, e la maggior parte di essi è stata creata da Databricks. Non è un vanto infondato, è un dato verificabile: all'inizio del 2026, Apache Spark è utilizzato da circa l'80% delle aziende Fortune 500 ed è il motore più ampiamente adottato per l'elaborazione dei dati su larga scala. MLflow supera i 30 milioni di download al mese. Delta Lake e Apache Iceberg coprono insieme la stragrande maggioranza delle tabelle lakehouse in produzione, con Delta Lake che detiene la base installata più ampia.

Insieme, si parla di oltre 90.000 stelle su GitHub e decine di milioni di download al mese. Ecco una panoramica dello stato di ciascun progetto (stelle su GitHub all'inizio del 2026):

Apache Spark

Apache Spark® è il motore di elaborazione. È stato creato presso l'UC Berkeley AMPLab nel 2009 dal team che ha poi fondato Databricks, ed è stato donato alla Apache Software Foundation, dove è diventato uno dei motori più utilizzati per l'elaborazione dei dati su larga scala. Un singolo runtime Spark gestisce job batch, streaming, SQL e machine learning, motivo per cui un team può eseguire un unico motore anziché mantenere un sistema diverso per ogni tipo di carico di lavoro. Nel lakehouse, Spark legge i dati grezzi, li perfeziona in più fasi e riscrive i risultati come tabelle aperte.

Delta Lake

Delta Lake è un formato di tabella che fa sì che lo storage di oggetti si comporti come un database invece che come un insieme di file. Oltre ai normali file Parquet, aggiunge transazioni ACID, applicazione dello schema e time travel, in modo che i job simultanei non corrompano le rispettive scritture e che una tabella possa essere interrogata per come appariva in un momento precedente. Una libreria complementare, Delta Kernel, racchiude la logica di lettura e scrittura in un componente indipendente dal motore, semplificando il supporto del formato da parte di motori diversi da Spark. Delta Lake è stato creato da Databricks, che ne rimane il principale contributore, ed è gestito come progetto della Linux Foundation.

Apache Iceberg

Iceberg è un secondo formato di tabella, progettato per tabelle analitiche di grandissime dimensioni e per spostarsi agevolmente tra i motori. È nato in Netflix anziché in Databricks, ed è ora un progetto Apache ampiamente adottato. Databricks is a major contributor, incluso il team fondatore di Iceberg che si è unito a seguito dell'acquisizione di Tabular. La sua specifica di tabella e il catalogo REST consentono a diversi motori di condividere facilmente le stesse tabelle, motivo per cui viene utilizzato ovunque sia presente più di un motore di query. Supportare sia Delta Lake che Iceberg significa che un team non deve vincolarsi a un unico formato fin dal primo giorno e convivere con tale scelta per sempre.

Unity Catalog

Unity Catalog è il livello di governance. Mantiene le policy di accesso, la distribuzione delle credenziali (credential vending) e la lineage in un unico posto, e i motori accedono ai dati attraverso di esso anziché aggirarlo. Poiché le regole risiedono nel catalogo anziché all'interno di un singolo motore, il controllo degli accessi e la lineage rimangono coerenti indipendentemente dal fatto che una query provenga da Spark, DuckDB o da un altro client. Unity Catalog è stato creato da Databricks ed è ora un progetto open source sotto la LF AI & Data Foundation, con una versione gestita disponibile su Databricks. La release open è più recente rispetto al prodotto gestito e alcune funzionalità di governance sono ancora in fase di perfezionamento, quindi vale la pena verificare il progetto open rispetto ai propri requisiti.

Unity Catalog non è l'unico catalogo aperto. Apache Polaris, Project Nessie, Hive Metastore e AWS Glue svolgono lo stesso ruolo, e il catalogo REST di Iceberg si sta affermando come interfaccia condivisa tra di essi. Un lakehouse aperto può utilizzare uno qualsiasi di essi. Questa architettura di riferimento utilizza Unity Catalog perché gestisce gli asset di dati, ML e AI insieme sotto un unico modello, ma il livello del catalogo è realmente intercambiabile.

MLflow

MLflow è il livello per il machine learning e l'AI. Gestisce il tracciamento degli esperimenti, il packaging dei modelli, un registro dei modelli, la valutazione e il serving, e lo stesso meccanismo ora si estende agli agenti AI: tracciando ciò che un agente ha fatto, valutando il suo output rispetto a dei valutatori e posizionando davanti ad esso un gateway con limiti di budget e guardrail. Eseguire modelli e agenti sulla stessa piattaforma aperta che gestisce i dati, anziché in uno stack separato e isolato, è in gran parte ciò che rende diversa questa versione del lakehouse. MLflow è stato creato da Databricks, che ne rimane il principale contributore, ed è un progetto della Linux Foundation.

Come funzionano insieme i livelli di un lakehouse aperto?

I livelli si connettono tramite interfacce aperte, quindi si integrano tra loro senza la necessità di soluzioni proprietarie e ognuno di essi può essere sostituito senza interferire con gli altri. Questo è ciò che trasforma cinque progetti in un'unica architettura.

Inizia con i dati. Spark scrive le tabelle nello storage di oggetti come Delta Lake o Iceberg. Poiché questi formati sono aperti, e poiché Delta Kernel e il catalogo REST di Iceberg li espongono in modo neutrale, altri motori leggono direttamente gli stessi file. Non è necessario copiare prima nulla in un archivio proprietario e non è previsto alcun passaggio di esportazione in uscita.

La governance copre l'intero sistema. Ogni motore accede ai dati tramite Unity Catalog, quindi una policy scritta una sola volta viene applicata ovunque. Introdurre un nuovo motore di query significa semplicemente indirizzarlo verso il catalogo, senza dover ricreare da zero le regole di accesso e la lineage.

Modelli e agenti attingono agli stessi dati gestiti. Un modello addestrato in MLflow legge le tabelle Gold prodotte da Spark. Un agente che risponde a una domanda esegue query tramite Unity Catalog in base alle stesse policy applicate a un analista umano. La lineage che collega l'input grezzo a un modello distribuito o alla risposta di un agente viene registrata lungo il percorso. Il livello AI non è aggiunto come un elemento separato alla fine; legge e scrive attraverso la stessa superficie gestita di tutto il resto.

Il vantaggio pratico è l'indipendenza tra i livelli. Un team può cambiare i motori di elaborazione, aggiungere un motore di query, adottare un secondo formato di tabella o sostituire il framework di un modello senza dover riprogettare la piattaforma dei livelli superiori o inferiori, poiché ogni livello dipende solo dall'interfaccia aperta di quello adiacente.

Quali sono i vantaggi di un lakehouse aperto?

Il vantaggio principale di un lakehouse aperto è la flessibilità di scelta: i team mantengono aperte le proprie opzioni man mano che crescono le esigenze di dati e AI, poiché nessun singolo livello è vincolato a un fornitore. I vantaggi specifici:

• Nessun lock-in: i formati aperti consentono ai team di cambiare strumenti senza migrare o riscrivere i dati.
• Costi inferiori: un'unica copia dei dati in uno storage economico evita la duplicazione tra i sistemi.
• Multi-motore: molti motori possono essere eseguiti sugli stessi dati per BI, SQL e machine learning.
• Governance unificata: un unico catalogo applica controlli di accesso e lineage coerenti.
• Pronto per l'AI: dati affidabili e unificati supportano l'addestramento dei modelli, i feature store e gli agenti AI.
• Libertà del cloud: i carichi di lavoro possono essere eseguiti su più cloud senza dover essere ricostruiti.

Come scala un lakehouse aperto con la crescita?

Un lakehouse aperto scala aggiungendo livelli, non riprogettando la piattaforma: si attivano più livelli man mano che il lavoro lo richiede, e i primi livelli rimangono al loro posto all'arrivo di quelli successivi. La stessa struttura si adatta a un team di due persone così come a un'azienda distribuita su più regioni; la differenza sta solo nel numero di livelli attivati.

• ETL di base. Storage di oggetti, tabelle Delta e Spark. I dati grezzi arrivano nel livello Bronze, vengono ripuliti nel livello Silver e vengono serviti dal livello Gold. Questa configurazione medallion costituisce di per sé uno stack aperto completo.
• Streaming e batch insieme. Quando i dati devono essere elaborati all'arrivo, Spark Structured Streaming e la modalità Real-Time eseguono lo streaming insieme al batch sullo stesso motore, con le Spark Declarative Pipelines che descrivono le trasformazioni. Non è richiesto un secondo sistema di streaming.
• Un catalogo condiviso e i primi agenti. Quando analisti, applicazioni, dashboard e machine learning hanno tutti bisogno degli stessi dati, Unity Catalog diventa il livello di governance comune attraverso cui leggono. Di solito è anche qui che compaiono i primi agenti, che monitorano la qualità dei dati, creano bozze di pipeline ed esplorano la lineage, il tutto gestito attraverso il catalogo come qualsiasi altro consumer.
• Scalabilità enterprise. Tra diverse aree geografiche e cloud, Unity Catalog aggiunge la distribuzione delle credenziali (credential vending), criteri dettagliati, Lakehouse Federation e Delta Sharing, mentre Spark viene eseguito come flotta gestita su Kubernetes. La base è la stessa; ci sono solo più governance e più risorse di calcolo.

In che modo l'AI si integra in un open lakehouse?

In un open lakehouse, le applicazioni e gli agenti AI sono workload di prima classe gestiti esattamente come qualsiasi altro data consumer, non un sistema separato aggiunto in un secondo momento. La maggior parte delle spiegazioni sul lakehouse si ferma alla business intelligence e al machine learning, il che ormai sembra un diagramma del 2021 con una casella AI appiccicata di lato. Trattare gli agenti come consumer gestiti degli stessi dati è ciò che rende davvero attuale questa versione.

Poiché MLflow viene eseguito sulla piattaforma che gestisce i dati, un agente è soggetto alle stesse regole di tutti gli altri. Legge tramite Unity Catalog, quindi vede solo ciò che i suoi permessi consentono. La sua attività viene tracciata e le sue risposte vengono valutate dai sistemi di valutazione in MLflow, nello stesso modo in cui viene monitorata la qualità di un modello, e il gateway di fronte ad esso può limitare la spesa e applicare guardrail. Niente di tutto questo richiede uno stack AI separato con una propria copia dei dati e una governance più debole, che di solito è l'alternativa comune.

In concreto:

• Attribuzione: un agente viene eseguito con la propria identità, quindi ogni azione viene ricondotta a un principal anziché essere nascosta dietro un account condiviso.
• Credenziali con ambito limitato: il catalogo distribuisce credenziali temporanee e limitate anziché chiavi a lungo termine, in modo che l'accesso di un agente possa essere limitato e revocato come quello di chiunque altro.
• Lineage: le letture e le scritture di un agente vengono registrate, consentendo di ricostruire il percorso dai dati di origine, attraverso il recupero, fino a una risposta per scopi di audit.
• Spesa e guardrail: i limiti di budget e i controlli sui contenuti risiedono nel gateway, al di fuori del codice dell'agente.
• Modalità di errore: poiché l'accesso avviene tramite il catalogo, ciò che accade quando il catalogo non è disponibile è una scelta di progettazione esplicita, come il rifiuto dell'accesso anziché il ricorso a letture dirette e non gestite.

L'identità di un agente può essere il proprio service principal o una delega dell'utente che lo ha richiamato (un modello "on-behalf-of"), e questa scelta determina il modo in cui le sue azioni appaiono nel log di audit. Inoltre, il percorso MLflow autonomo descritto più avanti offre tracciamento e valutazione senza un lakehouse, ma il controllo degli accessi imposto dal catalogo sopra descritto si applica solo dopo aver implementato Unity Catalog.

In pratica, questo è molto concreto. Un agente richiede una colonna per la quale non ha l'autorizzazione; Unity Catalog nega la lettura e il log di audit registra l'identità dell'agente, la tabella e la colonna richieste, l'ora e la decisione di rifiuto. Per le query consentite, la lineage collega la risposta alle specifiche tabelle Gold lette.

Il punto non è che gli agenti sostituiscano il resto dell'architettura, ma che si integrino in essa. Un agente è un ulteriore consumer di dati gestiti, creato e monitorato con gli stessi strumenti aperti delle pipeline e dei modelli circostanti.

Hai davvero bisogno di un open lakehouse?

Non sempre: un open lakehouse è la scelta giusta quando l'apertura e la scalabilità offrono un reale valore aggiunto, ed è eccessivo quando non lo fanno. È un'ottima soluzione quando si hanno molti tipi di dati, più team o engine che condividono gli stessi dati, requisiti multi-cloud o il chiaro obiettivo di evitare il lock-in. Può essere eccessivo per un workload ridotto e basato su un singolo strumento, con dati semplici e strutturati e senza la necessità di spostarsi tra strumenti diversi.

Un approccio pratico consiste nel iniziare con un progetto pilota a portata limitata legato a un requisito reale, ad esempio federando una sorgente esistente o spostando una singola pipeline, prima di impegnarsi in una migrazione completa. L'architettura è progettata per essere adottata un livello alla volta, quindi la scelta non è tra tutto o niente.

È possibile migrare a un open lakehouse in modo incrementale?

Sì. Un open lakehouse è progettato per integrarsi con ciò che è già in esecuzione, un livello alla volta, invece di richiedere lo smantellamento dello stack esistente. Pochi team partono da zero; la maggior parte utilizza già un data warehouse cloud, EMR, un catalogo dati o ha una migrazione a Iceberg completata a metà.

• Su un data warehouse cloud esistente: federalo tramite Unity Catalog in modo che la governance e la lineage lo raggiungano, lasciando i dati dove si trovano.
• Su EMR Spark: sposta solo il livello di creazione delle pipeline su Spark Declarative Pipelines e mantieni i cluster già in esecuzione.
• Su un catalogo separato: fai in modo che Unity Catalog emetta eventi di lineage aperti che il tuo catalogo esistente possa importare, in modo che i due lavorino fianco a fianco.
• A metà di una migrazione a Iceberg: posiziona Unity Catalog sopra il catalogo che hai già configurato e non modificare nient'altro.

Il passaggio è lo stesso ogni volta: sostituisci un livello con una versione aperta e lascia invariato il resto finché non c'è un motivo per modificarlo.

Cosa c'è di veramente difficile in un open lakehouse?

Un open lakehouse presenta alcune complessità reali ed è giusto parlarne apertamente. I formati di tabella aperti accumulano file di piccole dimensioni e richiedono compattazione e manutenzione regolari. La scrittura sulle stesse tabelle da più engine contemporaneamente è ancora meno matura rispetto alla lettura, quindi le scritture multi-engine richiedono attenzione. Le versioni open source di alcuni componenti sono leggermente indietro rispetto alle loro versioni gestite per quanto riguarda alcune funzionalità. Inoltre, l'hosting autonomo (self-hosting) dell'intero stack comporta un reale lavoro operativo. L'apertura a livello di formato e catalogo non elimina completamente ogni forma di lock-in. I runtime gestiti, gli acceleratori di query proprietari e i prezzi delle risorse di calcolo sono gli elementi con cui le piattaforme continuano a vincolarti, e vale la pena valutarli separatamente dai livelli aperti. Nulla di tutto ciò va contro l'architettura: è semplicemente il costo reale della gestione diretta di ogni livello.

Come puoi gestire autonomamente un open lakehouse?

Poiché ogni livello è open source, puoi gestire l'intera infrastruttura autonomamente. Esiste un'implementazione di riferimento aperta che configura i vari livelli insieme:

Questa avvia Apache Spark, Apache Kafka®, Apache Airflow®, Apache Iceberg, Delta Lake, Unity Catalog e MLflow in locale con Docker, con configurazioni per il deployment nel cloud. Se all'inizio hai bisogno solo del livello AI, puoi iniziare con il solo MLflow: sono sufficienti un pip install e poche righe in un'applicazione esistente, per poi aggiungere il resto in seguito.

Ad esempio, puoi indirizzare MLflow verso un agente esistente senza un lakehouse sottostante:

Il tuo agente LangGraph o OpenAI viene eseguito senza modifiche e i relativi tracciamenti, prompt e chiamate agli strumenti vengono visualizzati in MLflow. Postgres, il vector store e il model provider rimangono dove sono. Aggiungerai il lakehouse gestito sottostante solo quando i tuoi agenti avranno bisogno di dati aziendali gestiti.

Il repository di riferimento è rilasciato con licenza Apache 2.0 ed è gestito dal team di developer relations di Databricks. Non si tratta di una nuova tecnologia: sono i cinque progetti collaudati sopra menzionati, integrati con Docker per quando desideri avere l'intero stack in un unico posto. Ogni livello è anche indipendente; il pacchetto è una comodità, non una dipendenza. Gestire autonomamente un open lakehouse è fattibile, ma richiede un impegno reale, e il repository lo affronta in questo modo: include pattern di alta disponibilità, configurazioni di deployment e osservabilità, in modo che il self-hosting sia un percorso supportato e non solo una dichiarazione d'intenti.

Cosa cambia un open lakehouse per il tuo ruolo?

• Se scrivi SQL o dbt: Spark Declarative Pipelines ti offre la stessa creazione dichiarativa e SQL-first che conosci da dbt, e aggiunge lo streaming insieme al batch e a SQL e Python completi su un unico engine, il tutto su tabelle aperte gestite che puoi comunque interrogare dal tuo strumento di BI esistente.
• Se crei pipeline di dati: le sviluppi una sola volta, ad esempio con Spark Declarative Pipelines, ed esegui batch e streaming su un unico engine.
• Se crei modelli o agenti: li crei, li valuti e ne esegui il serving in MLflow a partire dagli stessi dati gestiti, con le stesse regole di accesso di tutti gli altri.
• Se gestisci tu la piattaforma: aggiungi livelli man mano che l'attività cresce e puoi sostituirne uno qualsiasi senza dover migrare il resto.

Quali piattaforme supportano gli open lakehouse?

Diverse piattaforme ora implementano i principi dell'open lakehouse. Databricks, Snowflake, Google Cloud, Microsoft Fabric, Cloudera, Dremio, Starburst e Qlik offrono tutti prodotti in questo ambito. Si tratta di prodotti basati sulle idee dell'open lakehouse, non sull'architettura stessa, e differiscono per il livello di apertura effettivo di ciascun livello.

Databricks ha creato la categoria dei lakehouse e offre prestazioni di livello data warehouse su una base open source, utilizzando Delta Lake e Apache Iceberg per l'archiviazione e Unity Catalog per la governance. La piattaforma Databricks offre questo servizio in modalità gestita per i team che preferiscono non gestire lo stack autonomamente.

Domande frequenti

Un open lakehouse è la stessa cosa di un data lakehouse?

Un data lakehouse è l'architettura: una gestione in stile data warehouse sull'archiviazione del data lake. Un open lakehouse è un data lakehouse in cui ogni livello (archiviazione, formato delle tabelle, motore, catalogo e gli strumenti di ML e AI sovrastanti) è open source e intercambiabile, in modo che nessun livello dipenda da un singolo fornitore.

Iceberg o Delta Lake: quale dovrei usare?

Entrambi sono formati di tabella aperti con transazioni ACID, evoluzione dello schema e time travel, e un open lakehouse può utilizzarli uno o entrambi. Delta Lake si integra strettamente con Spark e, tramite Delta Kernel, è sempre più leggibile da altri motori; Iceberg è progettato per un ampio accesso multi-motore attraverso il suo catalogo REST. Supportarli entrambi significa non dover fare una scelta immediata.

Ho bisogno di tutti e cinque i progetti per avere un open lakehouse?

No. L'architettura è pensata per crescere. Un open lakehouse di base è composto solo da un object storage, un formato di tabella e Spark. Unity Catalog e MLflow vengono aggiunti quando la governance tra molti utenti e i carichi di lavoro di machine learning o AI entrano a far parte del quadro.

Posso eseguire un open lakehouse senza Databricks?

Sì. Ogni livello è open source e viene eseguito sulla tua infrastruttura. L'implementazione di riferimento avvia l'intero stack localmente con Docker, e il livello di machine learning può essere utilizzato da solo con un singolo pip install. Databricks offre versioni gestite di questi componenti aperti, ma l'auto-hosting è un percorso supportato.

Come si collocano gli agenti AI in un open lakehouse?

Gli agenti sono trattati come utenti di dati regolamentati, non come un sistema separato. Leggono tramite Unity Catalog in base alle stesse policy applicate alle persone e ad altri motori, e vengono creati, tracciati e valutati in MLflow insieme ai modelli, mantenendo il livello AI all'interno della stessa architettura aperta e regolamentata anziché come elemento esterno aggiunto.

Quanto costa un open lakehouse?

I componenti open source sono gratuiti da utilizzare con licenze Apache 2.0 e Linux Foundation; i tuoi costi saranno l'object storage, le risorse di calcolo che utilizzi e l'impegno operativo per mantenere lo stack. Gestirlo autonomamente sostituisce i costi di licenza con il tempo di progettazione, mentre una piattaforma gestita come Databricks sostituisce il tempo di progettazione con un abbonamento, sulla stessa base aperta.

Un open lakehouse è pronto per la produzione?

Sì. I cinque progetti principali sono standard maturi già in esecuzione in produzione su larga scala, ad esempio Apache Spark in circa l'80% delle aziende Fortune 500 e MLflow con oltre 30 milioni di download al mese. Le principali considerazioni per la produzione sono di tipo operativo: manutenzione e compattazione delle tabelle, attenzione alle scritture multi-motore e il lavoro di auto-hosting se non si utilizza un servizio gestito.

Apache, Apache Spark, Apache Iceberg, Apache Kafka, Apache Airflow, Apache Parquet e il logo Apache feather sono marchi registrati o marchi di fabbrica di Apache Software Foundation negli Stati Uniti e/o in altri paesi. Delta Lake, MLflow e Unity Catalog sono marchi di LF Projects, LLC. Tutti gli altri marchi appartengono ai rispettivi proprietari.

Per vedere il tutto in funzione, clona l'architettura di riferimento ed eseguila end-to-end su github.com/open-lakehouse/open-lakehouse. Se parti dal lato AI, MLflow da solo è un ottimo punto di partenza, e il resto dello stack sarà pronto quando i tuoi modelli e agenti avranno bisogno di dati regolamentati alle spalle. Preferisci un percorso completamente gestito? La stessa base aperta alimenta la piattaforma lakehouse Databricks.

Esplora l'architettura di riferimento

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