Data Lake i scentralizowane przechowywanie
(Sekcja: Technologia i infrastruktura)
Krótkie podsumowanie
Data Lake to podstawowa warstwa scentralizowanego przechowywania surowców i skonsolidowanych zbiorów danych. Dla iGaming, akceptuje zakłady/płatności/zdarzenia dziennika gier, przesyłania partnerskie, CDC z OLTP i daje je analityce, anty-oszustwa, CRM i BI. Nowoczesna praktyka - Lakehouse: open column formats + ACID table layer + single directory + transactions/data versions. Kluczem do sukcesu jest dyscyplina programów i podziału, zarządzanie kosztami, bezpieczeństwo PII oraz ścisła kultura operacyjna (DQ, lineage, DR).
Rola jeziora danych w platformie iGaming
Pojedynczy punkt prawdy dla analityki: przechowywanie surowych i oczyszczonych danych niezależnie od źródła i formatu.
Elastyczność: wsparcie dla serii i strumieniowania (CDC/złącza, strumienie imprez).
Ewolucja: od surowego brązu do zgodnych przypadków biznesowych Silver i Gold.
Podział odpowiedzialności: usługi produkcyjne pisać do opony/staging, analityka/ML zużywa z warstw jeziora.
Modele architektoniczne: Jezioro vs Lakehouse
Data Lake (S3/ADLS/GCS + Parquet/ORC): schemat na czytanie, tanie przechowywanie, elastyczne formaty.
Lakehouse (Delta/Iceberg/Hudi over Parquet): transakcje ACID, upsert/merge, podróże w czasie, pliki kompaktowe, próżnia, indeksowanie/klastrowanie.
Praktyka: Lakehouse jest korzystne dla iGaming jako głównej warstwy, a zewnętrzne OLAP (ClickHouse/Query/Snowflake/Pinot) jako prezentacje i silniki specjalne.
Model warstwy medalionu
Brąz (Raw/Staging): pliki surowe ze źródeł (CDC, log dumps, affiliate CSV, webhooks). Minimalna walidacja, „tak jak jest”.
Srebro (Zgodne): czyszczenie/dedup, normalizacja walut/stref czasowych, wpisywanie, pomiary SCD, spójne klucze.
Złoto (Marts/Serving): agregaty dla GGR/NGR/LTV/Retention, zmaterializowane sklepy dla BI/CRM/anti-fraud.
TTL: agresywny na brązie, umiarkowany na srebrze, długoterminowy na złocie.
Formaty i warstwy stołowe
Kolumna: Parkiet (de facto standard), ORC.
Otwarte formaty tabeli (ACID):- Delta Lake - transakcje, „MERGE”, podróże w czasie, optymalizacja/próżnia, Z-order.
- Apache Iceberg - tabele z manifestami/migawkami, ukryte partycjonowanie, 'MERGE/DELETE/UPDATE', podróże w czasie.
- Apache Hudi - kopiowanie/pisanie/łączenie-on-read, upsert-optimizacja, ekstrakty przyrostowe.
- Dokonaj wyboru w oparciu o ekosystem i wymagania dla upsert/streaming/elastyczność ewolucji systemów.
Katalog i przerzut
Pojedynczy katalog (katalog Hive Metastore/Unity/Klej/platforma) przechowuje schematy, strony, wersje, prawa.
Wymagania: spójność transakcyjna z warstwą stołu, wsparcie dla wielu silników (Spark, Trino/Presto, Flink, dbt), audyt/linia.
Programy i ewolucja
Schemat umowy: ustalić obowiązkowe pola, rodzaje, semantyka; źródła wersji ('schema _ version').
Ewolucja: dodawanie pól fakultatywnych, zakaz przełamywania zmian bez migracji; automatyczne systemy kontroli w rurociągach.
Segmentacja PII: pola wrażliwe - na oddzielne kolumny/tabele z szyfrowaniem i oddzielnymi prawami.
Podział danych i ułożenie
Data/godzina - klucz bazowy dla wydarzeń; pola opcjonalne: "kraj", "produkt", "najemca _ id'.
W stylu ula мута: 's3 ://lake/bronze/payments/source = pspA/dt = 2025-11-05/hour = 13/part-0001. parkiet '.
Klastrowanie/sortowanie: Z-order/Sortuj klucze według często filtrowanych pól (player_id, kraj).
Rozmiar pliku: Cel dla 128-1024 MB; unikać „małych plików” (patrz poniżej).
Wirtualne kolumny (Iceberg/Delta) do ukrytego partycjonowania.
Małe pliki i problem z zagęszczeniem
Źródła strumień małe kawałki → degradacja skanów i metadanych.
Rozwiązanie: okresowa optymalizacja/zagęszczanie (koalesce), harmonogram zadań zagęszczania, partyjny mikro-pakiet na spożycie, „AutoOptimize” (jeśli jest dostępny).
Zasada scalania-on-read vs copy-on-write jest równowagą między opóźnieniem zapisu a szybkością odczytu.
Injest: partia, strumień, CDC
CDC z OLTP (Debezium/złącza) → Brąz (minuta świeżości).
Strumień (Kafka/Flink/Spark Structured Streaming) → Srebro/Złoto stopniowo (upsert/fuzja).
Partia (raporty partnerskie/CSV/JSON) - poprzez „odbiorniki” z manifestami, kontrolę duplikatów przez checksum.
Idempotencja: klucze (idempotency_key), dedup by (key, ts), „znaki wodne” dla późniejszych rekordów.
Jakość danych (DQ) i rodowód
Kontrole DQ: kompletność, wyjątkowość kluczy, zakresy, integralność odniesienia (listy krajów/walut), zasady prowadzenia działalności (GGR ≥ 0).
Liniowanie: wykres zależności od raportu do źródła, wersja kodu modelu i migawka tabeli.
Sterowanie schematem: automatyczne testy pleców/przednich kompat, które blokują zmiany „łamania”.
Pliki do pobrania audytu: kto/kiedy/ile, odrzucone partie, przekaźniki.
Obsługa i dostęp
Silniki SQL: iskra/trino/presto do doraźnych i transformacji; dbt dla modeli ELT.
W czasie rzeczywistym/w czasie zbliżonym do rzeczywistego: Pinot/Druid/ClickHouse jako sklepy; Lakehouse jest źródłem przez zlew przyrostowy.
Udostępnianie danych: udostępnianie tabel/migawek zewnętrznym poleceniom bez kopii (jeśli obsługiwany jest przez format).
Bezpieczeństwo, PII i wielopoziomowe
Szyfrowanie: odpoczynek (KMS) i tranzyt (TLS).
IAM/RBAC/ABAC: role na poziomie katalogu/tabeli/kolumny/wiersza (maskowanie, polityka dynamiczna).
Segmentacja według regionu (lokalizacja UE/Turcja/LatAm): izolacja wiader i puli obliczeniowe.
Wielopoziomowość: obszar nazw/katalogi i prefiksy ścieżek, filtry według 'lokator _ id', opcjonalnie - zasady rzędu.
Audyt dostępu: dzienniki odczytu/zmiany metadanych, dzienniki retencji i niewymiarowe.
Zarządzanie kosztami
Klasy pamięci masowej: gorący (często czytelny) w klasie standardowej, archiwum - w klasach zimnych/lodowcowych z zasadami TTL.
Partytura/klastry zmniejszyć skany → mniej niż $ $.
Zmaterializowane sklepy dla drogich raportów; Pamięć podręczna wyników BI.
Kompresja i „poprawny rozmiar pliku” - mniej metadanych i I/O.
Kwoty i budżetowanie: limity klastrów obliczeniowych/miejsc pracy, raporty kosztów zbioru danych/zespołu.
Usuwanie śmieci: 'VACUUM/REWRITE' w formatach tabeli, TTL Bronze.
DR i odtwarzalność
Wersioning stołu w czasie podróży i migawki katalogowe.
Replikacja międzyregionalna wiader i metadanych.
PITR: przechowywanie dzienników transakcji tabeli (Delta/Iceberg/Hudi) i dzienników rurociągów.
Dzień gry: regularne ćwiczenia odzyskiwania i przełączanie regionów.
Obserwowalność i SLO
Świeżość SLO: brąz ≤ 5 min, srebro ≤ 15-30 min, złoto ≤ 60 min (przykład).
Mierniki: objętość/liczba plików, średni rozmiar pliku parkietu, czas skanowania, udział pominiętych partii, częstotliwość zagęszczania, koszt/data, błędy DQ, późne dane.
Alerty: mały wzrost plików, wzrost kosztów, degradacja p95/p99, naruszenie DQ/schematu, strumień-niebieski lag.
Nazewnictwo konwencji i ścieżek (szablon)
s3://<lake>/<layer>/<domain>/<dataset>/
source=<sys>/ # для Bronze dt=YYYY-MM-DD/
hour=HH/
country=XX/Nazwy zbiorów danych: 'bets _ raw', 'payments _ cdc',' players _ silver ',' mart _ ggr _ daily '.
Kolumny metadanych: 'ingest _ ts',' source ',' schema _ version ',' trace _ id', 'lokator _ id'.
Przykłady (uogólnione)
1) Góra lodowa: Srebrny stół z ukrytą stroną według daty
sql
CREATE TABLE silver. bets (
bet_id BIGINT,
player_id BIGINT,
country STRING,
stake DECIMAL(18,2),
win DECIMAL(18,2),
event_ts TIMESTAMP,
ingest_ts TIMESTAMP,
schema_version INT
)
PARTITIONED BY (days(event_ts))
TBLPROPERTIES ('format-version'='2');2) Delta: przyrostowa przewaga z CDC
sql
MERGE INTO silver. players t
USING bronze. players_cdc s
ON t. player_id = s. player_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;3) Polityka TTL dla brązu (pomysł)
bronze/: keep 30 days silver/: keep 365 days (non-PII), 90 days (PII masked)
gold/marts/: keep 2–3 years (aggregated)Lista kontrolna implementacji
1. Wybierz format tabeli (Delta/Iceberg/Hudi) i katalog; zbieżność z silnikami (Spark/Trino/Flink/dbt).
2. Zdefiniuj warstwy medalionu, zasady TTL i odpowiedzialność zespołu.
3. Przechwytywanie kontraktów schematów, kontrola ewolucji, segmentacja PII i szyfrowanie.
4. Układ projektu: części, klawisze sortowania, rozmiar pliku docelowego; umożliwia zagęszczenie.
5. Konfiguracja ingestu (CDC/stream/batch) z idempotencją i deduplikacją.
6. Włącz DQ/lineage, katalog metadanych i audyt.
7. Zdefiniuj świeżość/koszt SLO, deski rozdzielcze mierników i wpisów.
8. Zorganizuj DR: migawki/replikacja/odzyskiwanie + regularne ćwiczenia.
9. Ujednolicenie nazw i ścieżek, kolumn meta ('ingest _ ts',' source ',' schema _ version ').
10. Przynieś prezentacje Gold i obsługę w czasie rzeczywistym do odpowiednich silników OLAP/RT.
Anty-wzory
Jeden wspólny „worek” bez warstw i TTL → chaos i eksplozja kosztów.
Tylko przegrody czasowe z wyłączeniem kraju/produktu → ciężkie skany.
Wątki, które tworzą tysiące małych plików/godzinę bez zagęszczania.
Brak kontroli nad systemami i DQ → „łamanie” zmian i nieufność do raportów.
Mieszanie PII z gablotami Gold bez maskowania/separacji praw.
Hardcode praw dostępu na poziomie wiader zamiast katalogu i polityki tabelarycznej.
Podsumowanie
Modern Data Lake for iGaming to Lakehouse z otwartym formatem stołu, jednym katalogiem i modelem medalionu. Dyscyplina schematów/stron, zagęszczenie przeciwko małym plikom, DQ/rodowód, bezpieczeństwo PII i higiena kosztów przekształcają warstwę jeziora w zrównoważony fundament: tani do przechowywania, szybki do odczytu, przewidywalny w SLO i gotowy do DR. Takie wagi fundamentowe do szczytów turniejowych i obsługuje zarówno analizy partii i sklepy w czasie zbliżonym do rzeczywistego.