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