Snapshots and slow change management

Prima o poi ogni team dati incontra la stessa domanda: come faccio a sapere com’era un cliente, un piano o un attributo in un momento preciso del passato? Lo stato attuale del database non basta, perché la storia che spiegava una decisione presa sei mesi fa è sparita. Gli snapshot di dbt conservano quella storia, e in questa lezione impari a configurarli e a interrogarli senza buchi temporali.

L’idea in una frase

Gli snapshot di dbt conservano la storia completa di una dimensione registrando ogni cambiamento di attributo con il suo periodo di validità.

La procedura in cinque passi

1. Scegli la tabella da storicizzare e la chiave immutabile che identifica ogni entità.
2. Dichiara la strategia di rilevamento: timestamp se la colonna di modifica è affidabile, check otherwise.
3. Schedula lo snapshot con una frequenza superiore al ritmo di cambiamento dei dati.
4. Interroga sempre con il filtro sul periodo di validità per ricostruire lo stato storico corretto.
5. Testa unicità della chiave, completezza delle righe e assenza di buchi temporali a ogni run.

Il problema che cambia le decisioni

Un cliente cambia segmento, piano, stato CRM e owner commerciale nel tempo. Se guardi solo lo stato attuale del database, perdi la storia che spiegava una decisione presa sei mesi fa. Gli snapshot servono a questo: tenere traccia di come un attributo è cambiato, così da ricostruire il contesto corretto di una metrica in qualsiasi momento del passato.

Cosa sono le slowly changing dimensions

Una Slowly Changing Dimension (SCD) è una dimensione i cui attributi cambiano nel tempo, e di cui ti serve il valore storico e non solo l’ultimo. Lo stato attuale non basta: devi poter rispondere quale fosse, ad esempio, il piano di abbonamento di un cliente a una data passata precisa.

I tipi più usati si distinguono per come trattano il valore vecchio.

Type	Strategy	Usage	Example
Type 1	Overwrite	When the old value is no longer needed	Fix a typo in the name
Type 2	New row with validity date	When full history is needed	Subscription plan change
Type 3	"Previous value" column + "current value"	When only the immediately preceding change is needed	Previous vs current registered office

Il Type 2 è il più usato, perché conserva la storia completa con colonne di validità temporale.

Verdetto: il Type 2 vince quando serve lo storico completo: conserva ogni cambiamento con periodo di validità, mentre Type 1 e Type 3 restano per correzioni e cambiamenti immediatamente precedenti.

customer_id	plan	valid_from	valid_to	is_current
C001	free	2023-01-10	2023-06-15	false
C001	pro	2023-06-15	2023-12-01	false
C001	enterprise	2023-12-01	NULL	true

Con questa struttura filtri per il periodo che ti interessa, con la data di analisi compresa tra inizio e fine validità.

Gli snapshot di dbt come Type 2 automatico

dbt offre un modulo per gli snapshot che automatizza il versionamento. Tu dichiari la strategia e dbt la applica a ogni esecuzione. Nel caso più comune definisci customer_id come chiave unica e usi una strategia basata sulla colonna updated_at.

A ogni esecuzione dello snapshot accade questo:

1. Legge la tabella sorgente
2. Confronta ogni riga con la versione salvata
3. If customer_id è nuovo, inserisce una riga con inizio validità uguale al momento corrente e fine validità vuota
4. If updated_at è cambiato, chiude la riga precedente e ne crea una nuova
5. Se nulla è cambiato, ignora

Le due strategie principali coprono casi diversi. Con la strategia timestamp ti affidi a una colonna di ultima modifica. Con la strategia check confronti un insieme di colonne e lo snapshot scatta se almeno una è cambiata, utile quando non ti fidi del campo di timestamp.

Gli errori che rovinano uno snapshot

Quasi tutti i problemi nascono da poche scelte sbagliate all’inizio. Una chiave unica non immutabile è la prima trappola: usa ID generati dal sistema, mai email o altri campi che il cliente può modificare. Quando updated_at non è affidabile, passa alla strategia check sulle colonne che contano. Una query storica senza filtro temporale restituisce risultati sbagliati, quindi usa sempre il range di validità. Infine la frequenza: se i dati cambiano più volte al giorno, uno snapshot giornaliero perde le variazioni intermedie.

Un esempio che ha fatto scuola

Monzo, banca digitale con 8 milioni di clienti, usa gli snapshot di dbt per tracciare ogni cambiamento di stato conto, piano tariffario e dati anagrafici con la data esatta. Senza snapshot la stessa logica avrebbe richiesto migliaia di righe di codice e mesi di lavoro; con dbt sono bastate poche righe e qualche settimana. Dai dati storici emerge un dettaglio operativo: i clienti che passano da standard a plus entro 30 giorni hanno un LTV del 43 per cento più alto di chi aspetta 90 giorni. È un’informazione che esiste solo se conservi la storia, e ha portato a rivedere l’onboarding.

Domande per verificare la comprensione

1. Quando basta sovrascrivere un attributo e quando serve invece uno storico completo?
2. Quale chiave immutabile scegli per lo snapshot e perché non usi la email?
3. Come ricostruisci il valore di un attributo a una data passata precisa?
4. Quale controllo ti segnala che lo snapshot sta perdendo cambiamenti intermedi?