GH GambleHub

Magazyny danych

1) Cel i rola DWH w iGaming

DWH jest centralną warstwą konsolidacji danych i służącą do sprawozdawczości, analizy, zgodności i ML. Zapewnia on:
  • Wspólne definicje metryczne (GGR/NGR, ARPPU, Retention, Churn).
  • Powtarzalne sprawozdania dla organów regulacyjnych i zainteresowanych stron wewnętrznych.
  • Szybkie sklepy do paneli BI/operacyjnych i źródła dla modeli.
  • Kontrola jakości na poziomie platformy, rodowód i bezpieczeństwo.

2) Opcje architektoniczne

2. 1 Klasyczny DWH

ETL → DWH → BI.
Plusy: Modele do zarządzania, silna konsystencja.
Minusy: drogie pliki do pobrania, złożone zasypki, ograniczona elastyczność.

2. 2 Lakehouse DWH

Brąz/srebro/złoto na stołach ACID (Delta/góra lodowa/Hudi) + silnik SQL/MPP.
Plusy: jednolite przechowywanie, podróże w czasie, proste przerobienie.
Minusy: wymaga dyscypliny warstw i DQ, dojrzałej orkiestry.

2. 3 Hybryda

Lakehouse jako „źródło prawdy” (brąz/srebro), DWH-marzec w MPP (ClickHouse/Pinot/Druid/Cloud DWH) do szybkiego czytania.
Plusy: bilans kosztów i wydajności, elastyczne sklepy.
Minusy: podwójne wsparcie dla obwodów i łyżwiarstwa, potrzebna jest synchronizacja.

Zalecenie: dla iGaming - Lakehouse + DWH-March (hybryda). Brąz/srebro - standaryzuj, Złoto/Marty w czasie rzeczywistym - służą do odczytu ładunków.

3) Modelowanie danych

3. 1 Gwiazda i płatek śniegu

Tabele informacyjne: wąskie, imprezowe: "fact _ bets'," fact _ payouts "," fact _ payments ".
Wymiary: 'dim _ users' (SCD), 'dim _ games', 'dim _ providers', 'dim _ markets'.
Płatek śniegu jest odpowiedni w srebrze (normalizacja), Gwiazda - w złocie (czytanie).

3. 2 Skarbiec danych 2. 0 (rdzeń integracji)

Centrale (klucze biznesowe), Linki (relacje), Satelity (kontekst/historia).
Zastosuj w Silver dla długotrwałego dostawcy/integracji PSP.

3. 3 SCD I/II/III

SCD II dla RG/KYC/kanałów i atrybutów gry (RTP/zmienność).
Ścisłe przedziały 'valid _ from/valid _ to', prawidłowe połączenie w czasie.

4) Obciążenie: ETL/ELT, CDC i przyrosty

Podejście ELT: załadunek w Silver → transformacja w DWH.
CDC: replikacja debezu/dziennika z OLTP; merzhi są idempotentne.
Przyrosty: według wody czasu ('updated _ at> max_loaded_ts') i/lub delta hash.
Zasypka/przeróbka: podróże w czasie, zakresy, kwoty, porównania suche.

POŁĄCZENIE (przykład):
sql
MERGE INTO silver. payments s
USING stage. payments_delta d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5) Warstwa semantyczna i mierniki

Metrics Store/Semantic Layer: jednolite wzory GGR/NGR/Conversion/LTV.
Mierniki wersionizacji i obliczenia „od” odtwarzalności.
Konwencje to nazwy metryczne, jednostki, waluta (baza EUR) i „fx _ source”.

6) Sklepy i obsługa

Prezentacje złota: denormalizowane, SLA gotowe (na przykład do 06:00 zamek.) .
Marty operacyjne: ClickHouse/Pinot/Druid na panele 1-5 minut.
Eksport: CSV/JSON/PDF + hash; pakiety niezmienne (WORM) dla regulatorów.

GGR Daily przykład:
sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
b. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

7) Jakość danych (DQ) i umowy

Schemat pierwszy: rejestr JSON/Avro + testy zgodności (napędzane przez konsumenta).
DQ-каков: kompletność/ważność/wyjątkowość/FK/zakres/temporal.
Polityka reakcji: krytyczne → niepowodzenie + DLQ; major/minor → tag i raport.
Obserwowalność DQ: Świeżość/Kompletność/Deski rozdzielcze ważności, utracony lejek rekordów.

8) Bezpieczeństwo, prywatność i pobyt

Minimalizacja PII: użytkownicy poprzez pseudo-ID; mapowania oddzielnie.
RLS/CLS: Dostęp liniowy/po stole według roli i jurysdykcji.
Szyfrowanie: TLS w tranzycie; w stanie spoczynku - KMS/CMK z rotacją.
rezydencja danych: oddzielne katalogi i klucze dla EOG/UK/BR; zakazanie przyłączeń międzyregionalnych bez powodu.
DSAR/RTBF: projekcje obliczeniowe i edycje selektywne; Prawne wstrzymanie artefaktów sprawozdawczych.

9) Wydajność i koszt (inżynieria kosztów)

Podział: według daty/rynku/najemcy; clustering/Z-order przez 'market', 'provider _ id',' game _ id', 'user _ pseudo _ id'.
Formaty: Parkiet + statystyki i kompresja; OPTYMALIZACJA/PRÓŻNIA w harmonogramie.
Materializacja: kruszywa stabilne i tabele podsumowujące; unikać „tłuszczu” przyłącza się do muchy.
Kwoty/obciążenie zwrotne: budżety na ciężkie wnioski/powtórki; raporty koszt/zapytanie, koszt/GB.
Magazyn wielopoziomowy: gorący/ciepły/zimny; jasne SLA odzyskiwania.

10) Obserwowalność i zarządzanie

Metryka rurociągu: czas trwania, objętości, przekładki, opóźnienia, tolerancja uszkodzeń.
Mierniki DWH: czas reakcji/konkurencyjność/hity pamięci podręcznej/wartość.
Rodowód: wykres ze źródeł do raportów; analiza wpływu na zmiany.
SLO: Freshness Silver p95 ≤ 15 мий; Złoto codziennie - gotowe do 06:00; Ważność ≥ 99. 9%; Kompletność ≥ 99. 5%; dostępność ≥ 99. 9%.

11) Wielozadaniowość i izolacja domen

Podział według schematu/bazy danych/katalogu na najemcę/rynek.
Kwoty i grupy zasobów; ograniczanie „hałaśliwych sąsiadów”.
Polityka eksportu/importu między najemcami, standaryzowane umowy.

12) Rejestr danych i dokumentacja

Katalog danych: właściciel, SLA, schemat, przykłady, zasady DQ, rodowód.
Mierniki/deski rozdzielcze: karty z formułami i odpowiedzialne.
Dziennik zmian: wersje logiki, migracji, wpływu.

13) Procesy i RACI

R (odpowiedzialny): Data Engineering (modele Silver/Gold, DAG'i), Data Platform (infra, registry, DQ).
A (Odpowiedzialność): szef danych/CDO.
C (skonsultowany): Zgodność/Prawna/DPO, Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимоста).
I (Poinformowany): BI, Produkt, Marketing, Operacje.

14) Plan działania w zakresie wdrażania

MVP (4-6 tygodni):

1. Lakehouse Bronze/Silver (tablice ACID), CDC/przyrosty płatności/Gameplay.

2. Pierwsze prezentacje złota (GGR Daily, konwersja), SLA do 06:00.

3. DQ-like-code (10-15 zasad) + Świeżość/Kompletność desek rozdzielczych.

4. Katalog danych i podstawowa warstwa semantyczna metryk.

Faza 2 (6-12 tygodni):
  • SCD II - użytkownicy/gry/dostawcy; rozszerzenie domeny.
  • Marzec online (ClickHouse/Pinot) dla paneli w czasie rzeczywistym/w czasie zbliżonym do rzeczywistego.
  • Analiza lineage/impact, procedury DSAR/RTBF, regionalizacja (EOG/UK).
Faza 3 (12 + tygodnie):
  • Automatyczna symulacja zmian (dry-run), powtórka i porównanie metryk.
  • Obciążenie zwrotne/kwoty, tablice rozdzielcze kosztów; ćwiczenia DR i odzyskiwanie podróży w czasie.
  • Automatyczna generacja dokumentacji prezentacyjnej i kart metrycznych.

15) Przykłady szablonów SQL

Rzeczywiste stawki (Silver, 3NF):
sql
CREATE TABLE silver. fact_bets (
bet_id STRING PRIMARY KEY,
user_pseudo_id STRING NOT NULL,
game_id STRING NOT NULL,
stake_ccy DECIMAL(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
stake_base DECIMAL(18,2) NOT NULL,
market CHAR(2) NOT NULL,
event_time TIMESTAMP NOT NULL
);
Połączenie z SCD II (uzyskaj status RG w momencie zakładu):
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);
Kontrola kompletności przez rynek:
sql
SELECT market, DATE(event_time) d, COUNT() n
FROM silver. fact_bets
GROUP BY market, DATE(event_time)
HAVING n = 0;

16) Lista kontrolna przedsprzedaży

  • Systemy i umowy w rejestrze, testy zgodności są zielone.
  • Procedury CDC/przyrostów i MERGE są idempotentne.
  • Prezentacje złota mają SLA, formuły metryczne są stałe.
  • Zasady DQ są aktywne (krytyczne → fail + DLQ), świeżość/kompletność desek rozdzielczych.
  • RBAC/ABAC, szyfrowanie, rezydencja według regionu, dzienniki dostępu.
  • Lineage/impact enabled; czas podróży/kopia zapasowa/DR sprawdzone.
  • Koszty kontrolowane: strony, klastry, materializacja, kwoty.

17) Przeciwdziałanie modelom i ryzyku

„Jeden tłuszcz DWH bez warstw”: mieszanina surowych i zgłoszonych danych → chaos i drogie poprawki.
Pełny przeładunek dziennie niepotrzebnie: przyrosty stosowania/CDC.
Złoto bez właściciela i formuły: brak jednej wersji prawdy → spory i regresje.
PII w warstwach analitycznych: przechowywać mapy oddzielnie, CLS/RLS.
Brak DQ/lineage: brak dowodów dla organów regulacyjnych/audytu.
Koszty niemożliwe do opanowania: brak partii/optymalizacji/kwot.

18) Słownik (krótki)

DWH jest magazynem danych dla konsolidacji i analityki.
Lakehouse - jezioro danych + tablice ACID i silnik SQL.
CDC - Przechwytywanie zmian z OLTP.
SCD - powoli zmieniające się pomiary (I/II/III).
Prezentacja złota - gotowy do spożycia arkusz raportu/prezentacja.
Warstwa semantyczna - jednolite definicje metryk i atrybutów.

19) Najważniejsze

Nowoczesny DWH dla iGaming nie jest „dużym stołem”, ale platformą do zarządzania: warstwy brązu/srebra/złota, ścisłe kontrakty i DQ, jednolite mierniki i rodowód, prywatność i rezydencja, wydajność i wydajność. Budując hybrydę Lakehouse + DWH-March, będziesz miał szybkie i weryfikowalne podejmowanie decyzji gotowych do audytu, skali i nowych rynków.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Telegram
@Gamble_GC
Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.