Полезно дополнить эту схему сценарием восстановления после семантической ошибки. Мониторинг обнаружил неверные значения, но данные уже разошлись по потребителям, а версия схемы могла вообще не измениться.
Кто в таком случае отвечает за исправление истории: команда сервиса публикует корректирующие события или каждый потребитель пересчитывает свой слой? Нужен ещё понятный сигнал, до какого момента данные восстановлены. Иначе можно получить несколько разных «исправленных» витрин при формально соблюдённой схеме.
Для еженедельных отчётов пригодилась бы ещё опция фиксированного диапазона шкалы. По описанию он рассчитывается заново при каждом экспорте: одинаковая длина полосы на слайдах за разные недели тогда может означать разные числа. Подписи помогают, но при быстром сравнении с прошлой неделей масштаб легко упустить.
Рассматривали необязательные минимум и максимум для серии отчётов, с предупреждением, если новое значение вышло за границу? Автоматический подбор при этом можно оставить по умолчанию.
На самом деле весь посыл статьи - не перекладывайте аналитику на 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). Таким образом вы сможете избавить себя от огромного кол-ва будущего гемороя