Не поэтому ли каждый крупный заказчик начав с "простого" и "дешёвого" PowerBI переходит на Qlik Sense в перспективе максимум 2-3 лет, когда понимает на собственной практике, что это лишь рисовалка на данных из готового хранилища? )))

Ну не каждый)

Но даже и в части рисования: молодцы, что через 20 лет после Qlik учатся делать интерактивные отборы хотя бы в виде прямоугольных лассо. Научиться бы еще не вовлекать в это клавиатуру, а то уж как-то неудобно носить её на цепочке привязанной к мобильному устройству)))

Каждый, кто попробовал поработать несколькими сотнями/тысячами пользователей не в отдельных дашбордиках, а в общих корпоративных интерактивных приложениях. Про объемы данных повторяться не буду

Да передергивание здесь не в этом, а в том что тут просто разный self service...
В целом для self service и там и там не надо ничего кроме как открыть приложение и мышкой куда-то что-то таскать и тыкать по фильтрам...

Ну давайте теперь ещё разделим, например,  самообслуживание по приготовлению пищи на плите на два вида: просто разогреть готовую еду (покрутить ручки плиты) и приготовить хотя бы простую яичницу)))

И варка яйца - тоже отдельный вид самообслуживания?

НУ если в таком контексте общаться, то
Python в Qlik тоже нужен для его задач.. VB в Qlik более убог, т.к. это QVScript, есть еще JScript... А если подключить SSE, то количество языков которые надо знать вырастает с сумасшедшей скоростью...
SetAnalysis не сильно отличается для не сильно близкого к ИТ от DAX (а если человек до этого работал с Excel худо бедно, а это практически все, то идеология будет проще для не самых сложных случаев)...

Безусловно... Ибо это два разных подхода к питанию...
Для одного их них достаточно микроволновки, а для другого еще и читатьнужно иметь, чтобы в рецептах что-то понимать...

Коллеги, наткнулся на такую штуку, что если назвать поле с нижнего подчёркивания то данное поле не будет отображаться в просмотре модели. Получается оно становится скрытым. Таким образом ключи, которые не должен видеть пользователь можно назвать _%key, есть еще подобные лайфхаки?

Это не лайфхак,  это возможность управления отображением с использованием hideprefix или hidesuffix

Вот здесь не соглашусь. Python, R и подобные вещи для Qlik - возможные, но не обязательные вещи.
Для PowerBI в большинстве случаев при серьёзной работе языка M недостаточно,  поэтому и приходится спрыгивать на SQl и/или Python

То есть если в main прописать set HidePrefix='%'; то пользователи будут недоступны ключи, которые у меня начинаются с %
Очень отлично

Спасибо!

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

Коллеги, добрый день! Подскажите, пожалуйста, как реализовать в Qlik Sense аналог сводной диаграммы Excel - линейный график - чтобы было несколько измерений и несколько мер на графике? Дело в том, что "The combo chart only supports one dimension", а в line chart есть ограничения на число измерений при нескольких мерах согласно базе знаний: https://support.qlik.com/articles/000041363

Мне кажется здесь вы слишком растягиваете понятие самообслуживание...
Потребитель информации (не аналитик) не будет разбираться даже в том как формулы писать, не то что скрипт загрузки ваять...
А аналитик приличный это уже не самообслуживание (особенно если мы говорим при скрипт трансформации, тем более "сколько нибудь серьезный")...

С SQL скорее соглашусь, а вот с Python все-таки ситуация аналогична (т.к. используется и там и там для аналогичных задач)...
Только в PowerBI слоем трансормации может пользоваться любой потребитель который может подключиться к базе без всяких бубнов...

Воспользоваться визуальным слоем трансформации в любом продукте можно лишь до той поры, пока задача раскладывается на последовательность шагов, для которых разработчики закодировали те самые меню и кнопки. Как только задача становится сложнее - приходится спрыгивать в те или иные языки, дающие большую свободу в описании логики. Язык Qlik в части табличных операций похож на SQL, да ещё и упрощён
синтаксически и при этом обогащён функционально.
Язык M - не имеет почти ничего общего с SQL. Поэтому трудозатраты на обучение различные. Синтаксис большинства функций Qlik - одинаков. В PowerBI языки DAX и M - совершенно разные сущностно

Поэтому Python и прочие - это лишь упоминание его в контексте того, что кому-то из собеседников было проще писать на нём, чем на M или на SQL