Потоковая и пакетная обработка данных: сравнение подходов

Прямой ответ

Потоковая обработка вычисляет результат по мере поступления данных, пакетная — по завершении периода над полным набором. Различие определяет задержку результата, стоимость и способ обработки поздних данных.

Потоковая обработка требует управления состоянием и временем: окна закрываются по watermark, а события, пришедшие после закрытия, требуют решения — отбросить либо пересчитать; об окнах — в статье про оконную агрегацию.

Пакетная обработка выполняется над полным набором, поэтому вопрос поздних данных не возникает: запуск по завершении периода видит все данные периода. О пакетной обработке — в статье про основы Spark.

# Потоковая: результат обновляется по мере поступления
for batch in kafka_consumer:
    for event in batch:
        window = window_for(event.event_time)
        state[window] = state.get(window, 0) + 1
        emit(window, state[window])          # обновлённый результат

# Пакетная: результат вычисляется один раз за период
result = spark.sql("""
    SELECT date_trunc('hour', event_time) AS hour, COUNT(*) AS cnt
    FROM events WHERE event_time >= :start AND event_time < :end
    GROUP BY 1
""")

Стоимость, корректность и повторный расчёт

Три аспекта определяют выбор подхода в конкретных условиях.

Стоимость при низкой нагрузке. Потоковый процесс работает постоянно, поэтому стоимость не зависит от объёма данных. Пакетное задание выполняется по расписанию и потребляет ресурсы только во время запуска, что дешевле при малом объёме.

Корректность при поздних данных. Пакетный расчёт по завершении периода включает все данные периода. Потоковый расчёт формирует результат до поступления поздних данных, поэтому требует пересчёта либо допускает неполноту.

Повторный расчёт при изменении логики. Изменение формулы показателя требует пересчёта истории. Пакетный пересчёт выполняется запуском задания по историческим данным. Потоковый пересчёт требует повторного чтения потока с сохранённого смещения и сохранения состояния, что сложнее.

Практическое следствие: потоковая обработка оправдана, когда задержка результата влияет на решение. Если результат используется через часы, пакетная обработка даёт тот же показатель при меньшей сложности и стоимости.

Распространённый компромисс — сочетание двух подходов. Потоковый расчёт даёт оперативный показатель, а пакетный периодически пересчитывает завершённые периоды и исправляет расхождения. О пакетных конвейерах — в статье про ETL-конвейер.

Компромисс имеет стоимость: две реализации одной логики расходятся со временем, поэтому расхождение требует сверки и разбора. Альтернатива — единая логика, выполняемая в обоих режимах, что поддерживается не всеми инструментами.

Отказоустойчивость и эксплуатационная нагрузка

Различие подходов проявляется не только в расчёте, но и в том, что происходит при сбое и как система ведёт себя в повседневной эксплуатации.

Восстановление после сбоя. Потоковое задание восстанавливается из контрольной точки, сохраняя состояние окон и агрегатов. Пакетное задание перезапускается целиком, поскольку состояния между запусками не существует. Первое быстрее при коротком сбое, второе проще при длительном.

Накопление отставания. Потоковая обработка при недостаточной производительности накапливает отставание, которое растёт до устранения причины. Пакетное задание при нехватке ресурсов увеличивает длительность запуска, но следующий запуск начинается с актуальных данных.

Порядок развёртывания. Обновление потокового задания требует сохранения состояния и проверки совместимости его структуры. Пакетное задание развёртывается без состояния, поэтому изменение кода не требует миграции.

Наблюдаемость. Потоковое задание требует метрик отставания, размера состояния и длительности контрольных точек. Пакетное задание — метрик длительности запуска и полноты обработанных данных.

Практическое следствие: эксплуатационная стоимость потоковой обработки выше не из-за расчёта, а из-за состояния, которое нужно сохранять, восстанавливать и мигрировать при изменении кода.

Отдельный аспект — влияние на хранилище источника. Потоковая обработка читает журнал постоянно, а пакетная — большими порциями по расписанию. При ограниченной пропускной способности хранилища постоянный поток чтения конкурирует с другими потребителями, тогда как пакетный запуск выполняется в выделенное окно.

Практика: выбор подхода обработки

0. Проверяйте, существует ли требование к задержке. Первый вопрос — кто и когда читает показатель. Если потребитель читает результат раз в сутки, потоковая обработка решает задачу, которой нет.

1. Начинайте с требования к задержке результата. Если показатель используется через часы, пакетная обработка достаточна и проще в эксплуатации.

2. Оценивайте стоимость при фактическом объёме. Постоянно работающий потоковый процесс дороже периодического запуска при малом объёме данных.

3. Учитывайте долю поздних данных. Высокая доля требует допустимой задержки и пересчёта, что усложняет потоковую реализацию.

4. Планируйте повторный расчёт истории. Изменение формулы показателя требует пересчёта, и стоимость различается между подходами.

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

6. Оценивайте сложность состояния. Потоковая обработка хранит состояние, объём которого растёт с размером окна и допустимой задержкой.

7. Проверяйте восстановление после сбоя. Потоковое задание восстанавливается из контрольной точки, пакетное — повторным запуском.

Рекомендации:

1. Не применяйте потоковую обработку только из-за её современности. Задержка результата оправдывает сложность только при фактической потребности в оперативном показателе.
2. Различайте оперативный и итоговый показатель. Оперативный показатель допустимо считать приближённо, итоговый требует полноты данных.
3. Учитывайте стоимость поддержки двух реализаций. Расхождение между потоковым и пакетным расчётом требует регулярной сверки.
4. Проверяйте поведение при всплеске нагрузки. Потоковая обработка накапливает отставание, пакетная — увеличивает длительность запуска.
5. Документируйте выбранный подход и его ограничения. Требование к задержке и допустимая неполнота фиксируются вместе с реализацией.

Практический сценарий: потоковый расчёт заменён пакетным после оценки требования

Контекст: показатель числа событий по часам считался в потоке, при этом использовался в отчёте, формируемом раз в сутки.

1. Диагностика. Потоковое задание работало постоянно, хранило состояние окон и требовало управления допустимой задержкой. Показатель читался из результата один раз в сутки при формировании отчёта.
2. Причина несоответствия. Требование к задержке результата отсутствовало: отчёт формировался по завершении суток, поэтому оперативность потокового расчёта не использовалась. Сложность управления состоянием и поздними данными не приносила пользы.
3. Действия. (а) Заменили потоковое задание пакетным расчётом по завершении суток; (б) убрали управление состоянием и допустимой задержкой, поскольку пакетный расчёт видит все данные периода; (в) сохранили исходный поток событий для повторного расчёта при изменении формулы; (г) сверили результат пакетного расчёта с прежним потоковым за несколько периодов и подтвердили совпадение; (д) зафиксировали требование к задержке результата в документации, чтобы возвращение к потоковой обработке выполнялось по обоснованию.
4. Результат. Стоимость обработки снизилась, а корректность результата повысилась, поскольку пакетный расчёт включает поздние данные без пересчёта.

Вывод: выбор подхода определяется требованием к задержке результата, а не возможностями инструмента. При отсутствии потребности в оперативном показателе пакетная обработка проще и точнее, поскольку включает поздние данные без управления допустимой задержкой.

FAQ

Когда потоковая обработка оправдана? Когда задержка результата влияет на решение: мониторинг, оповещение, оперативные показатели, обработка в реальном времени.

Можно ли сочетать оба подхода? Да. Потоковый расчёт даёт оперативный показатель, пакетный периодически пересчитывает завершённые периоды. Стоимость — две реализации и сверка расхождений.

Что проще пересчитать при изменении формулы? Пакетный расчёт: запуск задания по историческим данным. Потоковый пересчёт требует повторного чтения потока и сохранения состояния.

Какой подход дешевле при малом объёме данных? Пакетный, поскольку ресурсы потребляются только во время запуска, а потоковый процесс работает постоянно.

Источники: Apache Flink architecture, Spark Structured Streaming, Questioning the Lambda Architecture — ссылки в шапке.