Maʼlumotlarni validatsiya qilish

1) Nima uchun iGaming platformasiga kerak

Hisobotlar va KPIga ishonch: GGR/NET, konversiyalar, ushlab turish, RG-signallar.
ML/skoring ishonchliligi: antifrod/tavsiyalar/RG uchun to’g "ri chiziqlar.
Real vaqt operatsiyalari: to’lovlar/UX zarar ko’rishidan oldin siljish/hodisalarni yo’qotish alertlari.
Komplayens: PII/sirlar bo’lmasligi kerak bo’lgan joylarda ularning mavjud emasligi; isbotlanishi mumkin bo’lgan izlanuvchanlik.

2) Qayerda validlash kerak: nazorat darajalari

1. Injest (batch/stream): sxema, turlar, majburiy maydonlar, idempotency/dedup.
2. Strim-protsessing: deraza/suv belgilari, tartib, o’tkazib yuborish/kechiktirish, exactly-once.
3. ETL/ELT va transformatsiyalar: havolalar/joylar, agregatlar, biznes-balanslar.
4. DWH/vitrinalar (Gold): jadvallar orasidagi mustahkamlik, yangilik, kalitlarning o’ziga xosligi.
5. Feature Store/onlayn: fich diapazonlari, oflayn onlayn muvofiqlik.
6. BI/API: hisoblash va filtrlar, SLAs latency/freshness, k-anonimlik.

3) Tekshirish turlari (katalog)

Sxemali: tip/nullable/enum/regex/JSON-shape; mos kelmaydigan o’zgarishlar → to’xtash.
Domen: ≥ 0, valyuta ∈ {EUR, USD, TRY, BRL}, ≤ limit stavkasi, litsenziya ∈ mamlakat.
Identifikatsiya/kalitlar: birlamchi kalit noyobdir, foreign key «osilgan» emas.
Maydonlarning sifati: toʻldirilishi, uzunligi, formati (IBAN, BIN, e-mail token).
Statistika/bazaviy chiziqlar: chastotalar, taqsimotlar, kvantil koridorlar.
Anomaliyalar: hajm/ulushlarning keskin sakrashi, nul/dublikatlar, schema drift.
Yangiligi: max (ts) X dan katta emas; lag ingest → gold ≤ T.
Konsistentlik: detallar bo’yicha summa = yig’ma; multi-table reconciliation.
Maxfiylik/xavfsizlik: ruxsat etilgan zonalardan tashqarida Zero-PII; tokenizatsiya/niqob.
Regulyator: RG/AML maydonlari mavjud va ishonchli (sanalar, belgilar).

4) Data Contracts (ma’lumotlar kontraktlari)

Kontrakt manba va iste’molchilar o’rtasida + sifat qoidalari + SLO sxemasini belgilaydi.

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

Kontraktni o’zgartirish semver va migratsiya orqali amalga oshiriladi:’MAJOR’buzadi,’MINOR’qo’shadi,’PATCH’tavsifini tuzatadi.

5) «Kutish» (expectations) va siyosat

Kutish - payplaynlarda (batch/stream) bajariladigan deklarativ tekshirishlar.

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’ → partiya/batcha karantini, xabar berish + chipta; downstream bloki.
• ’warn’ → oʻtadi, lekin tahlil qilish vazifasini yaratadi; sifat belgisi.
• ’info’ → faqat monitoring.

6) Striming: tekshirishlarning o’ziga xos xususiyatlari

Watermarks/late data:’≤ 120s’kechikishiga yo’l qo’yamiz, aks holda - karantin; oxirgi derazalar bilan qoplaymiz.
Idempotency: hodisa kaliti + hash payload → deadup brokerda/oqimda.
Exactly-once: kritik oqimlar (to’lovlar/raundlar) uchun tranzaksion sing (+ idempotent sinks).
Hajm hisoblagichlari: «kutilgan» vs «derazadan olingan»; farqi → 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: invariantlar va solishtirmalar

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;

Vitrinalar bilan o’yin: har kuni taqqoslash’detail → summary’, tafovutlar hisoboti, avtomatik tekshirish.

8) Maxfiylik va xavfsizlik

PII - andoza tahriri: kirish joyidagi niqob/tokenlar; «xom» e-mail/kartalar/telefonlarni loglarda taqiqlaymiz.
Ruxsatnomalar siyosati: PII bo’lgan jadvallar - alohida qatlam/katalog, rollar bo’yicha kirish (RBAC/ABAC).
Hisobotlarning K-anonimligi: kesimdagi minimal N satr.
Leak-detektorlar: PII shablonlarini muntazam tekshirish, «sirlar» (kalitlar/tokenlar).
Yurisdiksiyalar: geo/tenant-izolyatsiya (mamlakat/brend/litsenziya), alohida kalitlar.

9) Sifat metrikasi va SLO

• Freshness - ortda qolish max (ts).
• Completeness - boʻsh boʻlmagan/kutilayotgan yozuvlar ulushi.
• Uniqueness - kalitlarning dublikatlari.
• Consistency - invariantlar va balanslar (jadvallararo).
• Accuracy - tashqi manba/domen qoidalari bilan tekshirish.
• Validity -/enum/regex turlariga muvofiqlik.

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

10) Alertlar, biletlar va runbook

Routing: Slack/PagerDuty → domen egasi; avtomatik ravishda sampllar va diff qo’llaniladi.
Guruhlash: «labels: dataset = payments, brand = TR» toʻplamiga bitta hodisa.

1. ingest lag va brokerning navbatini tekshirish.

2. PSP orqali «kutilgan vs olingan» ni solishtirish.

3. Retrayni yoqish/PSP yoʻnalishini oʻzgartirish.

4. Sababini izohlash; bektlarning restarti; post-mortem o’tkazish.

11) Versionlash, testlar va waiver-jarayon

Sifat qoidalari Semver:’quality @MAJOR. MINOR. PATCH`.
Unit-testlar transformatsiyalar (SQL/DBT/payton) va manbalar uchun kontrakt-testlar.
GOLDEN-setlar: farqlar/sizib chiqishlarning maʼlum holatlari regressiyada majburiy hisoblanadi.
Waiver (istisno): qoidani buzishga qisqa muddatli ruxsatnoma (tavsifi, egasi, muddati, kompensatsiya choralari).

12) Kataloglar/artefaktlar (tayyor shablonlar)

12. 1 Sanaset pasporti

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 Karantin siyosati

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) iGaming xususiyatlari: tayyor keyslar

To’lovlar/PSP: depozitlar/hisobotlar summasini PSP hisobotlari bilan solishtirish; yetishmayotgan maqomlar → karantin batcha; ’decline _ rate’ ga alert.
O’yin provayderlari: yiqilish’rounds _ per _ min’vs baseline + schema drift provayderdan → A provayderining transformatsiya bloki, maqom banneri.
RG/AML: majburiy maydonlar (limitlar, self-exclusion, KYC-maqomlar); to’lov bloki uchun muddati o’tgan KYC → bayroq, komplayens chiptasi.
Marketing/CRM: kampaniya parametrlari, UTM, voqealar dedupi; k-vitrinalarda anonimlik.

14) Joriy etish yo’l xaritasi

0-30 kun (MVP)

1. Asosiy toʻplamlar uchun shartnomalarni kiritish: payments, game_rounds, users, features.
2. Kutish katalogi (10-15 bazaviy) + karantin + alert.
3. Dashbord Freshness/Completeness/Uniqueness; hodisalar hisoboti.
4. Runbook’и для `Freshness`, `Duplicates`, `Schema drift`.

30-90 kun

1. Jadvallararo solishtirishlar va balanslar; waiver-jarayon va semver qoidalari.
2. Strim-validatsiya (late data, dedup, watermarks); PII detektorlar.
3. CI/CD bilan integratsiya: manbalar va transformatsiyalarning kontrakt-testlari.
4. Domen buyruqlari uchun SLO sifati.

3-6 oy

1. AIOps - ostonalar; sabablarni avto-mahalliylashtirish.
2. Kross-brend/geo sifat siyosati va komplayens hisobotlari.
3. P1 hodisalarning post-mortemalari → golden-setlar va qoidalarni to’ldirish.
4. Oqimlar alertingi va anomaliyalar tahlili bilan bog’lanish (yagona kontur).

15) RACI

Data Governance (A/R): standartlar, kontraktlar, qoidalar auditi.
Domain Owners (R): domen kutishlari va invariantlar.
Data Platform (R): kutish, karantin, alertlar, monitoring.
Security/DPO (A/R): maxfiylik/PII/k-anonimlik, geo/tenant-izolyatsiya.
SRE/Observability (C): hodisalarni yoʻnaltirish, SLO/SLI.
Product/Finance (C): biznes balanslari, hodisalarning ustuvorliklari.

16) Anti-patternlar

Validatsiya «faqat DWH» - kech, qimmat, og’riqli.
Karantin yo’q - «axloqsizlik» Gold/MLga kirib, ishonchni buzadi.
Mavsumiy/soat/bozorlarsiz qattiq ostonalar → alertlar bo’roni.
Egasining yo’qligi va qoidalar semveri → istisnolar tartibsizligi.
PII va «umumiy kanalga skrinshotlar».
Doimiy kontur o’rniga bir martalik «sanitariya kunlari».

17) Bog’liq bo’limlar

DataOps-amaliyotlar, Ma’lumotlar auditi va versiya, Ma’lumotlarning kelib chiqishi va yo’li, Ma’lumotlar oqimidagi alertlar, Anomaliyalar va korrelyatsiyalarni tahlil qilish, Kirish nazorati, Ma’lumotlar xavfsizligi va shifrlash, Ma’lumotlarni saqlash siyosati, MLOps: modellardan foydalanish.

Jami

Validatsiya - bu oxiridagi filtr emas, balki injest va oqimdan tortib vitrinalargacha bo’lgan sifat shartnomasi va onlayn fich. Aniq kutish, karantin, alertlar va SLO maʼlumotlarni ishonchli aktivga aylantiradi: hisobotlar toʻgʻri, modellar barqaror, toʻlovlar xavfsiz, komplayens xotirjam.