GH GambleHub

ისტორიულ მონაცემებთან მუშაობა

1) დანიშვნა და პრინციპები

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

პრინციპები:
  • დროის დიზაინი: დროის აშკარა მოდელები სქემებსა და მოთხოვნებში.
  • Reproducibility: იგივე დასკვნა D თარიღისთვის ყოველთვის იძლევა იმავე შედეგს.
  • Auditability: დადასტურებული წარმოშობა, უცვლელი ფენები, WORM იქ, სადაც საჭიროა.
  • Cost-aware: საარქივო ფენები, კომპრესია, ცივი სცენა გასაგები SLA.
  • Privacy-by-design: PII მენეჯმენტი რეტროსპექტული ოპერაციებითა და იურიდიული მოთხოვნებით.

2) დროის მოდელები

ღონისძიების დრო: ფაქტობრივი მოვლენის დრო (კურსი, ანაბარი).
პროფესიული დრო: როდესაც სისტემამ დაამუშავა ჩანაწერი (შეიძლება განსხვავდებოდეს).
Bitemporal: რეტროაქტიულად გადასინჯვისთვის როგორც საღამოს, ასევე პროფესიონალურ დროში შენახვა.
Validity ინტერვალები: 'valid _ from', 'valid _ to', 'is _ current'.
As-of queries: მონაცემთა ნიმუში „როგორც მათ იცოდნენ T დროს“.

ველის შაბლონი:
sql event_time TIMESTAMP, -- event time processed_at TIMESTAMP, -- TIMESTAMP valid_from processing time, -- start of version validity valid_to TIMESTAMP, -- end of validity (NULL if current)
is_current   BOOLEAN

3) შენახვის ფენები და ფორმატები

Lakehouse: Bronze (raw append-only) - Silver (clean/SCD/ნორმალიზაცია) - Gold (ფანჯრები).
ACID-форматы: Delta/Iceberg/Hudi (MERGE/Upsert, time-travel, snapshots).
Tiered storage: hot/warm/cold + WORM მარეგულირებელი არტეფაქტებისთვის.
განაწილება: 'event _ date', 'barket', 'tenant'; მტევანი/Z- რიგის ხშირი პრედიკატებში (user/game/provider).

4) გაზომვების ისტორიალიზაცია (SCD)

SCD I: გადაწერა - არაკრიტიკული კორექტირებისთვის.
SCD II: სრული ისტორია; რეკომენდებულია RG/KYC/ტრაფიკის/თამაშების ატრიბუტებისთვის.
SCD III: „ადრე/შემდეგ“ - შედარების იშვიათი შემთხვევები.

მაგალითი SCD II:
sql
MERGE INTO dim. users_scd t
USING stage. users u
ON t. user_pseudo_id = u. user_pseudo_id AND t. is_current = TRUE
WHEN MATCHED AND (t. rg_status <> u. rg_status OR t. country <> u. country) THEN
UPDATE SET is_current = FALSE, valid_to = CURRENT_TIMESTAMP
WHEN NOT MATCHED THEN
INSERT (user_pseudo_id, country, rg_status, valid_from, valid_to, is_current)
VALUES (u. user_pseudo_id, u. country, u. rg_status, CURRENT_TIMESTAMP, NULL, TRUE);

5) ფაქტების ისტორია: სურათები და ბიტემპორტალი

სურათები (snapshots): დანაყოფების სურათი დღის ბოლოს/თვის ბოლოს (მაგალითად, საფულის ბალანსი) - აჩქარებს ისტორიული ცნობების რეკონსტრუქციას.
Bitemporal ფაქტები: ჩვენ ვწერთ ღონისძიების დროსა და პროფესიულ დროს, რათა განვასხვავოთ გვიანდელი კორექტივები რეტროსპექტული გამოთვლებისგან.
Exactly-once მოთხრობა: 'event _ id' + idempotent MERGE.

6) მოგზაურობის დრო და რეპროდუქცია

Time-travel: ცხრილების წაკითხვა „T დროს“ გამართვის, ინციდენტების, შედუღების მიზნით.
ლოგიკის ვერსია: ტრანსფორმაციის არტეფაქტები (SQL/DBT ვერსიები, კონტეინერები) და ეტიკეტები „logic _ version“ გამომავალი ცხრილებში.
Frozen outputs: ოქროს საანგარიშო ნიმუშები ფიქსირდება და არ არის გადაწერილი, ასევე ხელმისაწვდომია hash და ექსპორტის ჟურნალი.

მოთხოვნის მაგალითი:
sql
SELECT
FROM silver. fact_bets VERSION AS OF 1678901234567
WHERE event_date = DATE '2025-10-31';

7) Backfill и Reprocessing

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

გარდერილი:
  • Idempotence (MERGE/upsert), დიაპაზონი, კვოტები, „dry-run“ მეტრული შედარებით.
  • ჩვენ აღვნიშნავთ შედეგს: 'recalc _ reason', 'logic _ version', 'reprocessessed _ at'.
Runbook (სქემა):

1. უფასო მიმდინარე ოქრო; 2) DLQ/DQ შემოწმება; 3) პროგონ სილვერი; 4) მეტრიკის შედარება; 5) ოქროს გადაკეთება; 6) პუბლიკაცია და ხელმოწერა.

8) სიზუსტის შერწყმა

მაკონტროლებელი თანხები: ბრუნვის/რაოდენობების შერწყმა OLTP, PSP/პროვაიდერებით.
ორმაგი წრიული შემოწმება: დამოუკიდებელი მილაკი ნიმუშზე (A/B შედარება).
მისცეს: მაგალითად, GGR-0 შეუსაბამობა. 2% დღეში.

SQL ნიმუშები:
sql
-- Duplicates
SELECT transaction_id, COUNT() c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

-- Unknown Currencies/Markets
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON r. code = p. currency
WHERE r. code IS NULL;

9) ვალუტა, დრო, კალენდარი: ისტორიული სისწორე

FX ღონისძიების თარიღისთვის: ჩაწერეთ 'fx _ rate _ used' და 'fx _ source'.
ადგილობრივი ბაზრის დრო: DST/Timesons კალენდრის დირექტორიის საშუალებით.
არდადეგები/სეზონური: კალენდრის ცალკეული ცხრილი, ჩვენ ვიყენებთ მოდელებსა და მოხსენებებში.

FX ნორმალიზაციის მაგალითი:
sql
SELECT p. transaction_id,
p. amount_orig,
r. rate AS fx_rate_used,
p. amount_orig r. rate AS amount_base,
r. fx_source
FROM bronze. payment_events p
JOIN dim. fx_rates r
ON r. date = DATE(p. event_time) AND r. ccy_from = p. currency AND r. ccy_to = 'EUR';

10) PII, შესაბამისობა და Legal Hold

PII მინიმიზაცია: ფსევდონიზაცია, ცალკეული დაცული მაპინგი.
DSAR/RTBF: გამოთვლილი პროექციები და ისტორიული ფენების შერჩევითი რედაქტორები; შენახვის იურიდიული მოვალეობის გამონაკლისი დოკუმენტირებულია.
Legal Hold: „გაყინვის“ დროშები დიაპაზონებზე/ობიექტებზე, WORM საანგარიშო არტეფაქტებისთვის.
აუდიტი: ხელმისაწვდომობისა და ექსპორტის უცვლელი ლოგოები.

11) DQ და lineage ისტორიისთვის

DQ კოდი (მაგალითი):
yaml table: silver. fact_bets slo:
completeness_percent: 99. 5 freshness_minutes: 60 rules:
- name: unique_bet type: unique columns: [bet_id]
severity: critical
- name: market_known type: in_set column: market set_ref: ref. markets
- name: ts_in_range type: temporal expression: "event_time BETWEEN date_sub(now(), interval 5 year) AND now()"

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

12) პროდუქტიულობა და ღირებულება

განაწილება: თარიღი/ბაზარი/ტენანტი; აგრესიული კლასტერიზაცია 'user _ pseudo _ id '/' game _ id' მიხედვით, თუ ხშირად ფილტრავს.
ფორმატები: Parquet + სტატისტიკა/კომპრესია; რეგულარული VACUUM/OPTIMIZE.
მატერიალიზაცია: precompute „ძვირადღირებული“ ისტორიული ერთეულებისთვის; Snaphots of pokvartal/წლიური ანგარიშგებისთვის.
არქივი: ძველი ნაწილების გადაცემა ცივ სცენაზე (SLA აღდგენისთვის არის დოკუმენტირებული).
სიმულაცია: მხოლოდ კვლევითი ამოცანებისთვის, არა მარეგულირებელი/ფინანსებისთვის.

13) ისტორიული ფიჩები ML- სთვის

Feature registry: თითოეულ ხაზს აქვს ფორმულა, owner, SLO, 'model _ version'.
ონლაინ/offline კოორდინაცია: ერთი კოდური ტრანსფორმაციის ბაზა, გადასასვლელი ტესტები.
ნიშნების დრიფტი: PSI/KS პერიოდებში, ისტორიული განაწილებების შენახვა.

14) მოთხოვნის ნიმუშები

As-of (თარიღისთვის): მოხსენებების რეპროდუქცია.
კოჰორტის ანალიზი: რეგისტრაციის კოჰორტები/პირველი ანაბრები, rolling ფანჯარა.
Slowly changing facts: корректные join’ы с SCD II (`event_time BETWEEN valid_from AND COALESCE(valid_to, '9999-12-31')`).

Join 'a მაგალითი SCD II- სთან:
sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);

15) პროცესები და RACI

R (Responsible): მონაცემთა ინჟინერია (მოდელები/SCD/backfill), Data Platform (ACID/არქივი), Finance/Compliance (შესანახი/მოთხოვნები).
A (Accountable): Head of Data/CDO.
C (Consulted): Legal/DPO (DSAR/RTBF/Legal Hold), SRE (ღირებულება/SLA), არქიტექტურა.
I (ინფორმირებული): BI/პროდუქტი/მარკეტინგი/ოპერაციები.

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

MVP (3-5 კვირა):

1. ACID ცხრილი time-travel- ით (Delta/Iceberg/Hudi) და ძირითადი განვადებით.

2. SCD II ძირითადი გაზომვებისთვის (users/games/providers).

3. კრიტიკული აგრეგატების ყოველდღიური snapshots (GGR Daily).

4. DQ-როგორც კოდი (uniqueness/in _ set/temporal) + ხაზის გრაფიკი.

ეტაპი 2 (5-10 კვირა):
  • Bitemporal ფაქტები, as-of API/SQL შაბლონები, runbooks backfill/reprocessing.
  • FX/კალენდარი/DST გამდიდრება, OLTP-DWH/პროვაიდერები.
  • ცივი სცენის არქივი, WORM საანგარიშო პაკეტებისთვის, Legal Hold.
ეტაპი 3 (10-16 კვირა):
  • „replay & what-if“ სრული ავტომატიზაცია, მეტრული და რეგრესიული ალერტების შედარება.
  • ისტორიული ფიჩები და დრიფტის კონტროლი ML, chargeback შენახვის ღირებულებით.
  • დოკუმენტაცია „as-of“ მეტრიკა და რეპროდუქციული მოხსენებები.

17) ჩეკის სია გაყიდვამდე

  • ცხრილები მხარს უჭერს დროის მოგზაურობას; შეთანხმებულია VACUUM/RETENTION პოლიტიკოსები.
  • SCD II ხორციელდება კრიტიკული გაზომვებისთვის; join's ტესტირება.
  • D/M- ზე საკვანძო ერთეულების სურათები ხელმისაწვდომია და გადამოწმებულია კრიკეტებით.
  • DQ წესები აქტიურია; ხაზს უსვამს შესასვლელი/გასასვლელი და ლოგიკის ვერსიები.
  • DSAR/RTBF/Legal Hold ტესტირება ხდება ისტორიულ ფენებზე.
  • ცივი სცენის საარქივო და რესტავრაცია დოკუმენტირებულია და გადამოწმებულია.
  • შენახვის ღირებულება კონტროლდება (cost/GB, წილი cold, SLA აღდგენა).

18) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

დროის აშკარა მოდელის არარსებობა: დაამატეთ ღონისძიება/სამუშაო/ვალიდაცია.
FX „რეტროაქტიულია“: ყოველთვის არის კურსი მოვლენის დროს, შეინახეთ 'fx _ source'.
არარეგულარული join's ერთად SCD: გამოიყენეთ ინტერვალის ინტერვალი და არა 'is _ current'.
მუტაციის ოქროს ფანჯრები: საანგარიშო გასასვლელი უნდა იყოს უცვლელი (ან ვერსიით).
ხაზის/DQ- ის გარეშე: არ არსებობს მტკიცებულება და საკონტროლო წერტილები - შემოიტანეთ ისინი პირველივე დღიდან.
უკონტროლო ღირებულება: გამორთეთ ცხელი მხარეები, ვაკუუმში, გადაიტანეთ ცივი.

19) გლოსარიუმი

As-of Query - მონაცემთა მოთხოვნა „როგორ გამოიყურებოდნენ T დროს“.
Bitemporal არის ღონისძიების და დროის ერთდროული დაფიქსირება.
Snapshot არის სტატუსის/შეკრების მატერიალური სურათი პერიოდის ბოლოს.
Time-travel - ცხრილების ისტორიული ვერსიების კითხვა.
WORM - უცვლელი შენახვა.

20) შედეგი

ისტორიულ მონაცემებთან მუშაობა არ არის მხოლოდ „გრძელი შენახვა“, არამედ დროის დისციპლინა: აშკარა ღონისძიების/პროფესიის/bitemporal, SCD და snapshots, reproducible as-of მოთხოვნები, მკაცრი კრეფა და შესაბამისობის კონტროლი, მონიტორინგი და ეკონომიკური შენახვის არქიტექტურა. ამ ხელმძღვანელობის შემდეგ, თქვენ მიიღებთ საიმედო ისტორიულ საფუძველს ანგარიშგების, ანალიტიკისა და ML- სთვის, რომელიც მდგრადია აუდიტის და ბიზნეს ლოგიკის ცვლილებების მიმართ.

Contact

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

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

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

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

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

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