Честно, ну не верю я в 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 аналитики и данные нормально собираются и хранятся, то можно начать собирать опережающие метрики. Грубо говоря не реализацию по сделке, а заходы на сайт. В таком случае, даже без предиктивной аналитики можно своевременно получать данные для принятия решения.
Большое спасибо за оценку :)
Честно, ну не верю я в 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 аналитики и данные нормально собираются и хранятся, то можно начать собирать опережающие метрики. Грубо говоря не реализацию по сделке, а заходы на сайт. В таком случае, даже без предиктивной аналитики можно своевременно получать данные для принятия решения.