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

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

Сначала задайте цену задержки

Для конкретной метрики запишите три условия: когда данные появились, к какому сроку нужен результат и можно ли позже его исправить. Например, статистика продаж для утреннего отчёта спокойно ждёт накопления данных. Сигнал о резком росте ошибок сервиса может требовать реакции за минуты. Обработка платежей — до принятия решения о заказе.

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

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

Три подхода и их цена

Пакет: считать по расписанию

Система собирает данные за интервал — например, за час или сутки — и запускает обработку целиком. Это удобный вариант для регулярных отчётов, сверок и задач, где важен итог за период. Если расчёт упал, часто можно повторить его на том же наборе входных данных.

Цена — ожидание и пиковая нагрузка во время запуска. Чем реже формируются пакеты, тем дольше результат устаревает. Если обрабатывать маленькие пакеты каждую минуту, расписание начинает напоминать поток, но сохраняет накладные расходы на запуск и управление отдельными заданиями.

Поток: обрабатывать события по мере поступления

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

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

Микропакет: компромисс между непрерывностью и расписанием

Обработчик набирает события короткими интервалами и обрабатывает их небольшими партиями. Для пользователя результат выглядит почти непрерывным, а команде проще мыслить пакетами и повторно обрабатывать данные. В Spark Structured Streaming 3.5.x микропакетная обработка — основной режим Structured Streaming; подробности и ограничения зависят от источника и приёмника.

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

Для ориентира: примеры технологий в этом разборе — Apache Kafka 3.8 как система доставки и хранения событий и Spark Structured Streaming 3.5.x как средство обработки. Kafka не заменяет вычислительный слой: события из неё всё равно должен читать и обрабатывать потребитель.

Сравнение для выбора

Когда что выбирать

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

Не превращайте показатель свежести в абстрактное требование вроде «почти онлайн». Согласуйте его с теми, кто использует результат: через какое время данные ещё полезны, когда опоздание уже мешает работе и допустимо ли показать предварительное значение. Это задаёт архитектуру лучше, чем само количество событий.

Что ломается в реальной системе

Повторная доставка меняет результат

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

Опоздавшее событие портит окно

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

Потребитель не успевает за входом

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

Пакет запускается повторно не на тех данных

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

Сноска. Водяной знак (watermark) — правило потокового движка, которое ограничивает, как долго он ждёт опоздавшие события для временного окна. Это не исправление данных: события, пришедшие позже принятого предела, могут потребовать отдельного пересчёта или обработки.

Что делать дальше

Возьмите один реальный показатель и опишите его путь от источника до потребителя. Измерьте время поступления, обработки и публикации, включая обычную нагрузку и пик. Затем проверьте сценарии перезапуска, повторного события и опоздавших данных. Если пакет уже укладывается в срок, потоковая архитектура не ускорит решение задачи автоматически. Если не укладывается, эти измерения покажут, где именно стоит менять расписание, вычисления или доставку.