Data Lake და DWH კაზინოებისთვის: სქემები, SLA ჩატვირთვა

სტატიის სრული ტექსტი

💡 18+. ტექნიკური მასალა პლატფორმების/ოპერატორებისთვის, სტუდიებისა და ანალიტიკური გუნდებისთვის. არა თამაშის მოწოდება. პლატფორმა გვესმის PAM/საფულე/სალარო/პრემია/RG, პროვაიდერების ქვეშ - RGS/live/jecpots/გადახდის ინტეგრაცია.

1) რატომ არის Data Lake და DWH კაზინოები

ანგარიში და შესაბამისობა: მარეგულირებელი გადმოტვირთვის (GGR/NGR, KYC/AML, RG), ფულის აუდიტი.

პროდუქტი/მარკეტინგი: LTV/retention, სეგმენტი, A/B, რეკომენდაციები.

ოპერაციები: პროვაიდერების, PSP, SLA ცოცხალი თამაშების და სალაროების მონიტორინგი.

მონაცემების გადაწყვეტილებები: სწრაფი ფანჯრები (DWH) იაფი გრძელვადიანი შენახვის თავზე (ტბა).

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

2) რეფერენდუმი-არქიტექტურა (lakehouse)


Sources (OLTP, Kafka, Webhooks, CDC)
│
├─Bronze (raw, append-only; Parquet/Delta/Iceberg)
│   ingestion_time, source_metadata, no schema changes in place
├─Silver (cleaned, conformed; dedup, PII masking, SCD2)
│   business keys, constraints, quality checks
└─Gold (marts; star/snowflake; cube tables, aggregates)
└─DWH/Query Engines (Snowflake/BigQuery/Trino/Spark SQL)

Форматы: Delta Lake / Apache Iceberg / Hudi (ACID в lake, time travel, MERGE).

ფაილები: Parquet + ZSTD/Snappy, target 128-512 MB; „მცირე ფაილების“ წილი.

კატალოგი: Hive/Unity/Iceberg Catalog; ზონები 'bronze/silver/gold' ბაზრებზე per region/tenant.

3) დომენის სქემები (კონცეპტუალურად)

3. 1 საფულე/ბუღალტრული აღრიცხვა

`wallet_entry`: `entry_id`, `account_id`, `direction (debit	credit)`, `amount_minor`, `currency`, `reason`, `reference_id`, `occurred_at`, `region`, `tenant_id`, `trace_id`, `idempotency_key`.
ინვარიანტი: თანხა = ბალანსი (snapshot + change log მეშვეობით).

3. 2 განაკვეთები/ნაკადი (RGS/live)

`bet`: `bet_id`, `round_id`, `player_id`, `game_id`, `stake_minor`, `currency`, `placed_at`, `brand/region`, `provider_id`, `in_bonus`.

`settlement`: `settlement_id`, `bet_id`, `round_id`, `win_minor`, `settled_at`, `jackpot_hit`, `bonus_state`.

3. 3 გადახდა (სალარო/PSP/კრიპტო)

`payment_intent`: `intent_id`, `player_id`, `method`, `status`, `amount`, `currency`, `psp`, `created_at`.

'capture/refund/chargeback': ცალკეული ცხრილი 'intent _ id "," psp _ ref ", მიზეზების კოდებით.

Крипто: `txid`, `network`, `confirmations`, `finalized_at`.

3. 4 ბონუსები/wager/jecpots

`bonus_grant`, `bonus_progress (wager)`, `jackpot_contribution`, `jackpot_payout`.

3. 5 სახელმძღვანელო და გაზომვები

'dim _ player' (ფსევდო-ID, გეო, არხები, RG სტატუსები - ანალიტიკის გარეშე PII), 'dim _ game', 'dim _ provider', 'dim _ psp', 'dim _ brand', 'dim _ region', კალენდარული გაზომები.

გასაღებები და თავსებადობა: Silver/Gold მოდელებში - სტაბილური ბიზნეს გასაღებები ('bet _ id', 'round _ id', 'payout _ id', 'intent _ id') და „idempotent“ მოვლენების სემანტიკა.

4) დატვირთვის ნაკადები: ნაკადი + მიკრობატი

Striming (Kafka/Pulsar-Bronze): OLTP და ვებჰუკების მოვლენები, outbox/CDC, გარანტიები „ყოველ ჯერზე ერთხელ მაინც“ Silver- ში.

CDC (Debezium/რეპლიკაციის ჟურნალი): OLTP ცხრილების ცვლილება (wallet/payments) - Bronze.

მიკრობატები: PSP/ბანკების/კასტოდების (SFTP/API) მოხსენებები, Bronze Raw Files - ნორმალიზაცია.

MERGE Silver- ში: ბაბუა 'idempotency _ key/event _ id', დაგვიანებული ('watermark') აღმოფხვრა, SCD2 გაზომვებზე.

5) SLA ჩატვირთვა და დაგვიანებული ფანჯარა (watermarks)

5. 1 ტიპიური SLA (სახელმძღვანელო)

Wallet/ledger events: Bronze - 1-2 წთ, Silver - 5-10 წთ, Gold marts - 15 წთ.

Bets/settlements: Bronze - 1-2 წთ, Silver - 10 წთ, Gold - 30 წთ.

Payments (PSP webhooks): Bronze - 5 წთ, Silver - 15 წთ, Gold - 30-60 წთ.

კრიპტო საბოლოო: ეს დამოკიდებულია ქსელზე; ფანჯრები lag N მტკიცებულებებით.

PSP/ბანკების ყოველდღიური მოხსენებები: T + 1 რეგიონის ადგილობრივი დროით 09:00 საათამდე.

5. 2 გვიან ფანჯრები

Watermark მოვლენის დროზე ('occurred _ at') + დაშვება:

საფულე/განაკვეთები: 24-48 საათი, გადახდა/PSP: 72 საათი (არსებობს რეტრო-ვებჰუკი), კრიპტო: 24 საათამდე იშვიათი რეორგისთვის.
Reprocess- ის გვიანდელი მოვლენები: Gold- ის ფანჯრის გადაანგარიშება დროულად (MERGE), კორექტირების ჟურნალი.

5. 3 SLA კომუნიკაცია

მონაცემთა კატალოგში მოცემულია SLA ატრიბუტები: 'freshness _ target', 'freshness _ status', 'expected _ lag _ p95', 'watermark'.

დაშბორდები „სიახლის“ ალერტებით დარღვევის შემთხვევაში.

6) მონაცემთა ხარისხი (DQ) და კონტრაქტები

მონაცემთა კონტრაქტები თითოეული თემისთვის: Avro/JSON სქემები, სემვერი, სავალდებულო ველები, ბიზნეს ინვარიანტები (მაგალითად, 'win _ minor' 0 ',' currence 'ISO-4217').

DQ Silver შემოწმება: კლავიშების უნიკალურობა, რეფერენდუმის მთლიანობა, ბალანსის შემოწმება (საფულის შერწყმა), PSP/მიზეზების კოდების შესაბამისობა, თარიღების დიაპაზონი.

Severity: 'ERROR' (ბლოკირება), 'WARN' (მარკირება), 'INFO'.

მონიტორინგი: დარღვევების%, ძირითადი მიზეზები, ავტომატური თიკეტები.

Sampling & replay: შეინახეთ ნედლეული Bronze ხელახლა დამუშავებისთვის.

7) PII, რეზიდენცია და უსაფრთხოება

PII ვიტრინა განცალკევებულია ანალიტიკისგან: Silver/Gold- ში - ფსევდონიმი, შენიღბვა/ჰაში, ტოკენიზაცია.

მონაცემთა აღდგენა: EU/UK/BR და სხვ. - ფიზიკურად ინდივიდუალური ბაკეტები/კატალოგები; არ არის ჯვარედინი რეგიონალური კითხვა თანხმობისა და პროქსის გარეშე.

Доступ: RBAC/ABAC (Lake/DWH), row-level security по `tenant/brand/region`.

დაშიფვრა: at-rest (KMS) და in-transit, გასაღებები per region/brand, WORM წვდომისა და პოლიტიკის ცვლილებების აუდიტი.

დავიწყების უფლება: თამაშის მონაცემების ლოკალიზაციის მექანიზმი ფინანსური ჩანაწერების წაშლის გარეშე (დე იდენტიფიკაცია).

8) ოქროს ფანჯრის მოდელირება (ვარსკვლავი)

8. 1 ფაქტი ცხრილი

'fact _ bets' (ფსონი და სეგმენტი სტრიქონზე/ან ორ ცხრილზე), 'fact _ wallet _ entries', 'fact _ payments' (დეპოზიტები/ქეშაუტები/გადახედვა), 'fact _ bonus _ wager', ',' fachacachact _ jacacacacacacacacacacacacacacacacacacacacacacacate '.

8. 2 გაზომვები

`dim_date/time`, `dim_player` (pseudonymous), `dim_game`, `dim_provider`, `dim_psp`, `dim_brand`, `dim_region`, `dim_currency`.

8. 3 მეტრიკა და გამოთვლები

GGR/NGR, გამართვა/სიხშირე, RTP (თამაშში/პროვაიდერის/რეგიონის მიხედვით), დეპოზიტის კონვერტაცია, settle lag, success-rate PSP, cost-per-success, FX-PnL L, jaCaConTCoNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOAAOpayouts.

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

განაწილება: 'occurred _ date' + 'region/tenant', ზოგჯერ 'game _ id' ოქროს ერთეულებისთვის.

კლასტერიზაცია/Z-Order: 'player _ id', 'game _ id', 'psp', 'currency'.

კომპაქტური და ვაკუუმი: დაგეგმილი 'OPTIMIZE/COMPACT', „ჩამოკიდებული“ ვერსიების წაშლა (იურიდიული ჭრილობების გათვალისწინებით).

ქეში: result-cache/warehouse cache, materialized views ცხელი პანელებისთვის.

ინდექსები DWH- ში: კლასტერული/სეგმენტი (Snowflake clustering keys, BigQuery partition + cluster).

ღირებულება: ცივი Bronze ობიექტის საცავში, ცხელი ოქროს/მარტის აგრეგატები - DWH- ში; ავტოსადგომი/მანქანის სკეიტი.

10) ხაზოვანი, კატალოგები და დოკუმენტაცია

მონაცემთა კატალოგი (OpenMetadata/Amundsen/Collibra): ცხრილების აღწერა, მფლობელი, SLA, PII ველები, წვდომის პოლიტიკა.

ხაზოვანი: წყაროდან (მოვლენა/CDC) ვიტრინამდე და მოხსენებით; დამოკიდებულების ხილვადობა უსაფრთხო ცვლილებებისთვის.

Changelog სქემები: სემვერი და დეპრესიის ჟურნალი; თავსებადობის ტესტები CI- ში.

11) რეკონსტრუქცია (მონაცემთა შერიგება)

ყოველდღიურად:

'wallet _ entry' - საბოლოო ნაშთები (დაგროვება snapshot), გადახდები: PSP/Banks- ის ანგარიშები, 'fact _ payments', კრიპტო: 'txid/network', 'fact _ payments'.
Категории: `match`, `timing`, `missing_source`, `missing_platform`, `amount_mismatch`.
ალერტები: წილი 'mismatch'> ბარიერი; დაუჯერებელი აჟიოტაჟი> N დღე.

12) ნიმუშის SLA ცხრილი (მაგალითი)

დომენი	Bronze (ingest)	Silver (გაწმენდა)	ოქროს (მარტი)	გვიანდელი მოვლენები (watermark)
Wallet	2 წუთზე მეტი ხნის წინ	10 წუთზე მეტი ხნით ადრე	15 წუთზე მეტი ხნის წინ	48 საათი
Bets/Settlements	2 წუთზე მეტი ხნის წინ	10 წუთზე მეტი ხნით ადრე	30 წუთი	48 საათი
Payments (PSP)	5 წუთზე მეტი ხნის წინ	15 წუთზე მეტი ხნის წინ	60 წუთი-ზე მეტი	72 საათი
Crypto	realtime საბოლოო	15 წუთზე მეტი ხნის წინ	60 წუთი-ზე მეტი	24 საათი
Reports (T+1)	06:00–08:00	≤09:00	≤10:00	7 დ

13) Paiplines: საიდანაც ვიღებთ

Ingestion: Kafka Connect/Debezium, ღრუბლოვანი ინვესტიციის სერვისები, SFTP pullers.

ETL/ELT: Spark/DBT/Trino/Beam/Flink (ნაკადი Silver), Airflow/Argo ორკესტრისთვის.

ხარისხი: დიდი გამოცდილება/Deen/dbt tests.

მონიტორინგი: OpenTelemetry + Lake/DWH (freshness delay, job latency, cost).

უბედური შემთხვევები და გამეორება: Bronze reprocess, Deadop კლავიშები, ვერსირებული რულონები.

14) ჩეკის ფურცლები

არქიტექტურა და უსაფრთხოება

Lakehouse ფორმატი (Delta/Iceberg/Hudi) ACID და time travel.
'bronze/silver/gold', outbox/CDC დაყოფა მთავარ წყაროებად.
PII იზოლაცია, ტოქსიკაცია, RLS 'tenant/brand/region'.
რეზიდენცია ბუკეტების/კატალოგების, გასაღებების/საიდუმლოებების შესახებ.
WORM აუდიტი სქემების/პოლიტიკის/დაშვების წესების ცვლილებების შესახებ.

ხარისხი და SLA

Data Contracts და semver სქემები; თავსებადობის ტესტები.
Watermarks და reprocess, witrings არის სავარაუდო MERGE.
დაშბორდები ახალი და SLA ალერტები; owner თითოეულ ცხრილში.
რეკონსტრუქცია საფულეზე/გადახდაზე/კრიპტოში.

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

განაწილება და კლასტერიზაცია; „მცირე ფაილების“ წილი.
მატერიალიზებული ფანჯრები ძირითადი მოხსენებების ქვეშ.
Autoskale/autoparking, retenschen პოლიტიკა და არქივები.

15) წითელი დროშები (ანტი-ნიმუშები)

BI და მარეგულირებელი ცნობები პირდაპირ ურტყამს OLTP- ს.

Bronze „გადაწერილია“ და კარგავს ნედლეულ მონაცემებს.

არ არსებობს watermarks, გვიანდელი მოვლენები „იშლება“.

Idempotency _ key '/' event _ id 'ბაბუის ნაკლებობა გოლდში.

PII და სხვადასხვა რეგიონის ფული ერთად ინახება RLS და რეზიდენციის გარეშე.

სქემები იცვლება „მშვიდად“ (სემვერის/კონტრაქტების გარეშე), გატეხილი ფანჯრები.

მილიონობით მცირე ზომის Parquet ფაილები კომუნალური მომსახურების გარეშე ძვირადღირებული მოთხოვნაა.

არა SLA/დაშბორდები; „სიურპრიზები“ კვარტალურ ანგარიშგებაში.

16) დასკვნა

მონაცემთა Lake + DWH iGaming- ში არ არის მხოლოდ საცავი, არამედ კონტროლირებადი ეკოსისტემა: სტანდარტიზებული სქემები და კონტრაქტები, ACID-lakehouse, მკაფიო SLA ახალი და დაგვიანებული ფანჯრები, ხარისხი და ხაზი, PII უსაფრთხოება და რეზიდენცია. დაამატეთ ჩანაწერები და დაზოგეთ განაწილება/კომპაქტები - და თქვენ გექნებათ საფუძველი ანგარიშგების, სასურსათო გადაწყვეტილებების და ბიზნესის მასშტაბების შესახებ ღამის მიგრაციისა და „სახელმძღვანელო Excel“ გარეშე.