Выбор правильного типа расчета…

Сегодня в Tableau есть несколько форм расчета:

Основные расчеты

Данные расчеты записываются как часть запроса, созданного Tableau и, следовательно, выполняются в источнике данных. Они могут быть выполнены либо в детализации источника данных (расчет на уровне строк) либо на уровне детализации визуализации (совокупность расчета).

Уровень детализации выражений

Как и основные расчеты, уровень детализации выражений также записывается как часть запроса, созданного с помощью Tableau и, следовательно, выполняется в источнике данных. Разница заключается в том, что LOD (уровень детализации) выражения могут работать при детализации, отличной от источника данных или визуализации. Они могут выполняться на более детальном уровне (с помощью INCLUDE), менее детальном уровне (через EXCLUDE) или на полностью независимом уровне (через FIXED).

Табличные расчеты

Табличные расчеты выполняются по возвращению запроса и, следовательно, могут работать только над значениями, которые находятся в наборе результатов запроса.
Одна из проблем, с которыми сталкиваются новички в Tableau, это понимание того, какой тип расчета использовать для данной задачи. Этот пост посвящен внесению некоторой ясности в то, как определить этот тип. Мы делаем это путем сравнения типов различных расчетов друг с другом.

№1 – Основной расчёт против табличного расчета

При попытке выбрать между основными и табличными расчетами, встает важный вопрос: «Есть ли все значения данных, необходимые для визуализации?» Если ответ «да», то вы можете рассчитать результат без дальнейшего взаимодействия с источником данных – чаще всего это значительно быстрее, так как меньше данных следует обрабатывать (т.е. мы просто производим расчет с использованием совокупных значений из набора результатов). Если вы не сделаете этого, то у вас не останется выбора, кроме как перейти к основному источнику данных для расчета ответа.

Рассмотрим пример, когда мы спрашиваем: «Что такое 90-й перцентиль вашего порядка детализации, показанный по стране»:

Обе стороны этой панели управления отвечают на вопрос, если бы вы были просто заинтересованы в значении 90-го перцентиля и не было необходимости в определении дальнейших выводов – в этом случае диаграмма слева будет оптимальной. Она обеспечивает минимальный набор результатов (один номер на каждую страну) с помощью базовой совокупности PCT90 ([Продажи]), которая рассчитывается в базовом источнике данных.
Тем не менее, если вы хотите получить дальнейшее результаты (например, определить детали распространения и выявлять посторонние значения) или добавить другие совокупности (например, вы также хотели бы определить медианные значения), то с помощью диаграммы можно сделать это без последующих запросов. Первоначальный запрос возвращает все записи деталей заказа (зеленые точки), предоставляет все данные, необходимые для вычисления локально 90-й перцентили, а также для изучения других результатов.
Одним из ключевых моментов этого поста является то, что именно расположение визуализации имеет значение. Как уже обсуждалось выше, именно визуализация будет влиять на то, сколько данных изначально вернется из источника данных, и это является важным фактором при определении вашего подхода. Тем не менее, бывают ситуации, когда даже при наличии всех необходимых данных в наборе результатов невозможно получить нужную визуализацию с помощью расчетной таблицы. Таким образом, вы также должны спросить, позволяет ли именно визуализация использовать расчетную таблицу.


Рассмотрим следующий пример, в котором мы запрашивает разницу продаж за год в двух форматах — один в виде диаграммы, а другой в виде таблицы:

Верхняя половина данной панели управления легко получается с помощью расчетной таблицы — просто продублируйте поле [Продажи] и примените быстрый расчет разницы таблицы, перейдите к параметру [Дата Заказа]. В то же время, если вы попытаетесь преобразовать эту структуру вычисления в таблицу, все сведется к следующему:

Вы поймете, что невозможно достигнуть определенного вида с расчетной таблицей, так как вам необходимы параметры Года с параметром Имена измерений, вложенного в него. Tableau не может блокировать строку «разница в продажах» относительно 2013 года, поэтому в этом примере единственный возможный вариант заключается в использовании основных расчетов:
[Продажи 2013]
IF YEAR([Order Date]) = 2013 THEN [Sales] END
[Продажи 2014]
IF YEAR([Order Date]) = 2014 THEN [Sales] END
[Разница]
SUM([2014 Sales]) – SUM([2013 Sales])
Такой подход позволяет получить только параметры Имена измерений, которые вы можете сортировать для их соответствия требованиям вида.

#2 – Основные расчеты против уровня детализации выражения

Если у нас не будет всех данных, необходимых для визуализации, нужно пропустить расчет через источник данных. Это означает, что необходимо использовать базовые расчеты или выражение LOD. Но как выбрать? Здесь важно понимать, соответствует ли детализация запроса именно детализации визуализации или детализации источника данных.

Основные расчеты могут быть выполнены либо в виде расчетов на уровне строк, либо в виде совокупности расчетов – таким образом они могут только ответить на вопросы о детализации источника данных или на уровне детализации визуализации. Уровень детализации выражений с другой стороны может ответить на вопросы в любой детализации.
Рассмотрим следующий пример, где мы спрашиваем, что такое 90-й перцентиль продаж на уровне детализации заказа по сравнению с уровнем общего заказа.

Если вы знакомы с набором данных Tableau Superstore, вы знаете, что он представляет собой один ряд данных для каждой позиции каждого заказа. Так что, если мы рассматриваем вопрос, приведенный выше, мы определяем:
 Детализацию источника данных: Детали заказа
 Детализацию визуализации: Страна
 Детализацию левой диаграммы: Детали заказа
 Детализацию правой диаграммы: Заказ

Таким образом, для левой диаграммы мы можем решить эту проблему методом базового расчета — PCT90 ([Продажи]) — однако для правой диаграммы мы должны сначала подсчитать детали заказа до уровня заказа, а затем выполнить совокупность перцентиля. Таким образом, мы должны использовать уровень детального выражения:
[Сумма продаж, включая заказы]
{INCLUDE [Order ID] : SUM([Sales])}
Затем мы можем использовать ту же совокупность, как указано выше — PCT90 ([Сумма продаж, включая заказы]) – для определения ответа. На следующей диаграмме приведены пояснения, как работает выражение LOG:

Обратите внимание, что мы используем выражение INCLUDE так, чтобы заказы, которые распределены между странами, были распределены правильно и не учитывались дважды. Некоторые читатели могут предпочесть решить эту проблему с помощью выражения FIXED – в этом случае мы должны были бы написать:
[Сумма продаж, включая заказы]
{INCLUDE [Country], [Order ID] : SUM([Sales])}
Это было бы рациональным для требуемой диаграммы, но будет ограничивать вашу адаптивность изменений группировки под какой-либо параметр – например, по регионам или по типу доставки.

#3 – Расчетные таблицы против уровня детализации выражения

Данное решение многих сбивает с толку, однако процесс выбора между расчетной таблицей и выражением LOD такой же, как и для расчётной таблицы относительно основного расчета. Стоит спросить:

Рассмотрим следующий пример, когда мы спрашиваем, что такое 90-й перцентиль продаж на уровне общего порядка, показанного по стране:

Вы заметите, что это почти идентично вопросу, заданному в пункте 1 выше. Единственное отличие в том, что расчет перцентиля производится на основе общего заказа, а не деталей заказа. Фактически можно реализовать диаграмму с левой стороны, на самом деле это та же диаграмма, что и с правой стороны в №2. Мы уже знаем, что детализация этой проблемы отличается от источника данных и визуализации – таким образом, мы должны использовать выражение LOD.
Диаграмма с правой стороны такая же, как и с правой стороны в №1, однако точки представляют собой заказы, а не детали заказа. Это осуществляется просто путем изменения детализации визуализации (поменять местами ID строки с ID заказа в поле Детали). Поскольку расчетные таблицы сохраняют логику расчетов отдельно от объема и направления расчетов, даже не нужно менять расчет – просто вычислите с помощью ID заказа.
Это может оказаться слишком сложно, что приведет к неуверенности в ответе на наши вопросы о процессе решения, поэтому иногда вы можете решить проблему в одностороннем порядке, пока позже не введете осложнение. Рассмотрим следующий пример, когда мы спрашиваем, для каждой возрастной группы, какой процент от болезней создает каждую учетную запись для болезни:

Очевидно, что это процент от общей задачи, и можно очень быстро устранить эту проблему с помощью расчета быстрой таблицы поверх вкладки «Болезни». Тем не менее, когда мы затем добавим сложность, позволяя пользователю осуществлять фильтрацию по конкретной болезни, мы увидим следующее:

Это происходит вследствие того, что набор результатов больше не содержит все необходимые нам данные – фильтр удалил расчетные данные пациента для других заболеваний. Вы могли бы решить эту проблему, создав фильтр расчетной таблицы:
[Фильтр болезни]
LOOKUP(MIN([Disease]), 0) расчет с использованием болезни
Или вы можете использовать выражения LOD, зная, что ФИКСИРОВАННЫЕ вычисления выполняются перед параметром фильтрации. Во-первых, необходимо обработать общее количество людей в возрастной группе:
[Общее количество пациентов относительно болезни]
{FIXED [Age]:SUM([Patient Count])}
После этого вы можете вычислить общий %:
[Общий процент]
SUM([Patient Count])/SUM([Total Patients per Disease])

#4 – В расчете будет учитываться только таблица

Наконец, нам нужно добавить одну окончательную концепцию для нашего процесса принятия решений. Есть несколько категорий проблем, которые можно решить только с помощью расчетной таблицы:
 Иерархия
 Рекурсия (например, сумма нарастающим итогом)
 Скользящие расчеты (например, скользящее среднее)
 Междурядные расчеты (например, период относительно расчетного периода)
Итак, вопрос, который нужно поставить в этом случае: «Требует ли моя проблема использования иерархии, рекурсии, скользящих расчетов или же междурядных расчетов?»


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

Здесь требуется рекурсивное вычисление: мне нужно рассмотреть все предыдущие значения, прежде чем сказать, что это новый максимум. Мы можем сделать это с помощью функции RUNNING_MAX. Таким образом, мы сначала рассчитаем максимальное значение на сегодняшний день:
[Запись по дню]
RUNNING_MAX(AVG([Close])) расчет с использованием дня
Затем на уровне дня мы должны отметить те дни, когда рекорд был побит:
[Расчет дня, когда был побит рекорд]
IF AVG([Close]) = [Record to Date] THEN 1 ELSE 0 END
И, наконец, нам нужно подсчитать эти дни:
[Общее время, на протяжении которого рекорд был побит]
RUNNING_SUM([Count Days Record Broken]) расчет с использованием дня.

Выводы

Ключевые моменты, вынесенные из всего этого:
 Нет верного решения проблемы. Ответ всегда «зависит от …», но процесс принятия решений поможет вам начать выбор правильного подхода.
 Расположение вопросов в визуализации имеет значение – так как его изменение предполагает необходимость изменения типа расчетов.
 Существуют ситуации, когда различные решения работают по-разному в зависимости от объема и сложности данных, от сложности вопроса и требуемого расположения.
 Всегда есть место компромиссам, которые стоит рассмотреть (производительность по отношению к гибкости и простоте). Хорошее правило – это когда вы можете выбрать любые два.


Найти решение у бизнес-партнера QlikTech (QlikView) в России.

Форум разработчиков QlikView и Qlik Sense. Получите ответы на все вопросы по QlikView и Qlik Sense!

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий

64 queries in 0,380 seconds