Capitolo 7: Business Intelligence, Data Lake, Delta Lake & Data Lakehouse

Il settimo modulo del corso analizza l’evoluzione delle architetture dati a supporto della Business Intelligence (BI) e della Data Science, tracciando il percorso tecnologico che porta dal tradizionale Data Warehouse (Schema-on-Write) al Data Lake (Schema-on-Read), fino all’introduzione delle transazioni ACID con Delta Lake e alla convergenza nel paradigma ibrido del Data Lakehouse.

1. Evoluzione della Business Intelligence e Nuove Esigenze Analitiche

La Business Intelligence (BI) comprende l’insieme di applicazioni, infrastrutture e strumenti analitico-statistici volti a esplorare, aggregare e interrogare le fonti informative aziendali per supportare e migliorare i processi decisionali.

Negli ultimi anni i sistemi di gestione dei dati hanno dovuto affrontare una profonda trasformazione guidata da tre fattori:

Il Ruolo della BI

Estrarre conoscenza strategica da grandi banche dati attraverso query di aggregazione, indicatori di performance (KPI) e analisi statistiche a supporto del management.

Fonti Eterogenee (Oltre le Tabelle)

Ai dati strutturati dei database relazionali (RDBMS) si affiancano oggi enormi volumi di dati semi-strutturati (JSON, XML, NoSQL) e non strutturati (video, file audio, immagini, documenti di testo libero, log di sensori IoT).

Oltre il Reporting Storico

Necessità di passare dalla sola reportistica consuntiva ad analisi avanzate in tempo reale (Real-Time Analytics), Data Science e addestramento di modelli predittivi di Machine Learning su un’unica piattaforma integrata.

2. Il Data Warehouse Tradizionale: Schema-on-Write e Limiti Strutturali

Come approfondito nel Capitolo 2, il Data Warehouse è una banca dati:

Integrata: raccoglie dati da molteplici fonti interne (caricamenti batch dai gestionali) ed esterne (API, web scraping);
Orientata al Soggetto (Subject-Oriented): centrata sui concetti chiave del dato piuttosto che sui singoli processi operativi;
Variabile nel Tempo (Time-Variant): copre un orizzonte temporale storico molto ampio, conservando anche i dati ormai obsoleti per i sistemi gestionali correnti;
Non Volatile: una volta che il dato è stato pulito e caricato, non viene più modificato (rendendo superfluo il mantenimento continuo di costose transazioni ACID in lettura).

Il Paradigma Schema-on-Write e i Suoi Punti Deboli

Il Data Warehouse si fonda rigorosamente sul paradigma Schema-on-Write (schema in fase di scrittura): prima ancora di poter archiviare i dati, è necessario definire a monte uno schema logico fisso (Star Schema o Snowflake Schema) ed eseguire una pipeline ETL che pulisce, omogeneizza, standardizza e valida ogni record prima dell’inserimento.

Punti di Forza del Data Warehouse	Limiti Critici in Scenari Big Data
Prestazioni di lettura elevatissime: poiché il dato è già pulito, strutturato e indicizzato al momento del caricamento, l’esecuzione delle query OLAP e della reportistica BI è immediata.	Scalabilità limitata e costi elevati: l’aumento massivo dei volumi satura le tabelle centrali; inoltre si sprecano risorse elaborando in fase di importazione (ETL) anche dati che potrebbero non essere mai interrogati.
Alta qualità e coerenza del dato: la fase preventiva di cleansing (inclusa l’eventuale anonimizzazione ai fini GDPR) garantisce dati certificati e affidabili.	Impossibilità di gestire dati non strutturati: uno schema a stella non può ospitare in modo efficiente video, audio, immagini o documenti destrutturati.
Ottimizzazione per query complesse: ideale per aggregazioni multidimensionali su dati tabellari.	Rigidità nell’evoluzione dello schema: poiché il Data Warehouse dura molti anni, qualsiasi cambiamento nelle esigenze di business impone una costosa e complessa riprogettazione della Fact Table e delle dimensioni.

3. Il Data Lake: Repository Grezzo e Paradigma Schema-on-Read

Per superare la rigidità del Data Warehouse è stato introdotto il Data Lake, un repository centralizzato progettato per accogliere qualsiasi tipologia di dato a basso costo.

Caratteristiche Fondamentali e Schema-on-Read

Formato Dati Variegato e Nativo: il Data Lake archivia contemporaneamente dati strutturati (tabelle relazionali), semi-strutturati (JSON, XML, CSV) e non strutturati (immagini, video, audio, log, documenti testuali) mantenendoli nel loro formato nativo grezzo.
Paradigma Schema-on-Read (Schema in fase di lettura): quando i dati vengono importati dalle sorgenti, vengono riversati nel Data Lake così come sono, senza alcuna operazione preventiva di pulitura, filtraggio o strutturazione. L’elaborazione, l’omogeneizzazione e l’applicazione di uno schema avvengono solo nel momento in cui viene eseguita una query (e solo sui dati effettivamente richiesti da quell’interrogazione).
Scalabilità Orizzontale e Storage Economico: si appoggia su infrastrutture distribuite e soluzioni di Cloud Object Storage a basso costo (es. Amazon S3, Azure Blob Storage, HDFS).
Ambiente Primario per Data Science e ML: grazie alla disponibilità dei dati grezzi integrali, rappresenta il bacino ideale per data discovery, esplorazione ad hoc, data mining e addestramento di modelli di Machine Learning.

Architettura Stratificata di un Data Lake

Come illustrato nello schema architetturale delle slide (Slide 5) e spiegato a lezione, un Data Lake ben progettato è organizzato in livelli funzionali e zone di archiviazione progressiva:

Ingestion Layer (Livello di Acquisizione)
Acquisisce i dati dall’esterno in maniera trasparente sia tramite Batch Ingestion (pipeline ETL da database e file system aziendali) sia tramite Streaming Ingestion (flussi continui da log, sensori IoT, API e applicazioni web).
Storage Zones (Zone Interne di Raffinamento del Dato)
All’interno dello storage del Data Lake i dati transitano attraverso tre zone logiche man mano che vengono richiesti ed elaborati:
- Raw Zone: contiene i dati grezzi appena importati nel loro stato originario;
- Cleansed / Refined Zone: ospita i dati che, in seguito all’attivazione del Processing Layer, sono stati puliti, filtrati e validati;
- Curated / Analytics Zone: conserva i dati ormai strutturati e aggregati (frutto di query già eseguite), pronti per essere riutilizzati rapidamente senza dover ripetere da zero la pulitura.
Processing Layer e Consumption Layer
Il Processing Layer esegue elaborazioni Batch e Stream sui dati delle Storage Zones per alimentare il Consumption Layer finale (Business Intelligence e Data Science / Machine Learning).
Metadata & Governance (Catalogo, Policy e Sicurezza)
Costituisce il pilastro trasversale indispensabile del Data Lake e comprende:
- Data Catalog: censisce i metadati semantici, la fonte, la codifica, la versione e la data di aggiornamento di ciascuna banca dati fin dal momento in cui se ne prevede l’integrazione (senza metadati, in fase di lettura il sistema non saprebbe nemmeno in quali file andare a cercare ad esempio gli “articoli di magazzino”);
- Policy Engine & Access Control: gestione dei permessi di accesso, crittografia (Encryption), Audit e monitoraggio.

I Limiti del Data Lake e il Rischio “Palude di Dati” (Data Swamp)

A fronte dell’estrema flessibilità in ingresso, il Data Lake puro presenta quattro criticità rilevanti:

1. Lentezza delle Query in Lettura

Poiché la pulitura, il filtraggio e l’integrazione devono essere eseguiti “al volo” al momento dell’interrogazione (Schema-on-Read), la prima query su grandi volumi di dati grezzi presenta tempi di risposta elevatissimi (anche ore o giorni), rendendo il Data Lake puro inadatto ad analisi real-time.

2. Rischio 'Data Swamp' (Palude di Dati)

Senza una governance rigorosa e una metadatazione puntuale fin dall’origine, continuare a riversare nel repository dati sporchi, ridondati e privi di controlli di qualità trasforma il Data Lake in una palude di dati (Data Swamp) opaca, inaffidabile, costosa in termini di spazio e impossibile da interrogare.

3. Assenza di Transazioni ACID

Nel Data Lake le elaborazioni avvengono con il sistema in esecuzione: se una banca dati sorgente aggiorna un record mentre un’analisi sta leggendo una copia precedentemente elaborata (o durante scritture concorrenti), la mancanza di transazioni atomiche ACID genera letture parziali, disallineamenti e incoerenze.

4. Rischi di Conformità GDPR

Mentre nel Data Warehouse la fase ETL consente di filtrare e anonimizzare i dati prima del caricamento, riversare dati grezzi non controllati in un Data Lake espone al rischio di archiviare dati personali o particolari non minimizzati, violando i principi del GDPR.

4. Delta Lake: Transazioni ACID e Affidabilità sul Data Lake

Per risolvere i problemi di inaffidabilità, incoerenza e degrado in Data Swamp dei Data Lake tradizionali, è stato sviluppato Delta Lake, un livello di archiviazione (storage layer) open-source che si posiziona sopra il Data Lake sfruttando il motore di calcolo distribuito Apache Spark.

Le quattro innovazioni chiave introdotte da Delta Lake sono:

Transazioni ACID su Apache Spark: garantisce Atomicità, Coerenza, Isolamento e Durabilità in fase di elaborazione e di query sul Data Lake. Quando viene richiesto un dato già pronto, Spark verifica automaticamente se esistono repliche più recenti o non concordanze con la sorgente, assicurando letture e scritture concorrenti sicure.
Evoluzione Dinamica dello Schema (Schema Evolution): consente di aggiungere o modificare dinamicamente le colonne dello schema associato ai dati già elaborati, senza dover riscrivere da zero i dataset preesistenti.
Viaggio nel Tempo (Time Travel): mantiene il tracciamento completo delle versioni storiche dei dati (data versioning), permettendo di eseguire rollback (ripristini in caso di scritture errate), verifiche di audit e query riproducibili su stati passati del repository.
Unificazione di Batch e Streaming: consente di far convergere sulla stessa tabella sia flussi di dati continui in tempo reale (streaming) sia caricamenti periodici (batch) ad alta affidabilità.

5. L’Architettura Ibrida: Data Lakehouse

L’evoluzione più moderna ed efficace è rappresentata dal Data Lakehouse, un’architettura ibrida che unisce in un unico sistema i vantaggi del Data Warehouse e quelli del Data Lake, affiancando due strutture di gestione complementari:

Gestione dei Dati Strutturati (logica Data Warehouse): i dati strutturati con schema stabile vengono puliti, omogeneizzati e standardizzati in ingresso e memorizzati in tabelle con schema fisso (Schema-on-Write), garantendo risposte istantanee per la reportistica di Business Intelligence;
Gestione dei Dati Non Strutturati o Altamente Variabili (logica Data Lake): i dati non strutturati (video, audio, testi), semi-strutturati o provenienti da sorgenti il cui schema evolve molto rapidamente vengono mantenuti nella componente Data Lake (Schema-on-Read), rimandando l’elaborazione al momento dell’effettiva richiesta.

Architettura Logica del Data Lakehouse (Slide 8):

  ┌───────────────────────────────┐     ┌───────────────────────────────┐
  │        Batch Ingestion        │     │      Streaming Ingestion      │
  │   (ETL/ELT, databases, files) │     │    (logs, IoT, clickstream)   │
  └───────────────┬───────────────┘     └───────────────┬───────────────┘
                  └──────────────────┬──────────────────┘
                                     ▼
                         ┌───────────────────────┐
                         │  Metadata & Catalog   │
                         └───────────┬───────────┘
                                     ▼
  ┌─────────────────────────────────────────────────────────────────────┐
  │                           DATA LAKEHOUSE                            │
  │   ┌───────────────────────────┐     ┌───────────────────────────┐   │
  │   │        File System        │     │  Delta Lake / Iceberg /   │   │
  │   │  (Cloud Object Storage)   │     │           Hudi            │   │
  │   └───────────────────────────┘     └───────────────────────────┘   │
  └──────────────────────────────────┬──────────────────────────────────┘
                                     ▼
                         ┌───────────────────────┐
                         │     Compute Layer     │
                         │  (Batch & Streaming)  │
                         └───────────┬───────────┘
                                     ▼
  ┌─────────────────────────────────────────────────────────────────────┐
  │                          CONSUMPTION LAYER                          │
  │    [ Business Intelligence ]   [ Data Science / ML ]   [ SQL ]      │
  └─────────────────────────────────────────────────────────────────────┘

Se dal punto di vista funzionale il Data Lakehouse offre il meglio dei due mondi, a lezione sono stati evidenziati due importanti svantaggi operativi:

Elevata complessità di configurazione e gestione: a differenza del Data Lake puro (in cui tutti i dati vengono riversati indistintamente nello stesso contenitore), nel Data Lakehouse gli architetti devono analizzare, classificare e configurare a monte ogni singola sorgente per decidere quali flussi indirizzare alla componente strutturata (Warehouse) e quali alla componente destrutturata (Lake).
Costi di implementazione molto elevati: è la soluzione tecnologicamente più onerosa da realizzare e manutenere; pertanto rappresenta un investimento giustificato solo quando l’organizzazione ha l’effettiva necessità di elaborare congiuntamente grandi volumi di dati strutturati e non strutturati con requisiti stringenti di velocità.

6. Matrice Comparativa e Scenari Pratici di Scelta Architetturale

Matrice Evolutiva delle Quattro Architetture Dati (Slide 10)

Caratteristica	Data Warehouse	Data Lake	Delta Lake	Data Lakehouse
Tipi di Dati	Solo Strutturati	Tutti (Grezzi)	Tutti + ACID	Tutti (Unificati)
Paradigma Schema	Schema-on-Write	Schema-on-Read	Evolutivo	*Ibrido (Read / Write)*
Transazioni ACID	Sì (Rigido)	No (Rischio Data Swamp)	Sì (tramite Apache Spark)	Sì (Nativo)
Scalabilità / Costo	Media / Elevato	Elevata / Basso	Elevata / Bilanciato	Massima / Ottimizzato (Alto costo iniziale di setup)
Workload Principale	BI / Reporting	Data Discovery / ML	Batch + Streaming	BI + ML + Streaming

Analisi degli Scenari Pratici (Slide 11–16 e Casi d’Esame)

Durante la lezione sono stati analizzati cinque scenari progettuali concreti per individuare quale architettura adottare (e quale scartare):

Scenario: Integrazione di Sistemi Gestionali Legacy (Molto Vecchi)

Problema: occorre integrare i dati provenienti da vecchi software gestionali che possiedono schemi interni rigidi o obsoleti e non consentono di sviluppare facilmente API di scambio diretto.
Scelta Architetturale: Data Lake (oppure Data Lakehouse). Non essendo agevole convertire immediatamente i vecchi schemi nel modello rigido di un Data Warehouse, conviene riversare i dati grezzi nel Data Lake mediante progetti pilota che non interrompano le operation, avendo cura di implementare fin dal primo giorno una solida Data Governance (metadatazione, controllo accessi e qualità).