მონაცემთა შესაბამისობა

1) რატომ სჭირდება iGaming პლატფორმა

ცნობების ნდობა და KPI: GGR/NET, კონვერტაცია, გამართვა, RG სიგნალები.
ML/Scoring- ის საიმედოობა: სწორი ხრიკები ანტიფროდისთვის/რეკომენდაციებისთვის/RG.
ოპერაციები რეალურ დროში: ალერტები დრიფტის დროს/მოვლენების დაკარგვამდე/UX.
შესაბამისობა: PII/საიდუმლოებების არარსებობა, სადაც ისინი არ უნდა იყვნენ; დადასტურებული ტრეკირება.

2) სად უნდა აკონტროლოთ

1. ინჟესტი (batch/stream): სქემა, ტიპები, სავალდებულო ველები, idempotency/ბაბუა.
2. Strim დამუშავება: ფანჯრები/წყლის ნიშნები, ბრძანება, გადასასვლელი/დაგვიანება, exactly-once.
3. ETL/ELT და ტრანსფორმაციები: ბმულები/ჯოინები, აგრეგატები, ბიზნეს ბალანსები.
4. DWH/witrins (Gold): თანმიმდევრულობა ცხრილებს შორის, სიახლე, გასაღებების უნიკალურობა.
5. Feature Store/ონლაინ: fich დიაპაზონი, offline კოორდინაცია ონლაინ რეჟიმში.
6. BI/API: გამოთვლები და ფილტრები, SLAs latency/freshness, k ანონიმურობა.

3) შემოწმების ტიპები (კატალოგი)

სქემები: ტიპი/nullable/enum/regex/JSON-shape; შეუთავსებელი ცვლილებები - გაჩერებები.
დომენი: თანხები - 0, ვალუტა - {EUR, აშშ დოლარი, TRY, BRL}, განაკვეთი - ლიმიტი, ქვეყანა - ლიცენზია.
იდენტურობა/გასაღებები: პირველადი გასაღები უნიკალურია, საგარეო გასაღები არ არის „ჩამოკიდებული“.
ველების ხარისხი: შევსება, სიგრძე, ფორმატი (IBAN, BIN, ელექტრონული ფოსტის ნიშანი).
სტატისტიკა/ძირითადი ხაზები: სიხშირეები, განაწილება, კვანტილის დერეფნები.
ანომალიები: მოცულობის/წილის მკვეთრი გადახტომა, ნული/დუბლიკატები, სქემა დრიფტი.
სიახლე: მაქსი (ts) არა უმეტეს X; Lag ingest gold T.
თანმიმდევრულობა: დეტალების თანხა = კონსოლიდირებული; multi-table reconciliation.
კონფიდენციალურობა/უსაფრთხოება: Zero-PII ნებადართული ზონების გარეთ; ტოქსიკაცია/ნიღბები.
მარეგულირებელი: RG/AML ველები არსებობს და სავარაუდოა (თარიღები, ნიშნები).

4) მონაცემთა კონტრაქტები (მონაცემთა კონტრაქტები)

კონტრაქტი აფიქსირებს + ხარისხის წესებს + SLO წყაროსა და მომხმარებლებს შორის.

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

ხელშეკრულების ცვლილებები - სემვერისა და მიგრაციის გზით: 'MAJOR' არღვევს, 'MINOR' ამატებს ველს, 'PATCH' ასწორებს აღწერილობას.

5) „მოლოდინი“ და პოლიტიკა

მოლოდინები - დეკლარაციული შემოწმებები, რომლებიც შესრულებულია რულონში (batch/stream).

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' - წვეულების/ბატჩის საკარანტინო, შეტყობინება + ტიკეტი; downstream ბლოკი.
• 'warn' გადის, მაგრამ ქმნის ანალიზის ამოცანას; ხარისხის აღნიშვნა.
• 'info' მხოლოდ მონიტორინგია.

6) ნაკადი: შემოწმების სპეციფიკა

Watermarks/late მონაცემები: ჩვენ ვუშვებთ დაგვიანებას '120s', წინააღმდეგ შემთხვევაში - კარანტინი; საბოლოო ფანჯრების ანაზღაურება.
Idempotence: ღონისძიების გასაღები + hash payload - ბაბუა ბროკერზე/ნაკადში.
Exactly-once: გარიგების სინგლი (+ idempotent sinks) კრიტიკული ნაკადებისთვის (გადახდები/რაუნდი).
მოცულობის მრიცხველები: „მოსალოდნელი“ vs „მიიღეს“ ფანჯარისთვის; შეუსაბამობა - ალერტი.

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: ინვარიანტები და კრიპტები

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;

მატჩის ფანჯრებთან თამაში: ყოველდღიური cryption 'detail - summary', განსხვავებების ანგარიშები, ავტომატური ტიკეტი.

8) კონფიდენციალურობა და უსაფრთხოება

ნაგულისხმევი PII გამოცემა: შესასვლელი ნიღბები/ნიშნები; ჩვენ კრძალავს „ნედლეულ“ ელ.ფოსტას/ბარათებს/ტელეფონებს ლოგებში.
ნებართვის პოლიტიკა: ცხრილი PII - ცალკეული ფენა/კატალოგი, როლების დაშვება (RBAC/ABAC).
K- ანონიმურობა: მინიმუმ N სტრიქონები ჭრილში.
Leak დეტექტორები: რეგულარული შემოწმება PII შაბლონებზე, „საიდუმლოებები“ (გასაღებები/ნიშნები).
იურისდიქცია: geo/tenant იზოლაცია (ქვეყანა/ბრენდი/ლიცენზია), ცალკეული გასაღებები.

9) ხარისხის მეტრიკა და SLO

• Freshness - max (ts) ჩამორჩენა.
• Completeness არის ცუდი/მოსალოდნელი ჩანაწერების წილი.
• Uniqueness - კლავიშების დუბლიკატები.
• Consistence - ინვარიანტები და ბალანსები (ინტერაქტიული).
• Accuracy - გარე დომენის წყაროს/წესების შემოწმება.
• Validity - შესაბამისობა ტიპების/enum/regex.

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

10) ალერტა, თიკეტები და runbook

Routing: Slack/PagerDuty - დომენის მფლობელი; ავტომატურად ვცდილობთ semples და diff.
ჯგუფი: ერთი ინციდენტი „labels: dataset = payments, brand = TR“.

1. შეამოწმეთ ingest lag და ბროკერის ხაზი.

2. შედარება „მოსალოდნელი იყო PSP- ზე“.

3. ჩართეთ retrai/გადართვა PSP მარშრუტი.

4. მიზეზის ანონსი; აღდგენის ბექტები; გამართეთ პოსტ-mortem.

11) ვერსიები, ტესტები და მიმდინარე პროცესი

Semver ხარისხის წესები: 'quality @ MAJOR. MINOR. PATCH`.
ტრანსფორმაციის ერთეულის ტესტები (SQL/DBT/Payton) და ხელშეკრულების ტესტები წყაროებისთვის.
GOLDEN ნაკრები: შეუსაბამობის/გაჟონვის ცნობილი შემთხვევები სავალდებულოა რეგრესში.
Waiver (გამონაკლისი): მოკლევადიანი ნებართვა წესის დარღვევისთვის (აღწერა, მფლობელი, ვადა, რომელიც ანაზღაურებს ზომებს).

12) კატალოგები/არტეფაქტები (მზა შაბლონები)

12. 1 Dataset პასპორტი

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 საკარანტინო პოლიტიკა

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 სპეციფიკა: მზა შემთხვევები

გადახდა/PSP: ანაბრების/დასკვნების ოდენობის შერჩევა PSP ანგარიშებით; დაკარგული სტატუსები და ბატჩის კარანტინი; ალერტული ზრდისთვის 'decline _ rate'.
თამაშის პროვაიდერები: ვარდნა 'rounds _ per _ min' vs baseline + schema drift პროვაიდერისგან - პროვაიდერის A ტრანსფორმაციის ბლოკი, სტატუსის ბანერი.
RG/AML: სავალდებულო ველები (limites, self-exclusion, KYC სტატუსი); ვადაგადაცილებული KYC - დროშა გადახდის ბლოკზე, თიკეტი შესაბამისობაში.
მარკეტინგი/CRM: კამპანიის პარამეტრების მიზანშეწონილობა, UTM, მოვლენების დედობა; კ ანონიმურობა ფანჯრებში.

14) გზის განხორციელების რუკა

0-30 დღე (MVP)

1. ჩართეთ კონტრაქტები საკვანძო ნაკრებისთვის: payments, game _ rounds, users, features.
2. მოლოდინების კატალოგი (10-15 ძირითადი) + კარანტინი + ალერტა.
3. Dashboard Freshness/Completeness/Uniqueness; ინციდენტების ანგარიში.
4. Runbook’и для `Freshness`, `Duplicates`, `Schema drift`.

30-90 დღე

1. ინტერტაბულური კრეფა და ბალანსი; waiver პროცესი და semver წესები.
2. Stream validation (late data, dedup, watermarks); PII დეტექტორები.
3. ინტეგრაცია CI/CD- სთან: წყაროების ტესტები და გარდაქმნები.
4. SLO ხარისხის დომენის ბრძანებების OKR- ში.

3-6 თვე

1. რეიდის AIOPS რჩევები; მიზეზების ავტომატური ლოკალიზაცია.
2. ჯვარედინი ბრენდი/გეო ხარისხის პოლიტიკა და შესაბამისობის მოხსენებები.
3. P1 ინციდენტების პოსტ-mortems - გოლდენ სეტებისა და წესების შევსება.
4. ნაკადების ალერტინგთან დაკავშირება და ანომალიების ანალიზი (ერთი წრე).

15) RACI

Data Governance (A/R): სტანდარტები, კონტრაქტები, წესების აუდიტი.
დომენის ობნერები (R): დომენის მოლოდინები და ინვარიანტები.
Data Platform (R): მოლოდინების ჩარჩო, კარანტინი, ალერტები, მონიტორინგი.
უსაფრთხოება/DPO (A/R): კონფიდენციალურობა/PII/k ანონიმურობა, geo/tenant იზოლაცია.
SRE/Observability (C): ინციდენტების მარშრუტი, SLO/SLI.
Product/Finance (C): ბიზნესის ბალანსი, ინციდენტების პრიორიტეტები.

16) ანტი შაბლონები

ვალიდაცია „მხოლოდ DWH- ში“ - გვიან, ძვირი, მტკივნეული.
კარანტინი არ არის - „ჭუჭყიანი“ მიდის გოლდ/ML- ში და არღვევს ნდობას.
მკაცრი ბარიერები სეზონური/საათის/ბაზრების გარეშე - ალერტის ქარიშხალი.
მეპატრონის არარსებობა და სემვერი მართავდა გამონაკლისების ქაოსს.
ლოგოები PII- დან და „ეკრანის კადრები საერთო არხზე“.
ერთჯერადი „სანიტარული დღეები“ მუდმივი მიკროსქემის ნაცვლად.

17) დაკავშირებული მონაკვეთები

DataOps პრაქტიკა, მონაცემთა აუდიტი და ვერსია, მონაცემთა წარმოშობა და მარშრუტი, ალერტა მონაცემთა ნაკადებიდან, ანომალიების და კორელაციების ანალიზი, წვდომის კონტროლი, მონაცემთა უსაფრთხოება და დაშიფვრა, მონაცემთა შენახვის პოლიტიკა, MLOps: მოდელების ექსპლუატაცია.

შედეგი

ვალიდაცია არ არის ფილტრი ბოლოს, არამედ დასრულებული ხარისხის კონტრაქტი: ინჟესტიდან და ნაკადიდან ფანჯარამდე და ონლაინ ფიკამდე. მკაფიო მოლოდინები, კარანტინი, ალერტინი და SLO მონაცემებს საიმედო აქტივად აქცევს: მოხსენებები სწორია, მოდელები მდგრადია, გადახდები უსაფრთხოა, შესაბამისობა მშვიდია.