GH GambleHub

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

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 з таймаутами.

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 при сильному відставанні.
Приклад Flink SQL (10-хв velocity депозитів):
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.

Псевдокод CEP:
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).
Асинхронні виклики: санкційні/РЕР 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: низька латентність для дашбордів і зовнішніх інтеграцій.

Приклад ClickHouse (щохвилинний GGR):
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

SLI/SLO (орієнтири):
  • p95 ingest→alert ≤ 2 с (критично), ≤ 5 с (інше).
  • Completeness вікна T ≥ 99. 5%.
  • Помилки схем ≤ 0. 1%; частка подій з'trace _ id'≥ 98%.
  • Доступність стрім-сервісу ≥ 99. 9%.
Дашборди:
  • Лаги по партіях/топіках, busy time операторів, розмір стану.
  • Воронка «sobytiye→pravilo→keys», карта «гарячих» ключів, 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, приклад):
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) Дорожня карта впровадження

MVP (2-4 тижні):

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

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

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

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

Фаза 2 (4-8 тижнів):
  • Онлайн-збагачення (Redis/Scylla), Feature Store, асинхронні lookups.
  • Управління правилами як кодом, канарські релізи, A/B.
  • Потокова DQ, регіоналізація конвеєрів, DSAR/RTBF процедури.
Фаза 3 (8-12 тижнів):
  • Мульти-регіон active-active, реплей-симулятор «what-if», автокалібрування порогів.
  • Повноцінні Gold-stream вітрини (GGR/RG/AML), звітність near-real-time.
  • Вартісні дашборди, chargeback, DR-навчання.

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

Flink CEP — device switch:
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
Kafka Streams - ідемпотентний фільтр:
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 і спостережуваність, приватність і вартість під контролем. Дотримуючись описаних практик, платформа отримує надійні детектори ризику, оперативні панелі і персоналізацію з передбачуваною латентністю і витратами.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.