Layering: staging, intermediate, marts

Senza strati, ogni team ricostruisce la propria versione della stessa logica: il calcolo del revenue, la definizione di utente attivo, la regola che esclude i resi. Il layering è la risposta a questo caos, e organizzare le trasformazioni in strati leggibili è il cuore del design dei modelli dbt. Qui impari a farlo mentre il progetto cresce, senza che i numeri smettano di coincidere.

L’idea in una frase

Il layering separa la pulizia delle sorgenti, la logica di business riusabile e i dataset finali in tre strati con responsabilità distinte.

La procedura in cinque passi

1. Mappa ogni tabella sorgente a un modello di staging con sole rinomine, cast di tipo e filtri di righe invalide.
2. Sposta ogni join e ogni regola di business riusata da più team in un modello intermediate.
3. Costruisci i marts come dataset finali denormalizzati senza logica di business complessa.
4. Applica a ogni modello il prefisso del suo layer e i test di unicità e completezza.
5. Blocca in review qualsiasi logica di business che ricompare dentro staging o marts.

Il problema che il layering risolve

Senza strati, ogni team ricostruisce la propria versione della stessa logica. Il calcolo del revenue, la definizione di utente attivo e la regola che esclude i resi vengono riscritti ognuno a modo suo. Il risultato sono numeri che non coincidono tra dashboard diverse, lavoro duplicato e manutenzione insostenibile appena cambia una definizione. Il layering impone che la logica viva in un solo posto. Così trasforma dati grezzi in modelli testati, documentati e riusabili.

I tre livelli

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

Layer	Responsabilità	Esempio
Staging (stg_)	Pulizia minima e allineamento con i dati sorgente. Nessuna logica di business.	stg_stripe__payments riflette la tabella 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, converte i tipi e filtra le righe tecnicamente invalide, senza join. L’intermediate ospita la logica pesante: join, aggregazioni intermedie e flag riusati da più team. I marts sono il prodotto finito, denormalizzato e leggibile, pensato per chi costruisce report senza dover ricostruire i calcoli.

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 mescolare pulizia e logica di business nello stesso modello, e così ritorna il problema iniziale. Quattro o più livelli aggiungono passaggi che nessuno mantiene davvero e rendono il lineage difficile da leggere. Tre è il punto di equilibrio: ogni layer ha una responsabilità propria e non invade quella degli altri.

Convenzioni di naming

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.

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

Errori da evitare

L’errore più comune è usare il layering come etichetta senza applicarne il processo: un grafico senza decisione chiara, una metrica senza baseline o una conclusione senza dire quali assunzioni potrebbero invalidarla. Prima di fidarti dei dati controlla completezza, duplicati, timezone, definizioni cambiate e segmenti esclusi. Non fermarti alla media aggregata: segmenta per canale, coorte, piano, paese, device e maturità dell’utente, perché due segmenti con trend opposti rendono la media fuorviante.

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

Verdetto: tre layer con responsabilità rigide battono sia i due layer che impastano tutto sia i quattro o più layer che nessuno mantiene.

Un esempio che ha fatto scuola

dbt nasce nel 2016 dentro Fishtown Analytics, una piccola consultancy di Philadelphia che si stanca di riscrivere le stesse trasformazioni SQL per ogni cliente. Dalla pratica quotidiana emerge la convenzione dei tre layer, con staging dedicato alla pulizia, intermediate alla logica riusabile e marts al consumo finale. Nel febbraio 2022 dbt Labs raccoglie 222 milioni di dollari a una valutazione di 4,2 miliardi, e quello schema diventa il riferimento condiviso dalla community. La lezione è che la separazione rigida dei layer elimina le definizioni duplicate: ogni metrica vive in un solo posto e ogni dashboard riusa lo stesso numero.

Domande per mettere alla prova il design

1. Quale logica metti in staging e quale vieti esplicitamente in quel layer?
2. Quando una regola di business merita un modello intermediate invece di vivere nei marts?
3. Come verifichi che due dashboard usino davvero la stessa definizione di metrica?
4. Quale segnale ti dice che la logica duplicata sta tornando nei marts?