Lac de date și stocare centralizată

(Secțiunea: Tehnologie și infrastructură)

Scurt rezumat

Data Lake este stratul de bază al stocării centralizate a materiilor prime și a seturilor de date consolidate. Pentru iGaming, acceptă evenimente de pariuri/plată/jurnal de joc, încărcări afiliate, CDC de la OLTP și le oferă analitice, anti-fraudă, CRM și BI. Practică modernă - Lakehouse: formate de coloane deschise + strat de tabel ACID + director unic + tranzacții/versiuni de date. Cheia succesului este disciplina schemelor și partiționării, managementul costurilor, securitatea PII și o cultură strictă de operare (DQ, descendență, DR).

Rolul lui Data Lake în platforma iGaming

Un singur punct de adevăr pentru analiză: stocarea datelor brute și purificate, indiferent de sursă și format.
Flexibilitate: suport pentru lot și streaming (CDC/conectori, fluxuri de evenimente).
Evoluție: de la bronz brut la cazuri de afaceri conforme Silver și Gold.
Împărțirea responsabilității: serviciile de producție scriu anvelopelor/montajului, analytics/ML consumă din straturile lacului.

Modele arhitecturale: Lacul vs Lakehouse

Data Lake (S3/ADLS/GCS + Parchet/ORC): schema-on-read, stocare ieftină, formate flexibile.
Lakehouse (Delta/Iceberg/Hudi over Parchet): tranzacții ACID, upsert/îmbinare, călătorie în timp, fișiere compacte, vid, indexare/grupare.
Practică: Lakehouse este benefic pentru iGaming ca strat principal și OLAP-uri externe (ClickHouse/BigQuery/Snowflake/Pinot) ca vitrine și motoare speciale.

Modelul stratului de medalion

Bronz (Raw/Staging): fișiere brute din surse (CDC, dumps jurnal, CSV afiliat, webhooks). Validare minimă, „așa cum este”.
Argint (Conform): curățare/dedup, normalizare valute/fusuri orare, tastare, măsurători SCD, chei consistente.
Aur (Marts/Servire): agregate pentru GGR/NGR/LTV/Retentie, storefronturi materializate pentru BI/CRM/antifrauda.
TTL: Agresiv pe bronz, moderat pe argint, pe termen lung pe unități de aur.

Formate și straturi de tabel

Coloana: Parchet (standard de facto), ORC.

Formate de tabel deschise (ACID):

Delta Lake - tranzactii, 'MERGE', calatorie in timp, optimizare/vid, comanda Z.
Apache Iceberg - tabele cu manifeste/instantanee, partiționare ascunsă, 'MERGE/ȘTERGE/UPDATE', călătorie în timp.
Apache Hudi - copy-on-write/merge-on-read, upsert-optimization, extracții incrementale.
Faceți alegerea pe baza ecosistemului și a cerințelor pentru upsert/streaming/flexibilitatea evoluției sistemelor.

Catalog și metastor

Un singur director (Stup Metastore/Unitate/Lipici/platformă directoare) stochează scheme, partide, versiuni, drepturi.
Cerințe: consistență tranzacțională cu un strat de masă, suport pentru mai multe motoare (Spark, Trino/Presto, Flink, dbt), audit/descendență.

Scheme și evoluție

Contract schema: fixați câmpurile obligatorii, tipurile, semantica; surse de versionare („schema _ versiune”).
Evoluție: adăugarea de câmpuri opționale, interzicerea schimbărilor de rupere fără migrații; sisteme de verificare automată în conducte.
segmentare PII: câmpuri sensibile - în coloane/tabele separate cu criptare și drepturi separate.

Partiționarea datelor și lay-out

Data/ora - cheia de baza pentru evenimente; câmpuri opționale: "țară", "produs", "chiriaș _ id'.
путь în stil stup: 's3 ://lake/bronze/payments/source = pspA/dt = 2025-11-05/hour = 13/part-0001. parchet ".
Clustering/sortare: Z-ordine/sortare chei de câmpuri filtrate frecvent (player_id, țară).
Dimensiune fișier: Scop pentru 128-1024 MB; evita „fișiere mici” (a se vedea mai jos).
Coloane virtuale (Iceberg/Delta) pentru partiționare ascunsă.

Fișiere mici și probleme de compactare

Sursele transmit bucăți mici → degradarea scanărilor și metadatelor.
Soluție: optimizare/compactare periodică (coalesce), planificator de sarcini de compactare, micro-pachet de lot pe ingestie, „autoOptimize” (dacă este disponibil).
Politica de fuzionare pe citire vs copy-on-write este un echilibru între latența de scriere și viteza de citire.

Injest: lot, flux, CDC

CDC de la OLTP (Debezium/conectori) → bronz (prospețime minut).
Stream (Kafka/Flink/Spark Structured Streaming) → Silver/Gold incremental (upsert/fuziune).
Lot (rapoarte partenere/CSV/JSON) - prin „receptoare” cu manifeste, controlul duplicatelor prin checksum.
Idempotența: chei (idempotency_key), dedup by (cheie, ts), „filigrane” pentru înregistrările ulterioare.

Calitatea datelor (DQ) și descendența

DQ verifică: integritatea, unicitatea cheilor, intervalele, integritatea de referință (liste de țară/valută), regulile de afaceri (GGR ≥ 0).
Liniage: graficul dependențelor de la raport la sursă, versiunea codului modelului și instantaneul tabelului.
Controlul schemei: teste automate back/forward-compat care blochează modificările „breaking”.
Descărcări de audit: cine/când/câte, loturi respinse, retribuții.

Servirea și accesul

Motoare SQL: Spark/Trino/Presto pentru transformări și transformări ad-hoc; dbt pentru modelele ELT.
Timp real/aproape în timp real: Pinot/Druid/ClickHouse ca storefronts; Lakehouse este o sursă prin chiuvetă incrementală.
Partajarea datelor: partajarea tabelelor/instantaneelor la comenzi externe fără copii (dacă este acceptată de format).

Securitate, PII și multi-chirie

Criptare: în repaus (KMS) și în tranzit (TLS).
IAM/RBAC/ABAC: roluri la nivelul directorului/tabelului/coloanei/rândului (mascare, politici dinamice).
Segmentarea pe regiuni (localizarea UE/Turcia/LatAm): izolarea găleților și a bazinelor de calcul.
Multi-chirie: namespace/directoare și prefixe de cale, filtre prin 'chiriaș _ id', politici opționale - la nivel de rând.
Auditarea accesului: jurnalele de citire/schimbare a metadatelor, jurnalele de retenție și jurnalele nemodificabile.

Managementul costurilor

Clase de depozitare: fierbinte (de multe ori lizibil) într-o clasă standard, arhivă - în clase rece/ghețar cu politici TTL.
Partiționarea/clusterele reduc scanările → mai puțin de $ $.
storefronturi materializate pentru rapoarte scumpe; Rezultate BI cache.
Compresie și „dimensiunea corectă a fișierului” - mai puține metadate și I/O.
Cote și bugetare: limite privind clusterele de calcul/locuri de muncă, rapoarte de costuri privind setul de date/echipa.
Îndepărtarea gunoiului: „VACUUM/REWRITE” în formate de masă, TTL Bronze.

DR și reproductibilitate

Tabel de călătorie în timp și instantanee catalog.
Replicarea transregională a găleţilor şi metadatelor.
PITR: stocarea jurnalelor de tranzacții de masă (Delta/Iceberg/Hudi) și a jurnalelor de conducte.
Ziua jocului: exerciții regulate de recuperare și regiuni de comutare.

Observabilitate și SLO

SLO prospețime: bronz ≤ 5 min, argint ≤ 15-30 min, aur ≤ 60 min (exemplu).
Valori: volumul/numărul de fișiere, dimensiunea medie a fișierului de parchet, timpul de scanare, cota loturilor pierdute, frecvența de compactare, costul/data, erorile DQ, datele târzii.
Alerte: val de fișiere mici, creșterea costurilor, degradarea p95/p99, încălcarea DQ/schemă, stream-albastru lag.

Denumirea convențiilor și căilor (șablon)


s3://<lake>/<layer>/<domain>/<dataset>/
source=<sys>/      # для Bronze dt=YYYY-MM-DD/
hour=HH/
country=XX/

Nume set de date: 'bet _ raw', 'payments _ cdc', 'players _ silver', 'mart _ ggr _ daily'.
Coloane metadate: 'ingest _ ts',' source ',' schema _ version ',' trace _ id', 'tenant _ id'.

Exemple (generalizate)

1) Iceberg: Masă de argint cu petrecere ascunsă după dată

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: Upsert incremental de la 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) Politica TTL pentru bronz (idee)


bronze/: keep 30 days silver/: keep 365 days (non-PII), 90 days (PII masked)
gold/marts/: keep 2–3 years (aggregated)

Lista de verificare a implementării

1. Selectați formatul tabelului (Delta/Iceberg/Hudi) și directorul; aliniați-vă cu motoarele (Spark/Trino/Flink/dbt).
2. Definiți straturile medalionului, regulile TTL și responsabilitatea echipei.
3. Capturați contractele de schemă, controlul evoluției, segmentarea PII și criptarea.
4. Design lay-out: părți, chei de sortare, dimensiunea fișierului țintă; activați compactarea.
5. Configurați ingerarea (CDC/stream/lot) cu idempotență și eliminare a duplicatelor.
6. Activați DQ/descendență, catalog de metadate și audit.
7. Definiți SLO-uri de prospețime/cost, tablouri de bord de valori și alerte.
8. Organizați DR: instantanee/replicare/recuperare + exerciții regulate.
9. Standardizați denumirea și traseele, coloanele meta ('inger _ ts',' source ',' schema _ version ').
10. Aduceți vitrinele Gold și servirea în timp real la motoarele OLAP/RT potrivite.

Anti-modele

Un „sac” comun fără straturi și TTL → haos și o explozie de costuri.
Partiționarea numai în timp, cu excepția țării/produsului → scanări grele.
Fire care creează mii de fișiere mici/oră fără compactare.
Lipsa controlului schemelor și DQ → „ruperea” schimbărilor și neîncrederea în rapoarte.
Amestecarea PII cu vitrinele Gold fără separarea de mascare/drepturi.
Codul hardcode al drepturilor de acces la nivelul găleților în loc de un director și politici tabelare.

Rezumat

Modern Data Lake pentru iGaming este un Lakehouse cu un format de masă deschisă, un singur catalog și un model de medalion. Disciplina de scheme/partide, compactarea împotriva fișierelor mici, DQ/descendență, PII de securitate și igiena costurilor transforma stratul lacului într-o fundație durabilă: ieftin pentru a stoca, rapid pentru a citi, previzibil în SLO și gata pentru DR O astfel de fundație scalează la vârfuri de turneu și sprijină atât analiza loturilor și aproape în timp real.