Kontrola jakości danych

1) Cel i zasady

Dlaczego: wiarygodne raporty (GGR/podatki), modele zwalczania nadużyć finansowych i RG, przesyłki zgodności, produkty i personalizacja.

• Schema-first & Kontrakty: Wszystkie źródła są wymagane do publikowania danych kontraktowych.
• DQ-as-code: zasady w repozytorium, wersje, testy i recenzje.
• Obserwacja domyślnie: metryka/logowanie/rodowód.
• Prywatność według projektu: minimum PII, maskowanie i RLS/CLS.
• Świadomość kosztów: priorytetowe określenie zasad krytycznych, inteligentne próbki.

2) Taksonomia pomiarów jakości

Kompletność - Odsetek wymaganych pól/wierszy.
Typy/zakresy/książki referencyjne ważności-dopasowania.
Unikalność: brak duplikatów klawiszy/zdarzeń.

Spójność: integralność referencyjna, niezmienne przedsiębiorstwa

Dokładność-Podejścia „prawdziwe” źródło (podsumowanie uzgodnień).
Linia czasu/świeżość - opóźnienie materialne.
Integralność Lineage: zachowanie pochodzenia/wersji transformacji.

KPI o wysokiej jakości i krytyczności (krytyczne/główne/niewielkie) są definiowane dla każdej domeny.

3) Umowy i systemy (źródło prawdy)

Umowy o dane: JSON Schema/Avro/OpenAPI/AsyncAPI, obsługiwane przez Registry.
Stabilność: zmiany kompatybilne z wstecznym - dodanie nieważności; breaking - nowa wersja + podwójne wejście.
Identyfikowalność: w zdarzeniach - 'event _ id',' trace _ id', 'schema _ version', 'source'.

4) DQ-as-code: struktura artefaktu

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

Zasady: deklaracyjne YAML/SQL;

Dotkliwość: mapowanie → kanały alarmowe/poziomy eskalacji;

CI: liniowce obwodowe, testy kompatybilności, suchy/symulator.

5) Przykładowe reguły (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) Badania SQL (próbki)

Wyjątkowość kluczy

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

Wymagana kompletność pola

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

Referencje/Spójność

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 (w czasie rzeczywistym)

Walidacja połykania: walidacja schematu, limity wielkości, typy i enum.
Kontrole strumieniowe: dedup '(event_id, źródło)', dopuszczalna opóźnienie, ważność waluty/kwoty.
Granice: błędy krytyczne → DLQ + alert; nie krytyczny → tag, ale skip (z flagą 'dq _ flag').
Wskaźniki: kompletność/lag/dup-rate według stron.

8) Obsługa błędów i wyjątków

DLQ/kwarantanna: Rejestry chorych są przechowywane, dostępne do korekty.
Zapisy wyjątkowe: karta wykluczenia (właściciel, data, powód, obszar).
Auto-fallback: Użyj ostatniego poprawnego migawki w obudowie wyświetlacza.
Zamknięcie SLA: krytyczne - ≤ 24-48 godzin; major - ≤ 5 dni pracowniczych.

9) Koordynacja z prywatnością i przestrzeganiem przepisów

Minimalizacja PII: nie sprawdzać „surowego” PII w warstwach analitycznych; Użyj pseudonimów.
RLS/CLS-Checks są wykonywane w oparciu o maskowanie pola.
Regionalizacja: zasady uwzględniają „jurysdykcję” (EOG/UK/BR).
Legal Hold: Brak przepisywania archiwów w ramach trzymania.

10) Obserwowalność, SLI/SLO i wpisy

• Świeżość p95 (srebro): ≤ 15 min
• Kompletność (typy krytyczne): ≥ 99. 5%.
• Ważność (schemat): ≥ 99. 9%.
• Duplikat szybkości: ≤ 0. 1%.
• Incydent DQ MTTR: ≤ 24-48 °.

Alerty: pager do krytycznych, antyaliasingu, okien konserwacyjnych.

11) Deski rozdzielcze (minimalny zestaw)

Świeżość/Kompletność mapa ciepła według domeny i rynku.
Górne tabele N według wskaźnika incydentów i kosztów korekt.
DQ lejek: połknięcie → srebro → złoto (utrata/korekta).
Mapa linedge dla raportów krytycznych (regulator/GGR/RG/AML).
Mapa „spuścizny” schematów i klientów (wersje SDK/schemat).

12) Procesy i RACI

R (Odpowiedzialny): Inżynieria danych (zasady dotyczące tabel), Właściciele domen (semantyka).
A (Odpowiedzialność): szef danych/CDO.
C (Konsultacja): Zgodność/Prawna/Inspektor Ochrony Danych, Architektura, SRE.
I (Poinformowany): BI/Бровика/Маркетин,/Кинанса/Оверавий.

Cykl życia reguły: oferta → przegląd → „dark run” → włączenie → monitorowanie → retrospektywne.

13) Pojednanie i dokładność

Czeki/transakcje: skarbiec z OLTP/dostawcami (PSP/KYC).
Porównanie dwóch pętli: niezależny rurociąg do walidacji selektywnej.
Tolerancje są progami procentowymi według mierników (np. Wariancja GGR ≤ 0. 2%).
Codzienne czynności: sprawozdania z uzgadniania audytu.

14) Koszty i priorytety

Uruchom reguły krytyczne częściej (strumieniowe/godzinowe), drobne - codziennie.
Użyj pobrań i zmaterializowanych kontroli ciężkich stołów.
Śledź koszt/zapytanie i koszt/GB, zastosuj klastrowanie/indeksowanie.
Przeznaczenie budżetu na DQ w kontekście zespołów (obciążenie zwrotne).

15) Szablony sklepów złota (przykład 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) Incydenty dotyczące jakości: Zarządzanie i komunikacja

Bilety: automatyczne tworzenie zadań z dołączonymi selekcjami i metrykami.
Szablony Comm: powiadamianie właścicieli/regulatorów produktów w przypadku ich wystąpienia.
Pośmiertnie: przyczyna korzenia (dryf schematu, błąd górnego strumienia, obciążenie), działania CAPA, kontrola „zwrotu regresji”.

17) Plan działania w zakresie wdrażania

1. Katalog tabel krytycznych (Płatności, Rozgrywka, GGR, Zgodność).

2. Zasady YAML dla 10-15 kontroli kluczowych + walidacja CI.

3. Świeżość/Kompletność deski rozdzielczej i wpisy dla krytycznych.

4. Poprawki DLQ/Quarantine + runbook.

• Rozszerzenie reguły (FK/dokładność), symulator suchego biegu, inkluzje A/B.
• Integracja linii, ustalenia dotyczące wyjątków i SLA.
• Streaming DQ na połknięcie dla „hałaśliwych” źródeł.

• Autogeneracja dokumentacji według zasad, mierniki kosztów.
• „Kontury kontroli” (niezależne pojednanie), co tydzień retrospektywne.
• SDK platformy Rule-as-Code, rejestru standardowych kontroli domeny.

18) Lista kontrolna przedsprzedaży

• Umowy i schematy w rejestrze, testy zgodności przejść.
• Zasady YAML zamrożone, ciężkość/eskalacja przypisane.
• Uruchamiane są deski rozdzielcze i wpisy; SLO są zdefiniowane i uzgodnione.
• DLQ/Quarantine jest dostępny, książki startowe są udokumentowane.
• Procedury wyjątkowe/procedury pojednawcze uzgodnione z przepisami prawa/zgodności.
• Pomiar kosztów inspekcji i limitów ciężkich wniosków.

19) Częste błędy i sposób ich unikania

Dane surowe bez umów: wprowadź schemat pierwszy i testy konsumenckie.
„Ręczne” kontrole: przełożyć na DQ-as-code i CI.
Brak priorytetów: oddzielne kanały krytyczne/główne/niewielkie i alarmowe.
Nie ma DLQ: nie ma nic do pracy z błędami - dodaj kwarantannę.
Ignoruj koszt: Zapytania profilowe, wykorzystaj materializację.
Brak pośmiertnych: powtarzają się błędy - wprowadź CAPA i kontrolę regresji.

20) Sedno sprawy

System kontroli jakości danych nie jest zbiorem rozproszonych kontroli, ale zarządzanym programem: kontrakty i programy, kod DQ, obserwowalność i SLO, dyscyplina incydentów i pojednania. Wykonując ten artykuł, otrzymasz powtarzalne, weryfikowalne i opłacalne dane wystarczające do sprawozdawczości regulacyjnej, rozwiązań produktowych i detektorów ryzyka w czasie rzeczywistym.