Jeziora danych i agregacja przepływów

1) Cel i wartość

• Strumienie z produktów/gier/płatności gruntów w Brąz „jak jest”.
• Srebro normalizuje i wzbogaca, zapewniając spójne klucze i jakość.
• Złoto - zagregowane prezentacje (w tym w czasie rzeczywistym/zbliżonym do rzeczywistego) dla BI, regulatora, zwalczania nadużyć finansowych/RG.

Agregacja przepływów na plonach Lakehouse: niski opóźnienie raportu, przewidywalny koszt, powtarzalność i kryminalistyka.

2) Architektura odniesienia

1. Ingest/Edge: HTTP/gRPC, OTel, endpointy partii → мина (Kafka/Redpanda).
2. Brąz (tylko dodatek): magazyn obiektów + tabele ACID (Delta/Iceberg/Hudi), przegrody według daty/rynku/najemcy; przechowywanie oryginalnego ładunku użytkowego.
3. Stream Compute: Flink/Iskra/Beam - jednostki okienne, CEP, deadup, online-lookups.
4. Srebro (czyste/zgodne): normalizacja waluty/timezon, FK/katalogi, SCD do pomiarów.
5. Serwowanie/OLAP: ClickHouse/Pinot/Druid - zmaterializowane kruszywa minutowe/sekundowe dla paneli.
6. Złoto (podawać): dzienne/godzinne skrzynki wyświetlające, plastry regulacyjne, niezmienne pakiety eksportowe (WORM).
7. Pętle kontrolne: Schema Registry, DQ-as-code, lineage, directories, secrets/KMS, RBAC/ABAC.

3) Umowy i systemy

Schemat pierwszy: JSON/Avro/Protobuf; wymagane pola to 'event _ time (UTC)', 'event _ id',' trace _ id', 'user _ pseudo _ id',' market ',' schema _ version '.
Ewolucja: kompatybilne z powrotem → dodanie nieważne; łamanie → '/v2 '+ podwójne wejście.
Katalog: opis domeny, właściciel, świeże SLA, zasady DQ, rodowód.

4) Strumienie do jeziora

Dokładnie raz na dole: co najmniej raz publikacja + idempotent sink (MERGE/upsert przez 'event _ id').
Dedup: statile w strumieniu + wyjątkowość w Silver.
Kompresja plików: małe pliki → regularne OPTIMIZE/VACUUM do odczytu i kosztów.
Podróże w czasie: obejmuje debugowanie, powtarzanie i audyt.

sql
CREATE TABLE bronze. payment_events (
event_id STRING, user_pseudo_id STRING, currency STRING,
amount DECIMAL(18,2), market STRING, event_time TIMESTAMP, payload STRING
)
PARTITIONED BY (days(event_time), market);

5) Agregacja strumieniowa: okna i znaki wodne

• Bębnowanie - stałe (np. 1 min/5 min) dla stabilnych paneli.
• Skok - nakładanie się (krok
• Sesja - luki behawioralne w bezczynności.
• Znaki wodne: późna kontrola danych (zwykle 2-5 minut), reguły wstępnej emisji/korekcji.

sql
SELECT market,
TUMBLE_START(event_time, INTERVAL '1' MINUTE) AS ts_min,
COUNT() AS deposits_1m,
SUM(amount_base) AS sum_1m
FROM silver. payments
GROUP BY market, TUMBLE(event_time, INTERVAL '1' MINUTE);

6) Materializacja kruszyw

Silnik OLAP (ClickHouse/Pinot/Druid): przechowuje kruszywa minutowe/sekundowe do desek rozdzielczych i analityki operacyjnej.
Lakehouse Gold: przechowuje dzienne/godzinne plasterki do sprawozdawczości i pojednania (odtwarzalność).

sql
CREATE MATERIALIZED VIEW mv_ggr_1m
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), market, provider_id) AS
SELECT toStartOfMinute(event_time) AS ts_min,
market,
provider_id,
sumState(stake_base) AS s_stake,
sumState(payout_base) AS s_payout
FROM stream. game_events
GROUP BY ts_min, market, provider_id;

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(event_time) AS event_date,
market, provider_id,
SUM(stake_base) AS stakes_eur,
SUM(payout_base) AS payouts_eur,
SUM(stake_base) - SUM(payout_base) AS ggr_eur
FROM silver. fact_game_financials
GROUP BY 1,2,3;

7) Srebro: normalizacja i pojednanie

Czas i waluta: 'event _ time (UTC)', 'amount _ base', 'fx _ rate _ used', 'fx _ source'.
Klucze/katalogi: 'user _ pseudo _ id',' game _ id', 'provider _ id',' market '.
SCD II: historyzacja wymiaru (użytkownicy/gry/dostawcy/RG/KYC).
Zasady DQ: wyjątkowość klucza, katalogi, zakresy kwot, ważność czasowa.

8) Rejestr jednostek i „poprawne” definicje

Warstwa semantyczna: jednolite wzory GGR/NGR, zakłady/wygrane, konwersja, ARPPU, opóźnienie p95.
Mierniki wersji: 'metric _ version' i 'as-of' obliczenia.
Dockcards: właściciel, formuła, źródła, gotowość SLA.

9) Dokładnie raz/idempotencja i porządek

Autobus: co najmniej raz + podział (lokalne zamówienie).
Przetwarzanie: dedup by 'event _ id' (TTL 24-72h), CEP/window operators with adjustments.
Zlew: commits transakcyjne lub idempotent upsert/merge.
Outbox/Inbox: publikowanie zdarzeń domeny z OLTP z gwarancją.

10) Późne dane i korekty

Dopuszczalna opóźnienie: 2-5 min dla wyświetlaczy operacyjnych; codzienna reasekuracja dla Gold.
Korekty: dodatkowe emisje w OLAP i przeredagowanie złota (idempotent).
Flagi: 'late = true', 'correction _ of = <event _ id>' dla audytu.

11) Obserwowalność i DQ

• pingest 95 → 1 -min showcase ≤ 2-5 s; Złoto codziennie jest gotowe do 06:00 zamek.
• Kompletność ≥ 99. 5%; Okres ważności schematu ≥ 99. 9%; Zasięg śladowy ≥ 98%.
• Mierniki rurociągów: czas opóźnienia/przepustowości/czas zajęty/rozmiar stanu, wskaźnik opóźnienia, szybkość opadania.
• Deski rozdzielcze DQ: Świeżość/Kompletność/Ważność, lejek utraty, karta klucza gorącego.
• Rodowód: droga z brązu do złota/eksportu; analiza wpływu na zmiany.

12) Prywatność, rezydencja, bezpieczeństwo

Minimalizacja PII: pseudonimizacja, oddzielne mapowanie chronione.
Miejsce zamieszkania: EEA/UK/BR - oddzielne katalogi i klucze szyfrujące; zakazanie przyłączeń międzyregionalnych bez powodu.
Szyfrowanie: TLS w tranzycie; KMS/CMK w stanie spoczynku; sygnatury eksportowe + WORM w throttling.
DSAR/RTBF/Legal Hold: selektywne edycje, zamrażanie usuwania, kontrolowane dostęp.

13) Wydajność i koszt

Podział: według daty/rynku/najemcy; clustering/Z-order przez często filtrowane atrybuty.
Zagęszczenie: eliminacja małych plików, regularna OPTYMALIZACJA/PRÓŻNIA.
Materializacja: minuty/sekundy - w OLAP; dzień/godziny - w Gold.
Magazyn wielopoziomowy: gorący/ciepły/zimny, odzyskiwanie SLA, obciążenie zwrotne według polecenia (koszt/GB, koszt/zapytanie).
Preagregacja/szkice: HyperLogLog/ok.

14) Przykłady (fragmenty)

python if count_deposits(window=10MIN) >= 3 \
and sum_deposits(window=10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window_events):
emit_alert("AML_STRUCTURING", user_id, snapshot())

sql
CREATE TABLE silver. payments AS
SELECT EXCEPT(rn) FROM (
SELECT p., ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time) rn
FROM bronze. payment_events p
) WHERE rn = 1;

sql
MERGE INTO silver. fact_bets s
USING stage. fact_bets_delta d
ON s. bet_id = d. bet_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

15) Procesy i RACI

• Platforma danych (Lakehouse/katalog/ACID, zagęszczenie),
• Streaming (jednostki/CEP/dedup),
• Analityka domeny (metryki/złoto).
• A (Odpowiedzialność): szef danych/CDO.
• C (skonsultowano się): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), SRE (SLO/стоимоста), Security.
• I (Poinformowany): BI/Produkt/Marketing/Operacje.

16) Plan działania w zakresie wdrażania

1. Lakehouse Bronze/Silver (stoły ACID), spożycie z Kafka, systemy rejestrowe.

2. Podstawowe jednostki strumieniowe (1-5 minut) w OLAP; pokaz Gold. ggr_daily (D + 1 do 06:00).

3. DQ-as-code for Payments/Gameplay, Świeżość/Deski rozdzielcze kompletności.

4. Zagęszczenie/OPTIMIZE, minimalne mierniki kosztów i alerty lag/late/dup.

• Rozszerzenie srebra (SCD II dla użytkowników/gier/dostawców), rodowód i analiza wpływu.
• Asynchroniczne poszukiwania (RG/KYC/ASN/BIN), późna kontrola korekcji.
• Warstwa semantyczna mierników, przepisy eksportowe (WORM/podpisy).

• Multi-region, DR/replay simulator, automatyczne dostrajanie okien i znaków wodnych.
• Deski rozdzielcze, obciążenie zwrotne/kwoty, wielopoziomowe przechowywanie i archiwizacja.
• Automatyczna generacja dokumentacji prezentacyjnej i kart metrycznych.

17) Lista kontrolna przedsprzedaży

• Systemy i umowy w rejestrze; testy porównania pleców są zielone.
• Dedup, znak wodny/dozwolone opóźnienie, DLQ zawarte.
• /OPTIMIZE/VACUUM jest skonfigurowany w harmonogramie.
• SLO: p95 ingest → minute-view, Gold дд06 06:00; alerts lag/late/dup/state size.
• Zasady DQ są aktywne; linia jest widoczna od brązu do eksportu.
• KMS RBAC/ABAC; pobyt i DSAR/RTBF/Legal Hold testowane.
• Koszt kontrolowany (koszt/GB, koszt/zapytanie, udział na zimno), limity powtórzeń.

18) Przeciwdziałanie modelom i ryzyku

Mieszanie surowych i zgłoszonych danych w tej samej tabeli: narusza odtwarzalność.
Brak kompresji: eksplozja małych plików → drogie żądania.
Obliczanie FX „retroaktywnie”: Łamie historię i raporty.
Brak znaków wodnych/późna polityka: sklepy i wpisy „float”.
Pełne ponowne naładowanie niepotrzebnie: użycie/przyrosty i korekty MERGE.
PII w Analytics: Zachowaj mapowanie oddzielnie, włącz CLS/RLS.

19) Słownik (krótki)

Lakehouse - jezioro danych + tablice ACID i silnik SQL.
Brąz/srebro/złoto - warstwy surowe/znormalizowane/serwujące.
Znak wodny - limit gotowości okna według czasu zdarzenia.
Zmaterializowany widok to wstępnie obliczona prezentacja do szybkiego czytania.
Podróże w czasie - czytanie historycznych wersji tabel.
WORM - niezmienne przechowywanie artefaktów eksportowych.

20) Sedno sprawy

Jezioro danych o odpowiedniej agregacji strumienia jest dyscypliną warstw i kontraktów: Brąz „jak jest”, Srebro dla normalizacji i jakości, OLAP dla paneli minutowych, Złoto dla raportów odtwarzalnych. Zarządzanie oknami i znakami wodnymi, deduplikacji i kompresji, prywatności i kosztów, otrzymujesz szybkie, weryfikowalne i zgodne ze sklepami dla zarządzania produktem, zgodności i operacyjnego.