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