Architettura ibrida, connessione a lakehouse esistenti e Managed Lakehouse nativo: come Irion EDM® porta il paradigma lakehouse nella piattaforma senza imporre migrazioni né formati proprietari
Dal data warehouse al data lake: una storia familiare
Chi lavora con i dati da qualche anno conosce bene questa storia: dai data warehouse ai data lake, fino alle architetture lakehouse. Ogni passaggio ha risposto a problemi reali, introducendone però di nuovi.
Vale la pena ripercorrere le tappe principali di questo cammino — un cammino che per molte aziende è ancora in corso — perché capire da dove veniamo aiuta a capire perché l’architettura lakehouse, e la sua integrazione all’interno di Irion EDM®, rappresenti oggi una risposta matura a esigenze concrete delle aziende.
L’era dei data warehouse: solidità a caro prezzo
I data warehouse hanno dominato la scena per decenni, e con buona ragione. Garantivano tutto ciò che un’organizzazione si aspettava da un sistema dati: consistenza, transazioni affidabili, una singola source of truth.
Il problema è arrivato con la crescita del volume dei dati. I warehouse non scalavano facilmente, soprattutto orizzontalmente, e farli scalare verticalmente richiedeva spesso interventi infrastrutturali costosi. Ma c’era anche un secondo problema: i dati venivano salvati in formati proprietari. Per accedervi bisognava passare dallo stesso fornitore o duplicarli altrove, perdendo di fatto l’unicità della fonte. Il vendor lock-in era spesso incorporato nell’architettura stessa.
I data lake: libertà senza governance
La risposta al warehouse è stata il data lake: separare i dati dalla logica di interrogazione, usare formati aperti e distribuire l’archiviazione su sistemi scalabili. Le prime implementazioni, fondate sull’ecosistema Hadoop e su file system distribuiti come HDFS, erano prevalentemente on-premise; con l’avvento del cloud il modello si è evoluto verso uno storage economico e virtualmente illimitato. Una svolta importante anche sul fronte della scalabilità, grazie alla separazione tra compute e storage che nei sistemi warehouse tradizionali tendevano a crescere insieme.
Sembrava la soluzione definitiva. Ma non lo era.
Il data lake soffriva e soffre tuttora di un problema di semantica. Una “tabella” può essere distribuita in centinaia o migliaia di file, con struttura e significato spesso noti solo ai processi che li avevano generati. Solo chi ha scritto quei dati sa come leggerli correttamente. Nella pratica, molti data lake si sono trasformati in quello che nel settore viene chiamato, non senza ironia, data swamp: un deposito di dati non governati e difficili da utilizzare.
Dal data lake al lakehouse: gli open table format e il concetto di catalogo
Il passo successivo è stato tentare di recuperare ciò che si era perso — governance, consistenza, semantica — senza rinunciare ai vantaggi della scalabilità cloud e dei formati aperti. Da questa esigenza è nato il concetto di lakehouse: un’architettura che combina la flessibilità e l’economicità dello storage cloud con alcune garanzie tipiche dei database tradizionali.
Un lakehouse è un’architettura ibrida che combina i migliori elementi di un data lake e di un data warehouse: storage e compute sono disaccoppiati e basati su standard aperti perché i dati risiedono in object storage sotto forma di file, ma possono essere interrogati da diversi motori di calcolo. Per l’utente finale, il sistema si comporta come un data warehouse (supporto SQL, schemi strutturati, garanzie ACID), mentre internamente mantiene la flessibilità di un data lake.
Per rendere possibile questa integrazione sono necessari due componenti fondamentali, che riflettono proprio l’unione dei due mondi: gli open table format e il metadata catalog. Il lakehouse può essere visto non solo come un nuovo approccio architetturale, ma anche come l’integrazione di componenti specifici.
Gli open table format — tra i più noti Delta Lake e Apache Iceberg — risolvono il problema della semantica a livello di singola tabella. L’intuizione di fondo era semplice quanto potente: rendere un insieme di file fisici visibile e interrogabile come se fosse una singola tabella coerente. Questi formati tracciano le operazioni di inserimento, modifica e cancellazione senza modificare direttamente i file, che restano immutabili, ma gestendo versioni tramite metadati.
In questo modo, le tabelle risultano modificabili a livello logico, e il layer di compute può accedere alla versione corretta dei dati in modo trasparente, mantenendo uno storico delle versioni dei dati.
Ma un database non è una tabella sola. È un insieme di tabelle, con relazioni e versioni. E così è tornata la necessità di un componente aggiuntivo: non un database nel senso classico del termine, ma un catalogo, un registro centrale che dice a qualsiasi motore di interrogazione quali tabelle esistono, dove si trovano fisicamente e a quale versione corrispondono. Con questa informazione, il motore accede in modo consistente ai dati giusti, indipendentemente da quanti file li compongano fisicamente.
Catalogo più open table format: questo è il lakehouse. Un’architettura che riporta ordine e governabilità sui dati distribuiti, mantenendo la separazione tra storage e compute e — cosa fondamentale — usando standard aperti accessibili a qualsiasi motore senza duplicazione o ulteriori step.
Come Irion integra l’architettura lakehouse
La scelta di integrare l’architettura lakehouse in Irion EDM non è solo una decisione tecnologica: è l’applicazione concreta di una filosofia architetturale precisa, quella della separazione tra compute e storage, tipica delle architetture cloud-native. Compute e storage operano su livelli indipendenti, scalabili separatamente, senza che la crescita dell’uno vincoli l’altro. È questo principio che rende l’architettura lakehouse sostenibile nel tempo.
Irion lo integra direttamente nella piattaforma in due modi complementari.
Per chi ha già il proprio lakehouse, Irion si connette ad esso direttamente, senza richiedere migrazioni né imporre formati proprietari.
Per le organizzazioni che non dispongono ancora di un lakehouse, mette a disposizione il Managed Lakehouse: uno strumento per persistere dati in un lakehouse direttamente all’interno della piattaforma. Il Managed Lakehouse è progettato per ambienti Kubernetes, con un’architettura cloud-native che include funzionalità native di backup, monitoraggio, resilienza e high availability.
In entrambi i casi, l’obiettivo è lo stesso: non è solo aggiungere uno storage analitico, ma portare questa architettura all’interno di una piattaforma già orientata alla governance, alla qualità e alla gestione del dato.
Connessione a lakehouse esistenti: zero migrazioni, zero duplicazioni
Per le organizzazioni che hanno già costruito il proprio lakehouse, Irion si connette direttamente all’infrastruttura esistente. Nessuna migrazione, nessuna duplicazione, nessun formato proprietario imposto.
Irion supporta la connessione a lakehouse basati su standard aperti e consolidati come Apache Iceberg e Delta Lake, cataloghi interoperabili come Unity Catalog, inclusi formati emergenti compatibili con gli ecosistemi open table, come DuckLake. Indipendentemente dalla tecnologia utilizzata, se i dati sono scritti su standard aperti o compatibili, Irion può leggerli.
Questo consente di adottare la soluzione senza dipendere da uno specifico cloud provider e apre la porta a strategie ibride: dati “caldi” su file system ad alte prestazioni, volumi storici su blob storage a basso costo. Il risparmio del TCO può essere considerevole, soprattutto nelle organizzazioni che gestiscono dataset di grandi dimensioni con accesso prevalentemente in lettura, e tutto questo senza compromettere accessibilità, performance e governance del dato.
Il Managed Lakehouse: costruire un lakehouse direttamente in Irion
Fin dalla sua nascita, Irion ha integrato nativamente la possibilità di persistere dei dati all’interno del prodotto: un vantaggio concreto, che consente di lavorare in modo più agile ed eliminare la dipendenza da tecnologie esterne. Fino ad oggi, questo layer di storage era affidato al DataShelf, una struttura proprietaria costruita su SQL Server. Al DataShelf si affianca una seconda opzione: un Managed Lakehouse, interamente gestito da Irion, che apre le porte a nuovi scenari per chi lavora con grandi volumi di dati e favorisce una maggiore interoperabilità con i moderni ecosistemi data.
Il Managed Lakehouse è fondato su standard aperti di mercato: questo significa che è accessibile anche da strumenti terzi e che si integra nativamente con le architetture hub & spoke, consentendo di interrogare dati che risiedono su un nodo distinto di Irion senza doverli spostare fisicamente (per approfondire l’architettura, vedi il whitepaper Data Quality Hub).
I vantaggi di costruire un lakehouse all’interno di Irion sono principalmente due: la riduzione del TCO e del vendor lock-in.
Solitamente i carichi analitici — i grandi volumi storici, i dataset di reportistica o i dati prevalentemente in lettura — vivono spesso su database relazionali commerciali come SQL Server, Oracle, DB2 o Teradata, con costi di licenza legati anche alla quantità di dati gestiti. Spostarli su un lakehouse significa farli uscire da questi sistemi, riducendo la necessità del database relazionale e di conseguenza il costo di licenza.
Inoltre, come abbiamo detto, l’intera struttura del Managed Lakehouse di Irion si basa su standard aperti: i dati sono in un formato noto e accessibile, i metadati risiedono su un database raggiungibile con protocolli standard, e quindi possono essere letti anche da strumenti esterni. Questo significa che i Managed Lakehouse possono essere letti anche da motori terzi compatibili con gli standard di mercato, senza passare per le API.
Tutte queste caratteristiche riducono significativamente il vendor lock-in: i dati di Irion sono leggibili dall’esterno, senza neanche sapere che sono gestiti da Irion. I dati restano accessibili in formati aperti e interoperabili, indipendentemente dalla piattaforma che li gestisce.
Query ibride tra sorgenti diverse
Che i dati si trovino sul Managed Lakehouse di Irion o su un lakehouse esterno, possono essere letti e interrogati ovunque risiedano. Ma c’è di più.
Irion consente di eseguire query ibride: in una singola interrogazione è possibile combinare dati provenienti da qualsiasi lakehouse con dati provenienti da qualsiasi altra sorgente già censita nella piattaforma. Una join tra una tabella del lakehouse e un dataset proveniente da una connessione esterna è possibile e trasparente per l’utente, senza processi di copia, senza pipeline di integrazione dedicate, grazie a sofisticate tecniche di pushdown che ottimizzano l’esecuzione direttamente alla sorgente.
Tutto questo è reso possibile dall’Analytics Engine di Irion, un nuovo motore analitico colonnare che opera in modalità in-memory e/o on-disk, nativamente progettato per i carichi OLAP.
Conclusioni
Integrare il lakehouse in Irion EDM® è stata una scelta precisa: portare un’architettura matura e moderna all’interno di una piattaforma già orientata alla governance e alla qualità del dato, senza imporre migrazioni, aggiungere complessità o stravolgere ciò che le organizzazioni hanno già costruito.
Sia nel caso di un Managed Lakehouse costruito in Irion, sia nel caso di una connessione a infrastrutture esistenti, il principio rimane lo stesso: i dati restano dell’organizzazione, in formati aperti, accessibili da qualsiasi motore compatibile. La scelta architetturale di oggi non chiude le porte alle opzioni tecnologiche di domani.
Due i benefici più concreti che ne derivano: una riduzione del TCO, spostando i carichi analitici fuori dai database relazionali commerciali, e una riduzione del vendor lock-in per quei casi in cui si utilizzano standard aperti, minimizzando le dipendenze da fornitori specifici.
Quella del lakehouse è solo una delle tappe di un percorso di evoluzione che Irion ha intrapreso, sempre più orientato al futuro.
Continuate a seguirci: abbiamo ancora molto da raccontare, e non vediamo l’ora di farlo nei prossimi appuntamenti.
