Посчитать число успешных контекстов, в которых есть определенный провайдер

Автор WA, 27 января 2021, 10:40:36

« назад - далее »

WA

Есть сущность - контекст. В контексте может быть несколько Call ID.
Пример контекстов.
Вы не можете просматривать это вложение.
Необходимо измерить только те контексты, в которых
1) число провайдеров >2
2) число уникальных "На номер" =1

Прописал измерения:
=Aggr(Count(Distinct Провайдер)>=3, Контекст)and Aggr(Count(Distinct [На номер])=1, Контекст)
=Провайдер

Не получается написать выражение, которое бы считало число успешных контекстов (контекст успешен если в нем есть направление="Вход (усп)"), в которых есть конкретный провайдер.
Нужны данные в таком виде
провайдер   всего   успешных контекст   успешных провайдер
a           114   17                   62
b           92   45                   0
c           44   9                   8
d           34   4                   2
e           24   2                   5
f           23   5                   2
Пробовал так, чтобы посчитать успешные контекты
if(Aggr(Count(Distinct Провайдер)>=3, Контекст)and Aggr(Count(Distinct [На номер])=1, Контекст)
,count(Aggr(Count({<Направление={"Вход (усп)"}>}Контекст), Контекст)))
Для успешных контекстов считает правильно только если счетчик "успешный провайдер"=0.
 "успешный провайдер" считает в скольких Call ID для конкретного провайдера Направление="Исх (усп)". Считается так  и результат правильный.
if(Aggr(Count(Distinct Провайдер)>=3, Контекст)and Aggr(Count(Distinct [На номер])=1, Контекст)
,Count({<Направление={"Вход (усп)"}>}Distinct [Call ID]))

admin

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

govorun

Поддержу adminа. Проще (лучше) флаги расставить в скрипте, чем переполнять расчеты агрегацией да еще и в условии

WA

Предположим я скриптом сформировал необходимые для анализа данные. Т.е. выбрал все контексты, в которых
1) число провайдеров >2
2) число уникальных "На номер" =1.

А как дальше? Мой основной вопрос то остается.  Как посчитать число успешных контекстов (контекст успешен если в нем есть направление="Вход (усп)"), в которых есть конкретный провайдер?

Uunit


WA

Ранее никогда не использовал Group By. Прочитал, что его использование приводит к "увеличение времени выполнения скрипта, значительный рост ресурсоемкости на этапе перезагрузки данных)." + рекомендации использовать AGGR, а не Group By.

Maks248

Здесь нужно для себя решить, что предпочтительнее.
Одно дело, когда нагрузка и тормоза возникают в момент обновления данных, которое запланировано, например, на ночь и пользователей нет в системе, другое дело, когда тормоза проявляются в момент построения визуализаций и пользователи начинают жаловаться. Причем некоторые, особо активные пользователи могут выдать - "А у нас плохо работает" или вообще - "у нас вооще ничо не работает"
Такое бывает ))

admin

Цитата: WA от 28 января  2021, 02:30:25  Ранее никогда не использовал Group By. Прочитал, что его использование приводит к "увеличение времени выполнения скрипта, значительный рост ресурсоемкости на этапе перезагрузки данных)." + рекомендации использовать AGGR, а не Group By.
Интересно, это где так написано?

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

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

WA

Цитату взял здесь. https://blog.atkcg.ru/gruppirovka-dannyx-v-qlik-prodvinutaya-rabota-s-group-by-v-skripte/. Те задержки, которые есть у меня  сейчас при использовании многочисленных AGGR совсем не напрягают. А что будет при использовании  Group By неизвестно + еще разбираться надо как это все в скрипте прописать. И самое главное, даже при использовании  Group By мой основной вопрос остается открытым.
Цитата: WA от 28 января  2021, 09:36:27  Предположим я скриптом сформировал необходимые для анализа данные. Т.е. выбрал все контексты, в которых
1) число провайдеров >2
2) число уникальных "На номер" =1.

А как дальше? Мой основной вопрос то остается.  Как посчитать число успешных контекстов (контекст успешен если в нем есть направление="Вход (усп)"), в которых есть конкретный провайдер?

Uunit

А кто вам запрещает в сформированных данных добавить некий маркер в виде:
1 as flagА не удовлетворяющие условия, добавить флаг 0.

А уже в диаграмме ссылаться на этот самый флаг. 

admin

Цитата: WA от 29 января  2021, 09:36:10  Цитату взял здесь. https://blog.atkcg.ru/gruppirovka-dannyx-v-qlik-prodvinutaya-rabota-s-group-by-v-skripte/.

Ясно )))
Проверьте вариант с group by в скрипте, нет в нем ничего такого страшного. Открываете диспетчер задач и смотрите как и что грузится во время выполнения скрипта. Вы сэкономите кучу времени и получите простые формулы.

admin

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


govorun

По сути при использовании aggr() происходит построение виртуальной таблицы с указанными группировками.
Таким образом:
- либо Вы используете группировку в скрипте загрузки (group by) и получаете сгруппированные данные,
- либо Вы загрузите разрозненные данные в скрипте загрузки и предложите Клику посчитать данные в диаграммах с помощью aggr(). И Клик посчитает данные используя все тот же group by, просто Вы этого не видите.

Вот и решайте где тратить ресурсы на группировку (group by): в скрипте (ночью)  или в диаграммах (когда все кому не лень ломятся в Клик).
А тратить ресурсы все равно придется.

Яндекс.Метрика