{"id":69838,"date":"2026-06-22T14:21:05","date_gmt":"2026-06-22T13:21:05","guid":{"rendered":"https:\/\/www.irion-edm.com\/?p=69838"},"modified":"2026-06-22T14:24:16","modified_gmt":"2026-06-22T13:24:16","slug":"lakehouse-in-irion-edm","status":"publish","type":"post","link":"https:\/\/www.irion-edm.com\/it\/under-the-hood\/lakehouse-in-irion-edm\/","title":{"rendered":"Dal data\u00a0warehouse\u00a0al\u00a0lakehouse: come Irion integra le architetture dati moderne"},"content":{"rendered":"\n

Architettura ibrida, connessione a lakehouse esistenti e Managed Lakehouse nativo: come Irion EDM\u00ae<\/sup> porta il paradigma lakehouse nella piattaforma senza imporre migrazioni n\u00e9 formati proprietari<\/h2>\n\n\n\n

Dal data warehouse al data lake: una storia familiare <\/h3>\n\n\n\n

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\u00f2 di nuovi.<\/p>\n\n\n\n

Vale la pena ripercorrere le tappe principali di questo cammino \u2014 un cammino che per molte aziende \u00e8 ancora in corso \u2014 perch\u00e9 capire da dove veniamo aiuta a capire perch\u00e9 l’architettura lakehouse, e la sua integrazione all’interno di Irion EDM\u00ae<\/sup>, rappresenti oggi una risposta matura a esigenze concrete delle aziende.<\/p>\n\n\n\n

L’era dei data warehouse: solidit\u00e0 a caro prezzo <\/h3>\n\n\n\n

I data warehouse hanno dominato la scena per decenni, e con buona ragione. Garantivano tutto ci\u00f2 che un’organizzazione si aspettava da un sistema dati: consistenza, transazioni affidabili, una singola source of truth.<\/p>\n\n\n\n

Il problema \u00e8 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\u00e0 della fonte. Il vendor lock-in era spesso incorporato nell’architettura stessa.<\/p>\n\n\n\n

I data lake: libert\u00e0 senza governance <\/h3>\n\n\n\n

La risposta al warehouse \u00e8 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 \u00e8 evoluto verso uno storage economico e virtualmente illimitato. Una svolta importante anche sul fronte della scalabilit\u00e0, grazie alla separazione tra compute e storage che nei sistemi warehouse tradizionali tendevano a crescere insieme.<\/p>\n\n\n\n

Sembrava la soluzione definitiva. Ma non lo era. <\/p>\n\n\n\n

Il data lake soffriva e soffre tuttora di un problema di semantica. Una “tabella” pu\u00f2 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<\/em>: un deposito di dati non governati e difficili da utilizzare.<\/p>\n\n\n\n

Dal data lake al lakehouse: gli open table format e il concetto di catalogo<\/h3>\n\n\n\n

Il passo successivo \u00e8 stato tentare di recuperare ci\u00f2 che si era perso \u2014 governance, consistenza, semantica \u2014 senza rinunciare ai vantaggi della scalabilit\u00e0 cloud e dei formati aperti. Da questa esigenza \u00e8 nato il concetto di lakehouse<\/strong>: un’architettura che combina la flessibilit\u00e0 e l’economicit\u00e0 dello storage cloud con alcune garanzie tipiche dei database tradizionali.<\/p>\n\n\n\n

Un lakehouse \u00e8 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\u00e9 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\u00e0 di un data lake.<\/p>\n\n\n\n

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\u00f2 essere visto non solo come un nuovo approccio architetturale, ma anche come l’integrazione di componenti specifici.<\/p>\n\n\n\n

Gli open table format \u2014 tra i pi\u00f9 noti Delta Lake e Apache Iceberg \u2014 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.<\/p>\n\n\n\n

In questo modo, le tabelle risultano modificabili a livello logico, e il layer di compute pu\u00f2 accedere alla versione corretta dei dati in modo trasparente, mantenendo uno storico delle versioni dei dati.<\/p>\n\n\n\n

Ma un database non \u00e8 una tabella sola. \u00c8 un insieme di tabelle, con relazioni e versioni. E cos\u00ec \u00e8 tornata la necessit\u00e0 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.<\/p>\n\n\n\n

Catalogo pi\u00f9 open table format: questo \u00e8 il lakehouse.<\/strong> Un’architettura che riporta ordine e governabilit\u00e0 sui dati distribuiti, mantenendo la separazione tra storage e compute e \u2014 cosa fondamentale \u2014 usando standard aperti accessibili a qualsiasi motore senza duplicazione o ulteriori step.<\/p>\n\n\n\n

Come Irion integra l\u2019architettura lakehouse <\/h2>\n\n\n\n

La scelta di integrare l’architettura lakehouse in Irion EDM non \u00e8 solo una decisione tecnologica: \u00e8 l’applicazione concreta di una filosofia architetturale precisa, quella della separazione tra compute e storage, tipica delle architetture cloud-native<\/strong>. Compute e storage operano su livelli indipendenti, scalabili separatamente, senza che la crescita dell’uno vincoli l’altro. \u00c8 questo principio che rende l’architettura lakehouse sostenibile nel tempo.<\/p>\n\n\n\n

Irion lo integra direttamente nella piattaforma in due modi complementari.<\/p>\n\n\n\n

Per chi ha gi\u00e0 il proprio lakehouse, Irion si connette ad esso direttamente<\/strong>, senza richiedere migrazioni n\u00e9 imporre formati proprietari.<\/p>\n\n\n\n

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<\/strong>. Il Managed Lakehouse \u00e8 progettato per ambienti Kubernetes<\/strong>, con un’architettura cloud-native che include funzionalit\u00e0 native di backup, monitoraggio, resilienza e high availability.<\/p>\n\n\n\n

In entrambi i casi, l’obiettivo \u00e8 lo stesso: non \u00e8 solo aggiungere uno storage analitico, ma portare questa architettura all’interno di una piattaforma gi\u00e0 orientata alla governance, alla qualit\u00e0 e alla gestione del dato.<\/p>\n\n\n\n

Connessione a lakehouse esistenti: zero migrazioni, zero duplicazioni  <\/h3>\n\n\n\n

Per le organizzazioni che hanno gi\u00e0 costruito il proprio lakehouse, Irion si connette direttamente all’infrastruttura esistente<\/strong>. Nessuna migrazione, nessuna duplicazione, nessun formato proprietario imposto.<\/p>\n\n\n\n

Irion supporta la connessione a lakehouse basati su standard aperti e consolidati come Apache Iceberg<\/strong> e Delta Lake<\/strong>, cataloghi interoperabili come Unity Catalog<\/strong>, inclusi formati emergenti compatibili con gli ecosistemi open table, come DuckLake<\/strong>. Indipendentemente dalla tecnologia utilizzata, se i dati sono scritti su standard aperti o compatibili, Irion pu\u00f2 leggerli<\/strong>.<\/p>\n\n\n\n

Questo consente di adottare la soluzione senza dipendere da uno specifico cloud provider<\/strong> 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\u00f2 essere considerevole, soprattutto nelle organizzazioni che gestiscono dataset di grandi dimensioni con accesso prevalentemente in lettura, e tutto questo senza compromettere accessibilit\u00e0, performance e governance del dato.<\/p>\n\n\n\n

Il Managed Lakehouse: costruire un lakehouse direttamente in Irion <\/h3>\n\n\n\n

Fin dalla sua nascita, Irion ha integrato nativamente la possibilit\u00e0 di persistere dei dati all’interno del prodotto: un vantaggio concreto, che consente di lavorare in modo pi\u00f9 agile ed eliminare la dipendenza da tecnologie esterne. Fino ad oggi, questo layer di storage era affidato al DataShelf<\/strong>, una struttura proprietaria costruita su SQL Server. Al DataShelf si affianca una seconda opzione: un Managed Lakehouse<\/strong>, interamente gestito da Irion, che apre le porte a nuovi scenari per chi lavora con grandi volumi di dati e favorisce una maggiore interoperabilit\u00e0 con i moderni ecosistemi data.<\/p>\n\n\n\n

Il Managed Lakehouse \u00e8 fondato su standard aperti di mercato<\/strong>: questo significa che \u00e8 accessibile anche da strumenti terzi<\/strong> e che si integra nativamente con le architetture hub & spoke<\/strong>, 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<\/a>).<\/p>\n\n\n\n

I vantaggi di costruire un lakehouse all’interno di Irion sono principalmente due: la riduzione del TCO e del vendor lock-in<\/strong>.<\/p>\n\n\n\n

Solitamente i carichi analitici \u2014 i grandi volumi storici, i dataset di reportistica o i dati prevalentemente in lettura \u2014 vivono spesso su database relazionali commerciali come SQL Server, Oracle, DB2 o Teradata, con costi di licenza legati anche alla quantit\u00e0 di dati gestiti. Spostarli su un lakehouse significa farli uscire da questi sistemi<\/strong>, riducendo la necessit\u00e0 del database relazionale e di conseguenza il costo di licenza<\/strong>.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Tutte queste caratteristiche riducono significativamente il vendor lock-in: i dati di Irion sono leggibili dall’esterno<\/strong>, senza neanche sapere che sono gestiti da Irion. I dati restano accessibili in formati aperti e interoperabili, indipendentemente dalla piattaforma che li gestisce.<\/p>\n\n\n\n

Query ibride tra sorgenti diverse <\/h2>\n\n\n\n

Che i dati si trovino sul Managed Lakehouse di Irion o su un lakehouse esterno, possono essere letti e interrogati ovunque risiedano. Ma c’\u00e8 di pi\u00f9.<\/p>\n\n\n\n

Irion consente di eseguire query ibride<\/strong>: in una singola interrogazione \u00e8 possibile combinare dati provenienti da qualsiasi lakehouse con dati provenienti da qualsiasi altra sorgente gi\u00e0 censita nella piattaforma. Una join tra una tabella del lakehouse e un dataset proveniente da una connessione esterna \u00e8 possibile e trasparente per l’utente, senza processi di copia, senza pipeline di integrazione dedicate, grazie a sofisticate tecniche di pushdown<\/strong> che ottimizzano l’esecuzione direttamente alla sorgente.<\/p>\n\n\n\n

Tutto questo \u00e8 reso possibile dall’Analytics Engine<\/strong> di Irion, un nuovo motore analitico colonnare che opera in modalit\u00e0 in-memory e\/o on-disk, nativamente progettato per i carichi OLAP.<\/p>\n\n\n\n

Conclusioni  <\/h2>\n\n\n\n

Integrare il lakehouse in Irion EDM\u00ae<\/sup> \u00e8 stata una scelta precisa: portare un’architettura matura e moderna all’interno di una piattaforma gi\u00e0 orientata alla governance e alla qualit\u00e0 del dato, senza imporre migrazioni, aggiungere complessit\u00e0 o stravolgere ci\u00f2 che le organizzazioni hanno gi\u00e0 costruito.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Due i benefici pi\u00f9 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.<\/p>\n\n\n\n

Quella del lakehouse \u00e8 solo una delle tappe di un percorso di evoluzione che Irion ha intrapreso, sempre pi\u00f9 orientato al futuro. <\/p>\n\n\n\n

Continuate a seguirci: abbiamo ancora molto da raccontare, e non vediamo l’ora di farlo nei prossimi appuntamenti.<\/em><\/p>\n\n\n\n