Validarea datelor

1) De ce platforma iGaming are nevoie de ea?

Încredere în rapoarte și KPI-uri: GGR/NET, conversii, retenție, semnale RG.
ML/scoring fiabilitate: caracteristici corecte pentru anti-fraudă/recomandări/RG.
Operațiuni în timp real: Alerte la derivă/pierderea evenimentelor înainte de plăți/UX sunt afectate.
Conformitate: nu PII/secrete în cazul în care acestea nu ar trebui să fie; trasabilitate dovedibilă.

2) În cazul în care pentru a valida: niveluri de control

1. Injecție (lot/flux): schemă, tipuri, câmpuri obligatorii, idempotență/dedup.
2. Procesare flux: ferestre/filigrane, ordine, omisiuni/întârzieri, exact o dată.
3. ETL/ELT și transformări: legături/bucurii, agregate, solduri de afaceri.
4. DWH/storefronts (Aur): coerența între mese, prospețimea, unicitatea cheilor.
5. Feature Store/online: game de caracteristici, consistență offlayn↔onlayn.
6. BI/API: numărători și filtre, SLA-uri pe latență/prospețime, k-anonimat.

3) Tipuri de verificări (catalog)

Schematică: tip/nullable/enum/regex/JSON-formă; modificări incompatibile pentru a opri →.
Domeniu: sume ≥0, valută ∈ {EUR, USD, TRY, BRL}, rată limită de ≤, strana∈litsenzii.
Identitate/chei: cheia principală este unică, cheia străină nu este „agățat”.
Calitatea câmpului: plenitudine, lungime, format (IBAN, BIN, e-mail token).
Statistici/linii de bază: frecvențe, distribuții, coridoare cantitative.
Anomalii: vârfuri de volum/fracție, zerouri/duplicate, derivă schemă.
Prospețime: max (ts) nu mai vechi de X; lag ingest→gold ≤ T.
Coerența: suma părților = rezumat; reconciliere multi-table.
Confidențialitate/securitate: Zero-PII în afara zonelor permise; tokenization/masti.
Reglementare: câmpurile RG/AML sunt prezente și plauzibile.

4) Contracte de date

Contractul stabilește schema + reguli de calitate + SLO între sursă ș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

Modificările contractului - prin semver și migrații: pauzele „MAJOR”, „MINOR” adaugă un câmp, „PATCH” corectează descrierea.

5) Așteptări și politici

Așteptări - controale declarative executate în conducte (lot/flux).

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"

• „eroare” → parte/lot carantină, alertă + bilet; blocul din aval.
• "varn' → trece, dar creează o sarcină de parsare; marcaj de calitate.
• numai „info” → monitorizare.

6) Streaming: Specificul verificărilor

Filigrane/date târzii: să întârziem „≤ 120”, altfel - carantină; compensa cu ferestre finite.
Idempotență: cheie eveniment + sarcină utilă hash → blocaj pe broker/fir.
Exact o dată: cântă tranzacțional (+ chiuvete idempotente) pentru fluxuri critice (plăți/runde).
Contoare de volum: „așteptat” vs „primit” pe fereastră; discrepanţă → alertă.

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: invarianți și reconcilieri

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;

Potrivirea ferestrelor: reconcilieri zilnice „detaliu → rezumat”, rapoarte de discrepanță, bilet automat.

8) Confidențialitate și securitate

Ediție PII implicită: măști/jetoane de intrare; interzicem „raw” e-mail/carduri/telefoane în jurnalele.
Politica de permisiune: tabele cu PII - strat separat/director, acces pe roluri (RBAC/ABAC).
K-anonimatul rapoartelor: minim N rânduri în felie.
Detectoare de scurgeri: verificări regulate pentru modele PII, „secrete” (chei/jetoane).
Jurisdicții: geo/chiriaș-izolare (țară/marcă/licență), chei separate.

9) Măsurători de calitate și SLO

• Prospețime - lag max (ts).
• Exhaustivitate - proporția înregistrărilor care nu sunt goale/așteptate.
• Unicitatea - chei duplicat.
• Coerență - invarianți și solduri (inter-table).
• Precizie - validare cu sursă/reguli externe de domeniu.
• Valabilitate - potrivire/enum/regex.

• „Prospeţime payments_gold ≤ 5 мин” (p95).
• "Integralitatea game_rounds ≥ 99. 7 %/zi ".
• 'Duplicate _ rate ≤ 0. 1‰`.
• 'PII _ leak = 0'.

10) Alerte, bilete și runbook

Rutare: Slack/PagerDuty → proprietarul domeniului; se aplică automat probe și diff.
Grupare: un incident pe set „etichete: set de date = plăți, brand = TR”.

1. Verificați jurnalul de ingerare și coada de broker.

2. Comparați „așteptat vs primit” de PSP.

3. Activați traseul Retrai/Switch PSP.

4. Cauza adnotării; repornirea spatelui; post-mortem.

11) Procesul de versionare, teste și renunțare

Semver de reguli de calitate: 'quality @ MAJOR. MINOR. PATCH ".
Testele unitare ale transformărilor (SQL/DBT/python) și testele contractuale pentru surse.
Seturi de AUR: cazurile cunoscute de discrepanțe/scurgeri sunt obligatorii în regresie.
Renunțare: permisiunea pe termen scurt de a încălca regula (descriere, proprietar, termen, măsuri compensatorii).

12) Cataloage/artefacte (șabloane gata făcute)

12. 1 Pașaport Datacet

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 Politica de carantină

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

12. 3 Așteptări для 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) Specificul iGaming: cazuri gata făcute

Plăți/PSP: reconcilierea depozitelor/retragerilor în rapoartele PSP; statut lipsă → carantină butch; alertă pentru creștere 'declin _ rate'.
Furnizori de jocuri: drop 'rounds _ per _ min' s baseline + schema de derivă de la furnizor → bloc de transformare a furnizorului A, banner de stare.
RG/AML: câmpuri obligatorii (limite, autoexcludere, stări KYC); steagul → KYC restante pe blocul de plată, bilet în conformitate.
Marketing/CRM: valabilitatea parametrilor campaniei, UTM, dedup de evenimente; k-anonimatul în storefronturi.

14) Foaia de parcurs privind implementarea

0-30 zile (MVP)

1. Includeți contracte pentru seturi cheie: plăți, game_rounds, utilizatori, caracteristici.
2. Catalog de așteptări (10-15 de bază) + carantină + alerte.
3. Tablou de bord Prospețime/Completitudine/Unicitate; raportul incidentului.
4. Runbook'и для "Prospeţime", "Duplicate", "Schema drift'.

30-90 zile

1. Reconcilieri și echilibre intertabile; procesul de renunțare și regulile semver.
2. validare flux (date tardive, blocaj, filigrane); Detectoare PII.
3. Integrarea cu CI/CD: contracte-teste de surse și transformări.
4. SLO-uri de calitate în domeniul de comandă OKRs.

3-6 luni

1. Indicații privind pragul AIOps; auto-localizarea cauzelor.
2. Politica de calitate cross-brand/geo și rapoarte de conformitate.
3. Incidentele post-morteme P1 → reaprovizionarea seturilor și regulilor de aur.
4. Legătura cu alertarea fluxului și analiza anomaliei (o singură buclă).

15) RACI

Guvernanța datelor (A/R): standarde, contracte, auditul regulilor.
Proprietarii de domenii (R): așteptări de domenii și invarianți.
Platforma de date (R): cadru de așteptări, carantină, alerte, monitorizare.
Securitate/DPO (A/R): confidențialitate/PII/k-anonimat, geo/chiriaș-izolare.
SRE/Observabilitate (C): rutarea incidentelor, SLO/SLI.
Produs/Finanțe (C): solduri de afaceri, priorități incidente.

16) Anti-modele

Validarea „numai în DWH” - târziu, scump, dureros.
Nici o carantină - „murdărie” merge la aur/ML și rupe încrederea.
Praguri grele fără sezonalitate/ore/piețe → furtună de alertă.
Lipsa regulilor proprietarului și semver → haosul excepțiilor.
Jurnalele cu PII și „capturi de ecran la canalul comun”.
O singură dată „zile sanitare” în loc de un circuit permanent.

17) Secțiuni conexe

Practici DataOps, Audit de date și versioning, Originea și calea datelor, Alerte de flux de date, Anomalie și analiză de corelație, Controlul accesului, Securitatea și criptarea datelor, Politici de păstrare a datelor, MLOps: Model de exploatare.

Total

Validarea nu este un filtru la final, ci un contract de calitate end-to-end: de la injecție și flux la storefronts și caracteristică online. Așteptările clare, carantinele, alertele și SLO-urile transformă datele într-un activ fiabil: rapoartele sunt corecte, modelele sunt stabile, plățile sunt sigure, conformitatea este calmă.