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

Выбирайте по сроку, за который нужен ответ

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

Ниже сравниваем подходы на типичных рабочих сценариях, а не на бенчмарках: результат зависит от объёма данных, требований к задержке и выбранных инструментов. Для ориентира упоминаются Apache Kafka 3.9.x и Apache Spark 3.5.x; это не инструкция по настройке и не рекомендация сочетать именно эти версии. Код здесь не нужен: предмет статьи — выбор архитектуры, а не конкретный API.

В чём разница на практике

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

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

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

Платите за потоковую обработку не за слово «реалтайм», а за конкретное решение, которое должно успеть до того, как изменится ситуация.

Четыре задачи — четыре разных компромисса

Контроль подозрительных платежей

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

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

Выручка и управленческий отчёт

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

Обновление остатков

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

Обучение модели и пересчёт истории

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

Сравнение подходов

Когда выбирать поток, а когда пакет

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

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

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

Что ломается и что измерять

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

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

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

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

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

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