Batch vs Stream Processing

Транзакция по карте - 100 миллисекунд на проверку мошенничества. Опоздал - деньги ушли. Отчёт «потрачено за месяц» - часы. Kafka в LinkedIn обрабатывает 7 триллионов сообщений в день. Netflix запускает Apache Flink на 2 миллионах событий в секунду. Одна компания - batch для ML-моделей ночью, stream для «Trending Now» прямо сейчас. Архитектор выбирает не «batch или stream», а понимает, что нужно каждой задаче.

• **Kafka (LinkedIn)** - 7 триллионов сообщений в день; Kafka Streams = stream processing без отдельного кластера, прямо внутри Java-приложения
• **Flink (Netflix)** - 2 миллиона событий в секунду, latency единицы миллисекунд; персонализация, мониторинг, A/B тесты в real-time
• **Spark Structured Streaming vs Flink**: Spark - micro-batch (100мс-2с, простой API); Flink - true stream (1-10мс, полный контроль, сложнее)

Batch Processing

Каждую ночь Amazon пересчитывает рекомендации для миллионов пользователей. Uber подводит итоги поездок за день. Netflix обновляет рейтинги фильмов. Всё это - **batch processing**: накопили данные, обработали целиком, получили результат. Apache Spark запускает такие задачи на кластерах с петабайтами данных - именно batch-режим обучает ML-модели в LinkedIn, Meta, Airbnb.

**Batch processing** - обработка конечного, фиксированного набора данных. Данные уже собраны (bounded dataset). Система читает весь вход, выполняет вычисления, записывает весь выход. Задержка - от минут до часов.

Главное преимущество batch: **простота и надёжность**. Данные не меняются во время обработки, результат детерминирован. Можно перезапустить задачу при ошибке. Главный недостаток: результаты устаревают к моменту готовности.

MapReduce (Google, 2004) → Spark (2012) → современные движки. Spark заменил MapReduce благодаря in-memory обработке: данные хранятся в RAM между шагами, а не записываются на диск. Ускорение 10-100x. Spark Structured Streaming - micro-batch поверх того же движка - используется Kafka при обработке 7 триллионов сообщений в день на LinkedIn.

Micro-batch Processing

А что если запускать batch каждые 2 секунды? Это и есть **micro-batch** - компромисс между batch и stream. Данные накапливаются маленькими порциями и обрабатываются как мини-batch. Задержка снижается до секунд.

**Spark Structured Streaming** - главный представитель micro-batch подхода. Каждые N секунд (по умолчанию 100 мс - 2 с) входящие данные объединяются в мини-DataFrame и обрабатываются тем же API, что и batch Spark. Это упрощает переход от batch к «почти-stream».

Micro-batch наследует все преимущества batch: exactly-once semantics (гарантия обработки ровно один раз), простой API, отличная fault tolerance. Недостаток - задержка не может быть ниже длительности micro-batch (обычно 100 мс - несколько секунд).

Для многих задач micro-batch - идеальный выбор. Дашборды обновляются каждые 5 секунд? Micro-batch. Агрегация метрик за последнюю минуту? Micro-batch. Spark Structured Streaming держит latency 100мс-2с. Но Netflix обрабатывает 2 миллиона событий в секунду через Apache Flink с latency в единицы миллисекунд - для этого нужен настоящий stream.

Stream Processing

**Stream processing** - обработка каждого события по мере поступления, без ожидания. Событие пришло - обработано - результат готов. Задержка измеряется в миллисекундах. Apache Flink - лидер: Netflix запускает на нём 2 миллиона событий в секунду для персонализации и мониторинга. Kafka Streams - встроенный stream-движок в Kafka, который в LinkedIn обрабатывает 7 триллионов сообщений в день.

Ключевое отличие от batch: данные **unbounded** - поток не имеет конца. Нет «всего набора данных». Нужно определить, что означает «последние 5 минут» (windowing), что делать с опоздавшими данными (watermarks), и как гарантировать корректность при сбоях.

**Windowing** - основной механизм агрегации в потоках. Tumbling window (непересекающиеся окна: [0-5с], [5-10с], ...), Sliding window (скользящие: [0-5с], [2-7с], ...), Session window (по активности пользователя, с gap timeout).

Lambda и Kappa архитектуры

Как совместить преимущества batch (точность, полнота) и stream (скорость)? Nathan Marz предложил **Lambda Architecture**: два параллельных слоя - batch (точный, медленный) и speed (быстрый, приблизительный). Результаты объединяются при запросе.

Jay Kreps (создатель Kafka) предложил альтернативу - **Kappa Architecture**: только один stream pipeline. Kafka хранит исторические данные (retention), поэтому при необходимости можно «перемотать» и перечитать поток заново. Один pipeline, одна логика.

Современный тренд: Kappa побеждает. Apache Flink обеспечивает exactly-once semantics, Kafka хранит данные годами (tiered storage). Необходимость в отдельном batch-слое уменьшается. Но для ML-тренировки и сложной аналитики batch по-прежнему оптимален.

На практике многие системы используют гибридный подход: Kafka для ingestion, Flink для real-time обработки, Spark для тяжёлой аналитики и ML. Важно выбирать архитектуру под конкретные требования к задержке, точности и сложности.

Ключевые идеи

• **Batch** - конечный bounded dataset, throughput максимальный, задержка минуты-часы; Spark обучает ML-модели LinkedIn, Meta, Airbnb
• **Micro-batch** - Spark Structured Streaming, latency 100мс-2с, тот же DataFrame API что batch; exactly-once встроено
• **True Stream** - Flink обрабатывает 2M событий/сек у Netflix с latency 1-10мс; windowing, watermarks для out-of-order данных
• **Lambda** = batch + stream (дублирование логики); **Kappa** = только Kafka + Flink (один pipeline, перечитать с начала при смене логики)
• **Kafka** - 7 триллионов сообщений/день в LinkedIn; это не только брокер, но и хранилище для Kappa-архитектуры

Связанные темы

Batch vs Stream - фундамент для архитектур обработки данных:

• Event-Driven Architecture — Events и commands - строительные блоки stream-систем
• Message Brokers — Kafka, RabbitMQ, NATS - транспорт для потоковых данных

Вопросы для размышления

• Kafka в LinkedIn обрабатывает 7 триллионов сообщений в день. Какие задачи из этого потока требуют true stream (Flink, мс latency), а какие можно делать micro-batch (Spark, 2с latency) - и почему разделение важно?
• Netflix держит batch Spark для переобучения ML-моделей ночью и Flink для real-time событий. Почему не перейти полностью на Kappa - что именно делает batch незаменимым для ML-тренировки?
• Backpressure - механизм, при котором перегруженный consumer сигнализирует producer замедлиться. Как Flink реализует это в контексте watermarks и windowing?

Связанные уроки

• stream-02 — Event-driven архитектуры строятся поверх stream processing - следующий логический шаг.
• stream-03 — Kafka и другие брокеры - транспортный слой для всех потоковых архитектур.
• bd-01 — Big Data Volume и Velocity - именно та среда, для которой придуманы batch и stream модели.
• st-01-feedback-loops — Lambda/Kappa-архитектуры - пример систем с обратной связью: batch-слой корректирует stream-слой.
• prob-03-conditional — Watermarks и оценка опоздавших событий требуют вероятностного мышления о задержках в потоке.