Data Lake and DWH dla kasyn: schematy, SLA pliki do pobrania

Pełny artykuł

💡 18+. Materiały techniczne dla platform/operatorów, studiów i zespołów analitycznych. Ani telefonu do zabawy. Przez platformę rozumiemy PAM/portfel/kasjer/bonusy/RG, przez dostawców - RGS/live/jackpots/integration payments.

1) Dlaczego Data Lake Casino i DWH

Sprawozdawczość i zgodność: przesyłki regulacyjne (GGR/NGR, KYC/AML, RG), audyt pieniężny.

Produkt/marketing: LTV/retencja, segmentacja, A/B, zalecenia.

Operacje: monitorowanie dostawców, PSP, gier na żywo SLA i kasy.

Rozwiązania do przechowywania danych: szybkie sklepy (DWH) na szczycie taniego długoterminowego przechowywania (Lake).

Linia dolna: Jezioro przechowuje warstwy surowe i oczyszczone, DWH daje szybkie zapytania i zarządzane modele.

2) Architektura referencyjna (lakehouse)


Źródła (OLTP, Kafka, Webhooks, CDC)
│
  Brąz (surowy, tylko dodatek; Parkiet/Delta/Góra Lodowa)
ingestion_time, source_metadata, brak zmian schematu
 Srebro (oczyszczone, zgodne; dedup, maskowanie PII, SCD2)
klucze biznesowe, ograniczenia, kontrole jakości
└─Gold (marts; gwiazda/płatek śniegu; tabele sześcienne, kruszywa)
Silniki └─DWH/Query (płatki śniegu/drukarki/trino/iskra SQL)

Мормата: Delta Lake/Apache Iceberg/Hudi (ACID - jezioro, podróże w czasie, MERGE).

Pliki: Parkiet + ZSTD/Snappy, cel ~ 128-512 MB; zagęszczenie „małego pliku”.

Katalog: Hive/Unity/Iceberg Catalog; wiadra strefy brązu/srebra/złota 'na region/najemcę.

3) Systemy domen (koncepcyjne)

3. 1 Portfel/księgowość

'portfel _ entry': 'entry _ id',' account _ id', 'direction (debit)	) credit ',' amount _ minor ',' currency ',' reason ',' reference _ id', 'occurred _ at', 'region', 'lokator _ id',' trace _ id', 'idempotence _ key'.
Niezmienny: kwota konta = saldo (poprzez migawkę + dziennik zmian).

3. 2 Zakłady/rozliczenie (RGS/live)

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

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

3. 3 Płatności (cash desk/PSP/crypto)

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

„komputer/zwrot/obciążenie zwrotne”: oddzielne tabele z odniesieniami do 'intent _ id',' psp _ ref ', kody uzasadnienia.

Крикта: 'txid', 'network', 'confirmates', 'finalized _ at'.

3. 4 Bonusy/vager/jackpoty

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

3. 5 Odniesienia i pomiary

'dim _ player' (pseudo-ID, geo, kanały, statusy RG - bez PII w analityce), 'dim _ game', 'dim _ provider', 'dim _ psp', 'dim _ brand', 'dim _ region', wymiary kalendarza.

Klucze i kompatybilność: w modelach Silver/Gold - stabilne klucze biznesowe ('bet _ id',' round _ id', 'payout _ id',' intent _ id') oraz semantyka zdarzeń „idempotent”.

4) Pobierz strumienie: Streaming + Microbatch

Streaming (Kafka/Pulsar → Brąz): imprezy OLTP i webhook, outbox/CDC, przynajmniej raz gwarancje z deduplication w Silver.

CDC (Debezium/dziennik replikacji): zmiana tabel OLTP (portfel/płatności) → Brąz.

Mikrobatches: PSP/bank/niestandardowe raporty (SFTP/API) → Brązowe pliki surowe → normalizacja.

MERGE in Silver: dedup by 'idempotency _ key/event _ id', eliminacja latecomerów (' znak wodny '), SCD2 na pomiarach.

5) Pobieranie SLA i późne okno (znaki wodne)

5. 1 Typowe SLA (punkty orientacyjne)

Wydarzenia portfelowe/księgowe: Brąz ≤ 1-2 min, Srebro ≤ 5-10 min, Marty złote ≤ 15 min

Zakłady/osiedla: Brąz ≤ 1-2 min, Srebro ≤ 10 min, Złoto ≤ 30 min

Płatności (haki PSP): brąz ≤ 5 min, srebro ≤ 15 min, złoto ≤ 30-60 min.

Kryptowaluta: zależna od sieci; wyświetlanie przypadków z potwierdzeniami lag N.

Dzienne raporty PSP/banku: T + 1 do 09:00 czasu lokalnego regionu.

5. 2 Późne okna

Znak wodny według czasu zdarzenia ('occurred _ at') + tolerancje:

portfel/zakłady: 24-48 godzin, płatności/PSP: 72 godziny (są haki retro), krypta: do 24 godzin dla rzadkich reorgs.
Późniejsze zdarzenia przerobu: ponowne obliczenie okien Gold stopniowo (MERGE), dziennik korekcji.

5. 3 Komunikat SLA

Katalog danych zawiera atrybuty SLA: 'freshness _ target', 'freshness _ status', 'expected _ lag _ p95', 'watermark'.

Deski rozdzielcze „świeżości” z naruszeniem wpisów.

6) Jakość danych (DQ) i umowy

Kontrakty na dane dla każdego tematu: programy Avro/JSON, semver, wymagane pola, niezmienniki biznesowe (na przykład "win _ minor ≥ 0", "waluta" ISO-4217 ").

Srebrne kontrole DQ: wyjątkowość klucza, integralność odniesienia, kontrola bilansu (uzgadnianie portfela), ważność kodów/powodów PSP, zakresy dat.

Nasilenie: 'ERROR' (blokowanie), 'WARN' (oznakowanie),' INFO '.

Monitorowanie:% naruszeń, najważniejsze powody, automatyczne bilety.

Pobieranie próbek i powtarzanie: Przechowywać surowy brąz do recyklingu.

7) PII, miejsce zamieszkania i bezpieczeństwo

PII-showcase jest oddzielony od analityki: in Silver/Gold - pseudonim, maskowanie/hashes, tokenizacja.

Miejsce zamieszkania danych: EU/UK/BR itd. - fizycznie oddzielne wiadra/katalogi; brak międzyregionalnego odczytu bez zgody i pełnomocników.

Достра: RBAC/ABAC (jezioro/DWH), zabezpieczenie na poziomie rzędu „tenant/brand/region”.

Szyfrowanie: odpoczynek (KMS) i tranzyt, klucze regionalne/markowe, audyt WORM dostępu i zmiany polityki.

Prawo do bycia zapomnianym: mechanizm lokalizacji danych gry bez usuwania dokumentacji finansowej (de-identification).

8) Modelowanie okien złota (gwiazda)

8. 1 Tabele rzeczywiste

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

8. 2 Pomiary

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

8. 3 Metryki i obliczenia

GGR/NGR, trzymaj/częstotliwość, RTP (według gry/dostawcy/regionu), konwersja depozytu, rozliczenie opóźnienia, PSP szybkości sukcesu, cost-per-success, FX-اL, składki jackpot/wypłaty.

9) Wydajność i koszt

Podział: przez 'occurred _ date' + 'region/lokator', czasami 'game _ id' for Gold aggregates.

Clustering/Z-Order: przez 'player _ id',' game _ id', 'psp', 'currency'.

Kompresja i próżnia: planowane 'OPTIMIZE/COMPACT', usunięcie wersji „wiszących” (z uwzględnieniem retencji prawnych).

Bufory: pamięć podręczna/magazynowa, zmaterializowane widoki na gorące panele.

Indeksy w DWH: klaster/segment (klawisze klasterowania płatków śniegu, partycja z oprogramOwaniem Zapytania + klaster).

Koszt: zimny Brąz w magazynie obiektów, gorące złoto/marzec jednostek w DWH; auto-parking/automatyczna skala.

10) Linaż, katalogi i dokumentacja

Katalog danych (OpenMetadata/Amundsen/Collibra): opis tabeli, właściciel, SLA, pola PII, zasady dostępu.

Rodowód: od źródła (event/CDC) do prezentacji i raportowania; widoczność ograniczeń dla bezpiecznych zmian.

Programy Changelog: semver i dziennik deprecates; badania zgodności w rurociągach CI.

11) Pojednanie

Codziennie:

„wallet _ entry” - salda całkowite (akumulacyjno-migawkowe), płatności: raporty PSP/bankowe, „fact _ payments”, krypto: „txid/network”, „fact _ payments”.
Катеворий: 'match', 'timing', 'missing _ source', 'missing _ platform', 'amount _ mismatch'.
Wpisy: odsetek „niedopasowania”> próg; starzenie się wybitne> N dni.

12) Przykładowe tabele SLA (przykład)

Domena	Brąz (połknięcie)	Srebro (czyszczenie)	Złoto (marzec)	Późne wydarzenia (znak wodny)
Portfel	≤ 2 min	≤ 10 min	≤ 15 min	48 h
Zakłady/rozliczenia	≤ 2 min	≤ 10 min	≤ 30 min	48 h
Płatności (PSP)	≤ 5 min	≤ 15 min	≤ 60 min	72 h
Krypta	realtime → finalnost	≤ 15 min	≤ 60 min	24 h
Sprawozdania (T + 1)	06:00–08:00	≤09:00	≤10:00	7 d

13) Rurociągi: co zbieramy z

Spożycie: Kafka Connect/Debezium, usługi spożywania w chmurze, ściągacze SFTP.

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

Jakość: Wielkie oczekiwania/testy Dequ/dbt.

Monitorowanie: OpenTelemetry + Lake/DWH (opóźnienie świeżości, opóźnienie pracy, koszt).

Wypadki i powtórzenia: przeróbka z brązu, odpływ z klawiszami, rurociągi wersjonowane.

14) Listy kontrolne

Architektura i bezpieczeństwo

Format lakehouse (Delta/Iceberg/Hudi) z ACID i podróży w czasie.
Podział „brąz/srebro/złoto”, outbox/CDC jako główne źródła.
Izolacja PII, tokenizacja, RLS przez „najemca/marka/region”.
Wiadro/rezydencja na poziomie katalogu, klucze/sekrety na region.
Audyt WORM schematu/polityki/zmian reguł dostępu.

Jakość i SLA

Umowy o dane i programy semeralne; testy kompatybilności.
Znaki wodne i powtórne przetwarzanie, dodatkowe prezentacje MERGE.
Deski rozdzielcze świeżości i wpisy SLA; właściciel dla każdego stołu.
Uzgodnienie według portfela/płatności/krypto.

Wydajność i koszt

Podział i klastrowanie; zagęszczenie „małego pliku”.
Zmaterializowane prezentacje najważniejszych raportów.
Autoskale/Auto-Parking, Polityka retencji i archiwum.

15) Czerwone flagi (anty-wzory)

BI i raporty regulacyjne uderzyły bezpośrednio w OLTP.

Brąz „zapisuje” i traci surowe dane.

Żadnych znaków wodnych, późne wydarzenia są „okrojone”.

Brak deduplikacji na 'idempotence _ key '/' event _ id' → duplikaty w Gold.

PII i pieniądze z różnych regionów są trzymane razem bez RLS i rezydencji.

Programy zmieniają się „cicho” (bez semver/kontraktów), rozbijając okna sklepu.

Miliony małych bezkompresowanych plików Parkiet → drogie wnioski.

brak desek rozdzielczych SLA/świeżości; „niespodzianki” w sprawozdawczości kwartalnej.

16) Wniosek

Data Lake + DWH in iGaming to nie tylko przechowywanie, ale kontrolowany ekosystem: znormalizowane schematy i kontrakty, ACID-lakehouse, czysta świeżość SLA i późne okna, jakość i liniowość, bezpieczeństwo PII i rezydencja. Dodaj uzgadnianie i podział/zagęszczenie oszczędności - i masz fundament do raportowania, rozwiązań produktowych i skalowania biznesu bez nocnych migracji i ręcznie Excel.