Stream vs Batch анализ

1) Краткая суть

Stream — непрерывная обработка событий за секунды: антифрод/AML, RG-триггеры, SLA-алерты, оперативные панели.
Batch — периодический перерасчет с полной воспроизводимостью: регуляторная отчетность (GGR/NGR), финсверки, ML-датасеты.

Ориентиры: Stream p95 e2e 0.5–5 с, Batch D+1 до 06:00 (лок.).

2) Матрица выбора (TL;DR)

Критерий	Stream	Batch
SLA реакции	секунды/минуты	часы/дни
Полнота (completeness)	высокая, но возможны late-исправления	очень высокая, контролируемая D+1
Воспроизводимость «as-of»	сложнее (replay)	проще (time-travel/snapshots)
Стоимость на единицу	дороже онлайн-путь	дешевле на объем
Типовые задачи	AML/RG алерты, SRE, real-time витрины	отчеты, сверки, ML off-line
Историзация (SCD)	ограниченно	полно
Регуляторка/WORM	через Gold-пересбор	нативно (Gold/D+1)

Правило 80/20: все, что не требует реакции <5 минут — в Batch; остальное — в Stream, с ночной валидацией Batch.

3) Архитектуры

3.1 Lambda

Stream для онлайна + Batch для консолидации. Плюс: гибкость. Минус: две логики.

3.2 Kappa

Все как потоки; Batch = «реплей» через лог. Плюс: единый код. Минус: сложность реплеев/стоимость.

3.3 Lakehouse-Hybrid (рекомендовано)

Stream → оперативные OLAP-марты (минуты) и Bronze/Silver; Batch пересобирает Gold (D+1) и публикует отчеты.

4) Данные и время

Stream

Окна: tumbling/hopping/session.
Watermarks: 2–5 мин; late data помечается и доэмитится.
Stateful: CEP, дедуп, TTL.

Batch

Инкременты/CDC: `updated_at`, лог-репликация.
SCD I/II/III: история атрибутов.
Снапшоты: дневные/месячные слои для «as-of».

5) Паттерны применения в iGaming

AML/Антифрод: Stream (velocity/структурирование) + Batch сверки и кейсы.
Responsible Gaming: Stream контроль лимитов/самоисключений; Batch отчетные реестры.
Операции/SRE: Stream алерты SLA; Batch пост-анализ инцидентов и тренды.
Продукт/маркетинг: Stream персонализация/миссии; Batch когорты/LTV.
Финансы/отчеты: Batch (Gold D+1, WORM-пакеты), Stream — оперативные панели.

6) DQ, воспроизводимость, реплей

Stream DQ: валидация схем, дедуп `(event_id, source)`, completeness окна, late-ratio, dup-rate; критичное → DLQ.
Batch DQ: уникальность/FK/range/temporal, сверки с OLTP/провайдерами; критичное → fail job + отчет.

Воспроизводимость:

Stream: реплей топиков по диапазону + deterministic трансформации.
Batch: time-travel/версии логики (`logic_version`) + снапшоты Gold.

7) Приватность и резидентность

Stream: псевдонимизация, online-маскирование, региональные конвейеры (EEA/UK/BR), таймауты на внешние PII-lookups.
Batch: изоляция PII-маппингов, RLS/CLS, DSAR/RTBF, Legal Hold, WORM-архивы.

8) Cost-инжиниринг

Stream: избегать «горячих» ключей (salting), ограничивать async lookups, TTL состояния, предагрегация.
Batch: партиционирование/кластеризация, компакция small files, материализация стабильных агрегатов, квоты/окна запуска.

9) Примеры

9.1 Stream — 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);

9.2 Stream — CEP (псевдокод AML)

python if count_deposits(10MIN) >= 3 and sum_deposits(10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window):
emit_alert("AML_STRUCTURING", user_id, snapshot())

9.3 Batch — MERGE (инкремент Silver)

sql
MERGE INTO silver. payments s
USING stage. delta_payments d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

9.4 Batch — Gold GGR (D+1)

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) event_date,
b. market, g. provider_id,
SUM(b. stake_base) stakes_eur,
SUM(p. amount_base) payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

10) Метрики и SLO

Stream (ориентиры)

p95 ingest→alert ≤ 2–5 c completeness окна ≥ 99.5%

schema-errors ≤ 0.1%

late-ratio ≤ 1%

доступность ≥ 99.9%

Batch (ориентиры)

Gold.daily готово до 06:00 лок.

completeness ≥ 99.5%

validity ≥ 99.9%

MTTR DQ-инцидента ≤ 24–48 ч

11) Тестирование и релизы

Контракты/схемы: consumer-driven tests; back-compat CI.
Stream: канареечные правила, темный запуск, replay-симулятор.
Batch: dry-run на выборках, сравнение метрик, контрольное суммирование (reconciliation).

12) Анти-паттерны

Дублирование логики: разные расчеты Stream и Batch без выравнивания формул.
Синхронные внешние API в горячем пути Stream без кэша/таймаутов.
Full reload «на всякий случай» вместо инкрементов.
Отсутствие watermarks/late-политик.
PII в аналитических слоях; отсутствие CLS/RLS.
Gold-витрины, которые «мутируют» задним числом.

13) Рекомендованный гибрид (плейбук)

1. Stream-контур: ingest → шина → Flink/Beam (watermarks, дедуп, CEP) →

OLAP (ClickHouse/Pinot) для 1–5-мин панелей + Bronze/Silver (append).
2. Batch-контур: инкременты/CDC → Silver нормализация/SCD → Gold суточные витрины/отчеты (WORM).
3. Согласование: единый семантический слой метрик; nightly сверки Stream↔Batch; расхождения > порога → тикеты.

14) RACI

R (Responsible): Streaming Platform (Stream-инфра), Data Engineering (Batch модели), Domain Analytics (метрики/правила), MLOps (фичи/Feature Store).
A (Accountable): Head of Data / CDO.
C (Consulted): Compliance/Legal/DPO, Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (Informed): BI/Продукт/Маркетинг/Операции.

15) Дорожная карта

MVP (2–4 недели):

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

2. Flink-джоба: watermark + дедуп + 1 CEP-правило (AML или RG).

3. OLAP-витрина 1–5 мин + дашборды lag/late/dup.

4. Lakehouse Silver (ACID), первая Gold.ggr_daily (D+1 до 06:00).

Фаза 2 (4–8 недель):

Инкременты/CDC по доменам, SCD II, семантический слой метрик.
Потоковая DQ и nightly сверки Stream↔Batch.
Регионализация (EEA/UK/BR), DSAR/RTBF, Legal Hold.

Фаза 3 (8–12 недель):

Реплей-симулятор, canary/A-B релизы правил/метрик.
Cost-дашборды и квоты; tiered storage; DR-учения.
Автогенерация документации витрин/метрик и lineage.

16) Чек-лист внедрения

Схемы/контракты в Registry; back-compat тесты зеленые.
Stream: watermarks/allowed-lateness, дедуп, DLQ; OLAP-панели в проде.
Batch: инкременты/CDC, SCD II, Gold D+1 с WORM-экспортами.
Единый семантический слой метрик; nightly сверки Stream↔Batch.
DQ-дашборды Freshness/Completeness/Validity; алерты lag/late/dup.
RBAC/ABAC, шифрование, резидентность; DSAR/RTBF/Legal Hold.
Стоимость под контролем (cost/GB, cost/query, state size, реплеи квотированы).

17) Итог

Stream и Batch не конкуренты, а две шестеренки одного привода. Stream дает реакцию «здесь и сейчас», Batch — проверяемую истину «на утро». Гибрид Lakehouse-подход, единый слой метрик и дисциплина DQ/lineage позволяют строить быстрые, воспроизводимые и комплаентные аналитические контуры, оптимальные по SLA и стоимости.

Stream vs Batch анализ

Batch

Batch (ориентиры)

Свяжитесь с нами

Быстрая связь

Видео скоро обновится

Мы сейчас очень загружены проектами