Data Lake та централізоване зберігання
(Розділ: Технології та Інфраструктура)
Коротке резюме
Data Lake - базовий шар централізованого зберігання сировини і консолідованих датасетів. Для iGaming він приймає події ставок/платежів/ігрових логів, партнерські вивантаження, CDC з OLTP і віддає їх аналітиці, антифроду, CRM і BI. Сучасна практика - Lakehouse: відкриті колонкові формати + ACID-табличний шар + єдиний каталог + транзакції/версії даних. Ключ до успіху - дисципліна схем і партіонування, управління вартістю, безпека PII і сувора операційна культура (DQ, lineage, DR).
Роль Data Lake в платформі iGaming
Єдина точка правди для аналітики: зберігання сирих і очищених даних незалежно від джерела і формату.
Гнучкість: підтримка batch і streaming (CDC/конектори, event-стріми).
Еволюція: від сирих Bronze до конформних Silver і бізнес-вітрин Gold.
Поділ відповідальності: прод-сервіси пишуть в шину/стейджинг, аналітика/ML споживає з шарів Lake.
Архітектурні моделі: Lake vs Lakehouse
Data Lake (S3/ADLS/GCS + Parquet/ORC): schema-on-read, дешеве сховище, гнучкість форматів.
Lakehouse (Delta/Iceberg/Hudi поверх Parquet): ACID-транзакції, upsert/merge, time-travel, компактні файли, вакуум, індексація/кластеризація.
Практика: для iGaming вигідний Lakehouse як основний шар, а зовнішні OLAP (ClickHouse/BigQuery/Snowflake/Pinot) - як вітрини і спец-рушії.
Медальйонна модель шарів
Bronze (Raw/Staging): сирі файли від джерел (CDC, лог-дампи, партнерські CSV, webhooks). Мінімальна валідація, «як є».
Silver (Conformed): чистка/дедуп, нормалізація валют/часових поясів, приведення типів, SCD-вимірювання, консистентні ключі.
Gold (Marts/Serving): агрегати для GGR/NGR/LTV/Retention, матеріалізовані вітрини під BI/CRM/антифрод.
TTL: агресивний на Bronze, помірний на Silver, довгостроковий на агрегатах Gold.
Формати та табличні шари
Колонкові: Parquet (де-факто стандарт), ORC.
Відкриті табличні формати (ACID):- Delta Lake - транзакції,'MERGE', time-travel, оптимізація/вакуум, Z-order.
- Apache Iceberg - таблиці з маніфестами/снапшотами, прихована партиціонізація,'MERGE/DELETE/UPDATE', time-travel.
- Apache Hudi - copy-on-write/merge-on-read, upsert-оптимізація, інкрементальні витяги.
- Вибір робіть по екосистемі і вимогам до upsert/стрімінгу/гнучкості еволюції схем.
Каталог і метастор
Єдиний каталог (Hive Metastore/Unity/Glue/платформні каталоги) зберігає схеми, партії, версії, права.
Вимоги: транзакційна узгодженість з табличним шаром, підтримка декількох рушіїв (Spark, Trino/Presto, Flink, dbt), audit/lineage.
Схеми та еволюція
Schema contract: фіксуйте обов'язкові поля, типи, семантику; джерела версіонуйте ('schema _ version').
Еволюція: додавання опціональних полів, заборона ламаючих змін без міграцій; автоматичні схем-чекери в пайплайнах.
PII-сегментація: чутливі поля - в окремі стовпці/таблиці з шифруванням і окремими правами.
Партіонування та lay-out даних
Дата/година - базовий ключ для подій; доп. поля: `country`, `product`, `tenant_id`.
Hive-style шлях: `s3://lake/bronze/payments/source=pspA/dt=2025-11-05/hour=13/part-0001. parquet`.
Кластеризація/сортування: Z-order/Sort keys по часто фільтруваних полях (player_id, country).
Розмір файла: цілитеся в 128-1024 МБ; уникайте «small files» (див. нижче).
Віртуальні колонки (Iceberg/Delta) для прихованої партиціонізації.
Проблема small files і компакшн
Джерела стримлять маленькі чанки → деградація сканів і метаданих.
Рішення: періодичний optimize/compaction (coalesce), планувальник compaction-задач, батч-мікро-bundle на ingestion,'autoOptimize'( якщо доступно).
Політика merge-on-read vs copy-on-write - баланс між латентністю запису і швидкістю читання.
Інжест: batch, stream, CDC
CDC з OLTP (Debezium/конектори) → Bronze (хвилинна свіжість).
Stream (Kafka/Flink/Spark Structured Streaming) → Silver/Gold інкрементально (upsert/merge).
Batch (партнерські звіти/CSV/JSON) - через «приймачі» з маніфестами, контроль дублів по checksum.
Idempotency: ключі (idempotency_key), дедуп по (key, ts), «водяні знаки» (watermarks) для пізніше прибулих записів.
Якість даних (DQ) і lineage
DQ-чеки: повнота, унікальність ключів, діапазони, референсна цілісність (списки країн/валют), бізнес-правила (GGR ≥ 0).
Лініедж: граф залежностей від звіту до джерела, версія коду моделі і снапшота таблиці.
Контроль схем: автоматичні тести back/forward-compat, що блокують «ламаючі» зміни.
Аудит завантажень: хто/коли/скільки, відхилені партії, ретраї.
Сервінг і доступ
SQL-рушії: Spark/Trino/Presto для ad-hoc і трансформацій; dbt для ELT-моделей.
Real-time/near-real-time: Pinot/Druid/ClickHouse як вітрини; Lakehouse - джерело через інкрементальні sink.
Data Sharing: шарінг таблиць/снапшотів зовнішнім командам без копій (якщо підтримується форматом).
Безпека, PII і мульти-тенантність
Шифрування: at-rest (KMS) и in-transit (TLS).
IAM/RBAC/ABAC: ролі на рівні каталогу/таблиці/колонки/рядки (маскування, динамічні політики).
Сегментація по регіонах (локалізація ЄС/Туреччина/ЛатАм): ізоляція бакетів і обчислювальних пулів.
Мульти-тенантність: namespace/каталоги і префікси шляхів, фільтри по'tenant _ id', опціонально - row-level policies.
Аудит доступу: логи читань/змін метаданих, ретеншн і немодифіковані журнали.
Управління вартістю
Класи зберігання: гаряче (часто читається) в стандартному класі, архів - в холодних/Glacier-класах з TTL-політиками.
Партіонування/кластери зменшують скани → менше $ $.
Матеріалізовані вітрини для дорогих звітів; кеш результатів BI.
Компакшн і «правильний розмір файлу» - менше метаданих і I/O.
Квоти та бюджетування: ліміти на compute-кластери/джоби, звіти по вартості на датасет/команду.
Видалення сміття: 'VACUUM/REWRITE'в табличних форматах, TTL Bronze.
DR і відтворюваність
Версіонування таблиць (time-travel) і снапшоти каталогу.
Крос-регіональна реплікація бакетів і метаданих.
PITR: зберігання журналів транзакцій таблиць (Delta/Iceberg/Hudi) і логів пайплайнів.
Game-day: регулярні навчання відновлення і перемикання регіонів.
Спостережуваність і SLO
SLO свіжості: Bronze ≤ 5 хв, Silver ≤ 15-30 хв, Gold ≤ 60 хв (приклад).
Метрики: обсяг/кількість файлів, середній розмір паркет-файлу, час сканів, частка пропущених партій, частота compaction, вартість/датасет, помилки DQ, що запізнилися дані.
Алерти: сплеск small files, зростання вартості, деградація p95/p99, порушення DQ/схем, відставання стрім-синків.
Конвенції неймінгу та шляхів (шаблон)
s3://<lake>/<layer>/<domain>/<dataset>/
source=<sys>/ # для Bronze dt=YYYY-MM-DD/
hour=HH/
country=XX/Імена датасетів: `bets_raw`, `payments_cdc`, `players_silver`, `mart_ggr_daily`.
Колонки-метадані: `ingest_ts`, `source`, `schema_version`, `trace_id`, `tenant_id`.
Приклади (узагальнено)
1) Iceberg: таблиця Silver з прихованою партією за датою
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 з 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) Політика TTL для Bronze (ідея)
bronze/: keep 30 days silver/: keep 365 days (non-PII), 90 days (PII masked)
gold/marts/: keep 2–3 years (aggregated)Чек-лист впровадження
1. Виберіть табличний формат (Delta/Iceberg/Hudi) і каталог; узгодьте з рушіями (Spark/Trino/Flink/dbt).
2. Визначте медальйонні шари, правила TTL і відповідальність команд.
3. Зафіксуйте schema contracts, контроль еволюції, PII-сегментацію і шифрування.
4. Спроектуйте lay-out: партії, сорт-ключі, цільовий розмір файлу; увімкніть compaction.
5. Налаштуйте ingest (CDC/stream/batch) з ідемпотентністю і дедупом.
6. Увімкніть DQ/lineage, каталог метаданих і аудит.
7. Визначте SLO свіжості/вартості, дашборди метрик і алерти.
8. Організуйте DR: снапшоти/реплікацію/відновлення + регулярні навчання.
9. Стандартизуйте неймінг і шляхи, метаколонки («ingest _ ts», «source», «schema _ version»).
10. Винесіть Gold-вітрини і real-time сервінг в відповідні OLAP/RT-рушії.
Антипатерни
Один загальний «мішок» без шарів і TTL → хаос і вибух вартості.
Партіонування тільки за часом без урахування країни/продукту → важкі скани.
Потоки, що створюють тисячі дрібних файлів/год, без compaction.
Відсутність контролю схем і DQ → «ламаючі» зміни і недовіра до звітів.
Змішування PII з Gold-вітринами без маскування/поділу прав.
Хардкод прав доступу на рівні бакетів замість каталогу і табличних політик.
Підсумки
Сучасний Data Lake для iGaming - це Lakehouse з відкритим табличним форматом, єдиним каталогом і медальйонною моделлю. Дисципліна схем/партій, compaction проти small files, DQ/lineage, PII-безпека і вартісна гігієна перетворюють lake-шар в стійкий фундамент: дешевий для зберігання, швидкий для читання, передбачуваний по SLO і готовий до DR. такий фундамент масштабується під турнірні піки і підтримує і batch-аналітику, і near-real-time вітрини.