Batch vs stream processing: что выбрать
Карьерник — квиз-тренажёр в Telegram с 1500+ вопросами для собесов аналитика. SQL, Python, A/B, метрики. Бесплатно.
Короткий ответ
- Batch — обрабатываем данные пачками по расписанию (например, раз в час / в сутки)
- Stream — обрабатываем события по мере их поступления, почти в реальном времени
- Batch — проще, дешевле, типичный для BI и отчётов
- Stream — сложнее, дороже, нужен когда latency критична (трекинг, антифрод, алерты)
Сравнительная таблица
| Критерий | Batch | Stream |
|---|---|---|
| Latency | часы / сутки | секунды / миллисекунды |
| Сложность | низкая | высокая |
| Стоимость | низкая | высокая |
| Пример задач | BI-отчёты, ML-обучение | трекинг, антифрод, алерты |
| Типичный объём | терабайты за раз | миллионы событий в секунду |
| Инструменты | Airflow, dbt, Spark | Kafka, Flink, Spark Streaming |
| Ошибка | заметим при следующем запуске | сразу в prod |
| Восстановление | перезапустил задачу | сложнее (state, checkpoints) |
Batch processing
Что это
Накапливаем данные, запускаем задачу пачкой. Результат сохраняем в хранилище.
Пример:
- каждую ночь в 3:00 Airflow запускает джобу
- джоба забирает новые заказы за сутки
- считает агрегаты
- сохраняет в DWH
- утром бизнес видит свежие дашборды
Инструменты
- Orchestration: Airflow, Dagster, Prefect, Luigi
- Compute: Spark, dbt, plain Python / SQL
- Storage: S3, HDFS, ClickHouse, Snowflake, BigQuery
Плюсы
- Простота: одна задача → один запуск
- Дешево: compute арендуется только на время джобы
- Легко отлаживать: логи, replay
- Zone для ошибок: падение до prod-запуска
Минусы
- Данные устаревают между запусками (1-24 часа)
- Не подходит для real-time задач (алертинг, trading)
- Большая задача — большое окно для сбоев
Stream processing
Что это
События обрабатываются сразу по мере прихода. Результат — в online-хранилище или в другой stream.
Пример:
- пользователь кликает → event публикуется в Kafka
- Flink-приложение читает event, считает агрегат (например, clicks per minute)
- результат пишется в dashboard / antifraud / recommendation engine
- latency — 100-500ms
Инструменты
- Broker: Kafka, Pulsar, RabbitMQ, AWS Kinesis
- Processing: Flink, Spark Streaming, Kafka Streams, ksqlDB
- Storage: ClickHouse (real-time), Redis, Materialize
- Orchestration: часто не нужна, всё 24/7
Плюсы
- Low latency: реагируем немедленно
- Для критичных use cases: антифрод, trading, алерты
- Incremental compute: не пересчитываем историю
- Backpressure: системы справляются с пиками
Минусы
- Сложность разработки: handling state, exactly-once semantics
- Дорого: работает постоянно, нужен кластер
- Сложно debug: проблема может быть в 10 разных местах
- Data correctness: late-arriving events, out-of-order
Когда batch?
- Дашборды для бизнеса (обновление раз в сутки — ок)
- ML-обучение моделей
- Финансовая отчётность
- Исторический анализ
- Data warehouse для аналитики
Когда stream?
- Антифрод (решение нужно за <1 сек)
- Realtime-дашборды для operations
- Алертинг (incident detection)
- Personalization (рекомендации at request time)
- Trading и high-frequency decisions
- IoT / sensor data
Lambda и Kappa архитектуры
Популярные паттерны:
Lambda
Два пути параллельно:
- Batch layer — историческая правда, пересчитывается целиком
- Speed layer — real-time stream для свежих данных
- Dashboards комбинируют оба
Kappa
Только stream. Re-processing через replay исторических событий.
Современный тренд — Kappa, потому что проще поддерживать.
Для аналитика
На работе аналитик чаще всего:
- Пишет SQL в DWH → это результат batch-обработки ELT
- Использует real-time dashboards → данные приходят stream-ом
- Не пишет сам stream-pipeline, но понимает архитектуру (чтобы не ждать «свежести» там, где batch ночной)
На собесе на middle+ роль могут спросить:
- Чем отличается batch от stream?
- Когда использовать какой?
- Какие инструменты знаете?
- Можете ли оптимизировать batch → near-realtime?
Micro-batch (компромисс)
Между batch и stream есть micro-batch — Spark Streaming работает именно так:
- Накапливает события в маленькие окна (1-30 сек)
- Обрабатывает каждое окно как mini-batch
- Latency: секунды (не миллисекунды, но и не часы)
- Сложность: средняя
Часто хорошее решение для аналитических задач.
Частые ошибки
Ошибка 1. Использовать stream там, где batch достаточен
Дашборд с суточной аналитикой через Flink — overkill. Airflow + SQL хватит.
Ошибка 2. Batch там, где нужен stream
Антифрод через ночную джобу → транзакции уже ушли. Нужен stream.
Ошибка 3. Смешивать свежесть в одном источнике
Если часть данных real-time, часть batch-обновляется — люди не понимают «насколько свежее» число на дашборде.
Ошибка 4. Stream без backpressure handling
При пиках stream-система падает. Нужно уметь обрабатывать всплески.
Связанные темы
FAQ
Что использовать для дашборда с продаж?
Batch (раз в сутки или раз в час). Stream тут избыточен.
Что использовать для антифрода?
Stream. Транзакция должна быть одобрена / отклонена за миллисекунды.
Lambda или Kappa?
Kappa проще. Lambda сложнее, но иногда необходима (legacy, compliance).
Нужно ли аналитику знать Kafka / Flink?
На уровне concepts — да. Писать stream-процессоры обычно задача data engineer.
Тренируйте знания по data engineering — откройте тренажёр с 1500+ вопросами.