Batch vs Stream: когда что

Зачем вообще выбирать

Любая система данных балансирует между свежестью (latency), стоимостью, сложностью поддержки и надежностью.
Batch — периодические «порции» данных с высокой пропускной способностью и низкой стоимостью за запись.
Stream — непрерывная обработка событий с минимальной задержкой и состоянием в памяти/локальных сторах.

Коротко о моделях

Batch

Источник: файлы/таблицы/снапшоты.
Триггер: расписание (час/день) или условие (новый паркет-файл).
Сильные стороны: простота, детерминизм, полный контекст данных, дешевые большие перерасчеты.
Слабые: нет «онлайна», высокая латентность, «окна» без сигналов реального времени.

Stream

Источник: брокеры (Kafka/NATS/Pulsar), CDC, очереди.
Триггер: событие.
Сильные: низкая задержка, реактивность, естественная интеграция с продуктом.
Слабые: сложность времени (event vs processing), порядок/дубли, состояние, эксплуатация.

Решение: матрица выбора

Правило 80/20: если SLA позволяет минутные/часовые задержки и нет реактивных фич — берите batch. Если критична реакция «здесь и сейчас» или нужны живые витрины — stream (часто + дополнительный ночной batch для выверки).

Типовые сценарии

• Ежедневная отчетность, биллинг периодами, ML-тренинг, крупные джоины, дедупликация «всем набором».
• Медальон-модель (bronze/silver/gold) с глубокими валидациями.
• Массовые бэктесты и пересборка витрин.

• Антифрод/мониторинг, алерты SRE, real-time баланс/миссии, рекомендации «сейчас».
• Интеграции «событие-как-факт» (EDC), обновление материализованных представлений (CQRS).
• Микросервисы: нотификации, вебхуки, реакции на бизнес-события.

• Поток формирует операционные витрины и сигналы; ночной batch делает выверку, свод и дешевые исторические пересчеты.

Архитектуры

Lambda (Stream + Batch)

Stream для инкремента и онлайна; Batch для полноты и коррекций.
Плюсы: гибкость и SLA. Минусы: двойная логика, дублирование кода.

Kappa (все — Stream + Replay)

Единый лог как источник истины; batch-пересчеты = replay.
Плюсы: одна кодовая база, единая семантика. Минусы: сложнее эксплуатация, требования к хранению лога.

Hybrid-Pragmatic

Потоковая «операционка» + периодические batch-джобы для тяжелых джоинов/ML/коррекций.
На практике — самый распространенный вариант.

Время, порядок, окна (для Stream)

Опирайтесь на event time, не на processing time.
Управляйте watermark и `allowed_lateness`; поддерживайте retractions/upserts для поздних событий.
Партиционируйте по ключам агрегатов, планируйте «горячие ключи».

Надежность и семантика эффектов

Batch

Транзакции БД или атомарная замена партиций/таблиц.
Идемпотентность — через deterministic-вычисления и overwrite/insert-overwrite.

Stream

At-least-once + идемпотентные sinks (upsert/merge, версии агрегатов).
Транзакционный «прочитал-записал-зафиксировал позицию» для EOS по эффекту.
Таблицы дедупа по `event_id`/`operation_id`.

Хранилища и форматы

Batch

Data Lake (Parquet/Delta/Iceberg), OLAP (ClickHouse/BigQuery), объектное хранилище.
ACID-таблицы для atomic replace, time travel.

Stream

Логи/темы в брокерах, state stores (RocksDB/embedded), KV/Redis, OLTP для проекций.
Реестр схем (Avro/JSON/Proto), режимы совместимости.

Стоимость и SLO

Batch: оплачиваете «пачками» — выгодно при больших объемах, но задержка ≥ расписания.
Stream: постоянные рантайм-ресурсы, пиковая стоимость при высоком QPS; зато SLA в секундах.
Считайте p95/p99 latency, сквозной лаг, стоимость в у.е./событие и TCO поддержки.

Тестирование

Общее: golden-наборы, property-based инварианты, генерация грязных входов.
Batch: детерминированность, идемпотентные перезапуски, сравнение сводов «до/после».
Stream: out-of-order/дубликаты, fault-injection между эффектом и фиксацией офсета, replay-тесты.

Обсервабилити

Batch: длительность джоб, доля фейлов/ретраев, свежесть витрин, скан-cost.
Stream: лаг по времени/сообщениям, watermark, late-rate, размер state/частота checkpoint, DLQ-ставка.
Везде: `trace_id`, `event_id`, версии схем/конвейеров.

Безопасность и данные

PII/PCI — минимизировать, шифровать at-rest/in-flight, метить поля в схемах (`x-pii`).
Для Stream — защита state/checkpoint’ов, ACL на топики.
GDPR/право на забвение: в Stream — крипто-стирание/редакция в проекциях; в Batch — перерасчет партиций.

Переходные стратегии

Batch → Stream: начните с публикации событий (Outbox/CDC), поднимите небольшую витрину real-time, не трогая существующий свод.
Stream → Batch: добавьте ежедневные своды для отчетности/выверки и снижения нагрузки на потоковые sinks.

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

«Все в Stream» ради моды: дорого и сложно без реальной нужды.
«Один гигантский ночной batch» при требованиях < 5 минут.
Использование processing time для бизнес-метрик.
Сырые CDC как публичные события: жесткая связность, боль при эволюции.
Нет идемпотентности в sinks → двойные эффекты на рестартах.

Чек-лист выбора

• SLO свежести: сколько секунд/минут/часов допустимо?
• Стабильность входов: есть ли out-of-order/дубликаты?
• Нужны ли онлайновые реакции/витрины?
• Стоимость: рантайм 24/7 vs «окно по расписанию».
• Способ коррекций: retract/upsert или ночной пересчет.
• Команда и операционная зрелость (обсервабилити, on-call).
• Требования к «ровно одному эффекту».
• Политики PII/ретенции/право на забвение.

Референс-паттерны

• Stream: EDC → проекции (KV/Redis, OLTP) для UI, идемпотентные upsert.
• Batch: nightly свод в OLAP, reconciliation, ML-фичи.

• Stream: session-окна, CEP-правила, алерты < 1–5 с.
• Batch: переобучение моделей, оффлайн-валидация.

• Stream: триггеры, сегменты в реальном времени.
• Batch: скоринги, LTV-модели, отчеты.

FAQ

Можно ли получить «почти real-time» на batch?
Да: микробатчи/триггерные джобы (каждые 1–5 минут) — компромисс, но без сложностей окон/late-events.

Нужен ли Lambda-подход везде?
Нет. Если поток закрывает все задачи и вы умеете делать replay — Kappa проще в долгую. Иначе — гибрид.

Как считать стоимость?
Суммируйте compute+storage+ops. Для Stream добавьте цену простоя «24/7» и аварийных ночей; для Batch — цену «просрочки» данных.

Итог

Выбирайте Batch, когда важны низкая стоимость, простота и периодические своды; Stream — когда критична реактивность и свежесть. На практике побеждает гибрид: поток — для онлайна и сигналов, батч — для полноты и дешевых исторических перерасчетов. Главное — задать SLO, обеспечить идемпотентность/наблюдаемость и заранее спроектировать путь коррекций.