Хранилища данных

1) Назначение и роль DWH в iGaming

• Единые определения метрик (GGR/NGR, ARPPU, Retention, Churn).
• Репродуцируемые отчеты для регуляторов и внутренних стейкхолдеров.
• Быстрые витрины для BI/операционных панелей и источники для моделей.
• Контроль качества, lineage и безопасность на уровне платформы.

2) Архитектурные варианты

2.1 Classic DWH

ETL → DWH (звезда/снежинка) → BI.
Плюсы: управляемые модели, сильная консистентность.
Минусы: дорогие загрузки, сложный backfill, ограниченная гибкость.

2.2 Lakehouse DWH

Bronze/Silver/Gold на ACID-таблицах (Delta/Iceberg/Hudi) + движок SQL/MPP.
Плюсы: единый сторедж, time-travel, простой reprocessing.
Минусы: требует дисциплины слоев и DQ, зрелой оркестрации.

2.3 Гибрид

Lakehouse как «источник истины» (Bronze/Silver), DWH-март в MPP (ClickHouse/Pinot/Druid/Cloud DWH) для высокоскоростного чтения.
Плюсы: баланс стоимости и производительности, гибкие витрины.
Минусы: двойная поддержка схем и катала, нужна синхронизация.

Рекомендация: для iGaming — Lakehouse + DWH-март (гибрид). Bronze/Silver — стандартизуют, Gold/Real-time marts — обслуживают нагрузки чтения.

3) Моделирование данных

3.1 Звезда и Снежинка

Факт-таблицы: узкие, событийные: `fact_bets`, `fact_payouts`, `fact_payments`.
Измерения: `dim_users` (SCD), `dim_games`, `dim_providers`, `dim_markets`.
Снежинка уместна в Silver (нормализация), Звезда — в Gold (чтение).

3.2 Data Vault 2.0 (ядро интеграции)

Hubs (бизнес-ключи), Links (отношения), Satellites (контекст/история).
Применять в Silver для долгоживущих интеграций провайдеров/PSP.

3.3 SCD I/II/III

SCD II для RG/KYC/каналов и игровых атрибутов (RTP/волатильность).
Строгие интервалы `valid_from/valid_to`, корректные join-ы по времени.

4) Загрузка: ETL/ELT, CDC и инкременты

ELT-подход: загрузка в Silver → трансформации в DWH.
CDC: Debezium/лог-репликация из OLTP; мержи идемпотентны.
Инкременты: по воде времени (`updated_at > max_loaded_ts`) и/или хэш-делта.
Backfill/Reprocessing: time-travel, диапазоны, квоты, dry-run сравнения.

sql
MERGE INTO silver. payments s
USING stage. payments_delta d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5) Семантический слой и метрики

Metrics Store/Semantic Layer: единые формулы GGR/NGR/Conversion/LTV.
Версионирование метрик и «as-of» вычисления для воспроизводимости.
Соглашения: имена метрик, единицы измерения, валюта (base EUR) и `fx_source`.

6) Витрины и сервинг

Gold-витрины: денормализованные, SLA готовности (например, до 06:00 лок.).
Оперативные марты: ClickHouse/Pinot/Druid для 1–5-минутных панелей.
Экспорт: CSV/JSON/PDF + hash; неизменяемые пакеты (WORM) для регуляторов.

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
b. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

7) Качество данных (DQ) и контракты

Schema-first: JSON/Avro registry + тесты совместимости (consumer-driven).
DQ-как-код: completeness/validity/uniqueness/FK/range/temporal.
Политики реакции: critical → fail + DLQ; major/minor → тег и отчет.
Наблюдаемость DQ: дашборды Freshness/Completeness/Validity, воронка потерянных записей.

8) Безопасность, приватность и резидентность

PII-минимизация: пользователи через псевдо-ID; маппинги отдельно.
RLS/CLS: доступ построчно/постолбцово по ролям и юрисдикциям.
Шифрование: TLS in-transit; at-rest — KMS/CMK с ротацией.
Data Residency: отдельные каталоги и ключи для EEA/UK/BR; запрет кросс-региональных join’ов без оснований.
DSAR/RTBF: вычислимые проекции и селективные редактирования; Legal Hold на отчетные артефакты.

9) Производительность и стоимость (Cost Engineering)

Партиционирование: по дате/рынку/тенанту; кластеризация/Z-order по `market`, `provider_id`, `game_id`, `user_pseudo_id`.
Форматы: Parquet + статистики и компрессия; OPTIMIZE/VACUUM по расписанию.
Материализация: стабильные агрегаты и summary-таблицы; избегайте «толстых» join’ов на лету.
Квоты/Chargeback: бюджеты на тяжелые запросы/реплеи; отчеты cost/query, cost/GB.
Tiered storage: hot/warm/cold; четкие SLA восстановления.

10) Наблюдаемость и управление

Метрики пайплайнов: длительность, объемы, ретраи, лаги, отказоустойчивость.
Метрики DWH: время ответов/конкурентность/кэш-хиты/стоимость.
Lineage: граф от источников до отчетов; impact-анализ при изменениях.
SLO: Freshness Silver p95 ≤ 15 мин; Gold daily — готово до 06:00; Validity ≥ 99.9%; Completeness ≥ 99.5%; доступность ≥ 99.9%.

11) Мультитенантность и доменная изоляция

Разделение по schema/database/catalog на тенант/рынок.
Квоты и resource groups; ограничение «шумных соседей».
Политики экспорта/импорта между тенантами, стандартизованные контракты.

12) Реестр данных и документация

Data Catalog: owner, SLA, схема, примеры, DQ-правила, lineage.
Метрики/дашборды: карточки с формулами и ответственными.
Change Log: версии логики, миграции, влияние (impact).

13) Процессы и RACI

R (Responsible): Data Engineering (модели Silver/Gold, DAG’и), Data Platform (инфра, registry, DQ).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO, Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (Informed): BI, Продукт, Маркетинг, Операции.

14) Дорожная карта внедрения

1. Lakehouse Bronze/Silver (ACID-таблицы), CDC/инкременты для Payments/Gameplay.

2. Первые Gold-витрины (GGR Daily, конверсия), SLA до 06:00.

3. DQ-как-код (10–15 правил) + дашборды Freshness/Completeness.

4. Каталог данных и базовый семантический слой метрик.

• SCD II для users/games/providers; расширение доменов.
• Оперативные марты (ClickHouse/Pinot) для real-time/near-real-time панелей.
• Lineage/impact-анализ, DSAR/RTBF процедуры, регионализация (EEA/UK).

• Автосимуляция изменений (dry-run), реплей и сравнение метрик.
• Chargeback/квоты, cost-дашборды; DR-учения и time-travel восстановления.
• Автогенерация документации витрин и карточек метрик.

15) Примеры SQL-шаблонов

sql
CREATE TABLE silver. fact_bets (
bet_id STRING PRIMARY KEY,
user_pseudo_id STRING NOT NULL,
game_id STRING NOT NULL,
stake_ccy DECIMAL(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
stake_base DECIMAL(18,2) NOT NULL,
market CHAR(2) NOT NULL,
event_time TIMESTAMP NOT NULL
);

sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);

sql
SELECT market, DATE(event_time) d, COUNT() n
FROM silver. fact_bets
GROUP BY market, DATE(event_time)
HAVING n = 0;

16) Чек-лист перед продом

• Схемы и контракты в реестре, тесты совместимости зеленые.
• CDC/инкременты и MERGE-процедуры идемпотентны.
• Gold-витрины имеют SLA, зафиксированы формулы метрик.
• DQ-правила активны (critical → fail + DLQ), дашборды Freshness/Completeness.
• RBAC/ABAC, шифрование, резидентность по регионам, журналы доступа.
• Lineage/impact включены; time-travel/backup/DR проверены.
• Стоимость под контролем: партиции, кластеризация, материализация, квоты.

17) Анти-паттерны и риски

«Один жирный DWH без слоев»: смесь сырых и отчетных данных → хаос и дорогие исправления.
Full reload ежедневно без нужды: используйте инкременты/CDC.
Gold без владельца и формул: отсутствие единой версии правды → споры и регрессы.
PII в аналитических слоях: держите маппинги отдельно, CLS/RLS.
Отсутствие DQ/lineage: нет доказуемости для регуляторов/аудита.
Неуправляемая стоимость: нет партиций/оптимизаций/квот.

18) Глоссарий (кратко)

DWH — хранилище данных для консолидации и аналитики.
Lakehouse — data lake + ACID-таблицы и SQL-движок.
CDC — захват изменений из OLTP.
SCD — медленно меняющиеся измерения (I/II/III).
Gold-витрина — готовая к потреблению отчетная таблица/представление.
Semantic Layer — единые определения метрик и атрибутов.

19) Итог

Современный DWH для iGaming — это не «большая таблица», а управляемая платформа: слои Bronze/Silver/Gold, строгие контракты и DQ, единые метрики и lineage, приватность и резидентность, производительность и экономичность. Выстроив гибрид Lakehouse + DWH-март, вы получите быстрое и проверяемое принятие решений, готовое к аудиту, масштабам и новым рынкам.