Дашборд, который обновляется раз в сутки, отвечает на вопрос «что было вчера». Бизнесу всё чаще нужен ответ на вопрос «что происходит сейчас» – пока заявку ещё можно обработать, склад не успел уйти в минус, а платёж не завис в шлюзе. Это и есть аналитика реального времени: данные попадают в отчёт за секунды, а не за часы. Разберём, как собрать такую систему на отечественном стеке и где обычно ломается внедрение.

Чем потоковая аналитика отличается от классического BI

Традиционный BI работает по схеме ETL: ночью забрали данные из источников, сложили в хранилище, утром построили витрины. Задержка от события до отчёта – часы. Для квартальной отчётности этого достаточно, для оперативного управления – нет.

Потоковая модель переворачивает порядок. Источники публикуют события в шину сразу при их возникновении: списание со счёта, изменение статуса заказа, показание датчика. Обработчик читает поток, агрегирует на лету и пишет в быстрое аналитическое хранилище. Дашборд опрашивает его с частотой в секунды.

Ключевая разница – не в скорости железа, а в архитектуре. Вы перестаёте «опрашивать» базы и начинаете «слушать» события. Это требует другого подхода к интеграции: системы-источники должны уметь отдавать изменения, а не только отвечать на запросы. Здесь та же дисциплина контрактов и адаптеров, что и при импортозамещении интеграционного middleware – без надёжной шины поток рассыпается.

Стек, который работает в реестровых проектах

Базовый контур для госсектора и регулируемого бизнеса собирается из компонентов, у которых есть российские поставки и поддержка:

  • Шина событий – Apache Kafka. Зрелая, проверенная, есть отечественные дистрибутивы и коммерческая поддержка внутри РФ.
  • Потоковая обработка – Apache Flink или Kafka Streams для агрегации, оконных функций и обогащения.
  • Аналитическое хранилище – ClickHouse. Колоночная СУБД российской разработки, в реестре отечественного ПО, держит миллиарды строк и отдаёт агрегаты за миллисекунды.
  • Визуализация – отечественные BI-платформы из реестра, которые умеют работать с ClickHouse по нативному коннектору и поддерживают авто-обновление панелей.

Этот набор закрывает требования по импортонезависимости и при этом не заставляет переучивать команду с нуля: SQL остаётся SQL, Kafka остаётся Kafka. Проектирование полного контура – от модели событий до регламентов эксплуатации – опирается именно на эту преемственность инструментов.

Где внедрение спотыкается

Три типичные ошибки.

Считают, что «реальное время» нужно везде. Не нужно. Поток дороже в эксплуатации, чем ночной ETL. Определите, для каких метрик задержка действительно стоит денег, и переводите в стрим только их. Остальное оставьте батчу.

Игнорируют качество данных на входе. В пакетной обработке мусор отлавливают ночью. В потоке кривое событие сразу искажает дашборд, и решение принимают по ошибке. Валидацию и дедупликацию закладывайте в обработчик, а не «потом».

Не считают наблюдаемость самой системы. Поток – это конвейер, который должен работать круглосуточно. Лаг консьюмеров, отставание партиций, дрейф схемы нужно мерить так же дисциплинированно, как мы делаем это для RAG-систем. Без метрик самого конвейера вы узнаете о сбое от пользователя, а не от мониторинга.

Отдельный сценарий – когда поверх потока работает ИИ-агент, реагирующий на события автоматически. Тогда требования к качеству и задержке ужесточаются ещё на порядок.

Вывод

Аналитика в реальном времени – не замена классическому BI, а его дополнение для тех решений, где промедление стоит денег. На отечественном стеке Kafka плюс ClickHouse такой контур собирается из проверенных компонентов и соответствует требованиям по импортонезависимости. Начните с одной метрики, где задержка критична, доведите конвейер до устойчивой работы и масштабируйте от практики, а не от презентации.