Materialization, incremental, and snapshot for events and customer state

In analytics engineering ti capita ogni giorno di gestire dati che arrivano quasi in tempo reale o che cambiano lentamente. La scelta tra vista, tabella, incremental e snapshot non è una questione di eleganza tecnica: è il modo in cui bilanci freschezza, costi e correttezza storica, e di solito ne puoi massimizzare solo due alla volta.

Il problema che guida la scelta

La domanda di fondo è come trasformare dati grezzi in modelli affidabili e riusabili dal business senza sprecare risorse né perdere eventi importanti. È questo che decide quale materializzazione usare per gli eventi e per lo stato cliente. Sapere cosa fa ogni tipo di materializzazione non basta: serve capire quale decisione concreta vuoi migliorare, quale dato osservi e quale errore vuoi evitare.

Un modello per restare sulla decisione

Per orientarti puoi tenere a mente quattro domande.

Phase	What to clarify	Output
Question	Which real choice needs improvement?	Decision to make
Measure	Quale segnale rappresenta il problema?	Metric or source data
Control	Which baseline makes the result interpretable?	Credible comparison
Action	What changes after the analysis?	Next operational step

Lo schema serve a tenere il focus su ciò che conta, cioè la decisione, invece che sulla scelta tecnica fine a se stessa.

Come rendere la scelta riproducibile

Perché un’altra persona possa ripetere e criticare il tuo ragionamento, dichiara gli elementi in gioco. L’unità di analisi è una source, un model, un test, un mart, una metrica o un’esposizione. Il segnale principale è di solito freshness, lineage, copertura dei test, costo del modello o fiducia degli stakeholder. La baseline arriva da un periodo precedente, da un gruppo comparabile, da un benchmark o da uno scenario controfattuale. La decisione attesa riguarda un modello dbt, un semantic layer, un contratto, un test o una pipeline di release. Il rischio ricorrente è confondere un numero disponibile con una prova sufficiente. Solo a queste condizioni un altro analista può ripetere la logica e confermare o smentire la decisione.

The four dbt materializations

Materialization	Behavior	When to use it	Storage	Freshness
View	SQL view, no data materialized	Staging, lightweight models	0	Always up to date
Table	Physical table, rebuilt from scratch	Small/medium models with complex logic	High	Updated at build
Incremental	Adds only new rows	Large tables with append-only data	High	Updated at build on new rows
Ephemeral	Inline CTE, never materialized	Light intermediate transformations	0	Calculated in the consumer query

La scelta dipende dalla dimensione del modello, dalla frequenza di aggiornamento e dal costo di ricostruirlo da zero.

Incremental, dove ripaga davvero

L’incremental ti permette di scalare senza ricostruire tutto a ogni esecuzione. Il meccanismo è caricare solo i dati nuovi o modificati, appoggiandosi a un campo affidabile come event_time. Le strategie disponibili coprono casi diversi: append aggiunge righe ed è adatta a dati immutabili; delete+insert aggiorna le righe esistenti cancellandole e reinserendole; merge aggiorna e inserisce ed è disponibile su Snowflake e BigQuery; insert_overwrite sovrascrive intere partizioni e conviene sui dati partizionati. Il cuore della sintassi è il blocco condizionale che filtra i dati da caricare solo quando il modello viene eseguito in modalità incrementale.

Quando l’incremental non conviene

Non sempre vale la pena complicare il modello. Se la tabella è piccola, sotto i <10M righe, una semplice table è più gestibile. Se la logica cambia spesso e va riapplicata a tutto lo storico, l’incremental ti costringe a continui full refresh che vanificano il vantaggio. E se non hai un campo affidabile per individuare le righe nuove, manca la base stessa su cui funziona il pattern.

Tenere sotto controllo i costi del warehouse

Sul warehouse paghi il compute consumato, quindi conviene contenerlo. In sviluppo limita la finestra dati, per esempio agli ultimi 30 giorni, così non ricostruisci miliardi di righe a ogni prova. Dimensiona il warehouse in base al carico, con una taglia XS per i test e una XL per la produzione. Disabilita i modelli che nessuno usa più, perché continuano a costare senza generare valore.

Caso pratico: il taglio dei costi di Zapier

Zapier ha individuato i modelli più costosi e li ha convertiti a incremental, abbattendo la spesa senza perdere dati. Ha anche introdotto timeout per le query lunghe e ridotto la retention in staging. Con questo approccio pragmatico la bolletta dbt è scesa da 28.000$a 11.200$ al mese.

Controllo di qualità prima di fidarti

Prima di affidarti a queste tecniche, controlla sempre la completezza dei dati, l’eventuale presenza di duplicati, il timezone, i cambiamenti nelle definizioni e i segmenti esclusi. Molti errori non nascono dal modello ma dai dati di partenza, che non rappresentano il comportamento atteso.

Interpretation by segments

Non fermarti alla media aggregata. Segmenta per canale, coorte, piano, paese, device e maturità dell’utente. Quando segmenti diversi si muovono in direzioni opposte, la media nasconde la realtà e ti porta a decidere male.

Caso studio: due miliardi di eventi

Pensa a una tabella eventi con due miliardi di righe e ritardi di arrivo fino a 48 ore. Qui serve una strategia incremental con una finestra di ricalcolo e test di completezza, perché un evento può arrivare anche due giorni dopo che è accaduto. Il lavoro non finisce con il modello: bisogna verificare se i numeri migliorano davvero o oscillano in modo normale, segmentare per coorti e pesare il costo rispetto al beneficio.

Observed evidence	Cautious interpretation	Recommended action
The number improves	Potrebbe essere reale o variazione normale	Cercare confronto e segmentazione
One segment changes more than others	La media nasconde differenze significative	Separate cohorts or use cases
Il costo cresce con il risultato	L’impatto va valutato sul margine	Estimate trade-offs and sustainability

Esercizio guidato

Al livello base descrivi in una pagina la decisione che queste materializzazioni dovrebbero supportare, la metrica primaria, la baseline, il rischio principale e l’azione da prendere se il segnale è confermato. Al livello intermedio costruisci una tabella con tre segmenti o scenari, indicando per ciascuno cosa cambia, una spiegazione alternativa plausibile e un controllo da fare prima di raccomandare un’azione. Al livello research-grade prepara un memo decisionale con ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio post-decisione. Per gli strumenti usa dbt, il warehouse, le sorgenti CRM, gli eventi, i marts, il semantic layer e il lineage; se non hai dati reali, costruisci un dataset sintetico di almeno 200 righe con una dimensione temporale, una dimensione segmento e una metrica di outcome.

L’errore tipico da evitare

Non trattare materialization, incremental e snapshot come semplici etichette. Il rischio è mostrare grafici senza decisioni, metriche senza baseline o conclusioni che non dichiarano le assunzioni critiche. La domanda chiave resta la stessa: se il risultato fosse instabile, quale scelta sbaglierei? Se non sai rispondere, manca il legame tra analisi e azione.

Checkpoint

Prima di chiudere, verifica di saper rispondere a queste domande.

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?

Summary

Materialization, incremental e snapshot servono solo se aiutano a decidere meglio, non se aggiungono terminologia. Il percorso problema, modello, formalizzazione, esempio, lab e checkpoint trasforma la teoria in una pratica che puoi verificare.

---

References: dbt Labs (2024), Zapier Engineering (2023), Snowflake Documentation (2024).