Озера даних і агрегація потоків

1) Призначення та цінність

• Потоки з продуктів/ігор/платежів приземляються в Bronze «як є».
• Silver нормалізує і збагачує, забезпечуючи узгоджені ключі і якість.
• Gold - агреговані вітрини (в т.ч. real-/near-real-time) для BI, регуляторки, антифроду/RG.

Агрегація потоків на Lakehouse дає: низьку затримку звітів, передбачувану вартість, відтворюваність і форензику.

2) Референс-архітектура

1. Ingest/Edge: HTTP/gRPC, OTel, batch endpoints → шина (Kafka/Redpanda).
2. Bronze (append-only): об'єктне сховище + ACID-таблиці (Delta/Iceberg/Hudi), партії by date/market/tenant; зберігання вихідного payload.
3. Stream Compute: Flink/Spark/Beam - віконні агрегати, CEP, дедуп, online-lookups.
4. Silver (clean/conform): нормалізація валют/таймзон, FK/довідники, SCD для вимірювань.
5. Serving/OLAP: ClickHouse/Pinot/Druid - матеріалізовані хвилинні/секундні агрегати для панелей.
6. Gold (serve): денні/годинні вітрини, регуляторні зрізи, незмінні експортні пакети (WORM).
7. Контури керування: Schema Registry, DQ-як-код, lineage, каталоги, секрети/KMS, RBAC/ABAC.

3) Контракти та схеми

Schema-first: JSON/Avro/Protobuf; обов'язкові поля: `event_time (UTC)`, `event_id`, `trace_id`, `user_pseudo_id`, `market`, `schema_version`.
Еволюція: back-compatible → додавання nullable; breaking → '/v2'+ подвійний запис.
Каталог: опис домену, власник, SLA свіжості, DQ-правила, lineage.

4) Приземлення потоків в озеро

Exactly-once на дні: at-least-once публікація + ідемпотентний sink (MERGE/upsert по'event _ id').
Дедуп: stateful в стрімі + унікальність в Silver.
Компакція файлів: small files → регулярні OPTIMIZE/VACUUM для читання та вартості.
Time-travel: включає налагодження, реплей і audit.

sql
CREATE TABLE bronze. payment_events (
event_id STRING, user_pseudo_id STRING, currency STRING,
amount DECIMAL(18,2), market STRING, event_time TIMESTAMP, payload STRING
)
PARTITIONED BY (days(event_time), market);

5) Агрегація потоків: вікна та watermarks

• Tumbling - фіксовані (наприклад, 1 хв/5 хв) для стабільних панелей.
• Hopping - перекриваються (крок <вікно) для «гладких» метрик.
• Session - поведінкові розриви по неактивності.
• Watermarks: управління late data (зазвичай 2-5 хвилин), правила доемісій/корекції.

sql
SELECT market,
TUMBLE_START(event_time, INTERVAL '1' MINUTE) AS ts_min,
COUNT() AS deposits_1m,
SUM(amount_base) AS sum_1m
FROM silver. payments
GROUP BY market, TUMBLE(event_time, INTERVAL '1' MINUTE);

6) Матеріалізація агрегатів

OLAP-рушій (ClickHouse/Pinot/Druid): зберігає хвилинні/секундні агрегати для дашбордів і оперативної аналітики.
Lakehouse Gold: зберігає добові/годинні зрізи для звітності та звірок (відтворюваність).

sql
CREATE MATERIALIZED VIEW mv_ggr_1m
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), market, provider_id) AS
SELECT toStartOfMinute(event_time) AS ts_min,
market,
provider_id,
sumState(stake_base) AS s_stake,
sumState(payout_base) AS s_payout
FROM stream. game_events
GROUP BY ts_min, market, provider_id;

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(event_time) AS event_date,
market, provider_id,
SUM(stake_base) AS stakes_eur,
SUM(payout_base) AS payouts_eur,
SUM(stake_base) - SUM(payout_base) AS ggr_eur
FROM silver. fact_game_financials
GROUP BY 1,2,3;

7) Silver: нормалізація та узгодження

Час і валюта: `event_time (UTC)`, `amount_base`, `fx_rate_used`, `fx_source`.
Ключі/довідники: `user_pseudo_id`, `game_id`, `provider_id`, `market`.
SCD II: історизація вимірювань (users/games/providers/RG/KYC).
DQ-правила: унікальність ключів, довідники, діапазони сум, temporal-валідність.

8) Реєстр агрегатів та «правильні» визначення

Semantic Layer: єдині формули GGR/NGR, ставки/виграші, конверсія, ARPPU, latency p95.
Версіонування метрик: 'metric _ version'і «as-of» обчислення.
Док-картки: owner, формула, джерела, SLA готовності.

9) Exactly-once/ідемпотентність і порядок

Шина: at-least-once + партіонування (локальний порядок).
Обробка: дедуп по'event _ id'( TTL 24-72ч), СЕР/віконні оператори з коригуваннями.
Sink: транзакційні коміти або idempotent upsert/merge.
Outbox/Inbox: публікація доменних подій з OLTP з гарантією.

10) Late data і коригування

Allowed lateness: 2-5 хв для оперативних вітрин; добові перезбірки для Gold.
Корекції: доемісії в OLAP і перезбір Gold (idempotent).
Прапори: 'late = true','correction _ of = <event _ id>'для аудиту.

11) Спостережуваність і DQ

• p95 ingest→1 -хв вітрина ≤ 2-5 c; Gold daily готове до 06:00 лок.
• Completeness ≥ 99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
• Метрики пайплайнів: lag/throughput/busy time/state size, late-ratio, dup-rate.
• DQ-дашборди: Freshness/Completeness/Validity, воронка втрат, карта «гарячих» ключів.
• Lineage: шлях від Bronze до Gold/експортів; impact-аналіз при змінах.

12) Приватність, резидентність, безпека

PII-мінімізація: псевдонімізація, окремий захищений маппінг.
Residency: EEA/UK/BR - окремі каталоги та ключі шифрування; заборона крос-регіональних join'ів без підстав.
Шифрування: TLS in-transit; KMS/CMK at-rest; підписи експортів + WORM при регуляторці.
DSAR/RTBF/Legal Hold: селективні редагування, заморожування видалень, аудіруемие доступи.

13) Продуктивність і вартість

Партіонування: за датою/ринком/тенантом; кластеризація/Z-order за часто-фільтрованими атрибутами.
Компакція: усунення small files, регулярний OPTIMIZE/VACUUM.
Матеріалізація: хвилини/секунди - в OLAP; доба/годинник - в Gold.
Tiered storage: hot/warm/cold, SLA відновлення, chargeback за командами (cost/GB, cost/query).
Передагрегації/скетчі: HyperLogLog/approx-distinct там, де прийнятно.

14) Приклади (фрагменти)

python if count_deposits(window=10MIN) >= 3 \
and sum_deposits(window=10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window_events):
emit_alert("AML_STRUCTURING", user_id, snapshot())

sql
CREATE TABLE silver. payments AS
SELECT EXCEPT(rn) FROM (
SELECT p., ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time) rn
FROM bronze. payment_events p
) WHERE rn = 1;

sql
MERGE INTO silver. fact_bets s
USING stage. fact_bets_delta d
ON s. bet_id = d. bet_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

15) Процеси і RACI

• Data Platform (Lakehouse/каталог/ACID, компакція),
• Streaming (агрегати/CEP/dedup),
• Domain Analytics (метрики/Gold).
• A (Accountable): Head of Data/CDO.
• C (Consulted): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), SRE (SLO/стоимость), Security.
• I (Informed): BI/Продукт/Маркетинг/Операції.

16) Дорожня карта впровадження

1. Lakehouse Bronze/Silver (ACID-таблиці), ingest з Kafka, registry схем.

2. Базові стрім-агрегати (1-5 хв) в OLAP; вітрина Gold. ggr_daily (D + 1 до 06:00).

3. DQ-як-код для Payments/Gameplay, дашборди Freshness/Completeness.

4. Компакція/OPTIMIZE, мінімальні cost-метрики та алерти lag/late/dup.

• Розширення Silver (SCD II для users/games/providers), lineage і impact-аналіз.
• Асинхронні lookups (RG/KYC/ASN/BIN), управління late-корекціями.
• Семантичний шар метрик, регламент експортів (WORM/підписи).

• Мульти-регіон, DR/реплей-симулятор, auto-tuning вікон і watermarks.
• Cost-дашборди, chargeback/квоти, tiered storage і архівація.
• Автогенерація документації вітрин і карток метрик.

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

• Схеми та контракти в реєстрі; back-compat тести зелені.
• Включені дедуп, watermark/allowed lateness, DLQ.
• Компакція/OPTIMIZE/VACUUM налаштовані за розкладом.
• SLO: p95 ingest→minute-view, Gold до 06:00; алерти lag/late/dup/state size.
• DQ-правила активні; lineage видно від Bronze до експортів.
• RBAC/ABAC и KMS; резидентність і DSAR/RTBF/Legal Hold протестовані.
• Вартість під контролем (cost/GB, cost/query, частка cold), ліміти на реплеї.

18) Анти-патерни і ризики

Змішування сирих і звітних даних в одній таблиці: порушує reproducibility.
Відсутність компакції: вибух small files → дорогі запити.
Обчислення FX «заднім числом»: ламає історію і звіти.
Немає watermarks/late-політик: «пливуть» вітрини і алерти.
Full reload без потреби: використовуйте інкременти/MERGE та коригування.
PII в аналітиці: тримайте маппінги окремо, включайте CLS/RLS.

19) Глосарій (коротко)

Lakehouse - data lake + ACID-таблиці та SQL-рушій.
Bronze/Silver/Gold - сирі/нормалізовані/сервінгові шари.
Watermark - межа готовності вікон за event-time.
Materialized View - передвирахувана вітрина для швидкого читання.
Time-travel - читання історичних версій таблиць.
WORM - незмінне зберігання експортних артефактів.

20) Підсумок

Озеро даних з правильною стрім-агрегацією - це дисципліна шарів і контрактів: Bronze «як є», Silver для нормалізації і якості, OLAP для хвилинних панелей, Gold для відтворюваних звітів. Керуючи вікнами і watermarks, дедупом і компакцією, приватністю і вартістю, ви отримуєте швидкі, перевіряються і комплаєнтні вітрини для продукту, комплаєнсу і операційного управління.