Data Lake și DWH pentru cazinouri: scheme, descărcări SLA

Articol complet

💡 18+. Materiale tehnice pentru platforme/operatori, studiouri și echipe analitice. Nu este un apel pentru a juca. Prin platformă înțelegem PAM/portofel/casier/bonusuri/RG, de către furnizori - RGS/live/jackpot/integrări de plată.

1) De ce Data Lake Casino și DWH

Raportare și conformitate: încărcări de reglementare (GGR/NGR, KYC/AML, RG), audit de bani.

Produs/marketing: LTV/retenție, segmentare, A/B, recomandări.

Operațiuni: monitorizarea furnizorilor, PSP, SLA jocuri live și case de marcat.

Soluții de date: storefronturi rapide (DWH) pe lângă stocarea ieftină pe termen lung (Lake).

Linia de fund: Lacul stochează straturi brute și curățate, DWH oferă interogări rapide și modele gestionate.

2) Arhitectura de referință (lakehouse)


Surse (OLTP, Kafka, Webhooks, CDC)
│
├─Bronze (crud, numai pentru adăugare; Parchet/Delta/Iceberg)
│ ingestion_time, source_metadata, nici o schemă de modificări în loc
├─Silver (curățate, conforme; dedup, PII mascare, SCD2)
│ chei de afaceri, constrângeri, controale de calitate
└─Gold (marts; stea/fulg de zăpadă; tabele cuburi, agregate)
Motoare └─DWH/Query (fulg de zăpadă/BigQuery/Trino/Spark SQL)

Форматы: Lacul Delta/Apache Iceberg/Hudi (ACID в lac, călătorie în timp, MERGE).

Fișiere: Parchet + ZSTD/Snappy, ~ țintă 128-512 MB; compactare „fișier mic”.

Catalog: Stup/Unitate/Catalog Iceberg; galeti de bronz/argint/aur 'pe fiecare regiune/chirias.

3) Scheme de domenii (conceptual)

3. 1 Portofel/contabilitate

'wallet _ entry': 'entry _ id',' account _ id', 'direction (debit	credit) ',' sound _ minor ',' valute ',' reason ',' reference _ id', 'happened _ at', 'region', 'tenant _ id',' trace _ id', 'idempotency _ key'.
Invariant: suma contului = soldul (prin instantaneu + jurnal de schimbare).

3. 2 Pariuri/decontare (RGS/live)

'bet': 'bet _ id',' round _ id', 'player _ id',' game _ id', 'miză _ minor', 'valută', 'plasat _ la', 'marcă/regiune', 'provider _ id',' in _ bonus '.

'settlement': 'settlement _ id',' bet _ id', 'round _ id',' win _ minor ',' settled _ at ',' jackpot _ hit ',' bonus _ state '.

3. 3 Plăți (cash desk/PSP/crypto)

'payment _ intent': 'intent _ id',' player _ id', 'metodă', 'status', 'cuantum', 'valută', 'psp', 'creat _ at'.

'capture/rambursare/chargeback': tabele separate cu trimiteri la 'intent _ id',' psp _ ref ', coduri de motive.

Крипто: 'txid', 'network', 'confirmări', 'finalized _ at'.

3. 4 Bonusuri/vager/jackpot-uri

'bonus _ grant', 'bonus _ progress (wager)', 'jackpot _ contribution', 'jackpot _ payout'.

3. 5 Referințe și măsurători

'dim _ player' (pseudo-ID, geo, canale, stări RG - fără PII în analiză), 'dim _ game', 'dim _ provider', 'dim _ psp', 'dim _ brand', 'dim _ region', dimensiuni calendar.

Chei și compatibilitate: în modelele Silver/Gold - chei de afaceri stabile ('bet _ id',' round _ id', 'payout _ id',' intent _ id') și semantica evenimentelor „idempotente”.

4) Descărcați fluxuri: Streaming + Microbatch

Streaming (Kafka/Pulsar → Bronze): evenimente OLTP și webhook, outbox/CDC, cel puțin o dată garantează cu eliminarea duplicatelor în Silver.

CDC (Debezium/replication log): schimbarea tabelelor OLTP (portofel/plăți) → bronz.

Microbatches: PSP/bank/custom reports (SFTP/API) → Bronze Raw Files → normalizare.

MERGE în argint: dedup prin 'idempotency _ key/event _ id', eliminarea latecomerilor (' filigran '), SCD2 pe măsurători.

5) descărcări SLA și fereastră târzie (filigrane)

5. 1 SLA-uri tipice (repere)

Evenimente portofel/registru: Bronz ≤ 1-2 min, Argint ≤ 5-10 min, Marte aur ≤ 15 min

Pariuri/așezări: Bronz ≤ 1-2 min, Argint ≤ 10 min, Aur ≤ 30 min

Plăți (cârlige PSP): bronz ≤ 5 min, argint ≤ 15 min, aur ≤ 30-60 min.

Finalitate cripto: dependentă de rețea; afișarea cazurilor cu confirmări lag N.

Rapoarte zilnice PSP/bancă: T + 1 până la ora locală 09:00 a regiunii.

5. 2 Ferestre târzii

Filigran după ora evenimentului ('happened _ at') + toleranțe:

portofel/pariuri: 24-48 ore, plăți/PSP: 72 ore (există cărți web retro), cripto: până la 24 ore pentru reorguri rare.
Evenimente ulterioare de reprocesare: recalcularea treptată a ferestrelor Gold (MERGE), jurnal de corecție.

5. 3 Comunicare SLA

Catalogul de date conține atribute SLA: „prospețime _ target”, „prospețime _ status”, „așteptat _ lag _ p95”, „filigran”.

Tablouri de bord de „prospețime” cu alerte în încălcare.

6) Calitatea datelor (DQ) și contractele

Contracte de date pentru fiecare subiect: scheme Avro/JSON, semver, câmpuri obligatorii, invarianți de afaceri (de exemplu, „win _ minor ≥ 0”, „valută ∈ ISO-4217”).

Verificarea DQ-ului de argint: unicitatea cheie, integritatea referențială, verificarea echilibrului (reconcilierea portofelului), valabilitatea codurilor/motivelor PSP, intervalele de date.

Severitate: 'EROARE' (blocare), 'AVERTIZARE' (marcare), 'INFO'.

Monitorizare:% încălcări, motive de top, bilete automate.

Eșantionare și reluare: Depozitați bronz brut pentru reciclare.

7) PII, rezidență și siguranță

Vitrina PII este separată de analiză: în Silver/Gold - pseudonim, mascare/hashes, tokenizare.

Rezidenta de date: EU/UK/BR, etc. - galeti/cataloage separate fizic; nici o lectură transregională fără consimțământ și proxy-uri.

Доступ: RBAC/ABAC (Lake/DWH), по de securitate la nivel de rând „chiriaș/marcă/regiune”.

Criptare: în repaus (KMS) și în tranzit, pe regiuni/chei de marcă, audit WORM de acces și modificări de politică.

Dreptul de a fi uitat: un mecanism de localizare a datelor de joc fără ștergerea înregistrărilor financiare (de-identificare).

8) Modelarea ferestrelor de aur (stea)

8. 1 Tabele reale

'fact _ bet', 'fact _ wallet _ entries', 'fact _ payments',' fact _ bonus _ wager ',' fact _ jackpot '.

8. 2 Măsurători

'dim _ date/time', 'dim _ player' (pseudonim), 'dim _ game', 'dim _ provider', 'dim _ psp', 'dim _ brand', 'dim _ region', 'dim _ valute'.

8. 3 Valori și calcule

GGR/NGR, hold/frequency, RTP (by game/provider/region), conversie depozit, decontare lag, PSP rata de succes, cost-per-succes, FX-PnL, contribuții jackpot/plăți.

9) Performanță și cost

Partiționare: prin 'appeared _ date' + 'regiune/chiriaș', uneori 'game _ id' for Gold agregates.

Clustering/Z-Order: by 'player _ id',' game _ id', 'psp', 'valută'.

Compresie și vid: planificat „OPTIMIZA/COMPACT”, eliminarea versiunilor „agățat” (luând în considerare retențiile legale).

Cache: rezultat-cache/depozit cache, vizualizări materializate pentru panouri fierbinți.

Indexuri în DWH: cluster/segment (clustere fulgi de zăpadă, partiție BigQuery + cluster).

Cost: bronz rece în depozitarea obiectelor, unități fierbinți de aur/martie în DWH; auto-parcare/auto-scară.

10) Linage, cataloage și documentație

Catalog de date (OpenMetadata/Amundsen/Collibra): descrierea tabelului, proprietar, câmpuri SLA, PII, politici de acces.

Lineage: de la sursă (eveniment/CDC) la prezentare și raport; vizibilitatea constrângerilor pentru schimbări sigure.

Scheme Changelog: semver și jurnal de depreciați; teste de compatibilitate în conducte CI.

11) Reconciliere

Zilnic:

'wallet _ entry' ↔ total balances (acumulare ≡ instantaneu), payments: PSP/bank reports ↔ 'fact _ payments', crypto:' txid/network '↔' fact _ payments'.
Категории: 'meci', 'sincronizare', 'lipsă _ sursă', 'lipsă _ platformă', 'sumă _ nepotrivire'.
Alerte: proporția de „neconcordanță”> prag; îmbătrânire remarcabilă> Zilele N.

12) Tabele SLA instanță (exemplu)

Domeniu	Bronz (ingerare)	Argint (curățare)	Aur (martie)	Evenimente târzii (filigran)
Portofel	≤2 min	≤10 min	≤15 min	48 h
Pariuri/Decontări	≤2 min	≤10 min	≤30 min	48 h
Plăți (PSP)	≤5 min	≤15 min	≤60 min	72 ore
Crypto	realtime→finalnost	≤15 min	≤60 min	24 h
Rapoarte (T + 1)	06:00–08:00	≤09:00	≤10:00	7 d

13) Conducte: ceea ce colectăm de la

Ingestie: Kafka Connect/Debezium, servicii de ingestie cloud, pullere SFTP.

ETL/ELT: Spark/DBT/Trino/Beam/Flink (streaming Silver), Airflow/Argo pentru orchestrare.

Calitate: Așteptări mari/teste Dequ/dbt.

Monitorizare: OpenTelemetry + Lake/DWH (întârziere de prospețime, latență a locului de muncă, cost).

Accidente și repetiții: reprelucrare din bronz, dedup cu chei, conducte versionate.

14) Liste de verificare

Arhitectură și securitate

Formatul Lakehouse (Delta/Iceberg/Hudi) cu ACID și călătoria în timp.
Split 'bronz/silver/gold', outbox/CDC ca surse principale.
Izolarea PII, tokenizarea, RLS prin 'chiriaș/marcă/regiune'.
Găleată/rezidență la nivel de director, chei/secrete pe regiune.
Auditul WORM al schemei/politicii/regulii de acces se modifică.

Calitate și SLA

Contracte de date și scheme semver; teste de compatibilitate.
Filigrane și reprocese, vitrine incrementale MERGE.
Tablouri de bord pentru prospețime și alerte SLA; proprietar pentru fiecare masă.
Reconcilierea prin portofel/plăți/cripto.

Performanță și cost

Partiționarea și gruparea; compactare „fișier mic”.
Vitrine materializate pentru rapoarte cheie.
Autoscale/Auto-Parcare, Politica de retenție și Arhive.

15) Steaguri roșii (anti-modele)

BI și rapoartele de reglementare au lovit direct OLTP.

Bronz „rescrie” și pierde date brute.

Fără filigrane, evenimentele târzii sunt „trunchiate”.

Nu există duplicate pe 'idempotency _ key '/' event _ id' → duplicate în Gold.

PII și banii din diferite regiuni sunt păstrate împreună fără RLS și rezidență.

Schemele se schimbă „în liniște” (fără semver/contracte), spargând ferestrele magazinelor.

Milioane de fișiere mici de parchet necomprimate → cereri scumpe.

Nu există tablouri de bord SLA/prospețime; „surprize” în raportarea trimestrială.

16) Concluzie

Data Lake + DWH în iGaming nu este doar o stocare, ci un ecosistem controlat: scheme și contracte standardizate, ACID-lakehouse, prospețime SLA clară și ferestre târzii, calitate și liniaritate, securitate PII și rezidență. Adăugați economii de reconciliere și partiționare/compactare - și aveți o bază pentru raportare, soluții de produse și scalarea afacerii fără migrații nocturne și manual Excel.