GH GambleHub

Procesy ETL/ELT

1) Cel i kontekst

Rurociągi ETL/ELT zapewniają przewidywalne obciążenie, transformację i publikację danych do celów sprawozdawczości (GGR/NGR, regulatory), analityki/ML i paneli operacyjnych.

ETL: przekształcić przed załadunkiem do DWH/Lakehouse (rzadziej w nowoczesnych stosach).
ELT: pierwsze obciążenie w Lakehouse (Bronze/Silver), a następnie przekształcenie SQL/silników (zalecane).

2) Architektura odniesienia

1. Ingest/Edge: HTTP/gRPC/Batch, CDC z OLTP, dostawca S3/FTP przesyłania.
2. Brąz (surowy, tylko dodatek): niezmienne ładunki użytkowe, strony według daty/rynku/najemcy.
3. Srebro (czyste/zgodne): normalizacja, dedup, katalogi, SCD, FX/timezones.
4. Złoto (służyć): denormalizowane sklepy dla BI/regulator/modele.
5. Orkiestra: Airflow/Dagster/Prefekt (DAG'i, SLA, Retrai, Shifts).
6. DQ/Contracts: Schema Registry + DQ-каб-коz, testy konsumenckie.
7. Obserwowalność: mierniki rurociągów, rodowód, kłody, deski rozdzielcze.

3) Wybór ETL vs ELT

KryteriumETLELT (zalecane)
Elastyczność przydziałówniskiewysoka (podróż w czasie, regeneracja)
Kosztdroższe, gdy rośnieoptymalne przy skalowaniu
Kontrola jakościpo połknięciudo srebra/złota + kod DQ-as
Historyczność/technika sądowaograniczonepełny (tylko z brązu)

Praktyka: w iGaming - ELT + CDC: ładowanie szybko, a następnie standaryzacja i liczenie.

4) Przyrosty i CDC

Podejście Delta:
  • CDC (Debezium/replikacja dziennika): OLTP zmienia → Brąz → MERGE w srebrze.
  • Znak wodny według czasu: 'updated _ at> max_loaded_ts'.
  • Różnica hash: porównanie 'md5 (wiersz)' do wykrywania zmian.
  • Upsert/MERGE: idempotencja plików do pobrania.
Przykład MERGE (Delta/Iceberg):
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) Umowy i systemy

Schemat pierwszy: JSON/Avro/Protobuf w rejestrze; 'schema _ version' w zdarzeniach/plikach.
Ewolucja: kompatybilne z powrotem (dodatki nieusuwalne); łamanie - '/v2 '+ podwójne wejście.
Wymagane pola to 'event _ time (UTC)', 'event _ id',' trace _ id', 'user _ pseudo _ id',' market '.

6) DQ-as-code (minimalny zestaw)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: unique_tx # uniqueness of transactions type: unique columns: [transaction_id]
severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
severity: major
- name: amount_positive type: range column: amount_base min: 0. 01 severity: critical
- name: fk_user type: foreign_key column: user_pseudo_id ref_table: dim. users_scd severity: critical

7) Orkiestra: DAG "i, zależności, SLA

Projekt DAG: od źródeł po sklepy; wyraźne zależności między zadaniami.
Retrai i idempotencja: backoff, „czyste” powtórki, punkty kontrolne.
Dogonienie: schludny połów pominiętych okresów.
SLA: Na przykład złoto. dziennie jest gotowy przed 06:00 czasu lokalnego; wpisy o naruszeniach.
Parameteryzacja: rynki/najemcy/daty poprzez vars; jeden szablon zadania.

8) Idempotencja i dokładnie raz

W połknięciu: duplikaty są możliwe → dedup przez '(event_id, źródło)'.
W przetwarzaniu: upsert/merge; funkcje „czystej” transformacji.
W zlewie: commits transakcyjne lub idempotent pisze; kontrola „podwójnego liczenia”.
Outbox/Inbox: transakcyjne publikowanie wydarzeń domeny z OLTP.

9) Backfill (reprocessing)

Zasypka: podstawowe zakresy wypełnienia/historyczne.
Ponowne przetwarzanie - ponowne obliczenie przy zmianach/korektach logiki.
Poręcze: limity zasięgu, kwoty, okna czasowe, suchy bieg z porównaniem metrycznym.
Oznaczenie: 'logic _ version', 'reprocessed _ at', 'recalc _ reason'.

10) Modelowanie srebra/złota

Srebro (3NF/BCNF): fakty „fact _ bets/payments/payouts”, wymiary „dim _ users/games/providers/markets (SCD II)”, standaryzacja waluty/strefa czasowa.
Złoto: denormalizowane sklepy dla BI/regulatora/modeli; niezmienne pakiety eksportowe (WORM) + podpis.

Przykład złota: GGR Daily

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;

11) Prywatność i miejsce zamieszkania

Minimalizacja PII: tokenizacja; mapowania prawdziwych identyfikatorów w izolowanej pętli.
RLS/CLS: polityka dostępu według roli/jurysdykcji, maskowanie.
Miejsce zamieszkania: oddzielne katalogi/klucze dla EOG/UK/BR; zakazanie przyłączeń międzyregionalnych bez powodu.
DSAR/RTBF & Legal Hold: selektywne edycje, archiwum WORM do raportowania, audyty eksportowe.

12) Obserwowalność i SLO

Wartości odniesienia SLI/SLO:
  • świeżość srebro p95 ≤ 15 min; Złoto codziennie jest gotowe do 06:00 zamek. czas.
  • Kompletność ≥ 99. 5%, ważność (program) ≥ 99. 9%.
  • Sukces miejsc pracy ≥ 99. 0%, incydenty MTTR ≤ 24-48 h.

Deski rozdzielcze: mapa grzewcza świeżości, lejek DQ utraty, koszt/zapytanie i koszt/GB, wykres linii.

13) Wydajność i koszt

Podział: data/rynek/najemca; clustering/Z-order według filtrów.
Formaty: Parkiet + KWAS (Delta/Góra Lodowa/Hudi), kompresja i statystyki.
Zagęszczenie: zwalczanie małych plików (OPTIMIZE/VACUUM).
Materializacja: kruszywa stabilne; unikać gigantycznych przyłączeń.
Obciążenie zwrotne: budżety, powtórne kwoty/zasypka; harmonogram w oknach o niskim obciążeniu.

14) Przykłady typowych zadań DAG (pseudokod przepływu powietrza)

python with DAG("elt_payments_daily", schedule="@daily", start_date=..., catchup=True) as dag:
extract = BashOperator(task_id="extract_cdc", bash_command="run_cdc_to_bronze. sh {{ ds }}")
load  = BashOperator(task_id="load_to_silver", bash_command="sql/run_merge_silver. sql {{ ds }}")
dq   = BashOperator(task_id="dq_checks", bash_command="dq/run_checks. sh silver. payments {{ ds }}")
gold  = BashOperator(task_id="build_gold_ggr", bash_command="sql/build_gold_ggr. sql {{ ds }}")
export = BashOperator(task_id="export_regulator", bash_command="export/run_worm_pack. sh {{ ds }}")

extract >> load >> dq >> gold >> export

15) Procesy i RACI

R (odpowiedzialny): Data Engineering (DAG, Silver/Gold models), Data Platform (Infra, Registry, DQ).
A (Odpowiedzialność): szef danych/CDO.
C (Skonsulowany): Zgodność/Prawna/DPO (PII/rezydencja/Legalne Holding), Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоноста).
I (Poinformowany): BI/Produkt/Marketing/Operacje.

16) Plan działania w zakresie wdrażania

MVP (3-5 tygodni):

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

2. DQ-like-code (10-15 zasad) i podstawowe deski rozdzielcze świeżości/kompletności.

3. Pierwszy Gold Showcase (GGR Daily) z SLA „do 06:00”, WORM eksport z podpisem.

4. DAG i orkiestra alarmowa na SLA/DQ.

Faza 2 (5-10 tygodni):
  • Rozszerzenie domeny, SCD II dla użytkowników/gier/dostawców.
  • Warstwa semantyczna mierników; rodowód/analiza oddziaływania; procedury zasypki/regeneracji.
  • Regionalizacja (EOG/UK), RLS/CLS, kontrola kosztów (kwoty/obciążenie zwrotne).
Faza 3 (10-16 tygodni):
  • Symulator powtórki (co-if), automatyczna generacja dokumentacji prezentacji/mierników.
  • Optymalizacja kosztów (klastrowanie, materializacja, TTL, kompresja).
  • ćwiczenia DR i odzyskiwanie podróży w czasie.

17) Lista kontrolna przedsprzedaży

  • Umowy/schematy w rejestrze, testy zgodności zielone.
  • CDC/przyrosty i MERGE są idempotentne; odpływ do połknięcia.
  • Zasady DQ są aktywne (krytyczne → fail + DLQ), deski rozdzielcze SLA są skonfigurowane.
  • Złote prezentacje są udokumentowane, metryczne wzory w warstwie semantycznej.
  • RBAC/ABAC, szyfrowanie, rezydencja, DSAR/RTBF/Legal Hold zweryfikowane.
  • Kompresja/OPTIMIZE/próżnia w harmonogramie; limity zasypki/powtórki.
  • Runbook "oraz incydenty i ponowne przetwarzanie, eksport audytu (WORM + hash).

18) Przeciwdziałanie modelom i ryzyku

Pełny przeładunek „just in case”: użyj CDC/przyrostów.
Mieszanie surowych i zgłoszonych danych: Zachować brąz/srebro/złoto oddzielne.
Brak DQ i rodowodu: brak provability i odtwarzalność.
PII w warstwach analitycznych: odizolować mapy, zastosować CLS/RLS.
Monolityczne "noc' jabs: zmiażdżyć, równolegle w partiach.
Ignoruj koszty: pilnuj małych plików, zmaterializuj agregaty, wprowadzaj kwoty.

19) Słownik (krótki)

ETL/ELT - ekstrakcja/transformacja/obciążenie (przed/po załadunku).
CDC - Zmiana przechwytywania.
SCD - historia pomiarów (I/II/III).
WORM - niezmienne przechowywanie pakietów raportów.
Podróże w czasie - czytanie historycznych wersji tabel.

20) Sedno sprawy

Nowoczesny ETL/ELT to nie skrypty, ale platforma zarządzana: kontrakty i DQ, przyrosty idempotentne/CDC, dyscyplina warstw brązu/srebra/złota, obserwowalność i SLO, prywatność i gospodarka. Wykonując ten przewodnik, otrzymasz odtwarzalne i audytoryjne rurociągi, które konsekwentnie raportują moc, produkty i modele w skali i bez niespodzianek.

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.