Я не сказал, что все за три года дорастают до синьоров. Но такие бывают и нередко. Если проект меняется раз в полгода, то он за три года 6 проектов пройдет. И если умный и ищущий, то много чего поймет и научится принимать самостоятельные решения. А учиться можно не только на своих ошибках). Хотя свои, конечно, важны. Но даже если за 8 лет. Представьте, человек в 20 лет пришел в компанию. Через 8 лет ему всего 28. Не 40 и тем более не 60. Почему такого синьора нужно считать закостеневшим. У таких молодых ребят еще все в переди и они обычно полны энтузиазма осваивать новое. А если человек ничего не хочет и ни к чему не стремится, то это не проблема его синьорности. Это его личное отношение к жизни и к работе.
Тоже часто сталкиваюсь с тем, что клиенты не хотят брать синьоров. Но проблемы не в том, что они ленивые или закостенелые. У нас из студентов зачастую до синьоров дорастают за три года, поэтому в большинстве случаев синьоры это вовсе не выгоревшие старики. Большая часть отказов из-за денег. Ставка синьоров существенно выше, нам продавать их услуги по цене мидлов невыгодно, а клиент считает, что у него не настолько сложные задачи, чтобы больше платить за опыт. Вторая причина в том, что клиент опасается, что синьор быстро заскучает без сложных задач. Если разработчик нужен на два три месяца, то это не проблема, но если на больший срок, то правда может заскучать. Третья проблема, что синьоры во многих случаях уже имеют под собой какую-то минимальную команду, коучат кого-то и отвечают за работу мидла или джунов. А далеко не всегда клиент готов брать синьора с его подаванами. Если это джуны, то почти никогда не готов. Что касается запроса на универсальность, то это во многом связано с тем, как вообще устроена работа с ИТ сотрудниками в самой организации, которая ищет внешний ресурс. Если у них все аналитки-разработчики-девопсы в одном лице, и с бизнесом на одном языке говорят, и код пишут, и оптимизируют производительность, и CI/CD настраивают, то им кажется, что и внешний специалист должен быть таким же. Тут ничего личного, просто иначе он плохо впишется в их модель управления. При том, что у нас все люди специализируются либо на аналитике либо на разработке, приходится подбирать для таких клиентов более-менее универсальных людей. Но на практике, если копнуть глубже, все равно специализация есть. Даже там где пестуют как бы универсалов. Все они называются словом дата-инженер, например, но реально кто-то больше с бизнесом разбирается, а кто-то больше в код закапывается. Просто это уже складывается по факту неформально.
Системы охлаждения магнитов коллайдера работают круглогодично. Это до 120МВт. Но эксперименты зимой не проводятся. В пике во время экспериментов требуется 180МВт. В зимний период энергия нужна для отопления и ее для экспериментов на коллайдере не хватает. Замкнутый круг. Вот когда сделают термоядерный реактор (может тот же коллайдер) с положительным КПД, то тогда и тепло будет и электричество почти в неограниченном объеме.
Хорошая идея. Нагреть песок можно. Но как сохранить тепло в песке? Он же остынет через несколько часов, ну дней, если его очень много. А запасать то нужно не на часы, а на месяцы.
А можете чуть подробнее о способах, которые имеете в виду? Понимаю, что можно вырабатывать электричество - заряжать аккумуляторы, или производить водород из воды. Но, кажется, что это не такие простые способы. Тем более, когда речь идет о больших объемах тепла. Иначе бы градирни уже давно отменили.
Ну если о самом коллайдере говорить, то там такие системы охлаждения, что могут что угодно до состояния плазмы разогреть, не только до 120 градусов. Вопрос стабильности этого потока. В пике коллайдер потребляет 180 МВт. Этого хватит на город 300 тыс. жителей. Если предположить, что 50% этого потребления в итоге переходит в тепло и его нужно сбрасывать, то на отопление соседнего городка остается очень даже много.
Отличная статья. Понравился и стиль изложения. Достаточно легкий, без разжевывания что такое сверточные сети и пр., чем грешат многие статьи и книги про AI. И структурированный подход к описанию проблемы мне тоже хорошо зашел. Отдельный респект за картинки) На мой взгляд, мало внимания уделяется проблеме потери управления AI со стороны человечества. Конечно, все знают про глюки и т.п. Но вот более серьезные инцеденты, которые неизбежны могут привести к резкому и серьезному оттоку инвестиций и схлопыванию отрасли, на какое-то время. Представьте себе вышедший из под контроля беспилотный автомобиль или группу автомобилей (если будет доказано, что именно мозги машины привели к аварии с летальным исходом). Или сбрендившие андроиды, которыми господин Маск планирует заполонить мир. Да, просто какой-то ИИ агент по торговле бумагами, который вдруг распродаст имущество хозяев подешевке. Набор таких кейсов, вылезших в побличное поле, может надолго подорвать доверие и похоронить отрасль. Ученые же уже констатировали, что мы не в состоянии точно понять, что происходит внутри электронных мозгов AI. Значит риск выхода AI из повиновения не нулевой, а может быть и больший, чем вероятность чисто экономического коллапса.
Проблема в том, что тепло нужно не тогда, когда проводятся эксперименты (а это не постоянно), а зимой, когда холодно. Если невозможно использовать продукт именно тогда когда он нужен, то другого смысла в этом, кроме как попиариться на экологии, нет. Поскольку коллайдер многократно обвиняли в том, что он чуть ли не всю землю может в черную дыру превратить, то экологические ощущения у населения от него скорее отрицательные. Поэтому владельцам проекта обязательно нужно было заняться экологическим пиаром. Вот они и занялись. Даже при нулевом экономическом эффекте. Ведь стоимость прокладки труб до ближайшего городка, на фоне многимиллиардных инвестиций в сам коллайдер, практически нулевая. Датацентры это другое дело. Но тут вообще нет ничего нового. У нас давно металлургические заводы (их печи) включены в систему отопления ближайших районов. Это нормальная практика. Датацентр - тот же завод с непрерывным производством. Выделяет большое количество тепла, грех не воспользоваться им для пользы общества.
Вопрос материальности потерь и вопрос перспектив отношений с заказчиком. Причем не только с ЮЛ, но и с конкретными ФЛ со стороны заказчика, которые сегодня тут работают, а завтра где-то еще, куда нам интересно попасть. Если вы выставляете клиента на штрафы или тем более идете в суд, то это значит, что у конкретного человека на стороне клиента скорее всего будут немаленькие неприятности. Вряд ли он после такого останется вашим лоялистом. Вообще, нужно признать, что у разных компаний разный аппетит к судебным разбирательствам. Кто-то готов судиться по поводу и без. Но мне как-то больше повезло работать в компаниях, которые считают суд самой крайней мерой и предпочитают в любой ситуации полюбовно договариваться. И я не жалею об этом. Считаю, что это сохранило и мне немало нервных клеток и моим работодателям добавило плюс к репутации, что в целом неплохо.
Спасибо за интересную статью. Отлично, что удалось так быстро запустить решение в прод и преодолеть обычные страхи пользователей перед новыми технологиями и перед "черным ящиком". Хотелось бы только больше узнать про сами сервисы и их встраивание в процессы, а не про классические подходы RAG, которые описаны в специальной литературе. Какую LLM использовали, локально или как сервис? Встроили ли AI-агента прямо в CRM как часть процесса взаимодействия с клиентом, которую невозможно обойти или это все же отдельная справочная система "сбоку", которую сотрудник работающий с клиентом может запросить, если захочет?
Superset прекрасный продукт для своего сегмента, но это opensource и его сравнивать с FineBI сложно. Ведь задача была Self-Service поддержать, как это было в Табло. Чтобы пользователи без ИТ и без программирования могли свои дашборды делать и данные анализировать. На Superset порог входа для пользователей гораздо выше. Да и скорость миграции немаловажна. Если с Табло на FineBI банк смог мигрировать довольно быстро и фактически своими силами, то миграция на Superset это был бы большой и сложный проект с большим объемом чд архитекторов, аналитиков, разработчиков.
Выбирали, выбирали. И довольно тщательно. Тут не было жесткого требования наличия ПО в реестре, поэтому смотрели не только российские продукты, но и решения из Китая
Кажется, что самое главное, что следует из статьи, что задачу Self-Service с помощью FineBI решили. Это главное, что отличает этот продукт и, как я понимаю, в этом он свою функцию в МКБ выполняет. Правильно подмечено, что для Self-Service очень важно наличие комьюнити. Но по FineBI оно на самом деле есть и одно из крупнейших в этой области в РФ. https://t.me/FineBIChat. 1132 человека на сегодняшний день. И очень живое. Десятки сообщений каждый день. Причем именно опытом люди обмениваются, что ценно.
Понимаю, что кто-то сам является экспертом в выборе систем BI и в импортозамещении. У эксперта всегда есть собственное мнение и большой объем материалов по теме в запасе. Только вот не стоит думать, что все остальные тоже суперэксперты в этом вопросе и что чужой совет для них абсолютно бесполезен. Тема резкого импортозамещения новая и многие с ней только пытаются освоиться. Количество запросов упомянутой в статье таблицы сравнения говорит, что материал очень востребован. На истину в последней инстанции никто не претендует, но это сейчас и не нужно. Большинству заинтересованных требуется просто структурированный взгляд на проблему импортозамещения BI. В этом и заключается наша помощь. А дальше уже каждый сам сможет подобрать для себя оптимальный вариант, исходя из своей конкретной ситуации. Мы не вендор. Мы не даем массовые советы что выбирать Визиолоджи, Полиматику, FineBI или что-то другое. Но показываем какие критерии стоит принять во внимание и какие плюсы/минусы у разных вариантов. Конкретные рекомендации даем только конкретным клиентам, хорошо разобравшись с их ситуацией и приоритетами. И то, по факту все равно требуется, пилот чтобы провалидировать выбор. Что касается выбора вместо специализированного BI какой-то другой технологии, вплоть до предложений дать аналитикам Питон или R и пусть сами разбираются, то считаю это утопией. Это можно сравнить с тем, как в СССР после революции пытались вывести нового советского человека, вместо того, чтобы работать с обычным человеком и его обычными потребностями и мотивами. Вывести нового потребителя BI (антиBI) если и получится, то очень не скоро. Нормальный self-service BI тем и хорош, что заточен под конкретную задачу и за счет этого сильно снижает для аналитиков и бизнеса порог входа и трудозатраты на анализ и разработку нужных дашбордов. А если брать какой-то универсальный инструмент, то, конечно, на нем можно сделать все что угодно, но на практике делать это никто не будет и в итоге никуда из своего Экселя не вылезет. А вот в Табло и Power BI из Эксель переходили, и не единицами, а тысячами.
Илья, у нас у всех какой-то бэкграунд. Но не считаю, что то, что кто-то говорит априори не интересно и неправильно только исходя из его бэкграунда или должности. Кто-то просто не интересен, а кто-то всегда интересен вне зависимости где он сейчас работает и чем занимается. Думаю, что длинная междусобойная дискуссия не совсем формат Хабра. Хочу лишь подчеркнуть еще раз, что производительность и архитектура это важные составляющие BI решения. Они в статье упомянуты отдельно, как факторы, которые нужно принимать во внимание. Просто требования к этим параметрам у всех очень сильно разнятся. И то, что у какой-то системы супербыстрый движок, не обязательно приводит к ее выбору, если система слишком сложна для использования бизнесом (чтобы сделать нужный бизнесу виз или рассчитать нужный показатель требуется писать код на JS или питоне). И наоборот, если решение по выбору системы принимает не бизнес, а ИТ, то выбрать могут по чисто техническим характеристикам, решив, что все красивости это блаж и без них все будет норм. Статья о том, что лучше учитывать все параметры в комплексе, оценив их вес для вашей конкретной организации. Тогда есть шанс снизить ошибки в условиях нынешнего цейтнота. На веса параметров выбора должны влиять и ИТ, и бизнес, и аналитики. Им же вместе потом делать миграцию и жить с тем что получится в итоге.
У Вас свое мнение и оно понятно. Но оно не единственное. Если решение покупает CDTO или CDO и бюджет их, то может они выберут по каким-то чисто техническим соображениям. А если бизнес, то простота и удобство, да и красота тоже, будут более важными факторами. И не нужно думать, что они ничего не понимают и выбирают не правильно, как неразумные дети. Они выбирают и потом пользуются и решают задачи своего бизнеса. А для чего это все внедряется, как не для бизнеса. Не для того же, чтобы в блоге писать про то какая крутая там архитектура. Про LuxMS знаем конечно.
Производительность оттачивается и оптимизируется в реальных проектах у живых клиентов. Никто не заморачивается оптимизацией, если клиентам это не требуется. Поскольку большинство российских BI решений используется не в ритейле, телекоме и банках, а в госведомствах, то требования к обрабатываемым массивам данных и скорости их обработки не были очень высоки. Сейчас, с учетом сложившейся ситуации, BI вендоры выходят на новые для себя рынки - крупных коммерческих компаний с большими объемами данных, со сформировавшимися потребностями в скорости обработки (Tableau и Co приучили к секундному отклику). Это будет суперстимул для доведения до ума решений в части производительности. Посмотрим на результат через годик.
Для любого инструмента можно придумать или найти задачу, которая его сломает. Это нормально. И DS не исключение. Главное правильно подобрать и применять инструмент для тех задач, которые Вы решаете на регулярной основе. А если есть какая-то уникальная задача, то ее можно решить разово и на чем угодно, на чем удобно. В хорошем BI основное преимущество в том, что он удобен и для разработчика и для пользователя. Позволяет быстро и просто решать большинство типовых задач построения дашбордов и анализа данных. В крутом BI 99% операций делается мышкой за минуты. При этом в обычном BI инструменте это все тоже можно сделать, только за часы и с использованием скриптов на JS, питоне и пр.
Согласен с InnovaIT. Зачем было писать в заголовке Индустрия 4.0, если эта тема вообще не затрагивается. Лучше профессионально написать про ИБП и люди проявят интерес. Те, кому это на самом деле надо.
А что значит «фактическое исполнение заказа было 20%». Разве может работать какая-то математика или автоматизация вообще, если из заказанного перечня привозят реально только 20%. А остальные 80% где теряются?
Я не сказал, что все за три года дорастают до синьоров. Но такие бывают и нередко. Если проект меняется раз в полгода, то он за три года 6 проектов пройдет. И если умный и ищущий, то много чего поймет и научится принимать самостоятельные решения. А учиться можно не только на своих ошибках). Хотя свои, конечно, важны.
Но даже если за 8 лет. Представьте, человек в 20 лет пришел в компанию. Через 8 лет ему всего 28. Не 40 и тем более не 60. Почему такого синьора нужно считать закостеневшим. У таких молодых ребят еще все в переди и они обычно полны энтузиазма осваивать новое. А если человек ничего не хочет и ни к чему не стремится, то это не проблема его синьорности. Это его личное отношение к жизни и к работе.
Тоже часто сталкиваюсь с тем, что клиенты не хотят брать синьоров. Но проблемы не в том, что они ленивые или закостенелые. У нас из студентов зачастую до синьоров дорастают за три года, поэтому в большинстве случаев синьоры это вовсе не выгоревшие старики. Большая часть отказов из-за денег. Ставка синьоров существенно выше, нам продавать их услуги по цене мидлов невыгодно, а клиент считает, что у него не настолько сложные задачи, чтобы больше платить за опыт. Вторая причина в том, что клиент опасается, что синьор быстро заскучает без сложных задач. Если разработчик нужен на два три месяца, то это не проблема, но если на больший срок, то правда может заскучать. Третья проблема, что синьоры во многих случаях уже имеют под собой какую-то минимальную команду, коучат кого-то и отвечают за работу мидла или джунов. А далеко не всегда клиент готов брать синьора с его подаванами. Если это джуны, то почти никогда не готов.
Что касается запроса на универсальность, то это во многом связано с тем, как вообще устроена работа с ИТ сотрудниками в самой организации, которая ищет внешний ресурс. Если у них все аналитки-разработчики-девопсы в одном лице, и с бизнесом на одном языке говорят, и код пишут, и оптимизируют производительность, и CI/CD настраивают, то им кажется, что и внешний специалист должен быть таким же. Тут ничего личного, просто иначе он плохо впишется в их модель управления. При том, что у нас все люди специализируются либо на аналитике либо на разработке, приходится подбирать для таких клиентов более-менее универсальных людей. Но на практике, если копнуть глубже, все равно специализация есть. Даже там где пестуют как бы универсалов. Все они называются словом дата-инженер, например, но реально кто-то больше с бизнесом разбирается, а кто-то больше в код закапывается. Просто это уже складывается по факту неформально.
Системы охлаждения магнитов коллайдера работают круглогодично. Это до 120МВт. Но эксперименты зимой не проводятся. В пике во время экспериментов требуется 180МВт. В зимний период энергия нужна для отопления и ее для экспериментов на коллайдере не хватает. Замкнутый круг. Вот когда сделают термоядерный реактор (может тот же коллайдер) с положительным КПД, то тогда и тепло будет и электричество почти в неограниченном объеме.
Хорошая идея. Нагреть песок можно. Но как сохранить тепло в песке? Он же остынет через несколько часов, ну дней, если его очень много. А запасать то нужно не на часы, а на месяцы.
А можете чуть подробнее о способах, которые имеете в виду? Понимаю, что можно вырабатывать электричество - заряжать аккумуляторы, или производить водород из воды. Но, кажется, что это не такие простые способы. Тем более, когда речь идет о больших объемах тепла. Иначе бы градирни уже давно отменили.
Ну если о самом коллайдере говорить, то там такие системы охлаждения, что могут что угодно до состояния плазмы разогреть, не только до 120 градусов. Вопрос стабильности этого потока. В пике коллайдер потребляет 180 МВт. Этого хватит на город 300 тыс. жителей. Если предположить, что 50% этого потребления в итоге переходит в тепло и его нужно сбрасывать, то на отопление соседнего городка остается очень даже много.
Отличная статья. Понравился и стиль изложения. Достаточно легкий, без разжевывания что такое сверточные сети и пр., чем грешат многие статьи и книги про AI. И структурированный подход к описанию проблемы мне тоже хорошо зашел. Отдельный респект за картинки)
На мой взгляд, мало внимания уделяется проблеме потери управления AI со стороны человечества. Конечно, все знают про глюки и т.п. Но вот более серьезные инцеденты, которые неизбежны могут привести к резкому и серьезному оттоку инвестиций и схлопыванию отрасли, на какое-то время. Представьте себе вышедший из под контроля беспилотный автомобиль или группу автомобилей (если будет доказано, что именно мозги машины привели к аварии с летальным исходом). Или сбрендившие андроиды, которыми господин Маск планирует заполонить мир. Да, просто какой-то ИИ агент по торговле бумагами, который вдруг распродаст имущество хозяев подешевке. Набор таких кейсов, вылезших в побличное поле, может надолго подорвать доверие и похоронить отрасль. Ученые же уже констатировали, что мы не в состоянии точно понять, что происходит внутри электронных мозгов AI. Значит риск выхода AI из повиновения не нулевой, а может быть и больший, чем вероятность чисто экономического коллапса.
Проблема в том, что тепло нужно не тогда, когда проводятся эксперименты (а это не постоянно), а зимой, когда холодно. Если невозможно использовать продукт именно тогда когда он нужен, то другого смысла в этом, кроме как попиариться на экологии, нет. Поскольку коллайдер многократно обвиняли в том, что он чуть ли не всю землю может в черную дыру превратить, то экологические ощущения у населения от него скорее отрицательные. Поэтому владельцам проекта обязательно нужно было заняться экологическим пиаром. Вот они и занялись. Даже при нулевом экономическом эффекте. Ведь стоимость прокладки труб до ближайшего городка, на фоне многимиллиардных инвестиций в сам коллайдер, практически нулевая. Датацентры это другое дело. Но тут вообще нет ничего нового. У нас давно металлургические заводы (их печи) включены в систему отопления ближайших районов. Это нормальная практика. Датацентр - тот же завод с непрерывным производством. Выделяет большое количество тепла, грех не воспользоваться им для пользы общества.
Вопрос материальности потерь и вопрос перспектив отношений с заказчиком. Причем не только с ЮЛ, но и с конкретными ФЛ со стороны заказчика, которые сегодня тут работают, а завтра где-то еще, куда нам интересно попасть. Если вы выставляете клиента на штрафы или тем более идете в суд, то это значит, что у конкретного человека на стороне клиента скорее всего будут немаленькие неприятности. Вряд ли он после такого останется вашим лоялистом.
Вообще, нужно признать, что у разных компаний разный аппетит к судебным разбирательствам. Кто-то готов судиться по поводу и без. Но мне как-то больше повезло работать в компаниях, которые считают суд самой крайней мерой и предпочитают в любой ситуации полюбовно договариваться. И я не жалею об этом. Считаю, что это сохранило и мне немало нервных клеток и моим работодателям добавило плюс к репутации, что в целом неплохо.
Спасибо за интересную статью. Отлично, что удалось так быстро запустить решение в прод и преодолеть обычные страхи пользователей перед новыми технологиями и перед "черным ящиком". Хотелось бы только больше узнать про сами сервисы и их встраивание в процессы, а не про классические подходы RAG, которые описаны в специальной литературе. Какую LLM использовали, локально или как сервис? Встроили ли AI-агента прямо в CRM как часть процесса взаимодействия с клиентом, которую невозможно обойти или это все же отдельная справочная система "сбоку", которую сотрудник работающий с клиентом может запросить, если захочет?
Superset прекрасный продукт для своего сегмента, но это opensource и его сравнивать с FineBI сложно. Ведь задача была Self-Service поддержать, как это было в Табло. Чтобы пользователи без ИТ и без программирования могли свои дашборды делать и данные анализировать. На Superset порог входа для пользователей гораздо выше. Да и скорость миграции немаловажна. Если с Табло на FineBI банк смог мигрировать довольно быстро и фактически своими силами, то миграция на Superset это был бы большой и сложный проект с большим объемом чд архитекторов, аналитиков, разработчиков.
Выбирали, выбирали. И довольно тщательно. Тут не было жесткого требования наличия ПО в реестре, поэтому смотрели не только российские продукты, но и решения из Китая
Кажется, что самое главное, что следует из статьи, что задачу Self-Service с помощью FineBI решили. Это главное, что отличает этот продукт и, как я понимаю, в этом он свою функцию в МКБ выполняет. Правильно подмечено, что для Self-Service очень важно наличие комьюнити. Но по FineBI оно на самом деле есть и одно из крупнейших в этой области в РФ. https://t.me/FineBIChat. 1132 человека на сегодняшний день. И очень живое. Десятки сообщений каждый день. Причем именно опытом люди обмениваются, что ценно.
Понимаю, что кто-то сам является экспертом в выборе систем BI и в импортозамещении. У эксперта всегда есть собственное мнение и большой объем материалов по теме в запасе. Только вот не стоит думать, что все остальные тоже суперэксперты в этом вопросе и что чужой совет для них абсолютно бесполезен. Тема резкого импортозамещения новая и многие с ней только пытаются освоиться. Количество запросов упомянутой в статье таблицы сравнения говорит, что материал очень востребован. На истину в последней инстанции никто не претендует, но это сейчас и не нужно. Большинству заинтересованных требуется просто структурированный взгляд на проблему импортозамещения BI. В этом и заключается наша помощь. А дальше уже каждый сам сможет подобрать для себя оптимальный вариант, исходя из своей конкретной ситуации. Мы не вендор. Мы не даем массовые советы что выбирать Визиолоджи, Полиматику, FineBI или что-то другое. Но показываем какие критерии стоит принять во внимание и какие плюсы/минусы у разных вариантов. Конкретные рекомендации даем только конкретным клиентам, хорошо разобравшись с их ситуацией и приоритетами. И то, по факту все равно требуется, пилот чтобы провалидировать выбор.
Что касается выбора вместо специализированного BI какой-то другой технологии, вплоть до предложений дать аналитикам Питон или R и пусть сами разбираются, то считаю это утопией. Это можно сравнить с тем, как в СССР после революции пытались вывести нового советского человека, вместо того, чтобы работать с обычным человеком и его обычными потребностями и мотивами. Вывести нового потребителя BI (антиBI) если и получится, то очень не скоро. Нормальный self-service BI тем и хорош, что заточен под конкретную задачу и за счет этого сильно снижает для аналитиков и бизнеса порог входа и трудозатраты на анализ и разработку нужных дашбордов. А если брать какой-то универсальный инструмент, то, конечно, на нем можно сделать все что угодно, но на практике делать это никто не будет и в итоге никуда из своего Экселя не вылезет. А вот в Табло и Power BI из Эксель переходили, и не единицами, а тысячами.
Илья, у нас у всех какой-то бэкграунд. Но не считаю, что то, что кто-то говорит априори не интересно и неправильно только исходя из его бэкграунда или должности. Кто-то просто не интересен, а кто-то всегда интересен вне зависимости где он сейчас работает и чем занимается. Думаю, что длинная междусобойная дискуссия не совсем формат Хабра. Хочу лишь подчеркнуть еще раз, что производительность и архитектура это важные составляющие BI решения. Они в статье упомянуты отдельно, как факторы, которые нужно принимать во внимание. Просто требования к этим параметрам у всех очень сильно разнятся. И то, что у какой-то системы супербыстрый движок, не обязательно приводит к ее выбору, если система слишком сложна для использования бизнесом (чтобы сделать нужный бизнесу виз или рассчитать нужный показатель требуется писать код на JS или питоне). И наоборот, если решение по выбору системы принимает не бизнес, а ИТ, то выбрать могут по чисто техническим характеристикам, решив, что все красивости это блаж и без них все будет норм. Статья о том, что лучше учитывать все параметры в комплексе, оценив их вес для вашей конкретной организации. Тогда есть шанс снизить ошибки в условиях нынешнего цейтнота. На веса параметров выбора должны влиять и ИТ, и бизнес, и аналитики. Им же вместе потом делать миграцию и жить с тем что получится в итоге.
У Вас свое мнение и оно понятно. Но оно не единственное. Если решение покупает CDTO или CDO и бюджет их, то может они выберут по каким-то чисто техническим соображениям. А если бизнес, то простота и удобство, да и красота тоже, будут более важными факторами. И не нужно думать, что они ничего не понимают и выбирают не правильно, как неразумные дети. Они выбирают и потом пользуются и решают задачи своего бизнеса. А для чего это все внедряется, как не для бизнеса. Не для того же, чтобы в блоге писать про то какая крутая там архитектура. Про LuxMS знаем конечно.
Производительность оттачивается и оптимизируется в реальных проектах у живых клиентов. Никто не заморачивается оптимизацией, если клиентам это не требуется. Поскольку большинство российских BI решений используется не в ритейле, телекоме и банках, а в госведомствах, то требования к обрабатываемым массивам данных и скорости их обработки не были очень высоки. Сейчас, с учетом сложившейся ситуации, BI вендоры выходят на новые для себя рынки - крупных коммерческих компаний с большими объемами данных, со сформировавшимися потребностями в скорости обработки (Tableau и Co приучили к секундному отклику). Это будет суперстимул для доведения до ума решений в части производительности. Посмотрим на результат через годик.
Для любого инструмента можно придумать или найти задачу, которая его сломает. Это нормально. И DS не исключение. Главное правильно подобрать и применять инструмент для тех задач, которые Вы решаете на регулярной основе. А если есть какая-то уникальная задача, то ее можно решить разово и на чем угодно, на чем удобно. В хорошем BI основное преимущество в том, что он удобен и для разработчика и для пользователя. Позволяет быстро и просто решать большинство типовых задач построения дашбордов и анализа данных. В крутом BI 99% операций делается мышкой за минуты. При этом в обычном BI инструменте это все тоже можно сделать, только за часы и с использованием скриптов на JS, питоне и пр.
Согласен с InnovaIT. Зачем было писать в заголовке Индустрия 4.0, если эта тема вообще не затрагивается. Лучше профессионально написать про ИБП и люди проявят интерес. Те, кому это на самом деле надо.