DAX CALCULATETABLE против функции FILTER

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

В этом блоге мы рассмотрим функцию CALCULATETABLE и ее план запроса в DAX studio и поймем, чем она отличается от функции FILTER . К концу вы будете лучше понимать, как выбрать правильную функцию для ваших нужд анализа данных.

Для демонстрации мы будем использовать приведенный ниже код DAX.

Когда вы запустите этот код, вы получите таблицу, показывающую марку и цвет.

На вкладке Query Plans вы получите код, соответствующий оператору CrossApply в Formula Engine .

В то же время вы можете видеть, что код получает только цвет и марку продукта на вкладке «Тайминги сервера» .

Оглавление

• Результат синхронизации сервера DAX Studio для CALCULATETABLE
• CALCULATETABLE План запроса в DAX Studio
• Переход контекста для аналогичных функций DAX
  • Тайминги сервера
  • План запроса
• Заключение

Результат синхронизации сервера DAX Studio для CALCULATETABLE

В качестве примера давайте отфильтруем цвет товара, чтобы отображались только красный и/или черный.

Это можно сделать с помощью функции ФИЛЬТР. Когда вы запустите его, серверные тайминги покажут, что аргумент FILTER не применяется к коду xmSQL .

Но если вы используете функцию CALCULATETABLE, запрос на вкладке Server Timings покажет, что результаты были отфильтрованы по цвету продукта.

CALCULATETABLE План запроса в DAX Studio

Давайте посмотрим на план запроса для каждой функции.

CALCULATETABLE находится в первой строке плана логического запроса, потому что это функция верхнего уровня в коде и, следовательно, не зависит ни от каких требований.

Когда вы читаете план запроса функции CALCULATETABLE, вы не начинаете с первого аргумента. Сначала вам нужно понять контекст используемого фильтра. Итак, переходим к строке 5.

Вы можете видеть, что оператору VertiPaq требуется столбец цвета продукта из-за примененного фильтра. Затем он сканирует этот столбец и использует комбинацию фильтров Not IsEmpty для проверки цвета продукта в каждой строке.

После подготовки контекста фильтра выполняется аргумент

Оглядываясь назад, если вы используете функцию FILTER, вы увидите другой план запроса, поэтому аргумент CROSSJOIN выполняется до определения контекста фильтра.

Недостатком этого подхода является то, что он не передает условие фильтра в Storage Engine. Вы не сможете использовать предложение WHERE внутри xmSQL, что создаст большую нагрузку на Formula Engine.

А когда вы работаете с несколькими таблицами, комбинация фильтров функции CROSSJOIN будет огромной. Это снижает производительность кода DAX. Таким образом, в большинстве случаев рекомендуется использовать функцию РАСЧЕТНАЯ ТАБЛИЦА.

Таким образом, вместо того, чтобы выполнять все вычисления в Formula Engine, вы можете внедрить условие фильтра в класс WHERE кода XMSQL.

Переход контекста для аналогичных функций DAX

Тайминги сервера

Эта концепция также применима к функции ВЫЧИСЛИТЬ. Давайте используем приведенный ниже код DAX в качестве примера.

Мера автоматически имеет функцию РАСЧЕТ.

Когда вы запустите этот код, вы получите таблицу, показывающую общую сумму продаж для каждого цвета.

На вкладке Server Timings вы можете видеть, что код выполняет два запроса. Первый запрос вычисляет сумму суммы продаж из таблицы «Продажи» по отношению к таблице «Продукты».

С другой стороны, второй запрос снова извлекает цвет продукта из таблицы Products. Это соответствует функции в коде DAX.

Механизм формул размещает кэши данных двух запросов рядом. Он начинается с извлечения значений из второго кэша данных, а затем выполняет поиск в первом кэше данных.

План запроса

На вкладке «План запроса» логический план запроса сканирует цвет продукта из-за аргумента .

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

Фильтр, созданный переходом контекста, транслируется в свойство DependOnCols в плане запроса. После того как VertiPaq просканирует столбцы, необходимые для расчета общего объема продаж, он умножает объем продаж на чистую цену.

Затем общий объем продаж возвращается как результат в виде валютного типа данных. И, наконец, ADDCOLUMNS возвращает таблицу с двумя столбцами, содержащими цвет и общую сумму продаж.

Заключение

План запроса может существенно повлиять на производительность запроса, поскольку разные планы запросов могут иметь разные уровни эффективности.

При использовании функций CALCULATETABLE и FILTER в запросе DAX план запроса может отличаться в зависимости от конкретного сценария и множества факторов, таких как используемое конкретное выражение формулы и возможности обработчика запросов.

Как правило, рекомендуется протестировать и сравнить производительность различных планов запросов, чтобы определить наиболее эффективный подход для данного сценария.

Всего наилучшего,