Інсайти в реальному часі

1) Що таке «інсайт в реальному часі»

Інсайт в реальному часі - перевіряється твердження про поточний стан процесу/користувача/системи, що з'являється в межах цільової затримки (латентності), достатньої для прийняття рішення (секунди-хвилини).
Формула контура: Подія → Збагачення/Агрегація → Рішення/Рекомендація → Дія → Зворотній зв'язок.

Приклади: антифрод на транзакції (≤500 мс), алерт SLO сервісу (≤60 с), персональна рекомендація на сторінці (≤200 мс), динамічний прайсинг (≤5 с), моніторинг кампаній (≤1 хв).

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

1. Інгест: брокер подій (Kafka/Pulsar/NATS/MQTT), контракти схем (Avro/Protobuf), ключі ідемпотентності.
2. Потокова обробка (CEP/Stream): Flink/Spark Structured Streaming/ksqlDB; вікна, watermarks, stateful-оператори.
3. Онлайн-фічі та стан: Feature Store (online) + кеш/TSDB (RocksDB/Redis) для швидких join/lookup.
4. Онлайн-скоринг/правила: моделі (ONNX/TF-Lite/XGB), rule-engine, контекст.
5. Сервінг інсайтів: low-latency API, вебхуки, шини команд (action bus), адаптивні дашборди.
6. НТАР/вітрини real-time: інкрементальні матеріалізації (ClickHouse/Pinot/Druid/Delta + CDC).
7. Спостережуваність і SLO: метрики латентності/лагів/помилок, трасування, алерти.
8. Управління та безпека: ОТА/фіч-прапори, RLS/CLS, маскування, аудит.

3) Тимчасова модель: вікна, watermarks, що запізнилися

Вікна: tumbling/sliding/session; для вітрин - гібрид (1s→5s→60s roll-ups).
Watermark: межа, після якої вікно «закривається»; баланс між свіжістю і повнотою.
Late data: політика доприема'Δ _ late'( напр. 2 хв), компенсаційні перерахунки.
Out-of-order: агрегуємо по'event _ time', зберігаємо'ingested _ at'для форензики.

4) Exactly-once за змістом і ідемпотентність

• глобальний'event _ id', таблиці idempotency keys;
• upsert/merge-sinks;
• state snapshots + транзакційні коміти (2-phase/transaction log);
• детерміновані трансформації і атомарний swap при публікації вітрин.

5) Стан і збагачення

Stateful-оператори: key-by (user/device/merchant), агрегати, top-K, distinct.
Онлайн-join: швидкі lookup-таблиці (наприклад, профіль клієнта, ліміти ризику).
Кешування: LRU/TTL, теплі фічі, версіонування довідників.
Узгодженість online/offline фіч: єдина специфікація в Feature Store.

6) Інсайт ≠ просто метрика

До інсайту додаємо картку рішення: гіпотеза/контекст → альтернатива → рекомендована дія → ожид. ефект → ризик/guardrails → власник/канал доставки.
Zero-click інсайт: короткий текст + готові кнопки (applied автоматично, якщо low-risk).

7) Аномалії, причинність та експерименти

Детекція: robust z-score/ESD, seasonal-decompose, change-point (CUSUM/BOCPD), ескізи (TDigest/HLL) для великих потоків.
Причинність: уникаємо «реакції на шум» - підтверджуємо ефект через квазі-експерименти/контрольні сегменти.
Онлайн-експерименти: бендіти/UCB/TS для вибору дії при обмеженому часі, guardrail-метрики (SLA, скарги, повернення).

8) SLO для real-time інсайтів

Latency p95/p99 end-to-end (ingest→deystviye).
Freshness вітрин (макс. лаг).
Completeness в межах вікна (частка пізніх врахованих).
Action Rate/Success Rate (скільки інсайтів перетворилося на дію/ефект).
Cost-to-Insight (CPU/IO/GPU/$, на 1 інсайт).

Приклад цільової матриці: антифрод p95≤300 мс, completeness≥99. 5%, cost/1k sobyty≤$Kh.

9) Доставка інсайтів і пріоритизація

Куди: вебхукі, message bus "actions. ", API дашбордів, push/чат-боти, CRM/CDP.
Пріоритети: Gold/Silver/Bronze; Gold - окремі пули і канали.
Дедлайни: якщо «deadline» закінчився - зниження класу або скасування.

10) Економіка і деградації

Cost-aware стратегія: спрощені моделі, більші вікна, семплінг при піку.
Graceful degradation: fallback на грубі агрегати/правила, «теплі» снапшоти.
Backpressure & shed-load: скидання best-effort тем, збереження Gold.

11) Безпека і приватність

RLS/CLS на стрім-вітринах; поділ по тенанту/регіону.
PII-редакція на краю: токенізація до центру.
Секрети та доступ: mTLS, короткі токени, аудит запитів/експорту.
Політики експорту: заборона «сирого» real-time PII назовні без підстав.

12) Спостережуваність real-time контуру

Лаги по топіках/ключах, queue depth, watermark skew.
p95/p99 на кожному шарі, error rate, reprocess count.
Data-quality в онлайні: дублікати, null-rate, аномалії розподілів.
Трейсинг: наскрізні trace-id від події до дії.

13) Антипатерни

«Все - real-time». Непотрібні витрати і шум; частина завдань краще batch/near-real-time.
SELECT і «вільні» схеми без контрактів.
Вікна без watermarks. Або вічні вікна, або втрати пізніх.
Немає ідемпотентності. Подвійні дії/спам.
Без guardrails. Реакція на «помилковий позитив» створює збиток.
OLTP під вогнем аналітики. Немає ізоляції - деградація прод-транзакцій.

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

1. Discovery: події, цільові рішення, дедлайни, ризики; класифікуйте Gold/Silver/Bronze.
2. Контракти даних: схеми (Avro/Protobuf), ключі, політики ідемпотентності.
3. MVP-потік: одне критичне рішення, вікно/WM, прості правила + онлайн-фічі.
4. Вітрини і сервінг: інкрементальні матеріалізації, low-latency API.
5. Спостережуваність: панелі лагів/latency/SLO, алерти; Трасинг.
6. Моделі та експерименти: онлайновий скоринг, bandits/guardrails.
7. Hardening: backpressure, деградації, cost-профіль; аудит і приватність.
8. Scale: мульти-регіон, edge-аналітика, пріоритизація потоків.

15) Чек-лист перед релізом

• Визначені SLO (latency, freshness, completeness) і власник.
• Схеми версіоновані; заборонений'SELECT'; є idempotency-keys.
• Налаштовані вікна і watermarks, політика late data/перерахунків.
• Exactly-once за змістом: upsert/merge-sinks, атомарний publish.
• Онлайн-фічі узгоджені з offline; кеші з TTL і версіями.
• Guardrails для дій; канали пріоритизовані; дедлайни вказуються.
• Моніторинг лагів/latency/SLO; трасинг включений; алерти на загрозу SLO.
• Політики приватності (RLS/CLS/PII) і аудит експорту включені.
• Runbooks деградацій і інцидентів готові (rollback/slow-path).

16) Міні-шаблони (псевдо-YAML/SQL)

Політика вікна/спізнілих

yaml windowing:
type: sliding size: 60s slide: 5s watermark:
lateness: 120s late_data:
accept_until: 90s recompute: true

Idempotent sink (SQL-ескіз)

sql merge into rt_fact as t using incoming as s on t. event_id = s. event_id when not matched then insert (...)
when matched and t. hash <> s. hash then update set...

Правила guardrails для дій

yaml action_policy:
name: promo_offer_rt constraints:
- metric: churn_risk_score; op: ">="; value: 0. 7
- metric: complaint_rate_24h; op: "<"; value: 0. 02 cooldown_s: 3600 owner: "growth-team"

Алерти SLO

yaml alerts:
- name: e2e_latency_p95 threshold_ms: 1500 for: 5m severity: high
- name: freshness_lag threshold_s: 60 severity: high

17) Підсумок

Інсайти в реальному часі - це не просто «швидкі графіки», а інженерний контур рішень: суворі контракти подій, коректна часова логіка (вікна/watermarks), ідемпотентні публікації, узгоджені онлайн-фічі, пріоритизована доставка дій і спостережуваність з SLO. Коли цей контур працює, організація реагує вчасно, безпечно і передбачувано, конвертуючи потік подій у вимірну бізнес-цінність.