Аналітика в реальному часі

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

• AML/Антифрод: структурування депозитів, velocity-атаки, ризик-транзакції.
• Responsible Gaming (RG): перевищення лімітів, патерни ризику, самовиключення.
• SRE/Операції: раннє виявлення деградацій SLA, сплесків помилок, перегріву кластерів.
• Продукт і маркетинг: тригери персоналізації, місії/квести, real-time сегментація.
• Операційна звітність: near-real-time GGR/NGR, дашборди залів/провайдерів.

Цільові орієнтири: p95 end-to-end 0. 5–5 с, completeness ≥ 99. 5%, доступність ≥ 99. 9%.

2) Еталонна архітектура

1. Ingest/Edge — `/events/batch` (HTTP/2/3), gRPC, OTel Collector; валідація схем, анти-дублі, гео-маршрутизація.
2. Шина подій - Kafka/Redpanda (партіонування по'user _ id/tenant/market', DLQ, ретеншн 3-7 днів).
3. Stream-обробка - Flink/Spark Structured Streaming/Beam: stateful-оператори, CEP, watermarks, allowed lateness, дедуп.
4. Online-збагачення - Redis/Scylla/ClickHouse lookups (RG-ліміти, KYC, BIN→MCC, IP→Geo/ASN), асинхронні виклики з таймаутами і fallback.
5. Сервінг - ClickHouse/Pinot/Druid (оперативні вітрини 1-5 хвилин), Feature Store (онлайн ознаки), webhooks/тікетинг/SOAR.
6. Lakehouse - Bronze/Silver/Gold для довготривалої консолідації, реплея і звірок.
7. Спостережуваність - метрики пайплайнів, трейсинг (OTel), логи, lineage і cost-дашборди.

3) Сигнали і таксономія

Платежі: `payment. deposit/withdraw/chargeback`.
Ігрові: `game. bet/payout', сесії.
Автентифікація та поведінка: `auth. login/failure`, device-switch, velocity.
Операційні: latency, error-rate, перезапуски подів, saturation.
Комплаєнс: санкційний скринінг, RG-прапори, DSAR-події.

Кожен тип має власника (domain owner), схему, SLO свіжості і політику late data.

4) Вікна, watermarks і late data

Вікна: tumbling (фікс.) , hopping (перекриття), session (по неактивності).
Watermark: межа «знання за часом» (зазвичай 2-5 хв).
Запізнілі події: доемісії коригувань, прапор'late = true', DLQ при сильному запізненні.

sql
SELECT user_id,
TUMBLE_START(event_time, INTERVAL '10' MINUTE) AS win_start,
COUNT() AS deposits_10m,
SUM(amount_base) AS sum_10m
FROM stream.payments
GROUP BY user_id, TUMBLE(event_time, INTERVAL '10' MINUTE);

5) CEP і stateful-агрегації

Ключування: `user_id`, `device_id`, `payment. account_id`.
Стан: ковзаючі лічильники/суми, bloom-фільтри для дедупа, TTL.
CEP-патерни: structuring (<поріг, ≥N разів, за вікно T), device-switch, RG-fatigue.

python if cnt_deposits(last=10MIN) >= 3 and sum_deposits(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, snapshot())

6) Exactly-Once, порядок та ідемпотентність

At-least-once доставка в шині + дедуп по'event _ id'на обробці (TTL 24-72 год).
Порядок: партіонування за ключами (локальний порядок гарантований).
Sink: транзакційні коміти (2-phase) або idempotent upsert/merge.
Outbox/Inbox: транзакційна публікація доменних подій з OLTP.

7) Online-збагачення і Feature Store

Lookup: RG-ліміти, KYC-статуси, BIN→MCC, IP→Geo/ASN, ринки/податки, FX на момент події.
Асинхронні виклики: санкційні/РЕР API з таймаутами; при помилці -'unknown'+ ретрай/кеш.
Feature Store: узгодження online/offline; одна кодова база трансформацій.

8) Real-time вітрини і сервінг

ClickHouse/Pinot/Druid: секундні/хвилинні агрегати, materialized views, SLA на затримку 1-5 хв.
API/GraphQL: низька латентність для дашбордів/віджетів.
Алерти: вебхукі/Jira/SOAR зі збагаченим контекстом (trace_id, last events).

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;

9) Метрики, SLI/SLO і дашборди

• p95 ingest→alert ≤ 2 с (критичні правила), ≤ 5 с (інше).
• Completeness вікна T ≥ 99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
• Доступність стрім-сервісу ≥ 99. 9%; late-ratio ≤ 1%.

• Лаг по партіях/топіках; busy time операторів; розмір стану.
• Воронка «sobytiye→pravilo→keys», precision/recall по доменах.
• Теплокарта late/completeness; карта «гарячих» ключів.

10) Потокова DQ (якість)

Ingest-валідації: schema/enums/size-limits, анти-дублі.
На потоці: completeness/dup-rate/late-ratio, коректність вікон (без подвійного обліку).
Політики реакції: critical → DLQ + pager; major/minor → тегування + звіт.

yaml stream: payments rules:
- name: schema_valid type: schema severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: dedup_window type: unique keys: [event_id]
window_minutes: 1440

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

PII-мінімізація: псевдонімізація ID, маскування чутливих полів, токенізація PAN/IBAN.
Data residency: регіональні конвеєри (EEA/UK/BR), окремі KMS-ключі.
DSAR/RTBF: селективні редагування на downstream вітринах; Legal Hold для кейсів/звітів.
Аудит: незмінні логи доступів/змін правил, журналізація релізів.

12) Економіка і продуктивність

Шардинг/ключі: уникайте «гарячих» ключів (salting/composite), баланс партій.
Стан: TTL, compact snapshots, тюнинг RocksDB/state backend.
Передагрегації: reduce на ранніх стадіях для гучних тем.
Sampling: тільки для некритичних метрик (не транзакції/комплаєнс).
Chargeback: бюджети на теми/джоби, квоти на реплеї і важкі запити.

13) Процеси і RACI

R: Streaming Platform (інфра/релізи), Domain Analytics (правила/фічі), MLOps (скоринг/Feature Store).
A: Head of Data/Risk/Compliance по доменах.
C: DPO/Legal (PII/retention), SRE (SLO/інциденти), Архітектура.
I: Продукт, Підтримка, Маркетинг, Фінанси.

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

1. Kafka/Redpanda + 2 критичних топіка (наприклад,'payments','auth').

2. Flink-джоба з watermark, дедупом і 1 CEP-правилом (AML або RG).

3. Оперативна вітрина в ClickHouse/Pinot (1-5 хв), дашборди lag/completeness.

4. Інцидент-канал (вебхукі/Jira), базові SLO і алерти.

• Online-збагачення (Redis/Scylla), Feature Store, асинхронні lookups.
• Управління правилами як кодом, canary/A-B, потокова DQ.
• Регіоналізація конвеєрів, DSAR/RTBF процедури, Legal Hold для кейсів.

• Мульти-регіон active-active, симулятор «replay & what-if», авто-калібрування порогів.
• Gold-stream вітрини (GGR/RG/AML), near-real-time звітність.
• Cost-дашборди, chargeback, DR-навчання.

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

sql
MATCH_RECOGNIZE (
PARTITION BY user_id
ORDER BY event_time
MEASURES
FIRST(A.device_id) AS d1,
LAST(B.device_id) AS d2,
COUNT()      AS cnt
PATTERN (A B+)
DEFINE
B AS B.device_id <> PREV(device_id) AND B.ip_asn <> PREV(ip_asn)
) MR

java if (seenStore.putIfAbsent(eventId, now()) == null) {
context.forward(event);
}

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

• Схеми/контракти в Registry, back-compat тести зелені.
• Включені watermark/allowed lateness, дедуп і DLQ.
• Налаштовані SLO і алерти (lag/late/dup/state size).
• Збагачення з кешами і таймаутами; fallback «unknown».
• RBAC/dual-control на правила/моделі; журнал змін включено.
• Документація правил/вітрин; runbook'і реплея/відкату.

17) Часті помилки і як їх уникнути

Ігнор event-time: без watermarks метрики «пливуть».
Немає дедупа: помилкові алерти, подвійний облік.
Гарячі ключі: перекіс партій → salting/resharding.
Синхронні зовнішні API в гарячому шляху: тільки async + кеш.
Некерована вартість: передагрегації, TTL стану, квоти, cost-моніторинг.
Відсутність симулятора: викати без «replay» → регресії.

18) Підсумок

Аналітика в реальному часі - це не «швидкий BI», а керований контур c контрактами, stateful-логікою, CEP, watermarks, online-збагаченням і строгими SLO. Дотримуючись цих практик, платформа отримує точні сигнали і рішення в межах секунд, підтримуючи комплаєнс, продуктові сценарії і операційну стійкість при контрольованій вартості.