Data warehouse

Il sistema separato dal database di produzione che raccoglie i dati di un'azienda in un unico posto, ottimizzato per l'analisi invece che per le transazioni.

Un data warehouse è un sistema, separato dal database di produzione, che raccoglie in un unico posto tutti i dati utili a un’azienda ed è ottimizzato per l’analisi umana: ampiezza, profondità storica, query complesse. La separazione è il suo tratto costitutivo. Il database di produzione (OLTP, online transaction processing) serve il prodotto e i suoi utenti: è veloce, ottimizzato per il codice che legge e scrive, e di norma non conserva la storia. Il warehouse (OLAP, online analytical processing) serve le persone dentro l’azienda: analisti, data scientist, management. Sahar Massachi, ex data engineer di Facebook e autore della serie “Stop using Slowly-changing Dimensions!” su DataExpert.io, la sintetizza così: “Your production database is meant to be fast, serve your product and users. Your warehouse is meant to be human-usable, and serve people inside the business”.¹

Perché esiste

Negli anni novanta e duemila costruire un warehouse comportava un compromesso reale tra “abbastanza grande da contenere tutti i dati” e “abbastanza veloce da essere utile”. Risolverlo richiedeva ingegneria costosa: cubi preaggregati, indici su misura, processi ETL pesanti. Secondo Massachi quel compromesso è praticamente scomparso attorno al 2015, con l’arrivo di motori come Presto/Trino, Spark, BigQuery, Snowflake e le offerte analoghe di AWS, che permettono di interrogare dati arbitrariamente grandi in secondi. Massachi chiama questo periodo la “golden age” del data warehousing: il collo di bottiglia non è più l’hardware ma il tempo ingegneristico e la complessità concettuale che il team riesce a reggere.¹

Da questo spostamento discende la tesi centrale della serie: molte pratiche storiche del data modeling, progettate per risparmiare storage costoso, sono diventate complessità senza beneficio. È l’argomento con cui Massachi critica le Slowly Changing Dimensions e propone il date stamping come principio organizzatore alternativo.²

Struttura: il dato scorre verso il basso

Massachi descrive il warehouse come una scatola in cui il dato scorre dall’alto verso il basso:¹

In cima stanno le copie raw: repliche esatte dei database di produzione, dati delle API di marketing, dei payment processor. Sono input non affidabili per definizione, e non si toccano.
In mezzo lavorano le pipeline: deduplicano, puliscono, rinominano colonne, poi trasformano, incrociano e arricchiscono i dati verso tabelle “master” ad alta affidabilità.
In fondo vivono le tabelle user-facing che gli analisti interrogano: le dimension table per le entità, le fact table per gli eventi, le tabelle di summary per gli aggregati.

Il flusso del warehouse secondo la Parte 1 della serie di Massachi: il dato entra grezzo in cima e scende, attraverso le pipeline, verso le tabelle pulite che gli analisti interrogano.

Il pattern moderno è ELT (extract, load, transform), non ETL: il dato si copia grezzo nel warehouse e si pulisce lì dentro, non prima del caricamento. Ogni giorno nuovo dato entra in cima e le pipeline lo fanno scendere, aggiornando le tabelle a valle.¹

Il caso paradigmatico: Meta

Facebook usava già nei primi anni 2010 un’architettura di questo tipo: MySQL per la produzione, HDFS con Hive per il data lake, e uno snapshot giornaliero del database di produzione spostato da MySQL a Hive con un date stamp. Massachi la indica come architettura di riferimento ancora valida: la stessa struttura funziona oggi con formati tabellari come Iceberg, Delta o Hudi, e ciò che è cambiato è il livello di astrazione, non il principio.²

Sulla scala di quel sistema esiste una testimonianza interna: Shridhar Iyer, per 13 anni nell’organizzazione dati di Meta fino al ruolo di Senior Tech Lead e Director per AI e data stack, racconta nell’Analytics Engineering Podcast la crescita dello stack da migliaia a decine di milioni di tabelle, a partire dagli anni di Hadoop e Hive con DataSwarm, l’orchestratore interno che precedette Airflow.³

Il warehouse come prodotto

Nella Parte 3 della serie Massachi sposta il fuoco dal sistema al ruolo: il warehouse è il “prodotto” di cui il data engineer è product owner, e la sua qualità si misura sul fatto che i colleghi lo usino per decidere. La tesi è sviluppata nella voce data engineer come product owner. Nello stesso articolo un aneddoto ridimensiona il warehouse ideale: in una startup Series B, il “vero data warehouse con Spark” che Massachi aveva progettato per un mese non fu mai costruito, mentre pochi giorni di script Python sui dati grezzi produssero le metriche che aiutarono a chiudere il round successivo (vedi credibility economy).⁴

Voci correlate

Pipeline (data engineering) — lo strumento numero uno per costruire e mantenere il warehouse
Dimension table e fact table — i due tipi di tabella user-facing
Date stamping — il principio organizzatore che rende banali le query storiche
Slowly Changing Dimensions — la pratica storica che Massachi considera superata
Functional data engineering — il fondamento teorico della semplificazione
Data engineer come product owner — il warehouse come prodotto
Portale: Data engineering

Bibliografia e sitografia

Sahar Massachi, The data warehouse setup no one taught you (Stop using Slowly-changing Dimensions! Part 1), DataExpert.io, 24 ottobre 2025. blog.dataexpert.io
Sahar Massachi, SCD-2 considered harmful! (Stop using Slowly-changing Dimensions! Part 2), DataExpert.io, 4 novembre 2025. blog.dataexpert.io
Sahar Massachi, Junior data engineers build pipelines. Seniors build trust, DataExpert.io, 30 giugno 2026. blog.dataexpert.io
Data lessons from inside Meta (intervista a Shridhar Iyer), The Analytics Engineering Podcast, dbt Labs, 30 luglio 2026.

Massachi, Stop using SCD! Part 1, DataExpert.io, 2025. ↩ ↩² ↩³ ↩⁴
Massachi, SCD-2 considered harmful! Part 2, DataExpert.io, 2025. ↩ ↩²
Data lessons from inside Meta, The Analytics Engineering Podcast, 2026. ↩
Massachi, Junior data engineers build pipelines. Seniors build trust, DataExpert.io, 2026. ↩