Как стать автором
Обновить

Комментарии 13

Так что по вендорам?
В свое время (2018 год) брали на PoC по self-bi системам Полиматику. Другими решениями были SAC, Tableau и Power BI + QlikView уже внедренный.
Не выдерживала никакой критики на данных более 10 млн строк.

Производительность оттачивается и оптимизируется в реальных проектах у живых клиентов. Никто не заморачивается оптимизацией, если клиентам это не требуется. Поскольку большинство российских BI решений используется не в ритейле, телекоме и банках, а в госведомствах, то требования к обрабатываемым массивам данных и скорости их обработки не были очень высоки. Сейчас, с учетом сложившейся ситуации, BI вендоры выходят на новые для себя рынки - крупных коммерческих компаний с большими объемами данных, со сформировавшимися потребностями в скорости обработки (Tableau и Co приучили к секундному отклику). Это будет суперстимул для доведения до ума решений в части производительности. Посмотрим на результат через годик.

Вендорский подход прекрасен. Сравнительные таблицы, конкурсные процедуры и т.д.
Все знакомо и уютно. Аналог считовода в колхозе.

Но далеко не всегда все эти дашборды и ползунки нужны и важны. Внятный storytelling куда удобнее для конкретного исполнителя.
И вся эта"бесконечная гибкость" чтобы "не думать" -- бесконечное зло.

Да, BI бывает нужен, но его роль раздута как мыльный пузырь.

При грамотной постановке задачи DS стек позволяет строить компактные и быстрые решения по воспроизводимым методологиям.

Как пример, есть классическая "гибкая" задачка, которая убивает все базы и BI на раз. Все недоменеджеры постоянно ее достают из кармана. Звучит так:

1. У меня база с триллионами строк и сотней колонок (терабайты на диске).
2. Мне нужен "гибкий конструктор", чтобы делать self-analytics. Чтобы не думать и не зависеть от кого-либо.
3. Хотим иметь возможность считать TopN по отфильтрованным записям, отсортированным по произвольным правилам и произвольным колонкам. (Индекс и партиции заранее сделать нельзя -- все ведь "гибко" и непредсказуемо).

DS инструментами такая задачка решается легко и элегантно.



Для любого инструмента можно придумать или найти задачу, которая его сломает. Это нормально. И DS не исключение. Главное правильно подобрать и применять инструмент для тех задач, которые Вы решаете на регулярной основе. А если есть какая-то уникальная задача, то ее можно решить разово и на чем угодно, на чем удобно. В хорошем BI основное преимущество в том, что он удобен и для разработчика и для пользователя. Позволяет быстро и просто решать большинство типовых задач построения дашбордов и анализа данных. В крутом BI 99% операций делается мышкой за минуты. При этом в обычном BI инструменте это все тоже можно сделать, только за часы и с использованием скриптов на JS, питоне и пр.

Все бы хорошо, и понятно, что тут, в корпоративном блоге надо писать все позитивненько, но не стоит забывать следующее, с чем любой человек из полей согласится без колебаний.

Вся эта визуальность и мышкоклей привели к тому, что в головах людей, особенно менеджеров, присутствуют только одни розовые пони. Как бы низкий уровень входа приводит к тому, что в индустрию вливается поток людей, которые 5+7 без калькулятора не сложат. Говорить о наличии понимания более сложных вещей -- почти бесполезная затея. Попытка перевести показатели со средних на медианы может занимать годы!!! Каждый день объяснять что это и зачем... а потом еще и распределения показать и хвосты затронуть.

В результате Fake data + Fake math = Fake reports.
А потом, опираясь на эти показатели, искажающие реальность как в кривом зеркале, принимаются ужасные для бизнеса решения.
+ набор имеющихся алгоритмов (словарь) крайне узок. Фейрверки нужны!!!

Весь этот self-bi -- по факту ужасно убогое математически дорогое удовольствие (учитываем понесенный ущерб от админ решений по неправильным показателям), сбивающих с пути и заставляющих копать не там и не то. Зло почти в рафинированном виде, но в красивом фантике. Про таймзоны кто-нибудь из self-bi спецов слышал? Еще один элементарный кейс, приводящий к радикально кривым результатам при его пренебрежении.

BI должен внедряться и сопровождаться специалистами. В команде должны быть хорошие инженеры, хорошие аналитики, хорошие математики и программисты, должен быть ОТК -- любые выводы и данные должны быть многократно кросспроверены. Никаких мышек. Только программирование с DevOps и reproducible research "во всю спину".
И не забывайте про Excel и PowerPivot -- не надо ми-ми аналитикам ничего покупать для красивых рисовалок, надо освоить уже стоящий на компьютерах инструмент.

Кстати, в полной таблице вот такие ребята у вас есть https://luxmsbi.com/?

У Вас свое мнение и оно понятно. Но оно не единственное. Если решение покупает CDTO или CDO и бюджет их, то может они выберут по каким-то чисто техническим соображениям. А если бизнес, то простота и удобство, да и красота тоже, будут более важными факторами. И не нужно думать, что они ничего не понимают и выбирают не правильно, как неразумные дети. Они выбирают и потом пользуются и решают задачи своего бизнеса. А для чего это все внедряется, как не для бизнеса. Не для того же, чтобы в блоге писать про то какая крутая там архитектура. Про LuxMS знаем конечно.

Если иные мнения не важны, то лучше закрывать комментарии.

Увы, это все общие слова, без аргументации.
Для веса тут стоило бы добавить количественных показателей:
"я принимал участие в N конкурсах/тендерах",
"я M раз принимал участие в карусели по замене решений",
"я внедрял X продуктов в Y компаниях",
"я недооценил бюджет на $Щ в $Ю проектах"...
...
Очевидно, что компания, внедряющая BI должна это решение расхваливать. И продавать через "гламурные буклеты" топам идею для получения бюджетов. Это все ясно как белый день.
Правда все это в софтверных интеграторских проектах поизмельчало за последние лет 10, коммодитизация погрызла и опенсорс поджимает. Маловато уже проектов на десятки млн У.Е....

Мои тезисы базировались исключительно на практических наблюдениях, даже думать не надо... Можно доставать записную книжку и называть компании, проекты, продукты, имена, ...

Кстати, каков средний срок работы топ-менеджеров от ИТ? 1-1.5 года?
Много опыта, когда подписанты актов на проекте меняются за срок проекта несколько раз? Уходят. О какой стратегии и осознанном выборе идет речь?

И прямо сейчас, подоспел весьма похожий тезис от известного человека в индустрии: https://t.me/cryptovalerii/200

и ничего стыдного в ИТ говорить про архитектуру и перформанс нет.
даже странно слышать 31.03.2022 такие аргументы.

если решение не позволяет переплыть залив в силу своей медленности, то проект потонет. какие-бы гламурные кнопочки там ни присутствовали.

кстати, поднимите архивы того же табло.
на заре, когда продукт создавался, была масса отличных материалов и публикаций (в т.ч. на https://arxiv.org/), где рассказывали о внутренностях табло, подходах, научной новизне и т.д...

со многими стартапами приходилось дело иметь? разве они только про подписку за чашку кофе говорят?

P.S.
и SAS я видел (этот COBOL и IBM 360...) и с GB сотрудничали, когда это еще был маленький GB и занимался заказной C++ разработкой.
Если про ИТ -- труды, например, Кнута нетленны, маркетинговая шелуха имеет срок жизни несколько минут.

Юлий (решил аккуратно посмотреть карточку), Ваши аргументы более чем понятны.
Мои тезизы никак к Вам не относятся, потому как весь бэкграунд понятен.
Равно как и все словесные лего-конструкции, определяемые занимаемой должностью и возложенной ответственностью.
У меня подобные конструкции давно начали вызывать аллергию, реакция не всегда сообразна исходному посылу.

Работа в интеграторе/вендоре оставляет отпечатки.
У меня они тоже должны остаться, это неизбежно...
По-моему, мы даже пересекались с Вами в проектной активности в Дальсвязи.

Илья, у нас у всех какой-то бэкграунд. Но не считаю, что то, что кто-то говорит априори не интересно и неправильно только исходя из его бэкграунда или должности. Кто-то просто не интересен, а кто-то всегда интересен вне зависимости где он сейчас работает и чем занимается. Думаю, что длинная междусобойная дискуссия не совсем формат Хабра. Хочу лишь подчеркнуть еще раз, что производительность и архитектура это важные составляющие BI решения. Они в статье упомянуты отдельно, как факторы, которые нужно принимать во внимание. Просто требования к этим параметрам у всех очень сильно разнятся. И то, что у какой-то системы супербыстрый движок, не обязательно приводит к ее выбору, если система слишком сложна для использования бизнесом (чтобы сделать нужный бизнесу виз или рассчитать нужный показатель требуется писать код на JS или питоне). И наоборот, если решение по выбору системы принимает не бизнес, а ИТ, то выбрать могут по чисто техническим характеристикам, решив, что все красивости это блаж и без них все будет норм. Статья о том, что лучше учитывать все параметры в комплексе, оценив их вес для вашей конкретной организации. Тогда есть шанс снизить ошибки в условиях нынешнего цейтнота. На веса параметров выбора должны влиять и ИТ, и бизнес, и аналитики. Им же вместе потом делать миграцию и жить с тем что получится в итоге.

Юлий, я хабр воспринимал как дискуссионную площадку. Просто формат корпоративного блога накладывает ограничения на допустимый градус и требует уважительного отношения к участникам.

Ни в коем случае я не говорил про интерес или его отстутсвие. Нет никакого психологизма или скрытых подтекстов. Картина предельно плоская. Сам формат корпоративного блока определяет достижение определенных целей. Тем более за площадку еще есть плата. Нельзя писать совсем свободно. Вот и все.

Таких сравнительных таблиц по различным решениям и тематикам мне пришлось написать тонны. Известно как это пишется, как потом играется и что получается на выходе. Не все радужно. Cам набор советов не меняется уже, наверное, лет 20. День Сурка. Научной новизны здесь 0, Вы же ведь это прекрасно знаете, и тут, наверняка, достали с прошлого шаблона (SAS ?). Я же в первом комментарии обращался более к проблематике задачи и предложением чуть порвать шаблоны.

Есть еще интересное заключение с полей. Теперь перед запуском аналитика или бизнес-аналитика требуется запускать "психолога", который будет работать с ощущениями заказчика и пытаться формулировать их в виде внятных ожиданий. Формировать задачу и потребности надо. Что надо хотеть и почему. Без навешивания ярлыков, озвучивания инструментов, технологий и вендоров. Бумага, ручка, книга и калькулятор. И только потом можно выбирать подходящий инструмент.

Ровно на этом этапе часто оказывается, что просили вовсе не то, что реально нужно, говорили о ярлыках, которые бесполезны к реальной задаче. И вообще масштаб задачи без потери в качестве можно сильно уменьшить, грамотно подрезав желания.

Более развернутый ответ я дал здесь: https://habr.com/ru/post/658657/

Понимаю, что кто-то сам является экспертом в выборе систем BI и в импортозамещении. У эксперта всегда есть собственное мнение и большой объем материалов по теме в запасе. Только вот не стоит думать, что все остальные тоже суперэксперты в этом вопросе и что чужой совет для них абсолютно бесполезен. Тема резкого импортозамещения новая и многие с ней только пытаются освоиться. Количество запросов упомянутой в статье таблицы сравнения говорит, что материал очень востребован. На истину в последней инстанции никто не претендует, но это сейчас и не нужно. Большинству заинтересованных требуется просто структурированный взгляд на проблему импортозамещения BI. В этом и заключается наша помощь. А дальше уже каждый сам сможет подобрать для себя оптимальный вариант, исходя из своей конкретной ситуации. Мы не вендор. Мы не даем массовые советы что выбирать Визиолоджи, Полиматику, FineBI или что-то другое. Но показываем какие критерии стоит принять во внимание и какие плюсы/минусы у разных вариантов. Конкретные рекомендации даем только конкретным клиентам, хорошо разобравшись с их ситуацией и приоритетами. И то, по факту все равно требуется, пилот чтобы провалидировать выбор.
Что касается выбора вместо специализированного BI какой-то другой технологии, вплоть до предложений дать аналитикам Питон или R и пусть сами разбираются, то считаю это утопией. Это можно сравнить с тем, как в СССР после революции пытались вывести нового советского человека, вместо того, чтобы работать с обычным человеком и его обычными потребностями и мотивами. Вывести нового потребителя BI (антиBI) если и получится, то очень не скоро. Нормальный self-service BI тем и хорош, что заточен под конкретную задачу и за счет этого сильно снижает для аналитиков и бизнеса порог входа и трудозатраты на анализ и разработку нужных дашбордов. А если брать какой-то универсальный инструмент, то, конечно, на нем можно сделать все что угодно, но на практике делать это никто не будет и в итоге никуда из своего Экселя не вылезет. А вот в Табло и Power BI из Эксель переходили, и не единицами, а тысячами.

Мне кажется, что на самом деле мы друг друга поняли. В последнем комментарии я говорил про ручку, бумагу и подключение головы.
Но, естественно, это сложно и тяжело. А дашборды как дашборды -- это уже дело десятое.

Большинство так и будут по традиции ездить по проезженной колее. Иногда даже бывает грустно смотреть на потухших участников процесса. Шутка ли, 3 года обсуждать тему отчетности до руководителя, но не сделать ни одного практического шага. Тут нужна особая закалка.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий