Walidacja danych

1) Dlaczego platforma iGaming jej potrzebuje?

Zaufanie do raportów i KPI: GGR/NET, konwersje, zatrzymanie, sygnały RG.
Niezawodność ML/punktacji: prawidłowe funkcje dla zwalczania oszustw/zaleceń/RG.
Operacje w czasie rzeczywistym: Alerty przy dryfowaniu/utracie zdarzeń przed wpłynięciem wypłat/UX.
Zgodność: brak PII/tajemnic, gdzie nie powinny być; możliwa do udowodnienia identyfikowalność.

2) Gdzie walidować: poziomy kontroli

1. Wtrysk (partia/strumień): schemat, typy, wymagane pola, idempotencja/dedup.
2. Przetwarzanie strumienia: okna/znaki wodne, zamówienie, pominięcia/opóźnienia, dokładnie raz.
3. ETL/ELT i transformacje: linki/radości, agregaty, salda biznesowe.
4. DWH/sklepy (Złoto): spójność między tabelami, świeżość, wyjątkowość kluczy.
5. Funkcja Sklep/online: zakresy funkcji, konsystencja offlayn i onlayn.
6. BI/API: liczniki i filtry, SLA dotyczące opóźnień/świeżości, k-anonimowości.

3) Rodzaje kontroli (katalog)

Schemat: typ/nieaktywny/enum/regex/kształt JSON; niekompatybilne zmiany zatrzymać →.
Domena: ≥ 0 kwot, α waluta {EUR, USD, TRY, BRL}, ≤ kurs graniczny, strana, litsenzii.
Tożsamość/klucze: klucz podstawowy jest unikalny, klucz obcy nie jest „wiszący”.
Jakość pola: pełność, długość, format (IBAN, BIN, token e-mail).
Statystyki/linie podstawowe: częstotliwości, dystrybucje, korytarze kwantowe.
Anomalie: kolce objętości/frakcji, zera/duplikaty, dryf schematu.
Świeżość: max (ts) nie starsza niż X; lag ingest → złoto ≤ T.
Spójność: suma części = podsumowanie; pojednanie wielostanowiskowe.
Prywatność/bezpieczeństwo: Zero-PII poza dozwolonymi strefami; tokenizacja/maski.
Regulacja: pola RG/AML są obecne i wiarygodne.

4) Umowy o dane

Umowa ustala system + zasady jakości + SLO między źródłem a konsumentami.

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

Zmiany w umowie - poprzez semver i migracje: „MAJOR” przerwy, „MINOR” dodaje pole, „PATCH” poprawia opis.

5) Oczekiwania i polityka

Oczekiwania - deklaracyjne kontrole wykonywane w rurociągach (partia/strumień).

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"

• „błąd” → kwarantanna stron/partii, alert + bilet; blok niższego szczebla.
• "varn' → przechodzi, ale tworzy zadanie parsing; znakowanie jakości.
• „info” → tylko monitorowanie.

6) Streaming: Szczegóły kontroli

Znaki wodne/późne dane: spóźnimy się '≤ 120', inaczej - kwarantanna; kompensować skończonymi oknami.
Idempotencja: klucz wydarzeniowy + ładunek hash → impas na brokerze/wątku.
Dokładnie raz: śpiew transakcyjny (+ zlewozmywaki) dla przepływów krytycznych (płatności/rundy).
Liczniki głośności: „oczekiwane” vs „otrzymane” na okno; rozbieżność → 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: niezmienne i pojednania

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;

Dopasowanie okien: codzienne 'szczegóły → podsumowanie' uzgodnienia, raporty rozbieżności, automatyczny bilet.

8) Prywatność i bezpieczeństwo

Domyślne wydanie PII: maski wejściowe/żetony; zabraniamy „surowego” e-maila/kart/telefonów w dziennikach.
Polityka uprawnień: tabele z PII - oddzielna warstwa/katalog, dostęp według ról (RBAC/ABAC).
K-anonimowość raportów: minimalne wiersze N w plasterkach.
Wykrywacze przecieków: regularne sprawdzanie wzorców PII, „sekrety” (klucze/żetony).
Jurysdykcja: geo/najemca-izolacja (kraj/marka/licencja), oddzielne klucze.

9) Wskaźniki jakości i SLO

• Świeżość - lag max (ts).
• Kompletność - odsetek niepustych/oczekiwanych zapisów.
• Wyjątkowość - duplikaty kluczy.
• Spójność - niezmienne i salda (międzystołowe).
• Dokładność - walidacja z zewnętrznym źródłem/regułami domeny.
• Ważność - dopasowanie/enum/regex.

• „payments_gold świeżości ≤ 5 мий” (p95).
• "Kompletność game_rounds ≥ 99. 7 %/dzień ".
• "Duplikat _ rate ≤ 0. 1‰`.
• „PII _ wyciek = 0”.

10) Wpisy, bilety i książeczka startowa

Routing: Slack/PagerDuty → właściciel domeny; automatycznie nakładać próbki i różnić.
Grupowanie: jeden incydent na zestaw „etykiety: zestaw danych = płatności, marka = TR”.

1. Sprawdź kolejkę ingest log i broker.

2. Porównaj "oczekiwane vs' otrzymane przez PSP.

3. Włącz trasę Retrai/Switch PSP.

4. Przyczyna adnotacji; ponowne uruchomienie pleców; pośmiertnie.

11) Weryfikacja, testy i proces zwolnienia

Semver zasad jakości: 'quality @ MAJOR. DROBNE. PATCH '.
Testy jednostkowe transformacji (SQL/DBT/python) i testy kontraktowe dla źródeł.
Zestawy GOLDEN: znane przypadki rozbieżności/przecieków są obowiązkowe w regresji.
Zwolnienie: krótkoterminowe zezwolenie na naruszenie zasady (opis, właściciel, termin, środki wyrównawcze).

12) Katalogi/artefakty (gotowe szablony)

12. 1 Paszport 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 Polityka kwarantanny

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

12. 3 Oczekiwanie дла Sklep funkcyjny

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) Specyfika iGaming: gotowe przypadki

Płatności/PSP: uzgodnienie depozytów/wypłat do raportów PSP; brakujące statusy → kwarantanna masła; alert dla wzrostu „decline _ rate”.
Dostawcy gier: drop 'rounds _ per _ min' vs baseline + schemat drift from the provider → transformation block of provider A, status banner.
RG/AML: pola obowiązkowe (granice, samodzielne wykluczenie, statusy KYC); zaległy KYC → flaga na bloku płatności, bilet zgodnie.
Marketing/CRM: ważność parametrów kampanii, UTM, event dedup; k-anonimowość w sklepach.

14) Plan działania w zakresie wdrażania

0-30 dni (MVP)

1. Zawiera umowy na kluczowe zestawy: płatności, game_rounds, użytkownicy, funkcje.
2. Katalog oczekiwań (10-15 podstawowych) + kwarantanna + wpisy.
3. Świeżość deski rozdzielczej/kompletność/wyjątkowość; raport o incydencie.
4. Runbook 'дла' Świeżość ',' Duplicates ',' Schema drift '.

30-90 dni

1. Wzajemne uzgodnienia i salda; procedury rezygnacji i zasady semver.
2. Walidacja strumienia (późne dane, impas, znaki wodne); Detektory PII.
3. Integracja z CI/CD: testy kontraktowe źródeł i transformacji.
4. SLO jakości w OKR polecenia domeny.

3-6 miesięcy

1. Wskazówki progowe AIOP; automatyczna lokalizacja przyczyn.
2. Cross-marki/geo polityki jakości i raporty zgodności.
3. Wypadki poubojowe P1 → uzupełnienie złotych zestawów i zasad.
4. Powiązanie z alarmowaniem przepływu i analizą anomalii (pojedyncza pętla).

15) RACI

Zarządzanie danymi (A/R): normy, umowy, audyt zasad.
Właściciele domeny (R): oczekiwania domeny i niezmienne.
Platforma danych (R): ramy oczekiwań, kwarantanna, wpisy, monitorowanie.
Bezpieczeństwo/DPO (A/R): prywatność/PII/k-anonimowość, geo/lokator-izolacja.
SRE/Obserwability (C): routing incydentów, SLO/SLI.
Produkt/finanse (C): saldo przedsiębiorstw, priorytety incydentów.

16) Anty-wzory

Walidacja „tylko w DWH” - późno, drogie, bolesne.
Brak kwarantanny - „brud” idzie do złota/ML i łamie zaufanie.
Ciężkie progi bez sezonowości/godziny/rynki → burza alarmowa.
Brak zasad właściciela i semver → chaos wyjątków.
Dzienniki z PII i „zrzuty ekranu do wspólnego kanału”.
Jednorazowe „dni sanitarne” zamiast stałego obwodu.

17) Sekcje powiązane

Praktyki w zakresie usług operacyjnych, audyt i weryfikacja danych, pochodzenie i ścieżka danych, alerty strumieniowe danych, analiza anomalii i korelacji, kontrola dostępu, bezpieczeństwo i szyfrowanie danych, polityka zatrzymywania danych, MLOp: wykorzystanie modelu.

Razem

Walidacja nie jest filtrem na końcu, ale końcowym kontraktem jakości: od wtrysku i strumienia po sklepy i funkcję online. Wyraźne oczekiwania, kwarantanny, wpisy i SLO przekształcają dane w wiarygodny składnik aktywów: raporty są poprawne, modele są stabilne, płatności są bezpieczne, zgodność jest spokojna.