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 витрины.