Rurociągi analityczne i ETL
(Sekcja: Technologia i infrastruktura)
Krótkie podsumowanie
Rurociąg analityczny zmienia „surowe” zdarzenia operacyjne iGaming (zakłady, depozyty, haki PSP, dzienniki gier) w stabilne prezentacje metryczne (GGR/NGR, LTV, retencja, sygnały antykonkurencyjne). Zasady pomocnicze: model jednowarstwowy (brązowy/srebrny/złoty), dyscyplina instrumentalna DQ/rodowód, przyrostowość i idempotencja, obserwowalność i SLO, kontrola kosztów. Decyzje podejmowane są z uwzględnieniem profilu obciążenia (szczyty turniejów), regulacji (PII/lokalizacja) i wymogów biznesowych dotyczących świeżości danych.
1) Architektury: ETL vs ELT, partia vs strumień
Ekstrakt → Przekształć → Ładunek-Transformaty przed załadunkiem do DWH. Odpowiednie, gdy transformacje wymagają kontrolowanego środowiska/tajemnic przed „chmurą”.
ELT (Wyciąg → Ładunek → Przekształcenie): surowce w jeziorze/Lakehouse/DWH, następnie SQL/silnik (skrypty dbt/SQL). Wygodne dla silników kolumn i elastycznych iteracji.
Partia: zaplanowane okna (co 5/15/60 minut, w nocy). Tanie i przewidywalne.
Stream: мобта w czasie rzeczywistym (Kafka → Flink/ksqlDB → OLAP). Dla okien w czasie zbliżonym do rzeczywistego (5-60 sekund) i sygnałów anti-fraud/CRM.
Hybryda: Brąz wypełnia strumieniem, Silver/Gold - przyrostowe modele partii.
Zalecenie: w iGaming zachować ELT + streaming: wydarzenia za pośrednictwem CDC/outbox → Brąz (minuta świeżości), przyrostowe transformacje w Silver/Gold.
2) Medalion
Brąz (Raw): Surowe wydarzenia/CDC bez logiki biznesowej. Parkiet/ORC formaty, schematy jak jest, minimalna walidacja.
Srebro (Zgodne): czyszczenie, deduplikacja, normalizacja ID, wymiar SCD, ujednolicenie strefy walutowej/czasowej.
Złoto (Marts): sprawy biznesowe (fakty/wymiary, kostki), zmaterializowane widoki, preagregacje (dni/kraje/produkty).
Plusy: odtwarzalność, przejrzysta ewolucja, różne SLO i TTL według warstwy.
3) Źródła i załadunek: CDC, outbox, pliki
CDC (Change Data Capture): zmiana przepływów z OLTP (Postgres/MySQL) z gwarantowanym zamówieniem i idempotencją.
Wzorzec skrzynki zewnętrznej: zdarzenia są zapisywane do tabeli/kolekcji skrzynki odbiorczej w transakcji serwisowej → złącze publikuje do autobusu/jeziora.
Przesyłanie plików: Przesyłanie PSP, raporty partnerskie; używać manifestów, checksum, i otrzymywać katalogi.
Praktyki: źródła są wersjonowane (wersja schematu), dla każdego źródła - kontrakt pól i oczekiwań jakościowych.
4) Orkiestra: DAG, zależności, rozmieszczenie
DAGs: wyraźne zależności (raw → staging → dims → fakty → marts).
Idempotencja zadania: powtórzenie bez skutków ubocznych (przegroda-nadpisanie, 'MERGE '/upsert).
Separacja środowisk: Dev/Stage/Prod, promocja artefaktów, „ręczne zatwierdzenie” kosztownego zasypu.
Harmonogram: cron/time windows + event triggers (zgodnie z przyjazdem plików/stron).
Sekrety: od tajnego menedżera; ukrywanie tajemnic w kodzie DAG.
python with DAG("dwh_daily", schedule="0 ") as dag:
bronze = ingest_cdc(source="payments", partition=hour())
silver = dedup_normalize(input=bronze)
dims = build_dimensions(input=silver)
facts = build_facts(input=silver, dims=dims)
marts = build_marts(input=facts)
bronze >> silver >> [dims, facts] >> marts5) Jakość danych (DQ) i rodowód
DQ-checks: kompletność (liczba, późne przyjazdy), wyjątkowość kluczy, zakresy/reguły domeny (kwota ≥ 0, waluta w katalogu).
Próg spustowy: hard stop/soft-fail z alertem w zależności od krytyki tabeli.
Rodowód/katalog: od raportu do źródła (tabele, kolumny, mierniki), właściciele, dokumentacja, klasyfikacja PII.
Sterowanie schematem: automatyczne testy kompatybilności (backward-/forward-compatible), ostrzeżenie o „łamaniu” zmian.
6) Symulacja: SCD, klucze zastępcze, normalizacja
SCD2 dla wymiarów to 'valid _ from/valid _ to/is _ current', klucz zastępczy ('_ sk') i klucz naturalny ('_ id').
SCD1-Overwrites dla drobnych atrybutów (na przykład lokalizacja interfejsu).
Klucze zastępcze: stabilne '_ sk' do przyłączenia, naturalne klucze do wyjątkowości.
Normalizacja wymiaru: płatek śniegu, gdzie hierarchie są głębokie; inaczej gwiazda dla prędkości.
7) Modele przyrostowe i podział
Znak wodny ('updated _ at', 'ingest _ ts'): czytać tylko nowe/zmienione linie.
Strategie przyrostowe: „ŁĄCZENIE” przez klucze biznesowe, „WSTAW NADPISAĆ” przez partie, „USUŃ + INSERT” dla małych partii.
Podział: według daty/godziny/regionu; clustering (sortuj klucze/Z-order) przez filtrowanie i łączenie klawiszy.
Zmaterializowane widoki: preagregacja GGR/NGR, pamięć podręczna popularnych sekcji.
Ok jednostek: HLL/approx_distinct na tanie prezentacje top-N.
sql
MERGE INTO fact_deposits f
USING staging_deposits s
ON (f. deposit_id = s. deposit_id)
WHEN MATCHED THEN UPDATE SET amount = s. amount, status = s. status, updated_at = s. updated_at
WHEN NOT MATCHED THEN INSERT (...)
VALUES (...);8) Zasypka, regeneracja i zarządzanie historią
Zasypka: poszczególne DAGs z limitami zasobów i oknami; jasne „okno prawdy” (np. 2024-01-01.. 2025-11-05).
Ponowne przetwarzanie: transformacje deterministyczne → powtarzane biegi dają ten sam wynik. Rejestrowanie wersji kodu modelu.
Wersje w czasie/tabeli: wygodne dla badań i DR „błędy logiczne”.
Odwracanie: wycofać (usunąć/naprawić) politykę z logowania.
9) Przenośnik CLO/SLA/SLO
świeżość: brąz ≤ 1-5 min, srebro ≤ 15 min, złoto ≤ 60 min (przykład).
Niezawodność: DAG ≥ 99 pass rate x%.
Wydajność: czas trwania węzła p95/p99; budżet czasu przyjęcia.
Monitorowanie opóźnienia: opóźnienie strumienia połknięcia, głębokość kolejki, udział „późnych danych”.
Wpisy: naruszenie świeżości/objętości, pliki DQ, wzrost kosztów skanów, degradacja SN.
10) Koszt: prognozowanie i optymalizacja
Partycje i klastry minimalizują objętość skanowania.
Materializacja markerów gorących (dni/kraje/produkty).
Wyniki pamięci podręcznej/MV dla często używanych desek rozdzielczych.
Monitorować częstotliwość ponownego uruchomienia (nie „co 5 minut” bez powodu).
TTL: agresywna retencja brązu, średni srebrny, długi złoty (tylko kruszywa).
Planowanie przepustowości: metryki katalogowe, prognoza szczytów turnieju/kampanii.
11) Bezpieczeństwo, PII i lokalizacja
Klasyfikacja danych: PII/finansowe/operacyjne.
Szyfrowanie: w stanie spoczynku i tranzytu; KMS/dostęp oparty na rolach.
De-identification: hashing/masking, oddzielne kolumny z klawiszami.
RLS/blizzzards dla wielozadaniowości (przez 'lokator _ id').
Lokalizacja: obszary składowania i przetwarzania według regionów (EU/TR/LATAM); eksport tylko do dozwolonych lokalizacji.
Audyt: odczytuje/zapisuje do tabel krytycznych, dostęp do katalogu.
12) Obserwowalność: mierniki, kłody, szlaki
Metryka rurociągu: czas trwania zadania, kolejka, błędy, przekładki, przetworzone bajty/wiersze, koszt.
Kłody: ustrukturyzowane; korelacja na 'trace _ id'/' run _ id'.
Odwzorowanie: od źródła do pokazu (ingest → transform → load → BI).
Deski rozdzielcze: świeżość warstw, sukces DAGs, top drogie żądania, p95/p99.
13) Instrumenty (wskaźniki roli)
Orkiestra: orkiestra DAG (z harmonogramem, przekaźnikami, wpisami, tajemnicami).
Transformacje: modelowanie SQL („modele jako kod”), testy jednostkowe modeli, dokumentacja.
DQ/umowy: ramy walidacji i SLA dotyczące zbiorów danych.
Lineage/Catalog: automatyczny wykres zależności, znajdź właściciela.
Przesyłanie strumieniowe: procesory okienne/agregacyjne, złącza zlewu/źródła.
(Konkretni dostawcy są wybierani do wymagań firmy dotyczących stosu i bezpieczeństwa).
14) Przykładowe szablony
Szablon prezentacji GGR (Generic SQL)
sql
CREATE OR REPLACE TABLE mart_ggr_daily AS
SELECT
DATE(b. ts) AS d,
c. country_code,
SUM(b. stake) AS stake_sum,
SUM(b. win) AS win_sum,
SUM(b. stake - b. win) AS ggr
FROM fact_bets b
JOIN dim_country c ON c. country_sk = b. country_sk AND c. is_current
WHERE b. ts >= DATE_SUB(CURRENT_DATE, INTERVAL 60 DAY)
GROUP BY d, c. country_code;Nadrzędny model znakowany wodą
sql
INSERT INTO fact_bets PARTITION (dt)
SELECT
FROM staging_bets
WHERE updated_at > (SELECT COALESCE(MAX(watermark), '1970-01-01') FROM _meta_watermarks WHERE table='fact_bets');
-- then update watermarkKontrole DQ (pomysł)
sql
-- 1) key uniqueness
SELECT deposit_id FROM fact_deposits GROUP BY deposit_id HAVING COUNT()>1;
-- 2) negative amounts (error)
SELECT FROM fact_deposits WHERE amount < 0;15) Lista kontrolna wdrażania
1. Zdefiniuj słownik metryki (GGR/NGR/LTV/Retention) i właścicieli.
2. Rekord świeżości SLO w warstwach brązu/srebra/złota.
3. Standaryzacja umów źródłowych (schematy, DQ, SLA).
4. Skonstruuj wykres DAG z idempotentnymi krokami i odizolowanymi tajemnicami.
5. Wdrożyć przyrostowość (MERGE/nadpisane przez stronę) i znaki wodne.
6. Zawiera DQ (sprawdzanie krytyczne/miękkie), lineage i katalog danych.
7. Ustawić obserwowalność (mierniki, kłody, szlaki) i wpisy.
8. Wprowadź politykę retencji/TTL i backfill/reprocessing.
9. Zapewnia kontrolę PII, szyfrowanie, RLS i lokalizację.
10. Spędzić dzień gry: imitacja kropli źródłowej, „łamanie” schematów, masowe zasypanie.
16) Antypattery
„One Night ETL for Everything” bez imprez i przyrostów.
Brak DQ i lineage → sprzeczne raporty i polowanie na duchy.
Pełna rewizja tabel przy każdym uruchomieniu (eksplozja kosztów).
Twardy pakiet w czasie rzeczywistym bez buforów/retras.
Mieszanie PII i publicznych sklepów bez segmentacji i maskowania.
Brak zasad wycofywania/usuwania (błędów nie można poprawić).
Podsumowanie
Solidny rurociąg analityczny w iGaming to ładowanie strumieniowe ELT + w model warstwowy z twardym DQ/lineage, modele przyrostowe, przezroczysty orkiestrnik i wymierne SLO. Dodaj kontrolę kosztów, politykę PII/lokalizację, regularne ćwiczenia backfill/DR - a Twoja platforma analityczna będzie niezawodnie skalować do szczytów turnieju, odpowiadając na interesy danymi o pożądanej świeżości i jakości.