На самом деле весь посыл статьи - не перекладывайте аналитику на it, а нанимайте профильных специалистов:)
По поводу реплики, она является основой 99% любых решений по развитию аналитики. Но как поднять ее правильно и что делать с ней дальше вопрос на несколько десятков статей. Поэтому все равно придется обращаться к профильным специалистам
Компания имеет монолит, создаваемый десятилетиями, и в какой то момент задумывается о создании аналитики. Начинаются прикидки что можно сделать и, при рассмотрении вариантов с отдельной БД для аналитических расчетов, оказывается, что эту БД нужно поднять, администрировать, интеграцию данных настраивать и еще отдельно даталенс поднимать. И все это ради 1-2 отчетов. Запилить аналитику внутри монолита силами разработки кажется не таким плохим вариантом
Обычно это происходит нативно, у компании уже есть какое-то собственное ПО и штат разрабов. В моменте начинает появляться потребность в небольших отчетах, на которые брать аналитика на полную ставку кажется странным и проще заделать какой-нибудь сервис отчетов или бота. А когда приходят со следующими отчетами уже есть готовый кейс, зачем идти во что то другое? Вот так и приходят к ситуации в статье:)
Добрый день! Очень приятно что в российском сегменте появляется все больше и больше bi-систем. Можете пожалуйста ответить на пару вопросов?
Кто ваша ЦА?
Мелкие компании (excel боженька, объем данных до 2-х миллионов строк)
Средние компании (уже есть нормальные бд, объем данных до 100 миллионов строк)
В статье вы подробно рассказываете о возможностях обработки данных, но на сайте я так же заметил «более 100 визуализаций». Вы позиционируете себя как аналог power bi или все таки сосредоточены на возможностях визуализации данных?
Первое правило построения аналитики на графане - необходимо отказаться от построения аналитики на графане
Графана отлично подходит для отслеживания системных «таймлайн» метрик (нагрузка, кол-во транзакций и пр.) которые в основном смотрят люди, понимающие специфику разработки. Но, стоит только показать эти метрики бизнесу, и вся ваша работа будет перенаправлена на реализацию их бесчисленного множества хотелок. Причем реализация этих хотелок как трудозатратна, так и вредна для разработки.
В конечном итоге вы придете к огромному кол-ву никак не связанных дашбордов, противоречащих и неидеальных метрик и огорченному бизнесу, потому что «как так нельзя посчитать кол-во новых юзеров зашедших к нам в 5-е полнолуние и зарегистрированных в меркурии под юпитером»
Поэтому, что бы избежать всех этих проблем очень советую продавить идею создания реплики продовой БД и развертки специализированных bi систем (для начала подойдут open-source сервисы superset/redash/metabase). Таким образом вы сможете избавить себя от огромного кол-ва будущего гемороя
Благодарю!
Да, как было подчеркнуто в статье модули - это скелет, который можно обвесить различными способами под удобства и требования бизнеса
На самом деле весь посыл статьи - не перекладывайте аналитику на it, а нанимайте профильных специалистов:)
По поводу реплики, она является основой 99% любых решений по развитию аналитики. Но как поднять ее правильно и что делать с ней дальше вопрос на несколько десятков статей. Поэтому все равно придется обращаться к профильным специалистам
Проблема как раз в отсутствии соседнего клика
Компания имеет монолит, создаваемый десятилетиями, и в какой то момент задумывается о создании аналитики. Начинаются прикидки что можно сделать и, при рассмотрении вариантов с отдельной БД для аналитических расчетов, оказывается, что эту БД нужно поднять, администрировать, интеграцию данных настраивать и еще отдельно даталенс поднимать. И все это ради 1-2 отчетов. Запилить аналитику внутри монолита силами разработки кажется не таким плохим вариантом
С прямым подключением к продовой БД?) Доставать данные все равно необходимо
Обычно это происходит нативно, у компании уже есть какое-то собственное ПО и штат разрабов. В моменте начинает появляться потребность в небольших отчетах, на которые брать аналитика на полную ставку кажется странным и проще заделать какой-нибудь сервис отчетов или бота. А когда приходят со следующими отчетами уже есть готовый кейс, зачем идти во что то другое? Вот так и приходят к ситуации в статье:)
Добрый день! Очень приятно что в российском сегменте появляется все больше и больше bi-систем. Можете пожалуйста ответить на пару вопросов?
Кто ваша ЦА?
Мелкие компании (excel боженька, объем данных до 2-х миллионов строк)
Средние компании (уже есть нормальные бд, объем данных до 100 миллионов строк)
В статье вы подробно рассказываете о возможностях обработки данных, но на сайте я так же заметил «более 100 визуализаций». Вы позиционируете себя как аналог power bi или все таки сосредоточены на возможностях визуализации данных?
Первое правило построения аналитики на графане - необходимо отказаться от построения аналитики на графане
Графана отлично подходит для отслеживания системных «таймлайн» метрик (нагрузка, кол-во транзакций и пр.) которые в основном смотрят люди, понимающие специфику разработки. Но, стоит только показать эти метрики бизнесу, и вся ваша работа будет перенаправлена на реализацию их бесчисленного множества хотелок. Причем реализация этих хотелок как трудозатратна, так и вредна для разработки.
В конечном итоге вы придете к огромному кол-ву никак не связанных дашбордов, противоречащих и неидеальных метрик и огорченному бизнесу, потому что «как так нельзя посчитать кол-во новых юзеров зашедших к нам в 5-е полнолуние и зарегистрированных в меркурии под юпитером»
Поэтому, что бы избежать всех этих проблем очень советую продавить идею создания реплики продовой БД и развертки специализированных bi систем (для начала подойдут open-source сервисы superset/redash/metabase). Таким образом вы сможете избавить себя от огромного кол-ва будущего гемороя