Batch против streaming

Урок объясняет два режима обработки данных — пакетный и потоковый — и как выбрать между ними.

Batch (пакетная обработка) — данные копятся и обрабатываются порциями по расписанию. Streaming (потоковая) — каждое событие обрабатывается сразу, как только пришло.

Две скорости данных

Представьте кассу магазина. Batch — это когда вечером собрали все чеки за день и одним заходом посчитали выручку. Streaming — когда каждая покупка тут же увеличивает счётчик на табло. Оба подхода правильные, просто для разных задач.

Batch:     [событие][событие][событие] ──(раз в час)──> обработать ВСЁ
Streaming: [событие]─>обработать  [событие]─>обработать  [событие]─>обработать

Чем платим за скорость

СвойствоBatchStreaming
Латентностьминуты–часымиллисекунды–секунды
Сложностьнижевыше
Типичный инструментAirflow + SparkKafka + Flink
Когда нуженотчёты, витрины за деньфрод, мониторинг, антифрод

Правило практика: начинайте с batch. Потоковая обработка дороже в разработке и поддержке, и нужна только там, где задержка в час реально вредит бизнесу (антифрод, биржа, мониторинг систем).

Есть и третий, промежуточный режим — микробатч: данные обрабатываются маленькими порциями каждые несколько секунд или минут. Он даёт почти потоковую свежесть, но сохраняет простоту пакетной модели, поэтому многие команды используют именно его как компромисс. Так работает, например, Spark Structured Streaming.

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

В streaming ключевое понятие — окно (window): события группируют по интервалам времени, потому что бесконечный поток нельзя «досчитать до конца». Сымитируем оконную агрегацию на чистом Python: считаем число событий в окнах по 10 секунд.

events = [1, 3, 7, 12, 15, 21, 22, 29]  # секунды прихода
window = 10
buckets = {}
for t in events:
    key = (t // window) * window
    buckets[key] = buckets.get(key, 0) + 1
for start in sorted(buckets):
    print(f"[{start}-{start+window}) с: {buckets[start]} событий")

Вывод:

[0-10) с: 2 событий
[10-20) с: 2 событий
[20-30) с: 3 событий

А вот пакетный аналог — посчитать всё разом, без окон.

events = [1, 3, 7, 12, 15, 21, 22, 29]
print("Всего событий в пакете:", len(events))
print("Среднее время прихода:", sum(events) / len(events))

Вывод:

Всего событий в пакете: 8
Среднее время прихода: 13.75

Сравните два подхода: оконная версия выдаёт результат по мере наполнения окон и никогда не «дочитывает» поток до конца, а пакетная спокойно ждёт, пока соберутся все события, и считает разом. Отсюда и компромисс: streaming отвечает быстро, но живёт в условиях неопределённости (а вдруг придёт ещё событие?), batch отвечает позже, зато на полных данных. Понимание этого различия — половина успеха при выборе архитектуры конвейера.

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

  • Брать streaming «потому что модно». Большинство аналитических задач прекрасно решаются пакетно раз в час или в сутки, а streaming добавляет сложность и стоимость.
  • Забыть про опоздавшие события. В потоке данные приходят не по порядку; окна должны уметь ждать запоздавшие записи или их потеряете.
  • Считать batch «устаревшим». Пакетная обработка — основа аналитики, её используют все крупные компании.

Итог

  • Batch обрабатывает данные порциями по расписанию, streaming — каждое событие сразу.
  • Streaming даёт низкую латентность ценой сложности; начинать стоит с batch.
  • В streaming события группируют по временным окнам.
Проверьте себя
1. Когда потоковая обработка (streaming) действительно оправдана?
AДля ежемесячного бухгалтерского отчёта
BДля антифрода, где задержка в час недопустима
CДля разовой выгрузки исторических данных
DВсегда, потому что она современнее
2. Зачем в потоковой обработке нужны окна (windows)?
AЧтобы сжимать данные
BЧтобы группировать бесконечный поток событий по интервалам и считать агрегаты
CЧтобы шифровать события
DОкна нужны только в batch-обработке