Test, contracts e fiducia nei modelli
Test, contracts e fiducia nei modelli. Lezione su come garantire la qualità dei dati con dbt.
Cosa imparerai
- Applicare test unique, not_null, accepted_values e relationships ai modelli dbt
- Dichiarare model contracts sugli staging per intercettare cambi di schema a monte
- Bloccare la pull request quando i test falliscono
Collegamenti
Test, contratti e fiducia nei modelli
Questa lezione appartiene al binario ml-tabellare: parliamo di tabelle che devono dire la verità. Il tema è la fiducia, e la fiducia nei dati non si dichiara: si costruisce con test che girano a ogni build e contratti che non lasciano spazio alle sorprese.
L’idea in una frase
Test e contratti rendono un modello dbt degno di fiducia perché ogni assunzione su schema, valori e relazioni viene verificata a ogni build invece di essere sperata. La differenza è sottile ma decisiva: passare dalla speranza alla verifica.
La sequenza di adozione
- Metti i test
uniqueenot_nullsulla chiave primaria di ogni modello e blocca la pull request se falliscono. - Aggiungi i test
accepted_valuessui valori ammessi delle colonne critiche e i testrelationshipstra chiavi esterne e primarie. - Scrivi test mirati in SQL per le regole di business che i test standard non coprono, come la coerenza tra ordini e pagamenti.
- Dichiara i contratti sui modelli di staging delle fonti esterne, così un cambio di tipo a monte fa fallire la build in minuti.
- Estendi ai controlli statistici sulle metriche centrali solo dopo che i livelli precedenti sono verdi e stabili.
La piramide dei test
dbt offre una strategia di test stratificata. Salendo di livello cresce la sofisticazione e cambia la severità con cui un fallimento blocca il lavoro.
| Livello | Tipo di test | Copertura | Impatto del fallimento |
|---|---|---|---|
| Livello 1, fondamentali | unique, not_null su primary key | Ogni modello | Blocca la PR |
| Livello 2, business | accepted_values, relationships | Ogni colonna critica | Blocca la PR |
| Livello 3, volume | Range di row count atteso | Modelli chiave | Warning |
| Livello 4, qualità statistica | Media, deviazione standard, distribuzione | Metriche core | Alert |
I test standard coprono la maggior parte dei casi comuni e fermano gli errori gravi. I test singolari aggiungono controlli specifici scritti in SQL, che per passare devono restituire zero righe. I test custom in Jinja sono riutilizzabili e diventano la base di una strategia matura.
I data contracts
Un data contract formalizza l’accordo tra chi produce e chi consuma i dati. Definisce schema, semantica, garanzie di qualità e accordi di freschezza.
Dalla versione 1.5 dbt offre i model contracts, che verificano tipi e vincoli al momento della build.
È uno spostamento netto: il sistema garantisce il dato invece di sperare che sia corretto, e la build fallisce in caso contrario.
Il caso più insidioso è il dato plausibile ma sbagliato. Una sorgente marketing smette di inviare campaign_id su alcune righe mentre il mart di attribuzione continua a produrre numeri verosimili. Solo i test not_null, accepted_values e relationships lo intercettano prima che la dashboard inganni.
Adozione progressiva
Non serve testare tutto subito. Provarci porta solo ad abbandonare. Prima settimana: not_null e unique sulla chiave primaria di ogni modello. Seconda settimana: valori ammessi sulle colonne critiche e relazioni sulle chiavi esterne. Secondo mese: test singolari per le regole di business critiche. Terzo mese: model contracts sui modelli di staging delle fonti esterne. Dal trimestre successivo: test custom riusabili e test di qualità statistica.
La pipeline di integrazione deve eseguire i test in automatico e bloccare la pull request quando falliscono. Senza questo blocco, i test restano documentazione che nessuno legge.
L’errore che svuota i test
Capita di usare test e contratti come etichetta invece che come processo: grafici senza decisione, metriche senza baseline, conclusioni che non dichiarano quale assunzione potrebbe invalidarle. I test ci sono, ma nessuno osa farli fallire.
La domanda di controllo è semplice, cioè quale scelta sbaglieresti se questo risultato fosse instabile. Se i test non ti aiutano a rispondere, stai collezionando badge, non proteggendo numeri.
Verdetto: prima unicità e non-nullità ovunque, poi valori e relazioni sulle colonne critiche, poi contratti sulle fonti esterne; i controlli statistici vengono dopo, non prima.
Il caso Knight Capital
Il primo agosto 2012 la società di trading Knight Capital ha perso 440 milioni di dollari in 45 minuti per aver rilasciato in produzione codice non testato, che ha generato milioni di ordini errati. L’errore stava in una funzionalità obsoleta riattivata per sbaglio, e nessun controllo automatico ha fermato il rilascio. La società non si è più ripresa ed è stata acquisita entro l’anno. È il caso estremo che giustifica la regola della lezione: nessun modello cambia in produzione se i suoi test non sono verdi.
Domande per metterti alla prova
- Quali test metteresti sulla chiave primaria di ogni modello e cosa succede se falliscono?
- Come intercetteresti una colonna rinominata o un tipo cambiato in una sorgente esterna?
- Quando un test mirato in SQL è necessario oltre ai test standard?
- Come organizzeresti l’adozione dei test in un progetto che non ne ha ancora?
Bloccato su questo argomento o vuoi applicarlo al tuo caso? Prenota una call di 15 minuti con un analista esperto.
Percorso collegato
Lezioni da leggere insieme
Questi collegamenti portano la lezione dentro il resto del corso: basi da riprendere, passaggi successivi e connessioni tematiche tra moduli.