Аналитика в реальном времени

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 на момент события.
Асинхронные вызовы: санкционные/PEP 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 операторов; размер состояния.
• Воронка «событие→правило→кейс», 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. Следуя этим практикам, платформа получает точные сигналы и решения в пределах секунд, поддерживая комплаенс, продуктовые сценарии и операционную устойчивость при контролируемой стоимости.