Потоковая обработка данных - это операционный вопрос, а не архитектурный
Почему решение о переходе на стриминг должно начинаться с понимания операционной нагрузки, а не с выбора технологии.
Разговор о потоковой обработке данных почти всегда начинается с технологии. Kafka, Flink, Spark Streaming - кто-то в команде слышал, что так делают крупные компании, или архитектор настаивает, что "батч устарел". Решение принимается, стек выбирается, и только потом начинается понимание, во что ввязались.
Это неправильный порядок. Переход на потоковую обработку - это в первую очередь операционное решение. И прежде чем его принимать, нужно ответить на несколько вопросов, которые не имеют ничего общего с выбором платформы.
Почему стриминг сложнее батча в операционном смысле
Батчевая обработка работает просто: задание запускается, завершается, результат есть. Если что-то пошло не так - видно сразу, перезапуск понятен, отладка относительно проста.
Потоковая система работает непрерывно. Она должна быть запущена всегда. Сбой означает, что обработка остановилась - и накопилось отставание. Восстановление требует не просто перезапуска, а понимания, с какой точки восстанавливаться, как обрабатывать дублирование, как не потерять данные и не посчитать их дважды.
Состояние потоковой системы значительно сложнее, чем у батча. Гарантии доставки, семантика exactly-once, управление смещениями - это реальная операционная нагрузка, которая требует понимания и постоянного обслуживания.
Когда стриминг действительно нужен
Стриминг оправдан, когда у бизнеса есть реальное требование к латентности - не "было бы хорошо видеть данные быстрее", а конкретная бизнес-задача, которая перестаёт работать при задержке больше нескольких минут.
Примеры, где это действительно так: фрод-мониторинг в реальном времени, где каждая минута задержки - это деньги. Операционные дашборды, где менеджер принимает решения прямо сейчас. Реакция на события - уведомления, триггеры, автоматические действия, где задержка меняет результат.
Примеры, где стриминг лишний: аналитика за прошлые периоды. Ночные отчёты. ML-обучение, которое само по себе занимает часы. Синхронизация данных, где пятиминутная задержка неотличима от мгновенной для пользователя.
Что нужно решить до выбора платформы
Первый вопрос: какова требуемая латентность, и откуда это требование? Кто из бизнеса поставил цифру, и что происходит, если она не выдерживается?
Второй: есть ли в команде люди с опытом эксплуатации потоковых систем? Не разработки - именно эксплуатации. Это разные знания.
Третий: какова допустимая потеря данных при отказе системы? Это определяет требования к гарантиям доставки и сложность всей системы.
Четвёртый: как будет выглядеть откат при серьёзном сбое? Можно ли переиграть историю с определённой точки?
Пятый: что происходит с downstream-системами, если поток встаёт? Это касается не только самого стриминга, но и всего, что на него опирается.
Практическая рекомендация
Если у вас нет опыта эксплуатации потоковых систем в команде и нет жёсткого бизнес-требования к латентности, которое не закрывает батч - начинать со стриминга не стоит. Хорошо построенный батч с частотой запуска раз в несколько минут покрывает большинство реальных потребностей и стоит значительно дешевле в обслуживании.
Стриминг - это мощный инструмент для конкретных задач. Но как и любой мощный инструмент, он требует понимания, когда его применять и как им управлять. Начинать надо с задачи, а не с технологии.