Layering: staging, intermediate, marts

Un data warehouse diventa fragile quando ogni query interpreta, pulisce e unisce i dati per conto proprio. Il layering risponde a questo problema separando tre cose che normalmente si confondono: la normalizzazione dei dati sorgente, la logica di business riutilizzabile e i prodotti dati finali che il business consuma. Ogni passaggio ha un proprietario chiaro e un livello di astrazione definito, e questo è il punto da cui parte tutta la disciplina.

Il problema che il layering risolve

Senza una struttura a strati, ogni team o analyst finisce per ricostruire la propria versione della stessa logica, spesso non verificata e non documentata. Il calcolo del revenue, la definizione di utente attivo, la regola che esclude i resi: ognuno la riscrive a modo suo. Il risultato sono numeri che non coincidono tra una dashboard e l’altra, lavoro duplicato e una manutenzione che diventa insostenibile appena cambia la definizione di una metrica. Il layering trasforma dati grezzi in modelli testati, documentati e riusabili, e lo fa imponendo che la logica viva in un solo posto.

I tre livelli

Il modello si appoggia su tre strati, ciascuno con responsabilità precise.

Layer	Responsibility	Example
Staging (stg_)	Pulizia minima e allineamento con i dati sorgente. Nessuna logica di business.	stg_stripe__payments reflects the payments di Stripe con colonne rinominate e tipi corretti
Intermediate (int_)	Logica di business complessa, join tra dati, aggregazioni intermedie e flag. Centralizza la logica riutilizzata da più team.	int_orders_with_customers unisce ordini e clienti, calcola metriche come net_revenue
Marts (mrt_)	Dataset pronti per il consumo da BI e analyst, denormalizzati e semplici. Nessuna logica di business complessa.	mrt_marketing__campaign_performance con metriche aggregate e pronte per reportistica

Lo staging legge i dati grezzi, rinomina le colonne, casta i tipi e filtra le righe tecnicamente invalide, senza fare join. L’intermediate è dove vive la logica di business pesante: join, aggregazioni intermedie, flag che più team riusano. I marts sono il prodotto finito, denormalizzato e leggibile, pensato per chi costruisce report e non vuole sapere come è stata calcolata una colonna.

Perché tre layer e non due o quattro

Il pattern a tre livelli si è affermato per convergenza nella community dbt intorno al 2020, non per dogma ma perché funziona. Due livelli costringono a impastare pulizia e logica di business nello stesso modello, e così torna il problema che il layering voleva risolvere. Quattro o più livelli aggiungono passaggi che nessuno mantiene davvero e che rendono il lineage difficile da leggere. Tre è il punto di equilibrio: ogni layer ha una responsabilità sua e non invade quella degli altri.

Naming conventions

La community dbt suggerisce uno schema di nomi prevedibile, che rende leggibile il DAG a colpo d’occhio.

stg_[source]__[table_name]     → stg_stripe__payments
int_[description]               → int_daily_customer_revenue
mrt_[domain]__[description]     → mrt_marketing__campaign_performance

Conviene usare nomi chiari, evitare abbreviazioni criptiche e il plurale per le tabelle di entità. Un nome ben scelto dice già a quale layer appartiene il modello e da dove arrivano i suoi dati.

Come impostare l’analisi

Prima di applicare il layering a un caso concreto, conviene fissare l’unità di lavoro (source, model, test, mart, metrica o esposizione) e collegarla a segnali osservabili come freshness, lineage, copertura dei test, costo del modello e fiducia degli stakeholder. La decisione attesa può essere un modello dbt, un semantic layer, un contratto, un test o una pipeline di rilascio.

Element	Specifica
Unit of analysis	source, model, test, mart, metric or exposure
Primary signal	freshness, lineage, test coverage, costo modello, fiducia stakeholder
Baseline	periodo precedente, gruppo comparabile, benchmark, scenario controfattuale
Decision	modello dbt, semantic layer, contratto, test, pipeline di release
Risk	scambiare un dato disponibile per una prova sufficiente

Esempio: un refactoring reale

Una media company europea con 30 milioni di utenti attivi mensili aveva oltre 200 modelli dbt, tutti organizzati come marts senza alcun layering. Capire le dipendenze era difficile e mantenere coerenti le metriche lo era ancora di più. Il team di analytics engineering ha rifatto la struttura in tre passi: ha mappato le dipendenze con dbt docs e il DAG per scovare le logiche duplicate, ha estratto quella logica in modelli intermediate aggiornando i marts perché li referenziassero, e infine ha aggiunto test automatici e regole CI per impedire che tornasse logica di business nei marts. I risultati si sono visti subito: onboarding più rapido, aggiornamenti delle metriche più veloci e con meno errori, e maggiore trasparenza per i team finance e marketing.

Esempio: la definizione di Monthly Active User

Senza layering ogni team scrive la propria query di MAU con definizioni leggermente diverse, e i numeri divergono. Con il layering la pulizia sta in staging, la logica di business in intermediate e la metrica finale nei marts, così la definizione è una sola e tutti la riusano.

-- Staging: stg_app__events
-- Intermediate: int_user_activity_flags
SELECT user_id, event_date,
  CASE WHEN event_date > CURRENT_DATE - 30 THEN 1 ELSE 0 END AS is_active_30d
-- Marts: mrt_metrics__mau
SELECT DATE_TRUNC('month', event_date) AS month,
  COUNT(DISTINCT CASE WHEN is_active_30d = 1 THEN user_id END) AS mau

Lab ed esercizio

Al livello base, descrivi in una pagina il layering applicato a un caso che conosci: quale decisione supporta, qual è la metrica primaria, la baseline di confronto, il rischio principale e l’azione prevista se il segnale è confermato.

Al livello intermedio, costruisci una tabella con tre segmenti o periodi. Per ciascuno indica cosa cambia, una possibile spiegazione alternativa e quale controllo adotteresti prima di raccomandare un’azione.

Al livello research-grade, prepara un decision memo dettagliato con ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio dopo la decisione. Come materiali usa dbt, un data warehouse, sorgenti CRM, eventi, marts, semantic layer e lineage. Se non hai dati reali, genera un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Errori da evitare e controlli prima di decidere

L’errore più comune è usare il layering come etichetta senza applicarne il processo. Succede quando si presenta un grafico senza una decisione chiara, una metrica senza baseline o una conclusione senza dire quali assunzioni potrebbero invalidarla. La domanda da porsi è semplice: se questo risultato fosse instabile, quale scelta sbaglierei? Se non c’è una risposta concreta, manca ancora il collegamento tra analisi e azione.

Prima di fidarti dei dati controlla completezza, duplicati, timezone, definizioni cambiate e segmenti esclusi, perché molte analisi falliscono quando il dato di partenza misura un comportamento diverso da quello che credi di osservare. E non fermarti alla media aggregata: segmenta per canale, coorte, piano, paese, device e maturità dell’utente, perché due segmenti con trend opposti possono rendere la media fuorviante. Ogni analisi dovrebbe chiudersi con una scelta concreta, continuare, fermare, iterare, investire, rimuovere o approfondire. Se il layering non cambia la decisione, il collegamento tra metrica e azione non c’è ancora.

Quiz e checkpoint

1. Which concrete decision should this lesson improve?
2. Which unit of analysis makes the problem measurable?
3. Which baseline would you use to avoid a naive reading?
4. Which typical mistake could change the conclusion?
5. Which output would you deliver to a non-technical stakeholder?

Operational Summary

Il layering è utile quando produce decisioni più chiare e azioni concrete, non quando aggiunge terminologia. Separare pulizia, logica di business e prodotti finali in staging, intermediate e marts dà a ogni passaggio un proprietario e un livello di astrazione, e impedisce che la stessa metrica venga ricalcolata in dieci modi diversi. Il valore arriva quando questa struttura cambia davvero come il business prende le sue decisioni.

---

References: dbt Labs (2024), Hughes (2022), Kimball & Ross (2013).