Потоковая обработка данных: когда операционные решения не терпят отложенного пакета
Когда бизнесу нужна потоковая обработка вместо пакетной, и что нужно решить до внедрения Kafka или аналогов.
Большинство аналитических систем в компаниях работают по одному принципу: данные накапливаются в течение дня, ночью запускается пакетная обработка, утром отчёт готов. Это работает для отчётности, для планирования, для анализа прошлого.
Но есть класс задач, где решение нужно принимать пока событие ещё происходит - или хотя бы в течение минут, а не часов. Мошенническая транзакция. Технический сбой в производственной линии. Аномальный всплеск возвратов. Для таких задач пакетная обработка не подходит по определению.
Это и есть territory потоковой обработки данных.
Чем потоки отличаются от пакетов
В пакетной модели данные сначала накапливаются, потом обрабатываются. Граница чёткая: вот набор данных, вот расчёт над ним.
В потоковой модели данные поступают непрерывно, и обработка происходит по мере поступления каждого события или небольших порций. Нет конечного набора - есть бесконечный поток.
Это требует другой архитектуры. Нельзя загрузить всё в память, посчитать и вернуть ответ. Нужно поддерживать состояние, обрабатывать опоздавшие события, управлять окнами времени - что считается "одновременно", если события разбросаны по времени?
Apache Kafka, ставшая де-факто стандартом для транспортного слоя потоков данных, решает задачу надёжной доставки событий. Но сам факт использования Kafka не означает, что задача потоковой обработки решена.
Где потоки реально нужны
Три класса задач, где задержка пакетной обработки - это не неудобство, а потеря ценности.
Операционные алерты. Аномалия в производственных показателях, выход метрики за порог, отклонение от нормального паттерна работы оборудования. Если обнаружение происходит через 12 часов после события - большую часть ущерба уже нанесено.
Реакция на поведение пользователей. Рекомендация в момент взаимодействия, предотвращение мошенничества до завершения транзакции, персонализированное предложение пока клиент ещё на сайте. Здесь задержка измеряется не в часах, а в секундах.
Интеграция между системами в реальном времени. Когда изменение в одной системе должно немедленно отразиться в другой - не через ночной ETL. Это часто встречается в операционных системах: изменение статуса заказа, обновление остатков, синхронизация между площадками.
Что нужно решить до внедрения
Самая распространённая ошибка при внедрении потоковой архитектуры - начать с инструмента, а не с задачи. Kafka удобна, её легко развернуть. Но Kafka - это транспорт. Что делает система с данными, которые через неё проходят?
Гарантии доставки. Что происходит, если потребитель недоступен? Данные сохраняются и будут обработаны позже - или потеряны? Kafka даёт инструменты для этого, но нужно явно настроить и протестировать поведение при сбоях.
Порядок и дубли. В распределённых системах события могут приходить не по порядку или приходить дважды. Логика обработки должна это учитывать - или гарантии на уровне инфраструктуры должны исключать такие ситуации.
Мониторинг задержки. Если система должна реагировать в реальном времени - нужно знать, сколько фактически занимает обработка от события до действия. Это отдельная метрика, которую нужно отслеживать.
Практический ориентир
Перед тем как двигаться в сторону потоковой архитектуры, стоит ответить на несколько вопросов:
- Есть ли конкретная задача, где задержка в часы - это проблема, а не просто неудобство?
- Что именно происходит с данными после того, как они попадают в поток - есть ли логика обработки или только транспортировка?
- Кто будет поддерживать потоковую инфраструктуру и какие у команды компетенции в этой области?
- Как система ведёт себя при сбое потребителя или брокера?
Потоковая обработка решает реальные задачи. Но она добавляет операционную сложность. Эта сложность оправдана там, где задержка дорого обходится - и избыточна там, где пакет справляется.