"Соответственно , хорошо бы в статье с таким заманчивым заголовком и дать +/- понятный алгоритм, по которому владелец бизнеса (не знаем какого масштаба) поймёт , нужно ли вкладываться в аналитику и что для него MVP. "
Все так. При этом клиент видит только итоговый дашбор или датасет и очень удивляется, что задача: "давайте добавим еще одно поле и фильтр по нему" превращается в квест на пару недель.
Мы идем по пути, когда осознанно закрываем глаза на неоптимальность системы, избыточность данных или нагрузку на железо. Основной фокус - сходимость данных и скорость ответа. При объеме менее 10 млн. Строк большинство косяков можно нивелировать большим объемом оперативы у базы.
Типизируем стек и используем облака, что бы сократить девопс. Это сильно все ускоряет и дает возможность сократить кост.
Чем ближе к реалтайму сбора, тем меньше это mvp. Обычно мы ставим раз в сутки. Бывает, что несколько раз, например перед планеркой, что бы успели поправить данные. Реализуем через cron либо на сервере источнике, либо на нашем сервере, если берем из api. Это если говорить про небольшие проекты на типовых источниках. Что бы не грузить базу, забираем в момент времени без нагрузки и инкрементами за небольшой период времени.
На больших проектах все потяжелее и с специальными системами типа airflow.
Есть механики, как даже риалтайм забор данных можно делать не нагружая прод. В частности посмотрите cdc (change data capture)
Под mvp мы говорим про построение первого пайплайна данных - сбор из источников, очистка, приведение типов, обновление, создание витрин и визуализаций
Эксель есть у всех, кто хоть как то пытается управлять по цифрам. Но его достаточно быстро становиться мало (ну или много по геморою)
Вот это "это же просто romi, все его считают", уже не так. Собрать данные от кабинета до выручки в 1с через crm, докинуть расходы на фот маркетолога и подрядчиков того же директа, правильно применить окно атрибуции. И вот тогда у нас получается romi. И это только mvp. Очень мало кто без выделенных людей в это умеет.
Стек действительно гораздо шире, но подавляющее большинство кейсов в малом бизнесе закрываются скриптами сбора на серверлесс, аналитической базой и бесплатным визуализатором.
" Слитая клиентская база - это уже совсем не шутка." Так большая тройка давно на этом бизнес делает. Есть сервисы, которые совершенно легально сливают все звонки на целевые номера.
Вопрос не в бухгалтерской, а в управленческой пртбыли. Как вам там нарисуют в учете это вообще другая история. Тут бы понять, а бихнес вообще приносит деньги.
И тут мы переходим к пониманию таких терминов как товары локомотивы и широта продуктовой матрицы и ее оптимизация, а так же неснижаемый остаток и товары в пути. И еще целая куча интересных показателей, которые так же являются предметами аналитики. А еще в продуктовых магазинах есть коэффициент потерь, который напрямую зависит от оборачиваемости.
В статье описана идея, что в каждой бизнес модели есть метрики, которые помогают избегать проблем с кассовыми разрывами и другими неприятностями. И в идеале их бы считать.
Честно, ну не верю я в Postgres в качестве высоконагруженной аналитической базы. Возможно это от неумения его готовить, но все же.
Выбор на ClickHouse пал из-за наличия его в management service формате в яндекс облаке, где клиент хостил свой прод. Отсутствие костов на devops были важной частью проекта.
Конечными пользователями были были не сотрудники Teachbase, а их клиенты, которые обучали в LMS своих сотрудников. Так, что для них это был переход с экселя на дашборды в даталенсе и они были просто счастливы! Дашборды еще встроили в их личные кабинеты и счастье было вообще полным.
Тут очень важно понимать контекст. Итоговое решение будет выдаваться наружу клиентам. Сколько будет пользователей, какие они будут давать нагрузки на базу мы не знаем. Соответственно мы сразу заложились на большой масштаб в ClickHouse с шардированием и всем вот этим.
Спор о границах BI решения: только визуализация или весь ETL был, есть и будет.
В статье не отразили важную подробность - клиент всю инфру держит на яндекс облаке и менеджмент сервисах. Так что ClickHouse и DataLense оптимально вписались в стек. 0 затрат да Devops и поддержку инфры в проекте, это приятный бонус.
10кк это уже в денормализованной таблице. В изначальной базе существенно больше. На первоначальном объеме промежуточный stage на Postresql действительно бы сработал, но при повышении нагрузки + большое количество пользователей, которые обращаются с тяжелыми запросами могут Postresql и положить.
Тут точно не соглашусь. Когда заходит речь про прогнозирование, предиктивную аналитику и остальные модели, эксель подходит разве что только для первых poc. Да и то с натяжкой, jupyter + python зарешает это сильно лучше.
А при переходе на продовое решение, эксель вообще не рядом. Там уже начинаются даталейки, спарки и остальные ETL пайплайны.
Если говорить про менее требовательное финансовое прогнозирование, то тут есть две части:
Ad hoc запросы финдира и генерального, которые можно делать и в экселе (но лучше в том же jupyter, ибо функциональнее и красивее)
Регулярный отчет с пересчетами на основе актуальных данных и сценарным планированием. То тут лучше все же делать через хранилище, используя тот же эксель как форму ввода. Если нет полноценных систем финансового планирования.
Эксель это гениальное изобретение, это совершенно бесспорно. Но, как и написано в статье, наступает момент для бизнеса, когда его гибкость приносит больше вреда, чем пользы.
Если принимать во внимание полную стоимость владения системы, то чем круче спец, тем дешевле будет система. Заложив масштабируемую архитектуру, которая оптимально будет сочетать в себе гибкость и масштабируемость с достаточностью используемых технологий. Да, за свою работу он возьмет дорого, но в общем система будет стоит дешевле.
Если есть возможность кастомной BI аналитики и данные нормально собираются и хранятся, то можно начать собирать опережающие метрики. Грубо говоря не реализацию по сделке, а заходы на сайт. В таком случае, даже без предиктивной аналитики можно своевременно получать данные для принятия решения.
"Соответственно , хорошо бы в статье с таким заманчивым заголовком и дать +/- понятный алгоритм, по которому владелец бизнеса (не знаем какого масштаба) поймёт , нужно ли вкладываться в аналитику и что для него MVP. "
А у нас уже есть такая статья :)
https://habr.com/ru/articles/917602/
Все так. При этом клиент видит только итоговый дашбор или датасет и очень удивляется, что задача: "давайте добавим еще одно поле и фильтр по нему" превращается в квест на пару недель.
Мы идем по пути, когда осознанно закрываем глаза на неоптимальность системы, избыточность данных или нагрузку на железо. Основной фокус - сходимость данных и скорость ответа. При объеме менее 10 млн. Строк большинство косяков можно нивелировать большим объемом оперативы у базы.
Типизируем стек и используем облака, что бы сократить девопс. Это сильно все ускоряет и дает возможность сократить кост.
Спасибо большое! Мы стараемся!
Чем ближе к реалтайму сбора, тем меньше это mvp. Обычно мы ставим раз в сутки. Бывает, что несколько раз, например перед планеркой, что бы успели поправить данные. Реализуем через cron либо на сервере источнике, либо на нашем сервере, если берем из api. Это если говорить про небольшие проекты на типовых источниках. Что бы не грузить базу, забираем в момент времени без нагрузки и инкрементами за небольшой период времени.
На больших проектах все потяжелее и с специальными системами типа airflow.
Есть механики, как даже риалтайм забор данных можно делать не нагружая прод. В частности посмотрите cdc (change data capture)
Под mvp мы говорим про построение первого пайплайна данных - сбор из источников, очистка, приведение типов, обновление, создание витрин и визуализаций
Эксель есть у всех, кто хоть как то пытается управлять по цифрам. Но его достаточно быстро становиться мало (ну или много по геморою)
Вот это "это же просто romi, все его считают", уже не так. Собрать данные от кабинета до выручки в 1с через crm, докинуть расходы на фот маркетолога и подрядчиков того же директа, правильно применить окно атрибуции. И вот тогда у нас получается romi. И это только mvp. Очень мало кто без выделенных людей в это умеет.
Стек действительно гораздо шире, но подавляющее большинство кейсов в малом бизнесе закрываются скриптами сбора на серверлесс, аналитической базой и бесплатным визуализатором.
" Слитая клиентская база - это уже совсем не шутка."
Так большая тройка давно на этом бизнес делает. Есть сервисы, которые совершенно легально сливают все звонки на целевые номера.
Ладно бы прибыль и выручка, это хоть как то понимают. А вот разница между денежными поступлениями и выручкой, вот это уже высший уровень!
Вопрос не в бухгалтерской, а в управленческой пртбыли. Как вам там нарисуют в учете это вообще другая история. Тут бы понять, а бихнес вообще приносит деньги.
И тут мы переходим к пониманию таких терминов как товары локомотивы и широта продуктовой матрицы и ее оптимизация, а так же неснижаемый остаток и товары в пути. И еще целая куча интересных показателей, которые так же являются предметами аналитики. А еще в продуктовых магазинах есть коэффициент потерь, который напрямую зависит от оборачиваемости.
В статье описана идея, что в каждой бизнес модели есть метрики, которые помогают избегать проблем с кассовыми разрывами и другими неприятностями. И в идеале их бы считать.
Именно!
Большое спасибо за оценку :)
Честно, ну не верю я в Postgres в качестве высоконагруженной аналитической базы. Возможно это от неумения его готовить, но все же.
Выбор на ClickHouse пал из-за наличия его в management service формате в яндекс облаке, где клиент хостил свой прод. Отсутствие костов на devops были важной частью проекта.
Конечными пользователями были были не сотрудники Teachbase, а их клиенты, которые обучали в LMS своих сотрудников.
Так, что для них это был переход с экселя на дашборды в даталенсе и они были просто счастливы! Дашборды еще встроили в их личные кабинеты и счастье было вообще полным.
Тут очень важно понимать контекст. Итоговое решение будет выдаваться наружу клиентам. Сколько будет пользователей, какие они будут давать нагрузки на базу мы не знаем. Соответственно мы сразу заложились на большой масштаб в ClickHouse с шардированием и всем вот этим.
Спор о границах BI решения: только визуализация или весь ETL был, есть и будет.
В статье не отразили важную подробность - клиент всю инфру держит на яндекс облаке и менеджмент сервисах. Так что ClickHouse и DataLense оптимально вписались в стек. 0 затрат да Devops и поддержку инфры в проекте, это приятный бонус.
10кк это уже в денормализованной таблице. В изначальной базе существенно больше.
На первоначальном объеме промежуточный stage на Postresql действительно бы сработал, но при повышении нагрузки + большое количество пользователей, которые обращаются с тяжелыми запросами могут Postresql и положить.
Все так. Пока количество строк не перевалит за 1 млн. :)
Тут точно не соглашусь. Когда заходит речь про прогнозирование, предиктивную аналитику и остальные модели, эксель подходит разве что только для первых poc. Да и то с натяжкой, jupyter + python зарешает это сильно лучше.
А при переходе на продовое решение, эксель вообще не рядом. Там уже начинаются даталейки, спарки и остальные ETL пайплайны.
Если говорить про менее требовательное финансовое прогнозирование, то тут есть две части:
Ad hoc запросы финдира и генерального, которые можно делать и в экселе (но лучше в том же jupyter, ибо функциональнее и красивее)
Регулярный отчет с пересчетами на основе актуальных данных и сценарным планированием. То тут лучше все же делать через хранилище, используя тот же эксель как форму ввода. Если нет полноценных систем финансового планирования.
Эксель это гениальное изобретение, это совершенно бесспорно. Но, как и написано в статье, наступает момент для бизнеса, когда его гибкость приносит больше вреда, чем пользы.
Есть у меня мнение, что если бизнес умер от переноса данных из экселя в модные системы управления, то дело далеко не в ИТ системах.
Если принимать во внимание полную стоимость владения системы, то чем круче спец, тем дешевле будет система. Заложив масштабируемую архитектуру, которая оптимально будет сочетать в себе гибкость и масштабируемость с достаточностью используемых технологий. Да, за свою работу он возьмет дорого, но в общем система будет стоит дешевле.
Если есть возможность кастомной BI аналитики и данные нормально собираются и хранятся, то можно начать собирать опережающие метрики. Грубо говоря не реализацию по сделке, а заходы на сайт. В таком случае, даже без предиктивной аналитики можно своевременно получать данные для принятия решения.