Сховища даних

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-березень, ви отримаєте швидке і перевіряється прийняття рішень, готове до аудиту, масштабів і нових ринків.