Controllo della qualità dei dati

1) Assegnazione e principi

Perché: rapporti affidabili (GGR/tasse), antifrode e modelli RG, download, prodotti e personalizzazione.

• Schema-first & Contracts: tutte le fonti sono obbligate a pubblicare i dati del contratto.
• Codice come DQ: regole nel repository, versioni, test e gelosia.
• Osservabilità-by-default: metriche/logica/linea.
• Privacy-by-design: PI minimo, maschera e RLS/CLS.
• Cost-aware - Priorità delle regole critiche, campionamenti intelligenti.

2) Tassonomia misurazione qualità

Completi - Percentuale di campi/righe obbligatori.
Validity: conformità a tipi/intervalli/guide.
Uniqueness - Nessuna chiave/evento duplicata.
Consistency - Integrità di riferimento, invarianti aziendali.
Accuratezza (Precisione) - Si avvicina alla sorgente «vera» (compresse di riepilogo).
Timelover/Freshness (Puntualità) - Ritardo del materiale.
Lineage Integrity - Conserva le origini/versioni delle trasformazioni.

Per ogni dominio vengono definite qualità e criticità KPI (critical/major/minore).

3) Contratti e schemi (fonte verità)

JSON , a Registry.
Stabilità: modifiche backward-compatibili - aggiunta di nullable; breaking - nuova versione + doppia voce.
Tracciabilità: «event _ id», «trace _ id», «schema _ variante», «source».

4) DQ-come-codice - Struttura degli artefatti

/dq/
rules/
silver. payments. yaml gold. ggr_daily. yaml checks/
sql/
python/
policies/
severities. yaml notifications/
routes. yaml

Regole: YAML/SQL dichiarativi;

Gravità: mapping, canali di alert/livelli di escalation;

CI: lenti di schema, test di compatibilità, «dry-run «/simulatore.

5) Esempi di regole (YAML)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive severity: critical type: range column: amount min: 0. 01
- name: currency_in_whitelist severity: major type: in_set column: currency set: [EUR, USD, GBP, TRY, BRL]
- name: unique_tx severity: critical type: unique columns: [transaction_id]
- name: fk_user_exists severity: critical type: foreign_key column: user_pseudo_id ref_table: dim. users ref_column: user_pseudo_id
- name: ts_monotonicity severity: minor type: temporal expression: "ts between date_sub(now(), interval 90 day) and now()"

6) SQL test (campioni)

Unicità delle chiavi

sql
SELECT transaction_id, COUNT() AS c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

Completezza campi obbligatori

sql
SELECT COUNT() AS nulls
FROM silver. payments
WHERE amount IS NULL OR currency IS NULL OR ts IS NULL;

Guide/Consistenza

sql
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON p. currency = r. code
WHERE r. code IS NULL;

7) Flusso DQ (real-time)

Ingest-validation: schema validation, size-limits, tipi ed enum's.
On-stream convalida: deadup '(event _ id, source)', allowed lateness, valenza valuta/somma.
Limiti: errori critici DLQ + alert; non critici, ma ignorare (con la bandiera'dq _ flag ').
Metriche: completeness/lag/dup-rate.

8) Operazioni con errori e eccezioni

DLQ/Quarantine - I record «malati» sono trattenuti e sono disponibili per la correzione.
Excection records - Scheda d'eccezione (owner, scadenza, motivo, area).
Auto-fallback - Utilizza l'ultima vetrina corretta.
Le chiusure SLA sono critiche - 24-48 ore; Maggiore - ≤ 5 schiavi. giorni.

9) Coerenza con la privacy e la compliance

Riduzioni PII: non controllare i PII crudi nei livelli analitici; Utilizzare gli alias.
RLS/CLS - I controlli vengono eseguiti in base al masking dei campi.
Regionalizzazione: le regole contano «jurisdiction» (EEA/UK/BR).
Legale Hold - Divieto di sovrascrivere gli archivi all'interno della custodia.

10) Osservabilità, SLI/SLO e alert

• Freshness p95 (Silver): ≤ 15 minuti
• Completeness (critical types): ≥ 99. 5%.
• Validity (schema): ≥ 99. 9%.
• Duplicate rate: ≤ 0. 1%.
• DQ incident MTTR: ≤ 24–48 ч.

Alert: routing in base alla serietà (pager per critical), antialiasing (deduplicazione degli alert), «mainenance windows».

11) Dashboard (set minimo)

Mappa termica Freshness/Completeness per domini e mercati.
Top N tabelle per inident rate e costo di correzione.
Vortice DQ: ingest → silver → gold (perdita/correzione).
Mappa della linea per report critici (regolatore/GGR/RG/AML).
Mappa di schemi e client «obsoleti» (versioni SDK/schemi).

12) Processi e RACI

R - Data Engineering (regole per tabella), Domain Owners (semantica).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legale/DPO, Architettura, SRE.
I (Informed): BI/Prodotto/Marketing/Finanza/Operazioni.

Ciclo di vita di una regola: suggerire con una voce «avvio oscuro» per attivare il monitoraggio della retrospettiva.

13) Accuratezza e precisione (Accuracy)

Checkpoint/transazioni è un insieme di provider OLTP (PSP/KYC).
Confronto a due contorni: pipeline indipendente per la convalida selettiva.
Tolleranze: soglie di percentuale per metriche (ad esempio, variazione GGR) 0. 2%).
Atti giornalieri - Report di fusione per il controllo.

14) Costo e priorità

Regole critiche avviate più spesso (streaming/orologio), minor - daily.
Utilizzare i prelievi e i checks materializzati per le tabelle pesanti.
Monitorare cost/query e cost/GB, applicare clustering/indicizzazione.
Assegnare il budget alla DQ nel taglio dei comandi.

15) Modelli per le vetrine Gold (esempio GGR Daily)

yaml table: gold. ggr_daily owner: fin-analytics slo:
ready_by_local_time: "06:00"
rules:
- name: ggr_not_negative severity: critical type: range column: ggr min: 0. 0
- name: market_known severity: major type: in_set column: market set_ref: ref. markets
- name: fx_source_present severity: major type: not_null column: fx_source
- name: completeness_by_market severity: critical type: completeness partition_keys: [event_date, market]
expected_rows_expression: "ref. expected_activity(event_date, market)"

16) Incidenti di qualità: gestione e comunicazione

Ticketing Crea attività automatiche con campionamenti e metriche attaccate.
Modelli di comm: notifica ai proprietari di prodotti/regolatori in caso di impatto.
Post mortem: causa radice (schema draft, upstream bug, carico di lavoro), azioni CAPA, controllo «ritorno regressione».

17) Road map di implementazione

1. Catalogo tabelle critiche (Payments, Gameplay, GGR, Compliance).

2. Regole YAML per 10-15 controlli chiave + convalida CI.

3. Dashboard Freshness/Completeness e alert per critical.

4. DLQ/Quarantine + runbook correzioni.

• Estensione delle regole (FK/accuracy), simulatore dry-run, A/B di inclusione.
• Integrazione con lineage, accordi di esclusione e SLA.
• DQ in streaming per le sorgenti «rumorose».

• Generazione automatica della documentazione delle regole, metriche del costo.
• Tracciati di controllo (independent recordation), retrospettive week.
• Rule-as-Code SDK, registro dei controlli di dominio standard.

18) Foglio di assegno prima della vendita

• Contratti e schemi in Registry, test di compatibilità in corso.
• Le regole YAML sono rovinate, severity/escalation assegnate.
• Dashboard e alert sono attivi; SLO definiti e concordati.
• DLQ/Quarantine è disponibile, runbooks documentato.
• Le procedure di esclusione/atto di foglio sono concordate con Legale/Compliance.
• Misurazione del costo dei controlli e limiti per le richieste pesanti.

19) Errori frequenti e come evitarli

Dati crudi senza contratto: immettere schema-first e consumer-test.
Controlli manuali: trasferisci in codice DQ come e CI.
Nessuna priorità: separa critical/major/minore e canali di alert.
DLQ mancante: impossibile gestire gli errori - Aggiungere la quarantena.
Ignora il costo: profila le richieste, usa la materializzazione.
Niente post mortem: gli errori si ripetono - inserisci CAPE e controllo delle regressioni.

20) Totale

Il sistema di controllo della qualità dei dati non è un insieme di controlli differenziati, ma un programma gestito: contratti e schemi, DQ-come-codice, osservabilità e SLO, disciplina degli incidenti e degli errori. In base a questo articolo, è possibile ottenere dati riproduttivi, verificabili e convenienti sufficienti per la regolamentazione dei rapporti, le soluzioni alimentari e i rilevatori di rischio real-time.