Il problema che risolve l’architettura lakehouse
Per anni le aziende con esigenze di analisi avanzata hanno dovuto scegliere tra due architetture con compromessi opposti.
Il data warehouse tradizionale offre prestazioni eccellenti nelle query SQL, una governance solida, qualità del dato garantita e strumenti di BI maturi. Ma è costoso su larga scala, difficile da adattare ai dati non strutturati e non è progettato per l’addestramento di modelli di machine learning.
Il data lake offre un’archiviazione economica per qualsiasi tipo di dato (strutturato, semistrutturato, non strutturato), flessibilità per i carichi di lavoro di machine learning e capacità di scalare su volumi enormi. Ma senza una gestione attenta diventa una «data swamp»: dati senza qualità, senza schema e senza governance, con cui è difficile lavorare in modo produttivo.
L’architettura lakehouse nasce proprio per risolvere questo dilemma, unendo in un’unica piattaforma i punti di forza di entrambe.
Che cos’è il lakehouse e come funziona
Il lakehouse archivia i dati in un data lake a basso costo (di solito un object storage in cloud come S3, Azure Data Lake Storage o GCS), ma vi aggiunge uno strato di metadati e di governance che fornisce le capacità del data warehouse: transazioni ACID, rispetto dello schema, query SQL ad alte prestazioni, controllo delle versioni e lineage dei dati.
I formati di tabella aperti che rendono possibile tutto questo sono:
Delta Lake: sviluppato da Databricks e oggi open source. È il formato di riferimento in Microsoft Fabric, Databricks e Azure. Supporta transazioni ACID, time travel (consultare lo stato dei dati in qualsiasi momento passato), modifiche dello schema e ottimizzazione automatica dei file.
Apache Iceberg: sviluppato da Netflix e ampiamente adottato nell’ecosistema AWS (Athena, EMR, Glue). Offre caratteristiche simili a Delta Lake, con particolare attenzione all’interoperabilità tra motori di query.
Apache Hudi: sviluppato da Uber, punta sugli aggiornamenti incrementali e sull’integrazione con Spark. È particolarmente utile nei casi d’uso di CDC (Change Data Capture).
Lakehouse e data warehouse tradizionale a confronto
| Dimensione | Data warehouse | Lakehouse |
|---|---|---|
| Costo di archiviazione | Alto | Basso (object storage) |
| Tipi di dati | Principalmente strutturati | Strutturati, semistrutturati, non strutturati |
| Machine learning e data science | Limitato | Nativo |
| Prestazioni SQL | Molto alte | Alte (con ottimizzazione) |
| Governance | Matura | In via di maturazione |
| Flessibilità dello schema | Bassa | Alta |
Per molte aziende l’architettura lakehouse è l’evoluzione naturale di un data warehouse che non riesce più a gestire la varietà e il volume dei dati attuali, senza dover mantenere due piattaforme separate con i relativi costi e complessità.
Le implementazioni lakehouse sul mercato
I principali fornitori che implementano l’architettura lakehouse sono:
- Databricks Lakehouse Platform: l’implementazione di riferimento, con Delta Lake come formato nativo.
- Microsoft Fabric: OneLake con formato Delta Parquet e accesso unificato da tutti i servizi.
- Snowflake: si è evoluto da data warehouse puro verso capacità lakehouse, con supporto per dati non strutturati e machine learning.
- AWS Lake Formation + Apache Iceberg/Hudi: stack open source su AWS.
La scelta tra queste opzioni dipende dall’ecosistema cloud esistente, dalle competenze del team e dai requisiti specifici di ciascun caso d’uso.
Quando adottare il lakehouse
I segnali che indicano il momento di valutare un’architettura lakehouse sono: il team dati ha bisogno di combinare SQL analitico e Python/machine learning sugli stessi dati; il costo dell’attuale data warehouse è un problema; l’azienda deve archiviare e analizzare dati non strutturati (immagini, testi, log); oppure si vuole evitare di mantenere due piattaforme separate (un lake per il machine learning e un warehouse per la BI).
Domande frequenti
Il lakehouse sostituisce completamente il data warehouse? In molti casi sì, ma non sempre. Per le organizzazioni con carichi di lavoro SQL molto intensi, il data warehouse tradizionale resta più veloce nelle query complesse su dati strutturati. Tuttavia il divario di prestazioni si è ridotto in modo significativo grazie alle ottimizzazioni di Delta Lake e Iceberg. La decisione deve basarsi sul mix di carichi di lavoro specifico di ogni azienda.
Quale formato di tabella aperto è migliore: Delta Lake, Iceberg o Hudi? Dipende dall’ecosistema. Delta Lake è la scelta naturale se si usano Databricks, Azure o Microsoft Fabric. Iceberg è preferibile su AWS. Hudi ha dei vantaggi nei casi d’uso con molti aggiornamenti incrementali. Il dato positivo è che i tre formati stanno convergendo nelle funzionalità e che l’interoperabilità tra loro migliora costantemente.
Come migrare un data warehouse esistente al lakehouse senza interrompere l’operatività? La migrazione più sicura è incrementale: si mantiene operativo il data warehouse esistente, si costruisce il lakehouse in parallelo con i nuovi flussi di dati e si spostano gradualmente i carichi di lavoro dal warehouse al lakehouse, per domini o per team. In questo modo ogni migrazione viene validata prima del passo successivo e il rischio operativo si riduce.