Функція DAX CALCULATETABLE проти FILTER

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

У цьому блозі ми розглянемо функцію CALCULATETABLE та її , а також зрозуміємо, чим вона відрізняється від функції FILTER . Зрештою ви краще зрозумієте, як вибрати правильну функцію для ваших потреб аналізу даних.

Для демонстрації ми використаємо наведений нижче код DAX.

Коли ви запустите цей код, ви отримаєте таблицю, у якій буде показано бренд і колір.

На вкладці Плани запитів ви отримаєте код, що відповідає оператору CrossApply у .

У той же час ви бачите, що код лише отримує колір і бренд продукту на вкладці «Таймінг сервера» .

Зміст

• Результат синхронізації сервера DAX Studio для CALCULATETABLE
• План запиту CALCULATETABLE у DAX Studio
• Перехід контексту для подібних функцій DAX
  • Таймінг сервера
  • План запиту
• Висновок

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

Як приклад, давайте відфільтруємо колір продукту, щоб відображати лише червоний та/або чорний.

Це можна зробити за допомогою функції FILTER. Коли ви запускаєте його, часові параметри сервера покажуть, що аргумент FILTER не застосовано до .

Але якщо ви використовуєте функцію CALCULATETABLE, запит на вкладці «Час сервера» покаже, що результати було відфільтровано за кольором продукту.

План запиту CALCULATETABLE у DAX Studio

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

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

Коли ви читаєте план запиту функції CALCULATETABLE, ви не починаєте з першого аргументу. Спочатку потрібно зрозуміти контекст фільтра, який використовується. Отже, переходимо до рядка 5.

Ви бачите, що оператору потрібен стовпець кольору товару через застосований фільтр. Потім він сканує цей стовпець і використовує комбінацію фільтра Not IsEmpty , щоб перевірити колір продукту в кожному рядку.

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

Оглядаючись назад, якщо ви використовуєте функцію FILTER, ви побачите інший план запиту, тому аргумент CROSSJOIN виконується перед визначенням контексту фільтра.

Недоліком цього підходу є те, що він не передає умову фільтра в Storage Engine. Ви не зможете використовувати речення WHERE всередині xmSQL, що ляже важким тягарем на механізм формул.

А коли ви працюєте з кількома таблицями, комбінація фільтрів функції CROSSJOIN буде величезною. Це сповільнює продуктивність коду DAX. Тому в більшості випадків рекомендується використовувати функцію CALCULATETABLE.

Таким чином, замість того, щоб виконувати всі обчислення в механізмі формул, ви можете додати умову фільтра всередину класу WHERE коду XMSQL.

Перехід контексту для подібних функцій DAX

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

Ця концепція також застосовна до функції CALCULATE. Давайте використаємо наведений нижче код DAX як приклад.

Міра автоматично має функцію CALCULATE навколо неї.

Коли ви запустите цей код, ви отримаєте таблицю, яка показує загальну суму продажів для кожного кольору.

На вкладці Server Timings ви можете побачити, що код виконує два запити. Перший запит обчислює суму обсягу продажів із таблиці продажів відносно таблиці продуктів.

З іншого боку, другий запит знову отримує колір продукту з таблиці «Товари». Це відповідає функції в коді DAX.

Formula Engine розміщує кеші даних двох запитів поруч. Він починається з отримання значень із другого кешу даних, а потім виконує пошук у першому кеші даних.

План запиту

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

Потім VertiPaq підсумовує загальну суму продажів залежно від кольору продукту. Він виконує перехід контексту, який перетворює значення кольору продукту в еквівалентний контекст фільтра.

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

Тоді загальний обсяг продажів повертається як результат у формі типу даних валюти. І, нарешті, ADDCOLUMNS повертає таблицю з двома стовпцями, що містять колір і загальну суму продажів.

Висновок

План запиту може мати значний вплив на продуктивність запиту, оскільки різні плани запиту можуть мати різні рівні ефективності.

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

Загалом доцільно протестувати та порівняти продуктивність різних планів запитів, щоб визначити найефективніший підхід для певного сценарію.

Все найкраще,