Casinolar için Data Lake ve DWH: şemalar, SLA indirmeleri

Tam makale

💡 18+. Platformlar/operatörler, stüdyolar ve analitik ekipler için teknik malzeme. Oynamak için bir çağrı değil. Platform olarak, PAM/cüzdan/kasiyer/bonuslar/RG, sağlayıcılar tarafından - RGS/canlı/ikramiyeler/ödeme entegrasyonları anlamına gelir.

1) Neden Data Lake Casino ve DWH

Raporlama ve uyumluluk: düzenleyici yüklemeler (GGR/NGR, KYC/AML, RG), para denetimi.

Ürün/pazarlama: LTV/tutma, segmentasyon, A/B, öneriler.

Operasyonlar: Sağlayıcıların izlenmesi, PSP, SLA canlı oyunlar ve yazarkasalar.

Veri çözümleri: Ucuz uzun süreli depolamanın (Lake) yanı sıra hızlı vitrinler (DWH).

Alt satır: Lake ham ve temizlenmiş katmanları saklar, DWH hızlı sorgular ve yönetilen modeller verir.

2) Referans mimarisi (lakehouse)


Kaynaklar (OLTP, Kafka, Webhooks, CDC)
│
├─Bronze (ham, yalnızca ekle; Parke/Delta/Buzdağı)
│ ingestion_time, source_metadata, yerinde şema değişikliği yok
├─Silver (temizlenmiş, uyumlu; Dedup, PII maskeleme, SCD2)
│ iş anahtarları, kısıtlamalar, kalite kontrolleri
└─Gold (mart; yıldız/kar tanesi; Küp tablolar, kümeler)
└─DWH/Query Motorları (Snowflake/BigQuery/Trino/Spark SQL)

Форматы: Delta Gölü/Apache Iceberg/Hudi (ACID в gölü, zaman yolculuğu, MERGE).

Dosyalar: Parke + ZSTD/Snappy, hedef ~ 128-512 MB; "küçük dosya" sıkıştırma.

Katalog: Kovan/Birlik/Buzdağı Kataloğu; Bölge/kiracı başına kovalarda 'bronz/gümüş/altın' bölgeleri.

3) Alan şemaları (kavramsal olarak)

3. 1 Cüzdan/muhasebe

'wallet _ entry': 'entry _ id', 'account _ id', 'direction (debit)	credit) ',' amount _ minor ',' currency ',' reason ',' reference _ id ',' occured _ at ',' region ',' tenant _ id ',' trace _ id ',' idempotency _ key '.
Değişmeyen: hesap tutarı = bakiye (anlık görüntü + değişim günlüğü aracılığıyla).

3. 2 Bahisler/Ödeme (RGS/canlı)

'bet': 'bet _ id', 'round _ id', 'player _ id', 'game _ id', 'stake _ minor', 'currency', 'placed _ at', 'brand/region', 'provider _ id','in _ bonus '.

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

3. 3 Ödemeler (nakit masası/PSP/kripto)

'payment _ intent': 'intent _ id', 'player _ id', 'method', 'status', 'amount', 'currency', 'psp', 'created _ at'.

'yakalama/geri ödeme/ters ibraz': 'intent _ id', 'psp _ ref', sebep kodlarına referanslar içeren ayrı tablolar.

Крипто: 'txid', 'network', 'confirmations', 'finaled _ at'.

3. 4 Bonuslar/vager/jackpotlar

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

3. 5 Referanslar ve ölçümler

'dim _ player' (pseudo-ID, geo, kanallar, RG durumları - analitikte PII olmadan),'dim _ game ',' dim _ provider ',' dim _ psp ',' dim _ brand ',' dim _ region ', takvim boyutları.

Anahtarlar ve uyumluluk: Gümüş/Altın modellerinde - istikrarlı iş anahtarları ('bet _ id', 'round _ id', 'payout _ id', 'intent _ id') ve 'idempotent' olaylarının anlambilimi.

4) İndirme Akışları: Akış + Microbatch

Akış (Kafka/Pulsar - Bronz): OLTP ve webhook etkinlikleri, giden kutusu/CDC, en az bir kez Silver'da veri tekilleştirme ile garanti eder.

CDC (Debezium/replication log): OLTP tablolarını değiştirme (cüzdan/ödemeler)

Mikrobatches: PSP/bank/custom reports (SFTP/API) - Bronze Raw Files - normalization.

Gümüşte MERGE: 'idempotency _ key/event _ id'ile dedup, geç gelenlerin ortadan kaldırılması (' filigran '), ölçümlere SCD2.

5) SLA indirmeleri ve geç pencere (filigranlar)

5. 1 Tipik SLA'lar (yer işaretleri)

Cüzdan/defter olayları: Bronz ≤ 1-2 dk., Gümüş ≤ 5-10 dk., Altın mart ≤ 15 dk

Bahisler/yerleşimler: Bronz ≤ 1-2 dk, Gümüş ≤ 10 dk, Altın ≤ 30 dk

Ödemeler (PSP web kitapları): Bronz ≤ 5 dakika, Gümüş ≤ 15 dakika, Altın ≤ 30-60 dakika.

Kripto kesinliği: ağa bağlı; Gecikmeli N onaylı vitrinler.

Günlük PSP/banka raporları: Bölgenin yerel saatiyle 09:00'a kadar T + 1.

5. 2 Geç pencereler

Olay zamanına göre filigran ('occured _ at') + toleranslar:

Cüzdan/bahisler: 24-48 saat, ödemeler/PSP: 72 saat (retro webhook'lar var), kripto: nadir reorg'lar için 24 saate kadar.
Daha sonraki yeniden işleme olayları: Altın pencerelerin aşamalı olarak yeniden hesaplanması (MERGE), düzeltme günlüğü.

5. 3 SLA İletişimi

Veri kataloğu SLA öznitelikleri içerir: 'tazelik _ hedef', 'tazelik _ durum', 'beklenen _ lag _ p95', 'filigran'.

Ihlal uyarıları ile "tazelik" panoları.

6) Veri kalitesi (DQ) ve sözleşmeler

Her konu için Veri Sözleşmeleri: Avro/JSON şemaları, semver, gerekli alanlar, iş değişmezleri (örneğin, 'win _ minor ≥ 0', 'currency ∈ ISO-4217').

Gümüş DQ kontrolleri: anahtar benzersizliği, referans bütünlüğü, denge kontrolü (cüzdan mutabakatı), PSP kodlarının geçerliliği/nedenleri, tarih aralıkları.

Önem: 'HATA' (engelleme), 'UYARI' (işaretleme), 'BİLGİ'.

İzleme: % ihlaller, en önemli nedenler, otomatik biletler.

Örnekleme ve tekrar oynatma: Geri dönüşüm için ham Bronzu saklayın.

7) PII, ikamet ve güvenlik

PII-vitrin analitikten ayrılır: Gümüş/Altın - takma ad, maskeleme/karma, tokenizasyon.

Veri ikametgahı: AB/İngiltere/BR, vb. - fiziksel olarak ayrı kovalar/kataloglar; İzin ve vekiller olmadan bölgeler arası okuma yok.

Доступ: RBAC/ABAC (Lake/DWH), satır düzeyinde güvenlik по 'kiracı/marka/bölge'.

Şifreleme: at-rest (KMS) ve transit, bölge/marka anahtarları başına, erişim ve ilke değişikliklerinin WORM denetimi.

Unutulma hakkı: Finansal kayıtları silmeden oyun verilerini yerelleştirme mekanizması (de-identification).

8) Altın Pencere Modelleme (Yıldız)

8. 1 Gerçek tablolar

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

8. 2 Ölçümler

'dim _ date/time','dim _ player '(takma ad),' dim _ game ',' dim _ provider ',' dim _ psp ',' dim _ brand ',' dim _ region ',' dim _ currency '.

8. 3 Metrikler ve hesaplamalar

GGR/NGR, hold/frequency, RTP (oyun/sağlayıcı/bölgeye göre), deposit conversion, settle lag, success-rate PSP, cost-per-success, FX-PnL, jackpot katkıları/ödemeleri.

9) Performans ve maliyet

Bölümleme: 'incidented _ date' + 'region/tenant', bazen Gold kümeleri için 'game _ id'.

Kümeleme/Z-Sırası: 'player _ id', 'game _ id', 'psp', 'currency'ile.

Sıkıştırma ve vakum: planlı 'OPTIMIZE/COMPACT', "asılı" sürümlerin kaldırılması (yasal retentions dikkate alınarak).

Önbellekler: sonuç-önbellek/depo önbelleği, sıcak paneller için materyalize görünümler.

DWH'deki dizinler: küme/segment (Kar tanesi kümeleme tuşları, BigQuery bölümü + kümesi).

Maliyet: Nesne deposunda soğuk Bronz, DWH'de sıcak Altın/Mart birimleri; otomatik park/otomatik ölçek.

10) Linage, kataloglar ve belgeler

Veri Kataloğu (OpenMetadata/Amundsen/Collibra): tablo açıklaması, sahibi, SLA, PII alanları, erişim ilkeleri.

Lineage: kaynaktan (olay/CDC) vitrin ve rapor için; Güvenli değişiklikler için kısıtlamaların görünürlüğü.

Changelog şemaları: semver ve amortisman dergisi; CI boru hatlarında uyumluluk testleri.

11) Uzlaşma

Günlük:

'wallet _ entry' ↔ toplam bakiyeler (birikim ≡ anlık görüntü), ödemeler: PSP/banka raporları ↔ 'fact _ payments', kripto: 'txid/network' ↔ 'fact _ payments'.
Категории: 'match', 'timing', 'missing _ source', 'missing _ platform', 'amount _ mismatch'.
Uyarılar: 'uyumsuzluk'> eşik oranı; yaşlanma olağanüstü> N gün.

12) Örnek SLA tabloları (örnek)

Domain	Bronz (yutmak)	Gümüş (temizlik)	Altın (Mart)	Geç olaylar (filigran)
Cüzdan	≤2 dk	≤10 dk	≤15 dk	48 saat
Bahisler/Yerleşimler	≤2 dk	≤10 dk	≤30 dk	48 saat
Ödemeler (PSP)	≤5 dk	≤15 dk	≤60 dk	72 h
Kripto	gerçek zamanlı - finalnost	≤15 dk	≤60 dk	24 saat
Raporlar (T + 1)	06:00–08:00	≤09:00	≤10:00	7 d

13) Boru hatları: topladıklarımız

Yutma: Kafka Connect/Debezium, bulut yutma hizmetleri, SFTP çekiciler.

ETL/ELT: Spark/DBT/Trino/Beam/Flink (Gümüş akış), Airflow/Argo orkestrasyon için.

Kalite: Büyük Beklentiler/Dequ/dbt testleri.

İzleme: OpenTelemetry + Lake/DWH metrikleri (tazelik gecikmesi, iş gecikmesi, maliyet).

Kazalar ve tekrarlama: Bronzdan yeniden işleme, anahtarlarla dedup, sürüm boru hatları.

14) Kontrol listeleri

Mimari ve güvenlik

Lakehouse formatı (Delta/Iceberg/Hudi) ACID ve zaman yolculuğu ile.
Bölünmüş 'bronz/gümüş/altın', çıkış kutusu/CDC ana kaynaklar olarak.
PII izolasyonu, tokenizasyon, RLS tarafından 'kiracı/marka/bölge'.
Kova/dizin düzeyinde ikamet, bölge başına anahtarlar/sırlar.
WORM şema/politika/erişim kuralı değişiklikleri denetimi.

Kalite ve SLA

Veri Sözleşmeleri ve semver şemaları; Uyumluluk testleri.
Filigranlar ve yeniden işleme, artımlı MERGE vitrinleri.
Tazelik panoları ve SLA uyarıları; Her masa için sahibi.
Cüzdan/ödemeler/kripto ile uzlaşma.

Performans ve maliyet

Bölümleme ve kümeleme; "küçük dosya" sıkıştırma.
Önemli raporlar için materyalize vitrinler.
Autoscale/Otomatik Park, Saklama Politikası ve Arşivler.

15) Kırmızı bayraklar (anti-desenler)

BI ve düzenleyici raporlar doğrudan OLTP'ye çarptı.

Bronz "yeniden yazar've ham verileri kaybeder.

Filigran yok, geç olaylar "kesilmiş".

'Idempotency _ key'/' event _ id' üzerinde veri tekilleştirme yok - Gold'da kopyalar.

PII ve farklı bölgelerden gelen para, RLS ve ikamet izni olmadan bir arada tutulur.

Şemalar "sessizce" değişir (semver/sözleşmeler olmadan), vitrinleri kırar.

Milyonlarca küçük sıkıştırılmamış Parquet dosyası - pahalı istekler.

SLA/tazelik panoları yok; Üç aylık raporlamada "sürprizler".

16) Sonuç

ITaming'deki Data Lake + DWH sadece bir depolama alanı değil, kontrollü bir ekosistemdir: standartlaştırılmış şemalar ve sözleşmeler, ACID-lakehouse, açık SLA tazeliği ve geç pencereler, kalite ve doğrusallık, PII güvenliği ve ikamet. Uzlaşma ve bölümleme/sıkıştırma tasarrufları ekleyin; gece geçişi ve manuel Excel olmadan raporlama, ürün çözümleri ve iş ölçeklendirmesi için bir temeliniz olur.