Convalida dei dati

1) A cosa serve la piattaforma iGaming

Fiducia nei rapporti e KPI: GGR/NET, conversioni, ritenzione, segnali RG.
Affidabilità ML/screening: fitta corretta per antifrode/raccomandazioni/RG.
Operazioni in tempo reale: alert alla deriva/perdita di eventi prima che i pagamenti/UX siano danneggiati.
Compagine: La mancanza di PII/segreti dove non dovrebbero essere; È provabile la tracciabilità.

2) Dove convalidare: livelli di controllo

1. Input (batch/stream) - Schema, tipi, campi obbligatori, idempotency/deadup.
2. Strim processing: finestre/filigrana, ordine, pass/ritardo, exactly-once.
3. ETL/ELT e trasformazioni: collegamenti/gioielli, aggregazioni, bilanci aziendali.
4. DWH/vetrine (Gold) - Consistenza tra le tabelle, freschezza, unicità delle chiavi.
5. Feature Store/online: intervalli di fich, coerenza di offlayn↔onlayn.
6. BI/API - Conteggio e filtri, SLAs su latency/freshness, k-anonimato.

3) Tipi di controllo (directory)

Schemi: tipo/nullable/enum/regex/JSON-shape; modifiche incompatibili.
: , valuta {EUR, USD, TRY, BRL}, tasso , .
Identità/chiave: la chiave primaria è univoca, la chiave foreign key non è sospesa.
Qualità dei campi: riempimento, lunghezza, formato (BAN, BIN, e-mail token).
Statistiche/linee base: frequenze, distribuzioni, corridoi quantali.
Anomalie: picchi bruschi di volume/quota, zero/duplicati, schema draft.
Freschezza: max (ts) non più grande di X; ingest→gold ≤ T.
Consistenza: somma delle parti = riepilogo; multi-table reconciliation.
Privacy/Sicurezza: Zero-PII fuori dalle aree autorizzate; Tornitura/maschera.
Regolazione: i campi RG/AML sono presenti e plausibili (date, segni).

4) Data Contracts (contratti dati)

Il contratto fissa lo schema + regole di qualità + SLO tra la fonte e i consumatori.

yaml dataset: payments_ingest_v2 owner: team-payments schema:
id: {type: string, pattern: "^[a-f0-9]{32}$", unique: true}
ts: {type: timestamp, timezone: "UTC", nullable: false}
amount: {type: decimal(18,2), min: 0. 00}
currency: {type: string, enum: ["EUR","USD","TRY","BRL"]}
psp: {type: string, required: true}
quality:
freshness_max: "PT5M"
completeness_min: 0. 995 duplicate_rate_max: 0. 001 pii_allowed: false slo:
p95_ingest_latency_ms: 30000 success_rate: 0. 995

Modifiche al contratto - Tramite semver e migrazioni: «MAJOR» rompe, «MINOR» aggiunge un campo, «PATCH» corregge la descrizione.

5) «Anticipazioni» e criteri

In attesa - Controlli dichiarativi eseguiti in pipline (batch/stream).

yaml expectations:
- name: unique_primary_key check: "unique(id)"
severity: "error"
- name: amount_non_negative check: "amount >= 0"
severity: "error"
- name: currency_enum check: "currency in ['EUR','USD','TRY','BRL']"
severity: "error"
- name: ts_fresh_enough check: "now() - max(ts) <= interval '5 minutes'"
severity: "warn"
- name: pii_absent check: "no_plain_pii(columns: ['email','card','iban'])"
severity: "error"

• 'error' → quarantena partizione/batch, avviso + ticket; blocco downstream.
• «warn» →, ma crea un compito da analizzare; contrassegno di qualità.
• «info» è solo un monitoraggio.

6) Streaming: specificità dei controlli

Watermarks/late data: consentiamo il ritardo dì ≤ 120s ", altrimenti la quarantena; Compensiamo con le finestre finali.
Idempotency è la chiave dell'evento + hash payload su un broker/flusso.
Exactly-once: sing transazionale (+ sinks idompotenti) per flussi critici (pagamenti/round).
Contatori di volume: «atteso» vs «ricevuto» per finestra; La discontinuità è →.

scala val deduped = stream
.keyBy(_.id)
.process(new DeduplicateWithin(Time. minutes(10)))

val validated = deduped
.filter(_.amount >= 0)
.filter(_.currency in Set("EUR","USD","TRY","BRL"))

emitToQuarantineIfLate(validated, allowedLateness = 120. seconds)

7) DWH/SQL - invarianti e compressioni

sql
-- uniqueness
SELECT id, COUNT() c FROM gold. payments GROUP BY 1 HAVING c>1;

-- freshness
SELECT NOW() - MAX(ts) AS lag FROM gold. payments;

-- reconciliation of totals
SELECT
SUM(amount) AS by_rows,
(SELECT total_amount FROM gold. payments_summary WHERE date=CURRENT_DATE) AS by_summary
FROM gold. payments
WHERE date = CURRENT_DATE;

Matching con vetrine: incrociature giornaliere dì detail ", rapporti di discrepanza, ticket automatico.

8) Privacy e sicurezza

La versione PII predefinita è maschere/token all'ingresso; Vietate le e-mail crude/mappe/telefoni.
Criteri di autorizzazione: tabelle PII - Livello/directory separato, accesso ai ruoli (RBAC/ABAC).
K-Anonimato report - Minimo N righe nel taglio.
Rilevatori Leak: controlli regolari per modelli PII, segreti (chiavi/token).
Giurisdizione: isolamento geo/tenant (paese/marchio/licenza), chiavi separate.

9) Metriche di qualità e SLO

• Freshness - Ritardo max (ts).
• Completeness è la percentuale di voci non vuote/attese.
• Uniqueness - Chiavi duplicate.
• Consistency - invarianti e bilanci (interstatali).
• Accuracy - Verifica con l'origine/le regole esterne del dominio.
• Validity - corrispondenza dei tipi/enum/regex.

• `Freshness payments_gold ≤ 5 мин` (p95).
• `Completeness game_rounds ≥ 99. 7 %/giorno '.
• `Duplicate_rate ≤ 0. 1‰`.
• `PII_leak = 0`.

10) Alert, ticchetti e runbook

Routing: proprietario del dominio applichiamo automaticamente sample e diff.
Raggruppamento: un incidente per «labels: dataset = payments, brand = TR».

1. Controlla la lega ingest e la coda del broker.

2. Confronta «atteso vs» con PSP.

3. Attiva retrai/sposta l'itinerario PSP.

4. Annotare la causa restart backt; Fare il post mortem.

11) Versioning, test e waiver

Regole di qualità Semver: 'quality @ MAJOR. MINOR. PATCH`.
Test unit di trasformazione (SQL/DBT/python) e test contratto per le sorgenti.
RETI GOLDEN - valigette conosciute di discrepanze/fuoriuscite - obbligatorie in regressione.
Waiver (eccezione): autorizzazione a breve termine a infrangere la regola (descrizione, proprietario, termine, misure compensative).

12) Cartelle/manufatti (modelli finiti)

12. 1 Passaporto dataset

yaml dataset: gold. game_rounds owner: team-games steward: data-governance contracts: ["games_rounds_v3"]
quality_slo:
freshness_p95: "PT10M"
completeness_min: 0. 997 uniqueness_max_dup: 0. 0005 alerts:
channels: ["#dq-incidents","#games-ops"]
severity_map: {error: "P1", warn: "P2"}

12. 2 Criteri di quarantena

yaml quarantine:
storage: "s3://quarantine/payments/"
retention: "P30D"
access: ["team-payments","data-governance"]
auto_reprocess:
cron: "/15  "
max_attempts: 3

12. 3 Expectation для Feature Store

yaml featureset: fs_payments_online_v1 checks:
- name: feature_freshness check: "now() - max(feature_ts) <= interval '60 seconds'"
severity: "error"
- name: range_amount_avg check: "amount_avg in [0, 2000]"
severity: "warn"
- name: enum_device check: "device in ['ios','android','web']"
severity: "error"

13) Particolare iGaming: valigette pronte

Pagamenti/PSP: accoppiamento dell'importo dei depositi/conclusioni con i rapporti PSP; stati mancanti per la quarantena di batch alert per «decline _ rate».
Provider di gioco: caduta dì rounds _ per _ min'vs baseline + schema drivt dal provider, unità di trasformazione del provider A, striscione di stato.
RG/AML: campi obbligatori (limiti, self-exclusion, stati KYC); La KYC in ritardo ha → la bandiera per il blocco dei pagamenti, il ticket per la compilazione.
Marketing/CRM: validità dei parametri delle campagne, UTM, deducibilità degli eventi; k-anonimato nelle vetrine.

14) Road map di implementazione

0-30 giorni (MVP)

1. Abilita i contratti per i set chiave: payments, game _ rounds, users, feures.
2. Elenco delle aspettative (10-15 base) + quarantena + alert.
3. Dashboard Freshness/Completeness/Uniqueness; Il rapporto degli incidenti.
4. Runbook’и для `Freshness`, `Duplicates`, `Schema drift`.

30-90 giorni

1. Incroci e bilanci interattivi; processo waiver e regole semver.
2. Strim-validation (late data, deadup, watermarks); Rilevatori PII.
3. Integrazione con CI/CD - Test di origine e trasformazione contrattuali.
4. Qualità SLO nei comandi di dominio OKR.

3-6 mesi

1. Suggerimenti delle soglie AOPS localizzazione automatica delle cause.
2. La politica di qualità e i rapporti della compilazione cross-brand/geo.
3. I post-mortem P1 incidenti hanno → i set e le regole.
4. Collegamento con alerting dei flussi e analisi delle anomalie (unico tracciato).

15) RACI

Data Governance (A/R): standard, contratti, controllo delle regole.
Domain Owners (R) - Attesa di dominio e invarianti.
Data Platform (R) - Cornice delle aspettative, quarantena, alert, monitoraggio.
Sicurezza/DPO (A/R): privacy/PII/k-anonimato, geo/tenant-isolamento.
SRE/Osservabilità (C): routing degli incidenti, SLO/SLI.
Product/Finance (C) - Bilanci aziendali, priorità degli incidenti.

16) Anti-pattern

La validazione DWH è tardi, costosa, dolorosa.
Niente quarantena - «sporcizia» va alla Gold/ML e rompe la fiducia.
Soglie rigide senza stagionalità/orologio/mercato, tempesta di alert.
L'assenza del proprietario e delle regole semver è un caos di eccezioni.
Loghi PII e screenshot nel canale comune.
Giorni di assistenza sanitaria al posto di un circuito permanente.

17) Sezioni correlate

Le prassi di controllo, Controllo dei dati e versioni, Origine e percorso dei dati, Alert dai flussi di dati, Analisi delle anomalie e delle correlazioni, Controllo degli accessi, Sicurezza dei dati e crittografia, Criteri di storage, MLops: utilizzo dei modelli.

Totale

La validazione non è un filtro all'estremità, ma un contratto di qualità trasversale, dall'iniezione e lo striam alle vetrine e al fich online. Aspettative chiare, quarantena, alert e SLO trasformano i dati in un bene affidabile: i rapporti sono corretti, i modelli sono sostenibili, i pagamenti sono sicuri, la compilazione è tranquilla.