Стриминг и потоковая аналитика

1) Назначение и ценность

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

Целевые характеристики: p95 end-to-end 0.5–5 с, полнота ≥ 99.5%, управляемая стоимость.

2) Эталонная архитектура

1. Ingest/Edge

`/events/batch` (HTTP/2/3), gRPC, OTel Collector.
Валидация схем, анти-дубликаты, гео-маршрутизация.

2. Шина событий

Kafka/Redpanda (партиционирование по `user_id/tenant/market`).
Retention 3–7 дней, компрессия, DLQ/«карантин» для «битых» сообщений.

3. Потоковая обработка

Flink / Spark Structured Streaming / Beam.
Stateful-операторы, CEP, watermark, allowed lateness, дедупликация.
Обогащение (Redis/Scylla/ClickHouse-Lookup), асинхронные I/O c таймаутами.

4. Сервинг/оперативные витрины

ClickHouse/Pinot/Druid для минутной/секундной агрегации и дашбордов.
Feature Store (online) для скоринга моделей.
Алерт-топики → SOAR/тикетинг/вебхуки.

5. Долговременное хранение (Lakehouse)

Bronze (raw), Silver (clean), Gold (serve) — Parquet + Delta/Iceberg/Hudi.
Реплей/бэктесты, time-travel.

6. Наблюдаемость

Метрики пайплайнов, трейсинг (OTel), логи, lineage.

3) Схемы и контракты

Schema-first: JSON/Avro/Protobuf + Registry, `schema_version` в каждом событии.
Эволюция: back-compatible — новые nullable поля; breaking — `/v2` + двойная публикация.
Обязательные поля: `event_time` (UTC), `event_id`, `trace_id`, `user.pseudo_id`, `market`, `source`.

4) Окна, watermarks и запоздалые данные

• Tumbling (фиксированное), Hopping (с перекрытием), Session (по неактивности).
• Watermark: порог «знания» по event-time; например, 2–5 минут.
• Late data: доэмиссия корректировок, «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) Stateful-агрегации и CEP

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

python if deposits.count(last=10MIN) >= 3 and deposits.sum(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, window_snapshot())

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

Шина: at-least-once + ключи партиционирования обеспечивают локальный порядок.
Идемпотентность: `event_id` + дедуп-стейт (TTL 24–72 ч).
Sink: транзакционные коммиты (2-phase) или upsert/merge-идемпотентность.
Outbox/Inbox: гарантированная публикация доменных событий из OLTP.

7) Обогащение в реальном времени

Lookup: Redis/Scylla (RG-лимиты, KYC-статус, BIN→MCC, IP→Geo/ASN).
Асинхронные вызовы: санкционные/PEP API с таймаутами и fallback («unknown»).
FX/таймзона: нормализация сумм и локальное время рынка (`fx_source`, `tz`).

8) Сервинг и real-time витрины

ClickHouse/Pinot/Druid: агрегации по минутам/секундам, materialized views.
Gold-stream: оперативные таблицы GGR/RG/AML, SLA на задержку ≤ 1–5 мин.
API/GraphQL: низкая латентность для дашбордов и внешних интеграций.

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) Наблюдаемость и SLO

• p95 ingest→alert ≤ 2 с (критично), ≤ 5 с (остальное).
• Completeness окна T ≥ 99.5%.
• Ошибки схем ≤ 0.1%; доля событий с `trace_id` ≥ 98%.
• Доступность стрим-сервиса ≥ 99.9%.

• Лаги по партициям/топикам, busy time операторов, размер состояния.
• Воронка «событие→правило→кейс», карта «горячих» ключей, late-ratio.
• Стоимость: cost/GB, cost/query, стоимость чекпойнтов/реплеев.

10) Приватность и комплаенс

PII-минимизация: псевдонимизация ID, маскирование полей, токенизация PAN/IBAN.
Резидентность данных: региональные конвейеры (EEA/UK/BR), отдельные ключи шифрования.
Правовые операции: DSAR/RTBF на downstream витринах, Legal Hold для кейсов/отчетов.
Аудит: логи доступа, неизменяемые архивы решений.

11) Экономика и производительность

Ключи и шардинг: избегайте «горячих» ключей (salting/composite key).
Состояние: разумные TTL, снэпшоты, тюнинг RocksDB/бэкенда стейта.
Предагрегация: up-front reduce для шумных потоков.
Sampling: допустим на некритичных метриках (не на транзакциях/комплаенсе).
Chargeback: бюджеты на темы/джобы, квоты и аллокация по командам.

12) Потоковая DQ (качество)

Ingest-валидация (schema, enums, size), дедуп `(event_id, source)`.
На потоке: completeness/dup-rate/late-ratio, контроль окон (двойного учета нет).
Политики реакции: critical → DLQ+алерт; 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

13) Безопасность доступа и release-контроль

RBAC/ABAC: отдельные роли на чтение потоков, изменение правил/моделей.
Dual control: выкаты правил и моделей через «2 ключа».
Canary/A/B: темные запуски правил и моделей, контроль precision/recall.
Секреты: KMS/CMK, регулярная ротация, запрет секретов в логах.

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

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

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

1. Kafka/Redpanda + два критичных топика (`payments`, `auth`).

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

3. ClickHouse/Pinot витрина 1–5 мин, дашборды lag/completeness.

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

• Онлайн-обогащение (Redis/Scylla), Feature Store, асинхронные lookups.
• Управление правилами как кодом, канареечные релизы, A/B.
• Потоковая DQ, регионализация конвейеров, DSAR/RTBF процедуры.

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

16) Примеры (фрагменты)

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);
}

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

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

18) Частые ошибки и как их избежать

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

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

CEP — Complex Event Processing (паттерны событий).
Watermark — граница готовности окон по event-time.
Allowed Lateness — допуск опоздалых событий.
Stateful Operator — оператор с сохраненным состоянием.
Feature Store — согласованный сервинг признаков (online/offline).

20) Итог

Стриминг и потоковая аналитика — это управляемая система: контракты, окна и watermarks, stateful-логика и CEP, обогащение и real-time витрины, SLO и наблюдаемость, приватность и стоимость под контролем. Следуя описанным практикам, платформа получает надежные детекторы риска, оперативные панели и персонализацию с предсказуемой латентностью и затратами.