Controlul calității datelor

1) Scop și principii

De ce: rapoarte fiabile (GGR/taxe), modele antifraudă și RG, încărcări de conformitate, produse și personalizare.

• Schema-first & Contracts: Toate sursele sunt necesare pentru a publica datele contractuale.
• DQ-as-code: reguli în depozit, versiuni, teste și recenzii.
• Observație în mod implicit: metrici/logare/descendență.
• Privacy-by-design: PII minim, mascare și RLS/CLS.
• Cost-conștient: prioritizarea regulilor critice, eșantioane inteligente.

2) Taxonomia măsurătorilor calității

Completitudine - Procentul câmpurilor/rândurilor necesare.
Valabilitate-Meciuri tipuri/intervale/cărți de referință.
Unicitate: fără chei/evenimente duplicate.

Coerență: integritate referențială, invarianți de afaceri

Precizie-abordează sursa „adevărat” (reconcilieri sumare).
Cronologie/prospețime - Întârzierea materialului.
Integritatea liniei: păstrarea originii/versiunilor transformărilor.

KPI-urile de calitate și criticitate (critice/majore/minore) sunt definite pentru fiecare domeniu.

3) Contracte și scheme (sursa adevărului)

Contracte de date: JSON Schema/Avro/OpenAPI/AsyncAPI, găzduit de Registry.
Stabilitate: modificări compatibile înapoi - adăugare nullable; breaking - versiune nouă + intrare dublă.
Trasabilitate: în evenimente - 'event _ id',' trace _ id', 'schema _ version', 'source'.

4) DQ-as-code: structura artefactului

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

Reguli: declarativ YAML/SQL;

Severitate: cartografiere → canale de alertă/niveluri de escaladare;

CI: lintere de circuit, teste de compatibilitate, uscat-run/simulator.

5) Reguli de exemplu (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) Teste SQL (probe)

Unicitatea cheilor

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

Câmpul necesar Completitudine

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

Referințe/Consistență

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

7) Streaming DQ (în timp real)

Validarea ingerării: validarea schemei, limitele de dimensiuni, tipurile și enum-urile.
Verificări on-stream: dedup „(event_id, sursă)”, întârziere permisă, valabilitate valută/sumă.
Limite: erori critice → alertă DLQ +; nu critic → tag, dar sari peste (cu „dq _ flag” pavilion).
Valori: integralitate/lag/dup- rata de către parte.

8) Erori de manipulare și excepții

DLQ/Carantină: Înregistrările bolnavilor sunt deținute, disponibile pentru corectare.
Înregistrări de excepție: card de excludere (proprietar, dată, motiv, suprafață).
Rezervă automată: Utilizați ultimul instantaneu corect al carcasei de afișare.
SLA de închidere: critică - ≤ 24-48 de ore; major - ≤ 5 zile de angajare.

9) Coordonarea cu confidențialitatea și conformitatea

Minimizare PII: nu verificați PII „brut” în straturi analitice; Foloseşte pseudonime.
Verificările RLS/CLS se efectuează pe baza mascării câmpului.
Regionalizare: Normele iau în considerare „competența” (SEE/UK/BR).
Legal Hold: Nici o rescriere a arhivelor ca parte a hold.

10) Observabilitate, SLI/SLO și alerte

• Prospețime p95 (argint): ≤ 15 min
• Completitudine (tipuri critice): ≥ 99. 5%.
• Valabilitate (schemă): ≥ 99. 9%.
• Rata duplicatului: ≤ 0. 1%.
• Incident DQ MTTR: ≤ 24-48 ч.

Alerte: pager pentru ferestre critice, anti-aliasing, de întreținere.

11) Tablouri de bord (set minim)

Prospețime/Harta de căldură completă după domeniu și piață.
Top N tabele după rata incidentelor și costul corecțiilor.
DQ pâlnie: ingera → argint → aur (pierdere/corecție).
Harta Linedge pentru rapoarte critice (regulator/GGR/RG/AML).
Harta schemelor și clienților „moșteniți” (versiuni SDK/schemă).

12) Procese și RACI

R (Responsabil): Ingineria datelor (reguli privind tabelele), Proprietarii de domenii (semantică).
A (Responsabil): șef de date/CDO.
C (Consultat): Conformitate/Legal/DPO, Arhitectură, SRE.
I (Informat): BI/Продукт/Маркетинг/Финансы/Операции.

Rule lifecycle: oferă revizuire „dark run” includerea monitorizarea retrospectivă.

13) Reconciliere și precizie

Sume de control/tranzacții: seif cu OLTP/furnizori (PSP/KYC).
Comparații în două bucle: conductă independentă pentru validare selectivă.
Toleranțele sunt praguri procentuale pe metrici (de ex. Varianța GGR ≤ 0. 2%).
Acte zilnice: rapoarte de reconciliere a auditului.

14) Costul și prioritizarea

Rulați reguli critice mai des (streaming/oră), minore - zilnic.
Utilizați fetches și cecuri materializate pentru mese grele.
Urmăriți costul/interogarea și costul/GB, aplicați clustering/indexare.
Alocați un buget pentru DQ în contextul echipelor (chargeback).

15) Șabloane pentru storefronturi de aur (exemplu 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) Incidente de calitate: management și comunicare

Ticketing: crearea automată a sarcinilor cu selecții și valori atașate.
Șabloane de comunicații: notificarea proprietarilor de produse/autorităților de reglementare atunci când sunt afectate.
Post-mortem: cauză principală (derivă schemă, bug în amonte, sarcină), acțiuni CAPA, controlul „returnării regresiei”.

17) Foaia de parcurs privind implementarea

1. Catalog de tabele critice (Plăți, Gameplay, GGR, Conformitate).

2. Reguli YAML pentru 10-15 controale cheie + validare CI.

3. Tabloul de bord Prospețime/Completitudine și alerte pentru critice.

4. DLQ/Carantină + runbook fixat.

• Extensia regulii (FK/precizie), simulator uscat, incluziuni A/B.
• Integrarea liniilor, acorduri de excepție și SLA-uri.
• Streaming DQ pe ingera pentru surse „zgomotoase”.

• Autogenerarea documentației după reguli, valori ale costurilor.
• „Contururi de control” (reconciliere independentă), retrospectivă săptămânală.
• Regula-as-Code platforma SDKs, un registru de verificări standard de domeniu.

18) Lista de verificare pre-vânzare

• Contracte și scheme în Registru, testele de compatibilitate trec.
• Regulile YAML înghețate, severitate/escaladare atribuite.
• Tablourile de bord și alertele sunt active; SLO-urile sunt definite și convenite.
• DLQ/Carantină este disponibil, runbooks sunt documentate.
• Proceduri de excepție/reconciliere convenite cu Legalitate/Conformitate.
• Măsurarea costului inspecțiilor și a limitelor la solicitările grele.

19) Greșeli frecvente și cum să le evitați

Date brute fără contracte: introduceți prima schemă și testele consumatorilor.
„Manual” verifică: traduce în DQ-as-code și CI.
Fără prioritizare: canale critice/majore/minore și de alertă separate.
Nu există DLQ: nu există nimic de a lucra cu erori - adăugați carantină.
Ignorați costul: interogări de profil, utilizați materializarea.
Nu există post-mortem: erorile sunt repetate - introduceți CAPA și controlul regresiei.

20) Linia de jos

Sistemul de control al calității datelor nu este un set de controale împrăștiate, ci un program gestionat: contracte și scheme, DQ-as-code, observabilitate și SLO, disciplină incidentă și reconciliere. Urmând acest articol, veți primi date reproductibile, verificabile și rentabile suficiente pentru raportarea de reglementare, soluții de produse și detectoare de risc în timp real.