1. Perche la data quality e essenziale
Ogni team ha una storia horror: dashboard a +40% revenue, il CEO lo annuncia, poi qualcuno trova una join duplicata. La data quality non e perfezione ma fermare i problemi prima dei decisori.
Il costo di dati sbagliati
Gartner stima $12.9M all anno di costo medio. Peggio ancora e la fiducia persa: se gli stakeholder non si fidano, smettono di usare i dati.
La data quality porta tre risultati:
Fiducia
Gli stakeholder usano i dati con sicurezza perche sanno che sono validati. Niente piu "ricontrollo un attimo".
Velocita
Trovi i problemi alla fonte invece di debuggare dashboard. Minuti invece di ore.
Scala
I controlli automatici scalano con i dati. I controlli manuali no quando hai centinaia di tabelle.
Dal campo
I team che funzionano trattano la qualita come i test unitari: non si rilascia codice senza test e non si rilascia dati senza controlli. E assicurazione, non burocrazia.
2. Le sei dimensioni della data quality
Non tutti i problemi sono uguali. Queste dimensioni ti guidano su cosa puo rompersi e cosa testare.
Completezza
Tutti i dati necessari ci sono?
Test: Tasso di null sui campi obbligatori = 0%
Accuratezza
I valori riflettono la realta?
Test: Confronto con i sistemi sorgente
Coerenza
Stesso formato ovunque?
Test: Formati data, enum, convenzioni di naming
Tempestivita
Dati abbastanza freschi?
Test: max(updated_at) dentro la finestra SLA
Validita
Rispetta le regole di business?
Test: Status in ('active','inactive'), price > 0
Unicita
Nessun duplicato indesiderato?
Test: Chiave primaria unica, nessun ordine duplicato
| Dimensione | Domanda | Errore comune |
|---|---|---|
| Completezza | C e tutto? | Null su campi richiesti |
| Accuratezza | E corretto? | Cache stale, join errate |
| Coerenza | Uguale ovunque? | Formati data diversi |
| Tempestivita | E abbastanza fresco? | Ritardi pipeline, SLA mancati |
| Validita | Ha senso? | Prezzi negativi, date future |
| Unicita | Ci sono duplicati? | Duplicati da fan-out join |
3. Dove testare nella pipeline
Principio "testare ai confini": valida quando i dati entrano e quando escono. Cattura sia problemi upstream che bug di trasformazione.
Stadio 1: Validazione sorgente (ingestion)
Testa i dati in arrivo dai sistemi esterni. Prima linea di difesa.
Cosa controllare:
- • Schema conforme (nessuna colonna nuova/mancante)
- • Conteggio righe nel range atteso
- • Campi obbligatori non null
- • Dati arrivati in tempo (freshness)
Stadio 2: Test di trasformazione
Testa l output delle trasformazioni. Cattura bug di logica SQL/Python.
Cosa controllare:
- • Chiavi primarie uniche (no fan-out)
- • Aggregazioni che sommano correttamente
- • Regole di business applicate
- • Integrita referenziale mantenuta
Stadio 3: Validazione output (delivery)
Testa prima che arrivi a dashboard e consumatori. Ultima chance di bloccare errori.
Cosa controllare:
- • Metriche nei limiti attesi
- • Nessuna anomalia rispetto alla storia
- • Dashboard critici popolati
- • SLA rispettati
Pro tip
Fail fast, fail loud
Meglio che una pipeline fallisca alle 6 con un errore chiaro che produrre dati sbagliati che emergono in board meeting. Configura i test per bloccare la propagazione di dati corrotti.
4. Cosa testare (check pratici)
Parti da questi controlli ad alto valore e basso sforzo. Coprono l 80% dei problemi.
Limiti sul conteggio righe
Verifica che il numero di righe sia nel range atteso (es. 900K-1.1M). Intercetta load troncati o duplicazioni.
expect_table_row_count_to_be_between(min=900000, max=1100000)Soglie di null
I campi obbligatori devono avere 0% null. Gli opzionali devono avere tassi stabili (alert se varia >10%).
expect_column_values_to_not_be_null(column="customer_id")Vincoli di unicita
Le chiavi primarie devono essere uniche. Ferma il fan-out che moltiplica le metriche.
expect_column_values_to_be_unique(column="order_id")SLA di freschezza
I dati non devono superare lo SLA. Controlla max(updated_at) o la partizione.
expect_column_max_to_be_between(column="updated_at", min=now()-24h)Range di valori
I campi numerici devono stare entro limiti validi. Revenue > 0, eta 0-150, percentuale 0-100.
expect_column_values_to_be_between(column="price", min=0, max=100000)Validazione enum
I campi di stato devono contenere solo valori attesi. Intercetta typo e stati imprevisti.
expect_column_values_to_be_in_set(column="status", value_set=["active", "inactive", "pending"])Esempio: test schema dbt
# models/marts/orders.yml
version: 2
models:
- name: orders_mart
description: "Order-level facts for analytics"
columns:
- name: order_id
tests:
- unique
- not_null
- name: customer_id
tests:
- not_null
- relationships:
to: ref('dim_customers')
field: customer_id
- name: order_total
tests:
- not_null
- dbt_utils.accepted_range:
min_value: 0
max_value: 10000005. Alerting senza overload
Il rischio maggiore nel monitoring e la fatigue: troppi falsi positivi e il team ignora tutto. Ecco come mantenere segnale alto.
Da fare
- • Tiering delle alert: P1 (pager), P2 (Slack), P3 (email digest)
- • Usa detection anomalie per metriche variabili
- • Metti contesto nell alert: cosa e rotto, impatto, link runbook
- • Soglie basate su storico
- • Rivedi mensilmente soglie e test
Da evitare
- • Pager su ogni test fallito
- • Soglie hard-code che non si adattano
- • Alert senza owner chiaro
- • Ignorare test "flaky" invece di correggere
- • Mancanza di runbook per guasti comuni
Schema di severita
P1 - Pager immediato
Dati errati nei dashboard di produzione. Dirigenti impattati. Rischio revenue.
P2 - Alert Slack
Qualita degradata ma non critica. Da risolvere entro 4h.
P3 - Digest giornaliero
Issue minori, informative. Revisione nel prossimo sprint.
Dal campo
Ho visto team con 200+ alert al giorno ignorate. Riducendo a 15 alert ad alto segnale, i fix arrivavano in giornata. Meno alert, piu azioni.
6. Strumenti per la data quality
| Strumento | Ideale per | Approccio | Prezzo |
|---|---|---|---|
| dbt tests | Test di trasformazione | Schema + test custom | Gratis (OSS) |
| Great Expectations | Validazione completa | Expectation suites | Gratis (OSS) |
| Monte Carlo | Data observability | ML anomaly detection | Enterprise |
| Soda | Monitoring dati | Check SodaCL | Free tier + piani |
| elementary | Observability nativa dbt | Anomaly detection | Gratis (OSS) |
Testing proattivo
Definisci le regole. I test girano ad ogni run. Esplicito e deterministico.
Strumenti: dbt tests, Great Expectations, Soda
Rilevamento anomalie
Il ML impara il pattern "normale" e allerta sulle deviazioni. Trova unknown unknowns.
Strumenti: Monte Carlo, elementary, Bigeye
7. Checklist delle best practice
Testare ai confini
Valida all ingestion (problemi upstream) e alla delivery (problemi di trasformazione). Blocca presto.
Parti dalle tabelle critiche
Focalizzati prima su quelle che alimentano dashboard esecutivi e report critici. Dimostra valore e poi espandi.
Usa regole e anomalie
Le regole trovano i noti (null, duplicati). L anomaly detection trova l inaspettato (salti di volume).
Tiering delle alert
Non ogni fail merita pager. P1 per impatto revenue, P2 per qualita degradata, P3 info.
Runbook collegati alle alert
Ogni alert linka un doc: significato, investigazione, fix tipici.
Traccia metriche di qualita
Misura: tasso di passaggio test, mean time to detection, mean time to resolution. Migliora continuativamente.
Qualita nel CI/CD
Esegui test su ogni PR. Blocca merge che rompono la qualita. Shift left.
Revisione mensile
Le soglie cambiano, i pattern mutano. Rivedi mensilmente per restare allineato.
Pro tip
Il test "Ci scommetterei?"
Prima di pubblicare una metrica chiediti: "Scommetterei 1.000$ che questo numero e corretto?" Se no, servono piu test. La qualita porta fiducia, e la fiducia nasce dalla validazione.
8. Domande frequenti
Quali sono le dimensioni chiave della data quality?
Completezza, Accuratezza, Coerenza, Tempestivita, Validita, Unicita. In breve: niente mancanti, valori corretti, formato uniforme, dati freschi, rispetto delle regole, zero duplicati.
Come misurare la qualita?
Test automatici su volumi, null rate, unicita, freschezza, drift di schema e regole di business. Traccia nel tempo e imposta soglie di alert.
Quali strumenti usare?
Great Expectations, test dbt, Monte Carlo, Soda, elementary. Scegli se ti servono regole esplicite o rilevamento di anomalie.
Testare prima o dopo le trasformazioni?
Entrambi. Controlli sulla sorgente prima (fail fast) e sul risultato dopo. Cosi intercetti problemi sia in ingresso che in uscita.
Documenta la tua strategia di data quality
Crea diagrammi chiari delle pipeline con i checkpoint di qualita. Mostra agli stakeholder dove e come avviene la validazione.
Guide correlate
Documentazione delle pipeline
Documentare pipeline che i nuovi possono debuggare dal giorno 1
Data Lineage Best Practices
Tracciare i dati dalla sorgente al dashboard
Data Contracts
Definire SLA di qualita con contratti formali
Medallion Architecture
Stratificare la qualita con Bronze, Silver, Gold
Architettura pipeline ML
Applicare il monitoring ai feature pipeline ML