მონაცემთა სქემები და მათი ევოლუცია

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

საიმედოობა: მონაცემთა ცვლილებები არ არღვევს მოხსენებებს, API და მოდელებს.
ფიკის სიჩქარე: უსაფრთხოდ დაამატეთ ველები (KYC/RG/PSP) ნაკადების შეჩერების გარეშე.
მარეგულირებელი: კვალიფიკაცია და რეპროდუქცია (audit/lineage, DSAR, Legal Hold).
ღირებულება: ჩვენ მინიმუმამდე დავიყვანთ „გადასასვლელებს“ და ზურგჩანთებს.

2) სქემების ტიპები და სად ცხოვრობენ ისინი

მოვლენები (ნაკადები): 'payments. deposit_accepted`, `game. round_finished`.
OLTP/DDL: ნორმალიზებული ცხრილი (KYC, ანგარიშები, ლიმიტები).
DWH/witrins (Gold): დენორმალიზებული დანაყოფები BI/ML- ის ქვეშ.
Feature Store: ონლაინ/ოფლაინის ფინალური ნაკრები, თანმიმდევრული გარანტიით.
გარე პარტნიორების კონტრაქტები: PSP, თამაშების პროვაიდერები, მარკეტინგული წყაროები.

ნოტაციები: Avro/Protobuf (ნაკადები), JSON Schema (ინტეგრაცია), SQL DDL (DWH), Parquet schema (lake).

3) თავსებადობა (ევოლუციის ბირთვი)

Backward compatible: ახალი მწარმოებლები - ძველი კონსუტერები (დაამატეს ველი default/nullable).
Forward Compatible: ძველი მწარმოებლები ახალი კონსიუმერები არიან (ახალი მკითხველი ზედმეტი უგულებელყოფს).
Full compatible: ორივე და სხვა (მოვლენების სასურველი მიზანი).
Breaking-changes: ველის შეცვლა/მოცილება, ტიპის/სემანტიკის შეცვლა, გასაღების შეცვლა/წვეულება.

წესი 1: მოვლენები ევოლუციის გზით, არა ცვლილების გზით.
წესი 2: წაშლა - მხოლოდ MAJOR სქემის ვერსიაში, დეპრესიის პერიოდის შემდეგ.

4) სემანტიკური ვერსიები და პოლიტიკოსები

`MAJOR. MINOR. PATCH 'თითოეული სქემისთვის/ფანჯრის ფანჯრები/ფეხის ნაკრები.

MAJOR - შეუთავსებელი (ახალი topic/ცხრილი/fich ნაკრები, ორმაგი რუნი).
MINOR - თავსებადია (ახალი არალეგალური/defoult ველები, ახალი enum მნიშვნელობები).
PATCH - აღწერილობის/ლიმიტების/კომენტარების რედაქტირება.

ველის სასიცოცხლო ციკლი: 'experimental - აქტიური - deprecated - removed' (თარიღებითა და მფლობელით).

5) სქემების და მონაცემთა კონტრაქტების რეესტრი

Schema Registry: ინახავს ვერსიებს, თავსებადობას, ევოლუციას და მფლობელებს.
Data Contract: აფიქსირებს + SLO ხარისხის + კონფიდენციალურობის სქემას (იხ. განყოფილება „მონაცემების შესაბამისობა“).

json
{
"type":"record","name":"deposit_accepted","namespace":"payments",
"fields":[
{"name":"event_id","type":"string"},
{"name":"occurred_at","type":{"type":"long","logicalType":"timestamp-micros"}},
{"name":"user_id","type":"string"},
{"name":"brand","type":"string"},
{"name":"country","type":"string"},
{"name":"psp","type":"string"},
{"name":"method","type":"string"},
{"name":"amount","type":{"type":"bytes","logicalType":"decimal","precision":18,"scale":2}},
{"name":"currency","type":{"type":"enum","name":"Currency","symbols":["EUR","USD","TRY","BRL"]}},
{"name":"risk_score","type":["null","int"],"default":null},       // MINOR+
{"name":"kyc_level","type":["null",{"type":"enum","name":"Kyc","symbols":["L0","L1","L2","L3"]}],"default":null}
],
"compatibility":"FULL","owner":"team-payments"
}

6) მიგრაციის ნიმუშები

6. 1 მოვლენები (ნაკადები)

Additive-only: დაამატეთ ველები default/nullable; ძველი კონსუტერები არ იშლება.
Enum გაფართოება: ახალი სიმბოლოები ითვლება MINOR, კონსიუმერებს უნდა ჰქონდეთ ფილიალი 'else/unknown'.
MAJOR მიგრაცია: ახალი topic 'payments. deposit_accepted. v2 ', ორმაგი write, shadow-reads, შემდეგ consumers გადართვა.

6. 2 DWH/witrins

Blue-Green ცხრილი: 'gold. revenue _ v2 '' 'მახლობლად' v1 '; ჩვენ ვამოწმებთ მასალებს, გადავცვლით BI- ს.
Backfill: Snapshots + idempotent merge (კლავიშების/ვერსიების მიხედვით).
SCD: ტიპი 2 ნელა ცვალებადი ატრიბუტებისთვის (ლიმიტები, KYC, VIP სტატუსები).

6. 3 Feature Store

Dual serve: ძველი set ემსახურება ახალი პარალელურად; მოდელს ემსახურება როუტერი.
Point-in-time კოორდინაცია: ევოლუცია არ უნდა დაარღვიოს PITA ჯოინები (timestamp/მარცვლოვანი უცვლელი MINOR- ის ქვეშ).

7) ცვლილებების ტაქსონომია (შემოწმების სია)

• დამატება 'არა/default' ველები;
• enum გაფართოება (მომხმარებელში 'unknown' ფილიალით);
• არასასურველი ინდექსის/კომენტარის/აღწერილობების დამატება.

• მასშტაბის/ერთეულების შეცვლა (მაგალითად, ძირითადი ვალუტით ცენტრებში ამოუნტი) - მხოლოდ MAJOR- ში;
• საცნობარო/რეფერენდუმის გადაცემა - პრეზენტაციის ფენის საშუალებით.

• ველის შეცვლა/მოცილება;
• ტიპის/ფორმატის/გასაღების/ნაწილის შეცვლა;
• სემანტიკის შეცვლა (მაგალითად, „bonus _ amount“ - დან „დარიცხული“).

8) სქემების და თავსებადობის ტესტები

Schema-lint: სახელების სტილი ('snake _ case'), სავალდებულო ეტიკეტები ('owner', 'doc', 'pii'), თარიღების/ვალუტის ფორმატი.
Compat-tests: ჩვენ ვამოწმებთ ახალ ვერსიას რეესტრის წინააღმდეგ (backward/forward/full).
Consumer-contract-tests: თითოეული სერვისი აწვდის „დატვირთვის მაგალითს“ და მოლოდინს; მოდით CI- ზე გადავიტანოთ სქემის შეცვლისას.
Golden მონაცემთა ბაზები: რეალური და „ბოროტი“ მაგალითების ერთობლიობა (ახალი enum, ცარიელი/გვიან ველები, თანხების ხაზოვანი მნიშვნელობები).

9) ცნობარები, ენები და ლოკალიზაცია

ანგარიშის მონაცემები (ქვეყნები/ვალუტები/PSP/პროვაიდერები): ცალკეული ვერსიები და SLA განახლებები; არ შეიყვანოთ მოვლენების კოდი.
Locale/დროის ზონები: შეინახეთ UTC ღონისძიებებში + აშკარა ადგილი პრეზენტაციისთვის.
იურისდიქციების წესები: ასაკობრივი დროშები, პრომო შეზღუდვები - საცნობარო წიგნების სახით, მოქმედების თარიღებით.

10) მულტიბრენდი/ანიმაცია და PII

ტენანტის იზოლაცია: 'brand', 'country', 'license' - სავალდებულო ველები enum- ით; მათზე როუტინგი.
PII პოლიტიკა სქემის დონეზე: ველი „pii = true“, ჩვენ ვიყენებთ ნიღბებს/ტოკენიზაციას; მოვლენებში - მხოლოდ ნიშნები.
DSAR: 'source _ id/trace _ id' არსებობა წაშლა/ძებნა; Legal Hold MAJOR მიგრაციებში.

11) DDL და Lake ვერსიები

DDL მიგრაცია: დეკლარაციული მიგრაცია (Liquibase/Flyway/dbt), შენახვა VCS- ში, დომენის ეჭვიანი მფლობელი.
ფორმატები ტბაში: Avro/Parquet - ჩვენ ვადგენთ ველების ევოლუციას; MAJOR- ში - ახალი ცხრილი/გზა... .../v2/'.
წვეულება: პარტიების ცვლილება (მაგალითად, 'date' date 'date, brand') - მხოლოდ MAJOR- ის საშუალებით და ორმაგი ჩაწერა.

12) iGaming- ის მაგალითები

12. 1 PSP- მა გააფართოვა მეთოდები

დაემატა 'method = „MEFETE“' enum.
MINOR სქემის გამოცემა 'deposit _ accepted v1. 8. 0`; კონსიუმერები, რომლებმაც არ იციან MEFETE, იგზავნება 'unknown _ method' ფილიალში.

12. 2 თამაშების პროვაიდერმა დაამატა მოედანი

'game. round _ finished 'დაემატა' jackpot _ id '(nullable).
ვიტრინ გოლდი. game _ rounds _ v3 'იღებს MINOR; ძველი მოხსენებები მუშაობს, ახლები ჯეკპოტებს თვლიან.

12. 3 RG ატრიბუტები

Bull 'self _ excluded' - დან სტატუსის 'rg _ state "გადასვლა {none, limit, cooldown, self _ excluded'} - MAJOR, ახალი topic + dul-write + ვიტრინების და.

13) ევოლუციის პროცესი (იდეიდან გადართვამდე)

1. Proposal (ADR): რატომ ვცვლით თავსებადობის ტიპს, რისკის შეფასებას და დაზარალებულ მომხმარებლებს.
2. დიზაინი და კონტრაქტი: სქემა რეესტრში, სემვერში, თავსებადობის პოლიტიკა.
3. ტესტები: linters, compat, consumer-contracts, raples golden სეტებზე.
4. განლაგება: ორმაგი write/blue-green/shadow-reads; ალერტა.
5. Cryption: ბიზნეს ბალანსი/ინვარიანტები (იხ. „მონაცემების შესაბამისობა“).
6. Switch: გადართეთ კონსიუმერები/BI/ფიჩები.
7. დეპრესია: ძველი სქემის freeze, grace-period, მოცილება და არქივი.

14) მეტრიკა და SLO ევოლუცია

Success-rate მიგრაცია, ორმაგი რუნის დრო, ახალი ფორმატის მოვლენების წილი, backfill, lag/freshness მოცულობა.
თავსებადობის ინციდენტები (P1/P2), ფანჯრების ხარისხი გადართვის შემდეგ.
Cost: $/TB გადაკვეთა, $/$ ორმაგი-write, კლასტერის დატვირთვა.
Compliance: 0 PII გაჟონვა, SLA DSAR/Legal Hold არის დაცული.

15) ხელსაწყოები და ნივთები

15. 1 თავსებადობის პოლიტიკა (რეესტრი)

yaml schema: payments. deposit_accepted compatibility: FULL default_nulls: true enums:
currency: {allow_new_symbols: true, require_consumer_unknown_branch: true}
pii: false owners: ["team-payments"]
reviewers: ["data-governance","security-dpo"]

15. 2 მიგრაციის პასპორტი (შაბლონი)

yaml change_id: MIG-2025-041 scope: game. round_finished -> v3 type: MAJOR plan:
dual_write: true shadow_reads: consumers: ["gold-rounds","rg-models"]
backfill: {from: "2025-01-01", mode: "idempotent-merge"}
validation:
invariants: ["sum_bets = sum_wins + margin + bonuses"]
freshness_delta_p95_max: "PT5M"
switch_criteria:
error_rate_max: 0. 1%
kpi_diff_pp_max: 0. 5 deprecate_after: "2025-12-31"

15. 3 Linter სახელები და ტიპები (წესები)

'snake _ case', UTC timestamps, DECIMAL (18.2) თანხებისთვის, 'country' შესაბამისად ISO-3166-1 alpha-2, 'currence' შესაბამისად ISO-4217.
არ არის „უფასო _ ტექსტი“ enum ველებისთვის; საცნობარო წიგნები - გარე.

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

0-30 დღე (MVP)

1. ჩართეთ Schema Registry + პოლიტიკის თავსებადობა საკვანძო მოვლენებისთვის (payments, game _ rounds, user).
2. Linters/compat ტესტები CI- ში; მფლობელთა კატალოგი და SLA მიმოხილვები.
3. ADR შაბლონები და მიგრაციის პასპორტი; MAJOR ჩეკის სია.

30-90 დღე

1. ცისფერი-მწვანე ოქროს ფანჯრისთვის; ორმაგი write კრიტიკული თემებისთვის.
2. Consumer-contract-tests ძირითადი სერვისებისთვის; golden-datasets.
3. ავტომატური დისკი და ალერტები გადართვის დროს; ღირებულების ანგარიშები.

3-6 თვე

1. ერთი დეპრესია/remove ერთად grace period; საარქივო და იურიდიული ჰოლდი.
2. Geo/tenant სპეციფიკური სქემები და დაშიფვრის გასაღებები; მგრძნობიარე ბაზრების DP ვარიანტები.
3. ველის სემანტიკის კატალოგი (მონაცემთა ციფრული) და ცოცხალი ხაზის დიაგრამები.

17) RACI

Data Governance (A/R): სტანდარტები, რეესტრი, მიგრაციის შურისძიება, დე პუბლიკაცია.
დომენის ობნერები (R): სფეროების მნიშვნელობა, საცნობარო წიგნები, ბიზნეს ინვარიანტები.
Data Platform (R): რეესტრის ინსტრუმენტები, კომპატის ტესტები, ორმაგი რუნი/ზურგჩანთა.
Security/DPO (A/R): PII პოლიტიკა, geo/tenant, DSAR/Legal Hold.
SRE/Observability (C): ალერტები, SLO ევოლუციები, capacity.
Product/Finance (C): KPI შესაბამისობა, გადართვის ფანჯრები.

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

„სწორი ველი ფრენაზე“ ვერსიების გარეშე და ორმაგი რუნი.
ახალი ველის დამატების ნაცვლად, სახელის გადარქმევა მასობრივი ავარია იყო.
მკაცრი enum ფილიალის გარეშე 'unknown' - ის დაცემის ახალი მნიშვნელობებით.
ერთი საცნობარო წიგნი „კოდში“ ყველა იურისდიქციისთვის.
Backfill idempotent-merge და ჩეკის ბალანსების გარეშე.
Logs ერთად PII და trace _ id ძიების გარეშე/DSAR.

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

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

შედეგი

სქემების ევოლუცია არის პროცესი და არა ერთჯერადი მიგრაცია: რეესტრი, ვერსიები და თავსებადობა; ორმაგი რუნი და ცისფერი-მწვანე ნაცვლად „შუაღამისას კონცენტრატორების“ ნაცვლად; თავსებადობის ტესტები და ბიზნესის ინვარიანტები წარმატების ნაცვლად. ასე რომ, მონაცემები რჩება სტაბილური, მოდელები პროგნოზირებულია, მოხსენებები სწორია, ხოლო რეგულატორები მშვიდია.