Sklepy danych i modele OLAP
(Sekcja: Technologia i infrastruktura)
Krótkie podsumowanie
Magazyn danych (DWH) - podstawowa warstwa analityczna iGaming: raporty dla regulatorów, rentowność według produktu/rynku, kohorta LTV, analityka zwalczania nadużyć finansowych, segmentacja CRM i deski rozdzielcze w czasie rzeczywistym. Zrównoważony DWH jest zbudowany w oparciu o przejrzysty model danych (Star/Snowflake/Data Vault), solidną integrację (ETL/ELT + CDC), przemyślane osiągi (silniki kolumn, imprezy, MV), ścisłe semantyki metryczne, bezpieczeństwo/PII i zarządzanie kosztami
Podejścia architektoniczne
Klasyczny DWH (Kimball vs Inmon)
Kimball (Dimensional/Star/Snowflake): przypadki szybkiego raportu; skupić się na faktach i wymiarach, historii SCD. Szybka wartość czasowa.
Inmon (Corporate Information Factory): znormalizowany rdzeń + sklepy; cięższy w czasie, ale ściśle i centralnie.
Skarbiec danych 2. 0
Hubs-Links-Satellites: skalowalny „surowy” model integracji źródeł i audytu zmian. Gwiezdne sklepienia są budowane na górze.
Jezioro Danych/Lakehouse
Jezioro danych: pliki surowe (Parkiet/ORC) + katalogi (Ul/Klej/Jedność/Metastore).
Lakehouse: pojedyncza warstwa dla partii/strumienia, stoły ACID (Delta/Iceberg/Hudi), podróż w czasie, upsert/fuzja, pliki kompaktowe, Z-order/Clustering.
Medalion (brązowy-srebrny-złoty)
Brąz: dane surowe (surowe) + CDC.
Srebro: oczyszczone i zgodne.
Złoto: sprawy biznesowe/metryki/kostki.
Nadaje się do hybryd (Kafka → Brąz; srebro „Lakehouse”; Złota kolekcja ClickHouse/Query/Snowflake).
Modele OLAP: Gwiazda, Płatek śniegu, Skarbiec danych
Schemat gwiazdy (gwiazda)
Tabele informacyjne: transakcje (stawki, depozyty, sesje).
Wymiary: gracz, gra, dostawca, data/czas, geo, kanał przyciągania.
Plusy: Proste joynes, przewidywane wykonanie.
Płatek śniegu
Normalizacja wymiaru (hierarchie kraju/regionu/miasta, hierarchie produktów).
Plusy: mniej powielania; minus - więcej joynes.
Skarbiec danych → Gwiazda
Dodajemy surowe zmiany do DV (audyt, pełna odtwarzalność), budujemy okna raportu, takie jak Star/Snowflake.
Integracja: ETL/ELT, CDC, powolne zmiany
Rurociąg
Outbox/CDC z OLTP (Postgres/MySQL) → Kafka/→ Złącza z brązu.
Czyszczenie, odkurzanie, normalizacja w Silver.
Logika biznesowa i agregacje w Gold/sklepach.
SCD (powoli zmieniające się wymiary)
Typ 1-Overwrite (dla pól innych niż istotne).
Typ 2: historyczność (wersje z datą) - standard dla profili/kanałów/cen.
Typ 3: przechowywanie pary wartości (rzadko).
sql
-- insert new dimension version
INSERT INTO dim_player (player_sk, player_id, country, valid_from, valid_to, is_current)
SELECT gen_sk(), s. player_id, s. country, now(), '9999-12-31', true
FROM staging_player s
LEFT JOIN dim_player d ON d. player_id = s. player_id AND d. is_current = true
WHERE d. player_id IS NULL OR d. country <> s. country;
-- closing the old version
UPDATE dim_player d
SET valid_to = now(), is_current = false
FROM staging_player s
WHERE d. player_id = s. player_id AND d. is_current = true AND d. country <> s. country;Warstwa semantyczna i „prawdziwe” mierniki
Wprowadź jedną warstwę semantyczną: GGR, NGR, depozyty netto, ARPPU, LTV, Churn, Retention Cohorts definicje.
Metryka jako kod (dbt metrics/LookML/Semantic Layer) → te same wzory we wszystkich raportach.
Kalendarz: data/godzina tabela z atrybutami TZ/regiony/weekendy/kampanie.
Sklepienia i silniki: wybór profilu
Kolumna i chmura DWH
ClickHouse: ultraszybkie skany/agregacje, zmaterializowane reprezentacje, projekcje; różni się dla imprez/telemetrii i prezentacji marketingowych.
• Zapytanie: bez serwera, skala, automatyczne bufory/klastry; cena za skanowanie; wygodne dla ładunków mieszanych i doraźnych.
Płatek śniegu: gałąź obliczeniowa/magazynowa, klastry na żądanie, podróże w czasie; przezroczyste dla różnych zespołów.
Redshift/Vertica/Pinot/Druid: opcje dla OLAP/w czasie rzeczywistym.
Dostrajanie profilu
Podział według daty/regionu/kanału.
Klaster/sortowanie przez filtr/joyn keys.
Kompresja i kodowanie przez słowniki.
Preagregacje (rollup, kostki), zmaterializowane poglądy.
Ok funkcje (HyperLogLog/approx_distinct) dla tanich ocen.
Inżynieria wydajności
Podział i klastrowanie
Partia jest granicą przedziału. Imprezy dzienne/godzinne.
Clustering (klawisze sortowania/Z-order) - przyspiesza zakresy i przyłącza.
Zmaterializowane widoki (MV)
Wstępne sprawozdanie GGR/NGR według dnia/kraju/produktu.
Dodatkowa aktualizacja ze strumienia CDC.
sql
CREATE MATERIALIZED VIEW mv_ggr_daily
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMMDD(ts)
ORDER BY (country, product_id, toDate(ts)) AS
SELECT toDate(ts) AS d,
country,
product_id,
sum(stake) AS stake_sum,
sum(win) AS win_sum,
sum(stake - win) AS ggr
FROM bets
GROUP BY d, country, product_id;Modele przyrostowe (dbt/ELT)
Strategie 'insert _ overwrite' by party, 'merge' by CDC keys, 'watermark' by 'updated _ at'.
Strategie przyłączeniowe
Replika pomiarów w każdym segmencie partii (denorm).
Nadawane małe obwody; shuffle duże fakty posortowane przez klucz.
Koszt: kontrola i optymalizacja
• Zapytanie/Płatek śniegu: ograniczony rozmiar skanowania (strony projektowe/klastry), włączanie pamięci podręcznej wyników/zmaterializowanych widoków, ograniczenie automatycznych zadań BI.
ClickHouse: rozmiar partii, częstotliwość merjey, budżet magazynowania (TTL dla zdarzeń surowych, agregacje są trwałe).
Semantyka metryczna zmniejsza „podwójne” obliczenia.
Przycinanie danych: retencja dla brązu, agregacja dla złota.
Jakość danych (DQ), katalog, rodowód
Kontrole DQ: kompletność, wyjątkowość, zakresy, zasady prowadzenia działalności (na przykład GGR ≥ 0 w kruszywach).
Data Catalog & Lineage: table/field descriptions, owners, PII classification, report-to-source odwzorowanie.
Systemy kontroli: umowa dotycząca zdarzeń/CDC, wpisy dotyczące niezgodnych ze wspólnym rynkiem zmian.
Bezpieczeństwo, zgodność i wielopoziomowość
Segmentacja PII: poszczególne strefy, maskowanie/pseudonimizacja, kolumny z szyfrowaniem KMS.
RBAC/ABAC: role na poziomie projektu/schematu/tabeli/wiersza (RLS), bębny dla „need-to-know”.
Lokalizacja danych: regionalne wiadra/magazyny (EU/TR/LATAM).
Audyt dostępu: którzy czytają/zmieniali sklepy i modele.
DR, kopie zapasowe i odtwarzalność
Wersioning kodu danych (dbt/git), środowisko Dev/QA/Prod.
Migawki z przerzutami/katalogiem + tabele podróży w czasie.
Warstwy retencyjne/TTL Brąz/srebro/złoto; eksport krytycznych sklepów.
Dzień gry: przywracanie prezentacji, sprawdzanie integralności metryk.
Magazyny w czasie rzeczywistym i hybrydowe
Stream-to-OLAP: Kafka → ClickHouse/Pinot/Druid na minutowe prezentacje.
Zmaterializowane widoki + CDC dla aktualizacji w pobliżu online (5-15 min).
Warstwa semantyczna pozostaje taka sama: wskaźniki są identyczne w czasie rzeczywistym i partii.
GGR według dnia i Country Showcase Example (Generic SQL)
sql
CREATE TABLE fact_bets (
bet_id BIGINT,
player_sk BIGINT,
game_sk BIGINT,
country_sk BIGINT,
stake DECIMAL(18,2),
win DECIMAL(18,2),
ts TIMESTAMP
) PARTITION BY DATE(ts);
CREATE TABLE dim_country (
country_sk BIGINT PRIMARY KEY,
iso2 STRING,
region STRING,
valid_from TIMESTAMP,
valid_to TIMESTAMP,
is_current BOOL
);
-- Showcase
CREATE MATERIALIZED VIEW mart_ggr_daily AS
SELECT
DATE(ts) as d,
c. region,
SUM(stake) AS stake_sum,
SUM(win) AS win_sum,
SUM(stake - win) AS ggr
FROM fact_bets f
JOIN dim_country c ON c. country_sk = f. country_sk AND c. is_current
GROUP BY d, c. region;Lista kontrolna implementacji
1. Zdefiniuj źródła i domeny, napraw słownik metryczny.
2. Wybierz model: DV dla warstw surowych/audytowanych + Gwiazda do wyświetlaczy.
3. Projektowanie stron/klastrów dla kluczowych zapytań i okien.
4. Konfiguruj CDC/ELT, politykę SCD i klucze zastępcze.
5. Wprowadź warstwę semantyczną (metryki jako kod) i kalendarz daty/godziny.
6. Utwórz MVs/preagregacje dla drogich raportów.
7. Włącz sterowanie DQ/directory/lineage i schematem.
8. Zdefiniuj RBAC/PII/lokalizację, szyfrowanie, audyt.
9. Ustaw monitoring p95/p99, koszty, wpisy o degradacji i przekroczeniu.
10. Regularne ćwiczenia DR i odtwarzalność środowisk.
Anty-wzory
„Jeden gigantyczny fakt bez stron” → skany terabajtowe i wynik rośnie.
Niespójne definicje mierników w różnych deskach rozdzielczych.
Brak SCD2, gdzie biznes wymaga historyczności.
Przedwczesna normalizacja pomiarów: niepotrzebne joynes i powolne raporty.
Surowe dane bez kontroli DQ i lineage → „nic” raportów.
Brak pozwolenia/TTL → przechowywanie śmieci i eksplozja kosztów.
Podsumowanie
Niezawodny iGaming-DWH to przejrzysty model (DV → Star), pojedynczy słownik metryczny, poprawne partycje/klastrowanie, zmaterializowane sklepy, ścisłe DQ/lineage i RBAC/PII/lokalizacja. Dodaj hybrydowe strumieniowe dla świeżości, ELT-napędzane i dyscypliny wartości - i uzyskać zrównoważoną platformę analityczną, która skaluje turnieje, raporty regulacyjne i badania ad hoc bez niespodzianek w p99 i budżetu.