Quando i dati mentono e nessuno se ne accorge: dieci anni di ETL on premise e cosa faremmo diversamente oggi

C'è un progetto che portiamo avanti da molti anni. Non é andato male — anzi, tutt'altro: ha girato per anni e ha dato valore reale. Ma ogni tanto vale la pena chiedersi: se ricominciassimo da zero, oggi, cosa cambierebbe?

 

Il cliente è un'azienda di servizi strutturata, con una complessità operativa importante: tanti gestionali che girano in parallelo, processi distribuiti, e una fame crescente di dati aggregati per prendere decisioni migliori. Il classico scenario in cui la Business Intelligence smette di essere un nice-to-have e diventa infrastruttura critica.

 

L'architettura che abbiamo costruito era quella giusta per il 2016-2018, il periodo in cui quel sistema è nato.  

 

Il progetto: architettura classica, problemi classici

I primi contatti risalgono al 2016. La soluzione progettata era quella consolidata del periodo: sorgenti dati esposte via web service dai vari gestionali, un processo ETL (Extract, Transform, Load) notturno che pescava tutto, denormalizzava e scriveva in un data warehouse Oracle on premise, e sopra Tableau a costruire le dashboard per gli utenti finali.

 

In termini di volumi: circa un gigabyte di dati al giorno da ingerire. Non astronomico, ma abbastanza da rendere impraticabile qualsiasi approccio improvvisato. Il sistema doveva essere robusto, schedulato, monitorato.

 

E lo era. Almeno in superficie.

 

Il problema — quello vero, quello che si è manifestato nel tempo — non stava nell'ETL, non stava in Oracle, non stava in Tableau. Stava in un'assunzione implicita che tutti quanti avevamo fatto senza rendercene conto: che i dati esposti dai web service dei gestionali corrispondessero fedelmente a ciò che c'era nei database sottostanti.

Spoiler: non sempre era così.

 

Il problema che non riesci a vedere finché è troppo tardi

I gestionali aziendali espongono i propri dati attraverso API e web service che, in teoria, dovrebbero essere una finestra trasparente sul database interno. In pratica, quella finestra è spesso costruita con logiche proprie: viste materializzate che si aggiornano con ritardo, query di estrazione ottimizzate per la velocità ma non per la completezza, sincronizzazioni asincrone che in certi momenti della giornata restituiscono dati parziali.

 

Il risultato è una divergenza sottile ma sistematica tra quello che il web service dice e quello che il database del gestionale contiene davvero.

E tu non lo sai. Non immediatamente, almeno.

Lo scopri quando una dashboard mostra un valore che non torna. Un totale che non quadra. Una variazione anomala che nessuno sa spiegare. A quel punto il primo colpevole è la BI e  comincia un'indagine che, senza gli strumenti giusti, assomiglia a navigare al buio:

- Il web service ha restituito un dato sbagliato al momento dell'estrazione?
- L'ETL ha applicato una trasformazione errata?
- C'è un bug nella logica della dashboard?
- Il dato è corretto e il problema è nell'interpretazione?

 

Per rispondere a queste domande serve una cosa sola: poter tornare indietro nel tempo e vedere com'erano i dati al momento esatto in cui sono stati estratti. Poter confrontare l'input grezzo con l'output trasformato, passo per passo.

 

All'epoca, questa possibilità non esisteva. Tenere 1 GB al giorno di dati grezzi "per sicurezza" avrebbe significato decine o centinaia di gigabyte di storage aggiuntivo, solo come archivio forense. I costi erano proibitivi, la logistica complicata, e soprattutto — diciamolo chiaramente — in pochi immaginavo quanto quei dati sarebbero stati preziosi.

 

Così ogni volta che un dato era sbagliato, si ricominciava dall'inizio. Si ricostruiva il percorso a intuito. Si trovava la causa, si correggeva, si ripartiva. E la prossima volta, magari, lo stesso problema si ripresentava in forma leggermente diversa.

 

Dieci anni dopo: lo stesso problema, un mondo diverso

Nel frattempo sono cambiate due cose fondamentali.

La prima è il costo dello storage. Oggi conservare 1 GB di dati grezzi al giorno per un anno intero costa pochissimo su qualsiasi cloud provider — qualcosa nell'ordine di pochi euro al mese su storage object come AWS S3, Azure Data Lake Storage o Google Cloud Storage. Quello che nel 2016 era un lusso inaccessibile, oggi è quasi un costo trascurabile.

 

La seconda è la maturità degli strumenti. Intorno all'idea di conservare tutti i dati in forma grezza e processarli in fasi successive si è costruito un paradigma architetturale solido, ben documentato, adottato dalle aziende più sofisticate del mondo: il data lake a livelli, comunemente noto come architettura **Bronze / Silver / Gold** o architettura a Medaglione.

 

 L'architettura che avremmo voluto: Bronze, Silver, Gold

L'idea di fondo è semplice: invece di trasformare i dati in volo e buttare via l'originale, li si conserva in ogni fase del loro ciclo di vita. Ogni livello ha uno scopo preciso.

 

Bronze: la prova del fatto

Il livello Bronze è l'archivio grezzo. I dati arrivano — dal web service, da un file CSV, da una coda Kafka, da qualsiasi sorgente — e vengono salvati esattamente com'erano nel momento in cui sono arrivati. Nessuna trasformazione, nessuna interpretazione, nessuna pulizia.

Se il web service del gestionale alle 2:14 di notte del 14 marzo ha restituito una risposta JSON con un campo mancante, quella risposta è lì, intatta, per sempre. È il tuo archivio forense. È la prova che ti permette di dire con certezza "il problema era a monte" oppure "il dato era corretto, il problema era nella trasformazione".

In un sistema classico come il nostro del 2016, questo livello non esisteva. Il dato grezzo veniva consumato dall'ETL e spariva.

 

Silver: dove avviene la magia (controllata)

Il livello Silver è dove i dati vengono puliti, validati, standardizzati e resi coerenti. È qui che si applicano le regole di business, le trasformazioni, le deduplicazioni. Ed è qui — e questo è il punto cruciale — che si intercettano le anomalie prima che arrivino alle dashboard.

 

In un sistema moderno, il passaggio da Bronze a Silver non è un processo cieco: è un processo con aspettative esplicite. Questo campo non può essere null. Questo valore deve essere positivo. Questa chiave deve esistere nella tabella di lookup. Se una di queste aspettative viene violata, il dato non viene promosso silenziosamente al livello successivo: viene messo in quarantena, registrato, segnalato.

 

L'anomalia viene scoperta nel momento in cui si verifica, non tre settimane dopo da un utente che nota un numero strano su una dashboard.

 

Gold: pronto per il consumo

Il livello Gold è quello che l'utente finale vede. I dati sono aggregati, denormalizzati, ottimizzati per le query di Tableau o di qualunque altro strumento. Sono il prodotto finito — ma un prodotto finito con una provenienza documentata, tracciabile, verificabile.

 

Strumenti concreti: cosa useremmo oggi

Tradurre questa architettura in pratica richiede scelte tecnologiche. Ecco quelle che valuteremmo seriamente per un progetto come quello descritto.

Databricks con Delta Lake

Databricks è oggi probabilmente la piattaforma più matura per costruire architetture lakehouse di questo tipo. Il suo layer di storage nativo, Delta Lake, porta sul dato una serie di garanzie che i file Parquet semplici non hanno: transazionalità ACID, time travel (la possibilità di interrogare i dati com'erano in un momento preciso del passato), e schema enforcement automatico.

 

La funzionalità che si sposerebbe meglio con il problema descritto è Delta Live Tables: permette di definire i pipeline di trasformazione come grafo dichiarativo, e di associare a ogni passaggio delle "expectations" — regole di qualità del dato esplicite, con comportamenti configurabili (warn, drop, fail) in caso di violazione. L'intero storico delle violazioni viene loggato automaticamente.

Su un progetto con 1 GB/giorno di dati e la necessità di tracciare anomalie sui web service, Delta Live Tables sarebbe la risposta diretta al problema che abbiamo vissuto.

 

Apache Iceberg (alternativa open)

Per chi preferisce evitare il lock-in su una singola piattaforma, Apache Iceberg è il formato di tabella open source che sta emergendo come standard de facto per i data lake moderni. Supportato da Spark, Trino, Flink e molti altri engine, offre funzionalità simili a Delta Lake (time travel, schema evolution, transazionalità) con il vantaggio di essere agnostico rispetto all'infrastruttura.

 

Combinato con strumenti come dbt(data build tool) per le trasformazioni e Great Expectations o Soda per la validazione dei dati, si costruisce un pipeline robusto, osservabile e mantenibile senza dipendere da un vendor specifico.

 

 Il problema del time travel applicato al nostro caso

Con una di queste architetture, lo scenario che ci ha fatto perdere ore di debugging cambia radicalmente. Un dato anomalo su una dashboard oggi scatena questa sequenza:

1. Si identifica il record problematico nel livello Gold.
2. Si risale al livello Silver per verificare se la trasformazione era corretta.
3. Se necessario, si apre il livello Bronze e si guarda il dato grezzo esattamente com'era al momento dell'estrazione.
4. Si confronta il dato Bronze con quello che il gestionale aveva nel suo database in quel momento (se si ha accesso) oppure si confronta con estrazioni precedenti via time travel.

In 15 minuti si ha una risposta certa su dove è nata l'anomalia. Non in tre giorni di debug.

 

Una nota onesta sul perché non lo avevamo fatto prima

Sarebbe facile, con il senno di poi, dire che l'architettura del 2016 era sbagliata. Non è così.

Le scelte fatte erano razionali rispetto al contesto: i costi dello storage erano diversi, gli strumenti per i data lake erano ancora immaturi o richiedevano competenze molto specializzate, e la cultura della "qualità del dato come parte del pipeline" non era ancora diffusa come lo è oggi.

 

Databricks è diventata una piattaforma enterprise matura solo nella seconda metà degli anni 2010. Delta Lake è stato open-sourcato nel 2019. Il concetto di "data observability" come disciplina strutturata è esploso dopo il 2020. Costruire un'architettura Bronze/Silver/Gold nel 2016 avrebbe richiesto di assemblare pezzi non ancora standardizzati, con team che avrebbero dovuto essere formati su tecnologie ancora in evoluzione. Certo un livello Bronze, Silver e Gold si può anche costruire "a mano" su Oracle, ma a prezzo di che occupazione di spazio? on premise per giunta!

In quel contesto, l'ETL classico su Oracle era la scelta giusta.

 

Cosa significa questo per i sistemi esistenti

Se avete un sistema BI che ha qualche anno sulle spalle — un ETL che gira su SQL Server Integration Services, su Informatica, su qualche script Python schedulato con cron — questo articolo non è un invito a buttare tutto e ripartire da zero.

 

È un invito a farsi alcune domande:

• Quando un dato è sbagliato, quanto tempo ci vuole per capire perché? Se la risposta è "ore o giorni", avete un problema di osservabilità che un'architettura moderna risolverebbe.
• Riuscite a ricostruire lo stato del vostro data warehouse in un momento preciso del passato? Se no, ogni anomalia storica è irrisolvibile.
• Le regole di qualità del dato sono esplicite e documentate, oppure vivono nella testa di chi ha costruito l'ETL? Se è la seconda, avete un rischio che cresce ogni volta che quella persona cambia ruolo o lascia l'azienda.

La migrazione non deve essere traumatica. In molti casi si può affiancare al sistema esistente un layer di landing in Bronze, aggiungere validazione progressivamente, e costruire il Gold sul nuovo stack mantenendo le dashboard invariate. È un percorso, non un big bang.

 

Conclusione: conservare le prove

Il problema fondamentale che abbiamo vissuto su questo progetto non era tecnico. Era epistemologico: non avevamo modo di sapere cosa fosse successo, perché avevamo buttato via le prove nel momento stesso in cui le avevamo usate.

L'architettura Bronze/Silver/Gold risolve esattamente questo. Non è una moda, non è un modo per usare tecnologie più moderne perché sì: è una risposta strutturata a un problema reale che chiunque abbia gestito pipeline di dati complessi ha incontrato almeno una volta.

La prossima volta che un web service mente, vogliamo avere la prova.

 

Ma quanto costa, concretamente?

È la domanda giusta. L'architettura Medallion è elegante, risolutiva, e oggi tecnicamente accessibile — ma "accessibile" non significa gratuita, e sarebbe disonesto non aprire questo capitolo.

La buona notizia è che i costi si distribuiscono in modo molto diverso da come si potrebbe immaginare. Vediamoli per componente.

 

Storage: quasi gratuito

Il layer Bronze — quello che nel nostro caso avrebbe fatto la differenza — costa pochissimo. Su qualsiasi cloud provider, lo storage object per dati "freddi" (che scrivi e leggi raramente) si aggira intorno a 0,02–0,023 dollari per GB al mese.

Nel nostro scenario: 1 GB al giorno, conservato per 2 anni, fa circa 730 GB. Costo: 15 dollari al mese. Meno di un abbonamento a Netflix.

Anche prendendo margini di errore generosi — compressione variabile, overhead dei metadati, repliche per ridondanza — si resta abbondantemente sotto i 50 euro al mese per il solo Bronze. Questo è il costo che nel 2016 sembrava inaccessibile e che oggi è diventato irrilevante.

Silver e Gold, essendo dati processati e compressi, pesano spesso meno del Bronze grezzo. Il totale di storage per un progetto come il nostro difficilmente supera i 100–150 euro al mese.

 

Compute: qui si ragiona davvero

Lo storage è quasi un non-problema. Il vero costo dell'architettura Medallion è il calcolo: i cluster che eseguono le trasformazioni Bronze → Silver → Gold.

Se si sceglie Databricks, il modello di pricing si basa sui DBU (Databricks Units) — un'unità propria che varia in base al tipo di workload e al cloud sottostante. Un cluster mid-range (4–8 core) che gira 2 ore a notte per processare 1 GB di dati può costare indicativamente 5–15 dollari a run, ovvero 150–450 dollari al mese solo per il processing notturno. A questo si aggiungono i costi del cloud sottostante (EC2, Azure VM, ecc.).

Databricks è potente ma non è economico. Per progetti di volume limitato come quello descritto, il costo della piattaforma può risultare sproporzionato rispetto al valore aggiunto. Ha senso quando il volume di dati è elevato, i pipeline sono complessi, o si vuole sfruttare l'ecosistema ML integrato.

Alternative più leggere e meno costose:

• Apache Spark su EMR o Synapse: si paga solo il cluster quando gira, senza il markup Databricks. Per un pipeline notturno di 2 ore si può scendere a 30–80 dollari al mese.
• dbt + DuckDB: per volumi sotto i 10–20 GB al giorno, DuckDB (gratuito, open source, gira in-process) con dbt come orchestratore delle trasformazioni è una soluzione sorprendentemente capace. Costo compute: quasi zero.
• AWS Glue / Azure Data Factory: servizi serverless, si paga per DPU-ora o per execution. Adatti a pipeline semplici con budget controllato.

 

Snowflake

Nella famiglia degli strumenti enterprise vale la pena citare anche Snowflake, che negli ultimi anni si è ritagliato uno spazio preciso in questo tipo di architetture. L'approccio è diverso da Databricks: dove Databricks nasce come piattaforma di processing (Spark prima, lakehouse dopo), Snowflake nasce come data warehouse cloud-native e ha esteso progressivamente le sue capacità verso il lake.

Per un'architettura Medallion, Snowflake regge bene il layer Silver e Gold — trasformazioni, aggregazioni, query analitiche veloci — e con l'introduzione di Snowflake Iceberg Tables si può usare come engine anche sul dato Bronze su storage esterno, mantenendo i file in formato aperto senza lock-in.

 

Sul fronte costi il modello è a consumo puro: si paga in crediti Snowflake per il compute (i "Virtual Warehouse") e separatamente per lo storage. Un Virtual Warehouse XS che gira 2 ore a notte per le trasformazioni consuma circa 2 crediti — il cui costo varia tra 2 e 4 dollari secondo il cloud e la region. Nella fascia di volumi che abbiamo descritto, si rimane in un range simile a Databricks, con picchi più prevedibili grazie alla separazione netta tra storage e compute.

 

Il vantaggio di Snowflake in certi contesti è la curva di adozione: team abituati a SQL standard trovano l'ambiente familiare, senza dover padroneggiare Spark o i notebook di Databricks. Se l'obiettivo è portare rapidamente un team BI esistente su un'architettura moderna, questo non è un dettaglio.

 

Il limite, specularmente, è che Snowflake è meno a casa sua nei workload di processing intensivo e ML: per quelle esigenze Databricks rimane la scelta più naturale.

 

 

 

 

Il costo che nessuno calcola: la governance

C'è una voce di costo spesso dimenticata nei preventivi: il tempo di setup e manutenzione dell'architettura stessa.

Definire le regole di qualità per il layer Silver richiede lavoro. Non è un'operazione una tantum: le sorgenti cambiano, i gestionali si aggiornano, i web service si evolvono. Qualcuno deve presidiare queste regole, aggiornare le expectations, gestire i dati in quarantena.

In un progetto come il nostro — con n gestionali eterogenei e web service non sempre affidabili — questo presidio è stimabile in 2–4 ore al mese di lavoro specializzato a regime, con un setup iniziale più impegnativo. Non è nulla, ma è un costo prevedibile e pianificabile, molto meno costoso delle giornate perse a debuggare anomalie a posteriori.

 

Il confronto onesto: vale il costo?

Proviamo a mettere i numeri in fila per un caso simile al nostro pensando al costo medio di inizio 2026 per i servizi cloud.

 

Voce	Architettura classica	Architettura Medallion
Storage raw	0 € (dato non conservato)	~50 €/mese
Compute processing	Incluso nel server on-premise	80–450 €/mese (dipende dallo stack)
Setup iniziale	Basso (ETL classico)	Medio-alto (2–6 settimane)
Debug anomalie (costo ricorrente)	Alto (giorni di lavoro)	Quasi zero
Rischio di decisioni su dati sbagliati	Alto	Basso

 

La variabile che di solito sblocca la decisione è l'ultima riga. Quanto costa, nella tua organizzazione, prendere una decisione sbagliata su un report che mostra dati incoerenti? Quanto costa un riunione di tre ore per capire perché un numero non torna? Quanto costa la perdita di fiducia degli utenti nelle dashboard, con il conseguente ritorno a Excel?

Per la maggior parte delle aziende che gestiscono dati operativi critici, la risposta rende il costo dell'architettura Medallion non solo giustificabile, ma conveniente.

 

La nostra raccomandazione pratica

Non esiste una risposta universale, ma esiste una logica:

Se il volume è sotto i 5 GB al giorno e il budget è limitato, dbt + DuckDB + storage object è un punto di partenza serio, modulare e quasi gratuito. Si può crescere senza riscrivere tutto.

Se il volume è significativo o si prevede crescita, o se l'azienda vuole anche capacità ML, Databricks è la scelta più solida — a patto di mettere nel preventivo il suo costo reale.

In ogni caso, il layer Bronze — conservare i dati grezzi — ha un costo così basso che non farlo è difficile da giustificare. È assicurazione a 15 euro al mese.

 

Stai gestendo un sistema BI che sta mostrando i suoi anni? Siamo disponibili a fare una valutazione dell'architettura esistente e a ragionare insieme su un percorso di modernizzazione — anche graduale. Contattaci