GH GambleHub

მონაცემთა აუდიტი და ვერსია

1) რატომ არის ეს აუცილებელი?

აუდიტი და ვერსია ქმნის რეპროდუქციას: შეგიძლიათ ახსნათ ნებისმიერი ციფრი, გაიმეოროთ გაანგარიშება და უსაფრთხოდ შეიმუშაოთ მოდელები/ფანჯრები. IGaming- ში ეს კრიტიკულია ფინანსებისთვის (GGR/NET), გადახდები, KYC/AML, Responsible Gaming და მარეგულირებელი ანგარიშგებები.

მიზნები:
  • ტრეკერი: ვინ შეცვალა მონაცემები/სქემა/ლოგიკა და რატომ.
  • რეპროდუქცია: მონაცემთა/კოდის/მოდელის რომელი ვერსია წარმოიშვა მოხსენება.
  • გამოშვების უსაფრთხოება: შექცევადობა და ცვლილებების პროგნოზირება.
  • შესაბამისობა: დადასტურებული ჟურნალები რეგულატორებისა და შიდა აუდიტისთვის.

2) ვერსიის ცნებები და დონე

1. სქემის ვერსია (შემა ვერსია): ველების/ტიპების/სემანტიკის ევოლუცია (SEMVER).
2. მონაცემთა ნაკრების ვერსია (Dataset Version): სურათი/მონაკვეთი დროის დროს; „ჭეშმარიტება“ მოხსენების/სწავლებისთვის.
3. ფანჯრის/BI მოდელის ვერსია (Data Product Version): ფორმულები, ფილტრები, აგრეგაცია.
4. Fich/ML მოდელის ვერსია: თარიღი/კოდი/ჰიპერპარამეტრები/ფიჩები/მონაცემები (end-to-end).
5. Paypline ვერსია: ტრანსფორმაციის კოდი, კონფიგურაცია, დამოკიდებულება.
6. მონაცემთა ხელშეკრულების ვერსია: მოთხოვნები მწარმოებლის/მომხმარებლისთვის (სქემა, SLA, ხარისხი).


3) აუდიტი: რა უნდა გაკეთდეს

ვინ: სუბიექტი (მომხმარებელი/სერვისი), როლი/ატრიბუტები (RBAC/ABAC).
რა: ცხრილი/ვიტრინა/მოდელი/სქემა/კონტრაქტი.
როდის: ზუსტი დრო, tz, კორელაციის id.
რატომ: ბმული ტასკზე/ტიკეტი/გამოშვება-ნოტი, მიზეზი.
რა: კოდის/მოდელის ვერსია, commit hash, კონტეინერის სურათი.
როგორ შეიცვალა: diff- ის დაწყებამდე, ხაზების რაოდენობა (rows affected), მთლიანობის კონტროლი (hash/ხელმოწერა).
კონტექსტი: გარემო (stage/stage), დომენი, მონაცემთა მგრძნობელობა (კლასი).

აუდიტის ჟურნალები უცვლელია (append-only/WORM), გაფორმებულია და ხელმისაწვდომია SIEM- ში.


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

SEMVER: `MAJOR. MINOR. PATCH`

MAJOR არის სქემის/სემანტიკის შეუთავსებელი ცვლილებები.
MINOR შექცევადი თავსებადი დამატებებია (ახალი ველები/სვეტები არალეგალური, ახალი vNext ფანჯრები).
PATCH - კორექტირება ხელშეკრულების შეცვლის გარეშე (quality-fix, backfill).
დეპრესიის პროცედურა: მოძველებული ფანჯარა, დირექტორიაში გაფრთხილება/CI, გათიშვის თარიღი.
Release Notes: გამოშვების ერთი გვერდი: რა, რატომ, რისკები, გამოტოვების გეგმა.


5) აღჭურვილობა საცავში და ნაკადში

Time travel/Snapshots: ცხრილის ვერსიების შენახვა; თხოვნის შესრულების შესაძლებლობა „როგორც ეს იყო T-0“.
SCD (Slowly Changing Dimensions): ტიპები 1/2/3 გაზომვებისთვის (თამაშები, პროვაიდერები, მოთამაშეები).
CDC/CDF (Change Data/Capture & Feed): ფაქტების სავარაუდო ცვლილებები (განაკვეთები, გადახდები, KYC).
საოპერაციო ჟურნალი (Audit Fact): ცალკეული ფაქტობრივი ცხრილი ცვლილებების/დამატებების/წაშლის მოვლენებით.
მთლიანობის კონტროლი: წვეულებების/ფაილების ჰეშები, პაკეტების ხელმოწერა, აგრეგატების შერიგება.


6) სქემების ევოლუცია და მონაცემთა კონტრაქტები

კონტრაქტი, როგორც კოდი: სქემა, ტიპები, ველების სავალდებულო, დასაშვები მნიშვნელობები, SLA სიახლე, DQ წესები.
თავსებადობა: დაამატეთ ველი MINOR; შეცვალა MAJOR ტიპის/სემანტიკა მიგრაციით და ორმაგი-write.
CI კარიბჭე: PR შეცვლის სქემა იბლოკება, თუ თავსებადობა შეფერხებულია ან არა Release Notes.
კატალოგი/რეგისტრი: ინახავს აქტიურ/მოძველებულ ვერსიებს და მფლობელებს.


7) ვერსია BI და მეტრებში

დამოწმებული „ოქროს“ ფანჯრები: დაფიქსირებული სემანტიკა KPI (GGR, ARPPU, გამართვა).
ორმაგი რუნი: ფანჯრის ფანჯრის ახალი ვერსია აგებულია პარალელურად (v2), მეტრული შედარება (tolerance bands).
ანგარიშების დაფიქსირება: თითოეული ექსპორტი/დაშბორდი ეხება „მონაცემთა ბაზას _ ვერსიას“ და „დეფინიციას _ ვერსიას“.
კალენდარული ნაჭრები: „dei-kat“, „თვე-k- თარიღი“ - აღირიცხება მონაცემთა ვერსიაში.


8) ვერსია ML/MLOps

Model Registry: მოდელი, თარიღი, ხარისხის მეტრიკა, სასწავლო მონაცემები (dataset _ version), fick (feature _ set _ version) ვერსიები.
Feature Store: ვერსირებული ფინალური ჯგუფები; „ცხელი“ მინდვრების აკრძალვა აშკარა ვერსიის გარეშე.
რეპრო ნაკრები: ტრენინგის კოდი (commit), გარემო (Docker/conda lock), sid.
Champion-Challenger: პარალელური გაყიდვების ვერსიები, მოხსენებები ხარისხის, fairness და კონფიდენციალურობის შესახებ.
Rollback: სწრაფი დაბრუნება წინა სტაბილურ მოდელზე და წინა ნაკრებზე.


9) Rollback, backfill და შესწორებები

Rollback გეგმა: თითოეული MAJOR/MINOR ვერსიისთვის - მკაფიო დაბრუნების ნაბიჯები.
Backfill playbuk: ჭეშმარიტების წყარო, თარიღების დიაპაზონი, გადაანგარიშების პროცედურა, საკონტროლო თანხები, ეტიკეტები „recomputed = ნამდვილი“.
რედაქტირების ხილვადობა: v2 შეცვლის v1 მხოლოდ შედარების გავლის შემდეგ; ყველა „ისტორიული“ ანგარიში კვლავაც ეხება მათ ვერსიებს.


10) უსაფრთხოება და შესაბამისობა აუდიტში

ღონისძიების/პაკეტების ხელმოწერა: პროდიუსერი ხელს აწერს, მომხმარებელი ამოწმებს.
PII შენარჩუნება: აუდიტი ინახავს ნიშნებს, რომლებიც არ არის ნედლეული PII.
Legal Hold: გამოძიების პერიოდისთვის ვერსიის/ლოგების ამოღების აკრძალვა.
DSAR: ვერსიები პოულობენ და ატვირთავენ საგნის ჩანაწერებს; მხედველობაში მიიღება ისტორიული სურათები.


11) მეტრიკა და SLO

Repro Rate: სამიზნე ბარიერის მონაცემთა/კოდის ვერსიიდან რეპროდუცირებული ანგარიშების წილი.
Coverage: ცხრილების%, რომლებიც ჩართულია time-travel/აუდიტის ჟურნალში.
Schema Compatibility Pass: წარმატებული თავსებადობის შემოწმების წილი CI- ში.
Dual-run Delta: განსხვავება v1/v2 მიღებაში.
Rollback MTTR: ვერსიის საშუალო დაბრუნება.
Audit Integrity: ხელმოწერილი და დადასტურებული მოვლენების წილი.
Backfill Success: სწორად დასრულებული გადარიცხვების წილი.


12) ნიმუშები iGaming- ისთვის (საქმეები)

GGR- ის კორექტირება რეტროაქტიულია: მიმწოდებელმა დაითვალა RTP - ჩვენ ვაკეთებთ ფაქტების პაკეტს პერიოდისთვის, ვაწარმოებთ 'recomputed _ at' - ს, ვაქვეყნებთ Release Notes- ს, ვადარებთ v1/v2; გასული თვეების განმავლობაში ჩვენ არ ვწერთ მოხსენებებს, ხოლო „შესწორებული ვერსია ხელმისაწვდომია“.
ანტიფროდიული წესები: შეცვალეთ ფიჩხის სემანტიკა - MAJOR, მოდელის და ფანჯრების ორმაგი რუნი, ჩემპიონის როლბეკი რეგრესში.
KYC/AML: დაამატეთ პროვაიდერის ახალი სტატუსები - MINOR უნებლიეთ; კონტრაქტებში თავსებადობის ტესტების ჩათვლით.
RG სიგნალები: მათ განმარტეს „დაკარგული სერიის“ ლოგიკა - MINOR + Release Notes და გავლენის მონიტორინგი.


13) ინსტრუმენტები და არტეფაქტები (კატეგორიები)

Catalog/Lineage/Registry: კომპლექტების/სქემების/ფანჯრების ვერსიები, მფლობელები, კომუნიკაციები, კონტრაქტები.
Orchestrator & CI/CD: თავსებადობის კარიბჭეები, ორმაგი რუნის პროგნოზი, გამოცემის ნოტების გამოქვეყნება.
სცენა time-travel: სურათების/ჟურნალების შენახვა.
Signing & Checksums: პაკეტების ხელმოწერა, პარტიების მაკონტროლებელი თანხები.
Model/Feature Registry: fick/მოდელების ვერსიები, champion-challenger ანგარიშები.


14) შაბლონები (გამოსაყენებლად მზად)

14. 1 Release Notes (ესკიზი)

ვერსია: 'payments _ gold v2. 1. 0`

ტიპი: MINOR (ახალი ველები 'psp _ country', 'method _ group')

მიზეზი: PSP/ქვეყნებში ანგარიშგების გაერთიანება

რისკები: ჯოინებზე გავლენა 'risk _ signals'

ვალიდაცია: ორმაგი რუნი 14 დღე, დელტა - 0. 2% GGR

Rollback: გადართვა 'v2. 0. 3 'ორკესტრის დროშის საშუალებით

deploy თარიღი/მფლობელი/tiket

14. 2 პასპორტი ვერსიის ვერსიაში

Dataset: `game_rounds_silver`

ვერსია: '2025-11-01T00: 00: 00Z' (snapshot id)

სქემა: 'schema @ 1. 7. 0 '(ხელშეკრულების ბმული)

წყარო: პროვაიდერის ფიდები A/B (commit...)

მთლიანობის კონტროლი: checksum, ხელმოწერილი მანიფესტი

DQ: სისრულე 99. 9%, სიახლის 15 წუთი

გამოყენება: 'games _ perf _ gold v3. x`, `rg_signals v1. x`

14. 3 ცვლილების აუდიტის აქტი

ღონისძიება: განახლება schema 'kyc _ status' kyc _ status, v2 '

ვინ: მომხმარებელი/სერვისი, 'Data-Engineer- ის როლი'

როდის: '2025-11-01 09:32:10 + 02'

რატომ: ticet # 3421 (პროვაიდერის ახალი სტატუსები)

Diff: + 'status _ reason' (nullable), გაფართოვდა enum

შემოწმებები: CI semver pass, MINOR კონტრაქტი

ხელმოწერა: 'sig =...', hish diff: 'sha256 =...'

14. 4 ვერსიის პოლიტიკა (ფრაგმენტი)

MAJOR: არღვევს თავსებადობას; ორმაგი write - 30 დღე; სავალდებულო rollback გეგმა.
MINOR: შექცევად თავსებადი; გაფრთხილებები კატალოგში; A/B ვიტრინა 7-14 დღე.
PATCH: ხარისხის ფიქსაცია/დათვლა; Release Notes აუცილებლად.
არქივირება: შეინახეთ მარეგულირებელი საშუალებების N თვე; WORM აუდიტისთვის.


15) პროცესები

1. ინიციატივა: ცვლილების ტიკეტი + იმპაქტის შეფასება ხაზის მიხედვით.
2. დიზაინი: ხელშეკრულების განახლება/სქემები + Release Notes.
3. სავალდებულო: CI თავსებადობის შემოწმება, DQ ტესტები, ორმაგი რუნი.
4. დაბრკოლება: დროშის გასწვრივ, კანარი; კატალოგის ვერსიის გამოქვეყნება.
5. მონიტორინგი: delta v1/v2, KPI, საჩივრები.
6. გამოტოვება/Backfill: playbook- ზე რეგრესიის დროს.
7. პოსტ-mortem: თუ ინციდენტი, პოლიტიკის/ტესტების განახლება.


16) RACI (მაგალითი)

პოლიტიკა და სტანდარტები: CDO (A), Data Governance Council (R/A), DPO/Sec (C).
კონტრაქტები/სქემები: დომენის ფანჯრები (A), Data Stewards (R), Platform/Eng (C).
ორკესტრი/საცავი: პლატფორმა/Eng (R), SRE (C).
BI/მეტრიკა: Analytics Lead (R), Product/Finance (C).
ML ვერსიები: ML Lead (A), DS (R), Platform (C).
აუდიტი/ჟურნალები: SecOps (R), Internal Audit (C).


17) საგზაო რუკა

0-30 დღე (MVP)

ჩართეთ time-travel/სურათები კრიტიკული ცხრილებისთვის (payments, game _ rounds, kyc).
დაიწყეთ უცვლელი აუდიტის ჟურნალები და ინვესტიციის პაკეტების ხელმოწერა.
მიიღეთ SEMVER პოლიტიკა და Release Notes შაბლონი.
კატალოგი: დაამატეთ 'owner', 'schema _ version', 'dataset _ version' საუკეთესო ფანჯრებისთვის.

30-90 დღე

შეიყვანეთ ორმაგი რუნი ყველა MINOR/MAJOR; ავტომატური შედარება v1/v2.
დააკავშიროთ კონტრაქტები CI თავსებადობასთან და DQ- სთან.
backfill/rollback რეგულაციები; გუნდების მომზადება.
Model/Feature Registry სრული კავშირებით „მონაცემები ფიჩქების მოდელისთვის“.

3-6 თვე

აუდიტის ჟურნალების სრული დაფარვა, WORM საცავი, მოხსენებები რეგულატორებისთვის.
ავტომატური Release Notes diff + ხაზიდან.
Repro Rate/Schema Compatibility/Rollback MTTR ანგარიშები დაშბორდში.
KPI- ს კვარტალური ვერსიები და განმარტებების „გაყინვა“.


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

KPI სემანტიკის ცვლილება ახალი ვერსიის/გამოცემის ნოტის გარეშე.
„ჩუმად“ გადარიცხვები backfill გეგმის და ნიშნის გარეშე.
ნედლეული PII- ის შენახვა აუდიტის ლოგოებში.
ორმაგი რუნის ნაკლებობა და ფანჯრების მყისიერი ჩანაცვლება.
„მარადიული“ მოდელები/ფანჯრები ვერსიისა და წყაროების მითითების გარეშე.


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

მონაცემთა მენეჯმენტი, მონაცემთა წარმოშობა და მარშრუტი, წვდომის კონტროლი, ტოკენიზაცია, უსაფრთხოება და დაშიფვრა, მოდელების მონიტორინგი, ეთიკა და DSAR, ფედერალური ხაზი, კონფიდენციალური ML.


შედეგი

აუდიტი და ვერსია მონაცემებსა და მოდელებს საიმედო პროდუქტად აქცევს: თითოეული ცვლილება გამჭვირვალე, რეპროდუქციული და შექცევადია. IGaming- ისთვის ეს არის KPI- ს ნდობის საფუძველი, შესაბამისობის სტაბილურობა და უსაფრთხო გამოშვებების სიჩქარე.

Contact

დაგვიკავშირდით

დაგვიკავშირდით ნებისმიერი კითხვის ან მხარდაჭერისთვის.ჩვენ ყოველთვის მზად ვართ დაგეხმაროთ!

ინტეგრაციის დაწყება

Email — სავალდებულოა. Telegram ან WhatsApp — სურვილისამებრ.

თქვენი სახელი არასავალდებულო
Email არასავალდებულო
თემა არასავალდებულო
შეტყობინება არასავალდებულო
Telegram არასავალდებულო
@
თუ მიუთითებთ Telegram-ს — ვუპასუხებთ იქაც, დამატებით Email-ზე.
WhatsApp არასავალდებულო
ფორმატი: ქვეყნის კოდი და ნომერი (მაგალითად, +995XXXXXXXXX).

ღილაკზე დაჭერით თქვენ ეთანხმებით თქვენი მონაცემების დამუშავებას.