Батч против стрима: два взгляда на данные

Урок объясняет фундаментальную развилку обработки данных: накапливать и считать пачками или реагировать на каждое событие сразу.

Потоковая обработка (stream processing) — модель, в которой данные обрабатываются как непрерывный поток событий по мере их появления, а не накапливаются в большие порции для периодического пересчёта.

Зачем это нужно

Десятилетиями данные обрабатывали батчами: ночью запускался ETL-процесс, который читал вчерашние транзакции, агрегировал их и складывал в хранилище. Утром аналитик открывал отчёт за прошлый день. Это работало, пока «вчерашних данных» было достаточно для решений. Но мир ускорился: антифрод должен заблокировать подозрительную операцию за миллисекунды, а не через сутки; рекомендации обновляются по мере того, как вы листаете ленту; склад пересчитывает остатки в момент покупки. «Раз в сутки» здесь бессмысленно.

Разница не только в скорости. В батче у вас есть фиксированный, ограниченный набор данных — вы знаете его начало и конец. В стриме данные бесконечны: поток событий не заканчивается, вы обрабатываете его «на лету», никогда не видя всю картину целиком. Это меняет саму постановку задачи: вместо «посчитай сумму всех заказов» вы решаете «поддерживай сумму заказов, обновляя её на каждом новом».

Событие как единица данных

Стриминг строится вокруг понятия события (event) — неизменяемого факта о том, что что-то произошло в конкретный момент: «пользователь 42 положил товар 17 в корзину в 12:03:41». Событие не команда («сделай») и не состояние («корзина содержит X»), а запись о случившемся. Состояние системы — производная: его можно восстановить, проиграв поток событий заново.

{
  "event": "item_added_to_cart",
  "user_id": 42,
  "product_id": 17,
  "ts": "2026-06-24T12:03:41Z"
}

Поток таких событий и есть «сырьё», которое Kafka переносит между системами.

Где проходит граница

Как работает под капотом

На уровне инфраструктуры разница в том, кто кого «толкает». Батч-система тянет данные: запускается, читает источник целиком, считает, завершается. Стрим-система живёт постоянно и реагирует на приходящие события. Поэтому стриминговая платформа должна уметь буферизовать всплески, гарантировать порядок и не терять события при сбоях — задачи, которых у одноразового ночного скрипта просто нет. Kafka — это транспорт и буфер, который делает потоковую модель надёжной.

Частые ошибки

• Считать стрим «быстрым батчем». Микробатч (обработка маленькими порциями каждые несколько секунд) — компромисс, но архитектурно стрим про бесконечность данных, а не про размер порции.
• Тянуть реальное время туда, где оно не нужно. Если отчёт смотрят раз в день, стриминг лишь усложнит систему. Реальное время оправдано там, где задержка стоит денег.
• Путать событие и состояние. Хранить в потоке «текущую корзину» вместо фактов «добавил/удалил» лишает вас главного преимущества — возможности переиграть историю.

Итоги

• Батч обрабатывает конечные порции по расписанию; стрим — бесконечный поток событий непрерывно.
• Событие — неизменяемый факт о случившемся; состояние выводится из потока событий.
• Реальное время оправдано там, где задержка критична: антифрод, рекомендации, остатки.