Почти real-time: когда бизнесу нужен поток, а когда хватает каждые 15 минут
Не всякая онлайн-аналитика имеет экономический смысл. Разбор того, когда поток данных оправдан, а когда это дорогостоящая иллюзия скорости.
Несколько раз в год я слышу от клиентов примерно одно и то же: "нам нужен real-time". Иногда это точная формулировка реальной потребности. Чаще - это лозунг, за которым стоит что-то другое: желание видеть актуальные цифры, ощущение контроля, зависть к тому, как работают крупные онлайн-площадки.
Прежде чем проектировать потоковую обработку, я всегда задаю один вопрос: что именно изменится в решениях или действиях, если данные будут обновляться раз в секунду, а не раз в пятнадцать минут?
Где задержка действительно стоит денег
Есть классы задач, где каждая секунда задержки имеет измеримую цену:
- обнаружение мошенничества в платёжных транзакциях: блокировка через 200 мс и через 15 минут - это принципиально разные результаты;
- мониторинг оборудования на производстве, где отказ нужно поймать до того, как он стал аварией;
- алгоритмическая торговля, где порядок миллисекунд влияет на прибыль напрямую.
Это узкий список. И обратите внимание: во всех этих случаях есть не просто "мы хотим видеть цифры быстрее", а конкретное действие, которое нужно совершить немедленно.
Где задержка в 15 минут - это не компромисс, а норма
Большинство управленческих задач живут в другом времени:
- дашборд продаж на сегодня: директор смотрит его раз в несколько часов, и данные трёхминутной давности ничего не меняют;
- отчёт по остаткам на складе: обновление каждые полчаса достаточно для большинства операций;
- CRM-аналитика по воронке: данные за вчера утром - это норма, а не ограничение.
Здесь задержка в 15 минут или даже час - не слабость системы. Это адекватный ответ на реальную потребность.
Чем платит бизнес за настоящий real-time
Потоковая архитектура - это не просто другой инструмент, это другая экономика проекта. У пакетной модели, которую она заменяет, есть собственные сбои и операционная логика:
- сложнее инфраструктура: нужны компоненты, которые умеют обрабатывать данные в движении, а не пакетами;
- сложнее обеспечить качество данных: ошибки и дубли распространяются мгновенно;
- выше требования к мониторингу: сломанный поток незаметен до тех пор, пока кто-то не посмотрел на цифру и не почувствовал неладное;
- дороже в поддержке: специалистов меньше, и они стоят дороже.
Всё это не аргументы "против". Это аргументы за честный расчёт: стоит ли ускорение тех затрат, которые за ним следуют.
Промежуточный вариант, о котором забывают
Между "батчем раз в ночь" и "потоком в реальном времени" есть большое пространство - мини-батчи, обновление каждые 5-15 минут, событийная доставка без сложного стримингового стека. Для большинства задач именно здесь лежит оптимум: данные достаточно свежи, а архитектура остаётся управляемой.
Я видел проекты, где "мы переходим на real-time" означало переход с ежедневного батча на батч каждые 10 минут. Это было правильным решением и решило проблему - без полного переписывания инфраструктуры.
Проверочные вопросы перед выбором архитектуры
Прежде чем ставить задачу на потоковую обработку, стоит ответить:
- Какое решение нельзя принять с данными 15-минутной давности, но можно с секундными?
- Кто конкретно будет реагировать на изменение в данных - человек или автомат?
- Если автомат - у нас уже есть логика этой реакции, или её тоже нужно строить?
- Как мы узнаем, что поток сломался и данные перестали поступать?
- Кто будет поддерживать эту систему через год, когда автор уйдёт?
Если на первый вопрос нет конкретного ответа - почти наверняка задача решается без потоковой архитектуры. И это хорошая новость: значит, можно сделать быстрее, дешевле и надёжнее.