«Нам нужны дашборды в реальном времени» — запрос, который звучит на каждом втором проекте по аналитике, и кажется солидным и современным. Но если изучить его глубже, в девяти случаях из десяти выясняется, что реальное время компании не нужно, необходимо нечто другое, а именно более свежие данные, чем раз в неделю из выгрузки вручную. Разница между этими двумя вещами измеряется в деньгах, причем очень заметных.
Что значит «реальное время» на самом деле
Сначала договоримся о терминах, потому что под real-time все понимают разное. Строго говоря, real-time аналитика — это когда данные доступны для анализа в течение нескольких секунд после наступления события. Рядом стоит near-real-time, задержка в минуты. И есть классический batch, когда данные обновляются раз в час, в день или в неделю. Между секундами и сутками лежит пропасть в стоимости инфраструктуры, и именно про нее забывают, когда заказывают «реальное время».
Большинство управленческих задач могут быть решены на данных, полученных с задержкой в час или даже в день. Выручка за вчера, воронка продаж, остатки на складе на утро — для этих решений секунды не нужны. Реальное время требуется там, где решение принимается прямо сейчас и без участия человека: антифрод в платежах, динамическое ценообразование, мониторинг оборудования, который должен диагностировать аварию до того, как она случится.
Главный вопрос перед внедрением
Прежде чем строить потоковую архитектуру, ответьте на один вопрос: что вы сделаете по-другому, если узнаете об этом через секунду, а не через час? Если ответ «ничего, все равно решение принимает человек на утренней планерке», значит реальное время вам не нужно, и платить за него не стоит. Если ответ «система среагирует автоматически» или «дежурный должен вмешаться немедленно», то только в этом случае разговор становится более предметным.
Этот вопрос отсекает большую часть запросов на real-time, которые на самом деле про другое: про то, что данные собираются руками, приходят с опозданием и им нельзя доверять. Эта проблема устраняется не с помощью потоковой обработки, а нормальным автоматическим обновлением раз в час.
Где real-time оправдан в B2B
Честный список задач, где задержка в секунды действительно стоит денег:
- Мониторинг оборудования и инфраструктуры (датчики, телеметрия, предсказание отказов), в этих сферах промедление может привести к простою или аварии.
- Операционные процессы с быстрым циклом: логистика, где маршрут надо перестроить на лету; склады с высокой оборачиваемостью.
- Антифрод и безопасность: подозрительную транзакцию надо остановить до подтверждения, а не разобрать утром.
- Цифровые продукты с динамикой, где цена или доступность меняются от спроса в моменте.
Заметьте, что во всех случаях на том конце стоит автоматическое действие или дежурный, который реагирует сразу. Там, где данные идут в отчет для еженедельного решения, real-time — выброшенные деньги, как бы солидно он ни выглядел в презентации.
Полезно различать две вещи, которые часто путают: свежесть данных и скорость реакции. Свежесть — это то, насколько данные актуальны, а скорость реакции относится к тому, как быстро на их основе принимаются решения. Реальное время нужно только тогда, когда свежесть и скорость имеют первостепенную важность одновременно. Если данные обновляются каждую секунду, но решение по ним принимают раз в неделю на совещании, вы платите за свежесть, которая никому не нужна. Чаще всего бизнесу нужна предсказуемая свежесть (например, данные не старше часа), а вовсе не минимальная задержка любой ценой.
Из чего складывается цена
Чтобы разговор о больших затратах был предметным, полезно понимать, за что именно платят в потоковой системе. Сама по себе технология приема событий является лишь верхушкой айсберга. Дальше идет их обработка на постоянной основе, которая в отличие от ночного пересчета никогда не выключается, а значит, и счет за вычисления капает круглосуточно. Добавьте хранение, рассчитанное на быструю запись и чтение, мониторинг самой потоковой системы (ее работу тоже нужно контролировать) и, главное, людей, которые умеют все это сопровождать и чинить в три часа ночи.
Именно последний пункт чаще всего недооценивают. Лицензии и железо относятся к разовому и понятному расходу, а вот инженеры по потоковой обработке стоят дорого и на рынке их мало. Batch-система прощает ошибки: что-то сломалось ночью, починили утром, пользователь не заметил. Потоковая не прощает: сбой виден сразу всем, кто смотрит в дашборд. Эта разница в требованиях к надежности и есть основная скрытая статья бюджета.
Дешевый путь
Хорошая новость: чтобы получить «достаточно свежие» данные, почти никогда не нужно строить полноценную потоковую платформу с очередями сообщений и стрим-процессорами. Между ручной выгрузкой раз в неделю и настоящим real-time есть огромная недооцененная середина, и большинство компаний живет именно в ней.
Первый дешевый шаг — инкрементальное обновление по расписанию. Вместо того чтобы раз в сутки пересчитывать все заново, система каждые несколько минут подтягивает только новые записи. Для бизнеса это выглядит почти как реальное время, а стоит копейки по сравнению с потоковой архитектурой. Вторым приемом являются микро-батчи, т.е. обработка маленькими порциями каждые несколько минут, чего хватает с запасом для большинства задач.
Третий прием — не трогать то, что не требует свежести. Real-time обычно нужен одному-двум показателям, а не всему дашборду. Сделайте быстрыми только их, остальное оставьте на ночном обновлении. Смешивать скорости в одной системе нормально, и это сильно дешевле, чем гнать все через потоковую обработку ради единственной плитки на экране.
Покажем на примере. Производственная компания пришла с запросом «дашборд в реальном времени по всем показателям». Стали разбирать по пунктам. Выручка, маржа, остатки на утро — все эти показатели могли спокойно обновляться раз в час, поскольку никто не принимал по ним решений чаще. Единственное, что действительно требовало секунд, статус линии розлива, где остановка стоит дорого и реагировать надо немедленно. В итоге вместо потоковой платформы на весь дашборд сделали инкрементальное обновление раз в десять минут для большинства плиток и настоящий поток только для одного показателя — статуса оборудования. Бюджет проекта сократился в разы, а компания получила ровно ту пользу, которая ей была необходима.
Типичные ошибки
Самая частая ошибка заключается во внедрении real-time ради статуса, а не ради задачи. Компания строит дорогую потоковую систему, дашборд обновляется каждую секунду, а смотрят в него раз в день. Деньги потрачены, эффекта ноль. Вторая — реальное время поверх плохих данных: если источник грязный, вы будете быстро получать неверные цифры, и скорость лишь ускорит распространение ошибки. Сначала качество, потом скорость. Третья ошибка состоит в недооценке стоимости эксплуатации: потоковая система требует постоянного наблюдения за ее работой, а значит и дополнительных расходов, и это обнаруживается уже после внедрения, когда отступать поздно.
Что сделать управленцу
Порядок действий простой. Составьте список показателей, для которых вы вообще рассматриваете real-time, затем по каждому задайте вопрос про необходимость автоматического действия. Оставьте в категории «реальное время» только те, для которых это критически важно, обычно это один-два пункта. Для остального настройте инкрементальное обновление раз в несколько минут или раз в час, этого достаточно. И только для прошедших отбор задач стройте потоковую обработку, заранее заложив в бюджет не только внедрение, но и сопровождение.
И не стройте все сразу, возьмите один показатель, который точно прошел отбор, сделайте по нему пилот и посмотрите, как им пользуются на практике. Часто после пилота выясняется, что и здесь хватило бы обновления раз в минуту, а иногда наоборот, что рядом есть вторая задача, которая по-настоящему требует скорости. Пилот стоит дешево и страхует от самой дорогой ошибки: построить большую потоковую систему и обнаружить, что в нее никто не смотрит.
Вывод
Real-time аналитика — мощный инструмент для узкого класса задач, где решение принимается автоматически в течение нескольких секунд. Для всего остального это дорогая имитация ощущения, что компания находится в тренде. Деньги экономятся не на технологиях, а на честном ответе на вопрос, что именно вы будете делать с данными быстрее. Чаще всего оказывается, что свежих данных раз в час достаточно, а сэкономленный бюджет лучше вложить в их качество, там отдача выше, чем от лишних секунд.