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