Потоковая обработка против пакетной: где выигрывают цифры

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

Сравниваем одинаковую задачу

Представим сервис, который получает события о заказах и показывает продажи по минутам. Сейчас приложение складывает события в PostgreSQL 16, а агрегаты пересчитываются почасовым запросом. Для сравнения возьмём потоковую архитектуру: события поступают в Apache Kafka 3.9, Apache Flink 1.20 обновляет агрегаты, а результат сохраняется для отчёта.

Цифры в примере — расчёт для заданного объёма, не результат замера на реальном кластере. 10 млн событий в сутки — около 116 событий в секунду в среднем. Почасовой запуск читает около 416 667 событий, если нагрузка распределена равномерно. В пиковые часы поток может быть гораздо выше среднего: именно его и нужно измерить перед выбором архитектуры.

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

Что именно меняется внутри

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

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

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

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

Как оценить «до и после» без выдуманных бенчмарков

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

1. Опишите цель. Запишите допустимую задержку, например p95 не более 5 секунд, и укажите, от какого момента её считаете: приёма события приложением или записи в итоговую таблицу. Результат шага — метрика, которую можно измерить и сопоставить в обеих схемах.
2. Измерьте вход. Снимите среднюю и пиковую скорость, размер события, число повторов и долю опоздавших записей. Для расчёта возьмите период с характерными пиками, а не только спокойный час. Результат — профиль нагрузки, который можно воспроизвести в тесте.
3. Снимите пакетную базу. Измерьте длительность запроса, число прочитанных строк, нагрузку на PostgreSQL и время от события до появления в отчёте. Разделите задержку расписания и время самого пересчёта. Результат — зафиксированные показатели текущей схемы.
4. Проверьте поток на тех же данных. Нагрузите Kafka и Flink тем же потоком, включая повторы и опоздания. Измерьте p50 и p95 задержки, отставание очереди, потребление CPU и памяти, а также время восстановления после остановки обработчика. Результат — сравнение при равных условиях, а не две несопоставимые цифры.
5. Посчитайте цену эксплуатации. Сложите ресурсы постоянно работающих компонентов, хранилище, мониторинг и время команды на поддержку. Сравните с затратами на пакетные запуски и последствиями устаревших данных. Результат — решение, в котором видна не только скорость, но и её стоимость.

Для иллюстрации восстановления: при среднем потоке 116 событий в секунду за 15 минут простоя накопится примерно 104 400 событий. Если после перезапуска обработчик устойчиво потребляет 232 события в секунду, то при неизменном входящем потоке он будет разбирать накопленное ещё примерно 15 минут. Это упрощённый расчёт: пики, повторная обработка и запись результата могут увеличить время.

Где потоковая схема ломается

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

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

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

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

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

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

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

Зафиксируйте для одного отчёта допустимую задержку, пиковую скорость событий и стоимость ошибки в цифрах. Затем снимите базовые метрики пакетного процесса и проведите нагрузочный тест потоковой схемы на Apache Kafka 3.9 и Apache Flink 1.20, сверяясь с документацией именно этих версий. В проде особенно важны p95 задержки, рост очереди, доля повторов и время восстановления: если эти показатели не укладываются в цель, «реальное время» существует только в архитектурной диаграмме.