Когда владельцы бизнеса просят команду IT «добавить аналитику» в продукт, часто это заканчивается болью — и для разработчиков и для самого бизнеса. За последние несколько лет я участвовал в построении аналитических решений более чем в 10 компаниях — от стартапов до крупных корпораций. Почти во всех компаниях среднего уровня, только начинающих выстраивать BI-аналитику, я видел одну и ту же ошибку: попытку встроить аналитику в архитектуру приложения как обычный модуль. Это не работает, и вот почему.
Стандартная разработка ≠ аналитика
Разработчики мыслят фичами, модулями, интерфейсами. Они привыкли, что пользователь кликает — что-то происходит — и можно это зафиксировать. Поэтому когда поступает запрос «сделайте аналитику», часто реализуется нечто вроде:
Аналитический модуль в приложении
Сбор и агрегация данных внутри боевой БД
Набор фиксированных отчётов по заранее прописанным правилам
Выглядит как нормальное решение. Пока бизнес не попросит «а теперь добавьте ещё один разрез», «а можно посмотреть не по дням, а по неделям?», «а сколько таких событий было за последние 7 дней, но только по пользователям, у которых был чек больше 5000?».
И тут наступает реальность.
Что идёт не так
Отчёты жёстко закодированы. Любая новая метрика или разрез — это доработка.
Нагрузка на боевую БД. Когда отчёты дергают боевую базу — ждите проблем.
Никакой гибкости. Бизнесу нужна живая, подстраиваемая аналитика, а не фиксированные отчеты раз в день/неделю.
Отсутствие масштабируемости. Такой подход не выдерживает роста данных и запросов.
Аналитика — это не отчёты. Это среда для поиска инсайтов. И она требует гибкости. Метрик много. Разрезов — ещё больше. Сегодня хотят одно, завтра — другое. Аппетиты растут. Если архитектура не готова к такому сценарию, бизнес остаётся в слепой зоне.
Как должно быть на самом деле
Вот минимальный набор принципов, если вы хотите, чтобы аналитика работала по-взрослому:
Отделяйте аналитику от приложения. Никаких аналитических модулей внутри боевого кода.
Снимайте нагрузку с основной БД. Используйте реплику. При небольших объёмах (до 100 млн строк) — подойдет даже реплика боевой БД.
Переходите на аналитические СУБД. При росте объёма данных переходите на СУБД, специально созданные для агрегации больших объемов данных — ClickHouse, GreenPlum и т.п.
Позвольте аналитикам самим забирать данные. Лучше всего — передавайте данные в виде, не мешающем работе основного приложения.
Самое главное: аналитика — это не фича, это отдельная подсистема. И она требует своих инструментов, подходов и приоритетов. IT-команда не обязана строить все расчёты и метрики. Наоборот — она должна помочь передать данные туда, где аналитики сами смогут строить любые отчёты и дашборды. Тогда и разработка не будет забита тасками по “ещё одному отчёту”, и аналитика будет действительно полезной.
Вместо вывода
Если вы владелец бизнеса и хотите, чтобы аналитика реально работала — не просите разработчиков “сделать пару отчётов”. Постройте архитектуру, в которой аналитика живёт отдельно. Тогда у вас будет шанс действительно понимать, что происходит в бизнесе.