Real-time данные и right-time данные: в чём разница и почему она важна
Не каждая задача требует данных в реальном времени. Ошибка в этом выборе стоит денег и усложняет архитектуру без пользы.
Когда компания начинает серьёзный разговор об аналитике и данных, рано или поздно появляется запрос на "данные в реальном времени". Руководитель хочет видеть текущую картину, а не вчерашнюю. Это понятное желание.
Но за словами "в реальном времени" скрывается техническое и операционное решение, стоимость которого сильно зависит от того, насколько буквально мы понимаем это требование. Разница между "данные обновляются каждые 15 минут" и "данные обновляются каждую секунду" - это не детали реализации. Это принципиально разные архитектуры с разной стоимостью и сложностью.
Что такое "правильное время"
Настоящий real-time - это данные, которые доступны за секунды или доли секунды после события. Это нужно для конкретных задач: обнаружение мошенничества в момент транзакции, управление производственным процессом с немедленной обратной связью, торговые системы. Там задержка в несколько минут делает данные бесполезными.
Большинство управленческих задач устроены иначе. Руководитель смотрит на отчёт по продажам не для того, чтобы принять решение в следующие 30 секунд. Ему нужна актуальная картина - но "актуальная" здесь может означать "обновлена час назад" или "обновлена сегодня утром".
Я использую понятие "right-time" - данные обновляются с частотой, которая соответствует частоте принятия решений. Для ежедневного оперативного отчёта это один раз в сутки. Для мониторинга производительности колл-центра - может быть, раз в 15 минут. Для управления складскими остатками - раз в час или раз в несколько часов.
Почему правильный выбор частоты важен
Архитектура данных в реальном времени значительно сложнее и дороже, чем пакетная обработка. Она требует специальной инфраструктуры - потоковых платформ типа Kafka или Spark Streaming, другой схемы хранения, другого подхода к мониторингу и надёжности.
Если строить real-time архитектуру для задачи, которая не требует секундной актуальности - это переплата за инфраструктуру и источник дополнительной сложности без практической пользы.
Обратная ошибка тоже бывает: строить пакетную обработку с обновлением раз в сутки для задачи, где решение нужно принять в течение дня - и получить аналитику, которая всегда описывает вчера.
Как определить правильную частоту для задачи
Несколько вопросов, которые помогают это понять:
Как быстро после возникновения события нужно принять решение? Если мошенническая транзакция - немедленно. Если отклонение производительности на линии - в течение часа. Если изменение в динамике продаж - в течение дня или даже недели.
Как часто человек, использующий эти данные, смотрит на дашборд или отчёт? Если раз в утро - нет смысла обновлять чаще, чем ночью.
Что произойдёт, если данные задержатся на час, на три часа, на день? Если ответ "ничего критичного" - это сигнал, что real-time не нужен.
Практическое следствие
Прежде чем инвестировать в потоковую инфраструктуру, стоит пройти по ключевым аналитическим задачам и честно ответить на вопрос: какая задержка данных приемлема для каждой из них?
Часто оказывается, что 80-90% задач вполне решаются пакетной обработкой с разумной частотой - и это решение дешевле, надёжнее, и проще в поддержке. Для оставшихся 10-20% с реальной потребностью в малой задержке - строить специализированное решение.
Смешивать всё в один "real-time" пайплайн ради единообразия - одна из самых дорогих архитектурных ошибок в аналитике.