Оптимизация DAX для LuckyTemplates с помощью DAX Studio — Formula Engines

Когда вы оптимизируете свою модель данных и DAX для LuckyTemplates, полезно помнить, что за кулисами работают два механизма — механизм формул и механизм хранения .

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

Оглавление

• Роль формульного двигателя
• Как работает формульный движок
• Основные ограничения Formula Engine
• Как Formula Engine помогает оптимизировать DAX для LuckyTemplates
• Снижение нагрузки на формульный движок
• Инструменты, которые могут помочь оптимизировать DAX для LuckyTemplates
• Заключение

Роль формульного двигателя

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

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

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

Механизм формул понимает запросы, полученные не только в DAX, но и в MDX. Например, когда вы используете Excel, вы создаете сводные модели на основе сводных таблиц, а сводные таблицы фактически используют язык MDX.

Здесь вступает в действие обработчик формул. Поскольку он понимает как DAX, так и MDX, вы можете использовать другую модель LuckyTemplates. Запросы, отправленные из этой модели данных, будут использовать DAX, а запросы, исходящие из сводной модели, будут использовать MDX.

Как работает формульный движок

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

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

При создании плана запроса обработчик формул сначала строит логический план запроса, а затем — физический план запроса. И логический, и физический план запроса должны быть похожи друг на друга.

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

Основные ограничения Formula Engine

Механизм формул играет огромную роль при оптимизации DAX для LuckyTemplates с помощью DAX Studio. Однако он также имеет некоторые ограничения.

Во-первых, механизм формул всегда использует одно ядро ​​для управления всей вашей операцией, независимо от того, сколько ядер ЦП доступно в вашей системе .

Когда я открою свой диспетчер задач, вы увидите, что мой процессор имеет шесть ядер.

Несмотря на этот факт, механизм формул по-прежнему будет выбирать одно из этих шести ядер для работы, в то время как он предоставляет механизму хранения использовать остальные.

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

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

Как Formula Engine помогает оптимизировать DAX для LuckyTemplates

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

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

Как это будет работать?

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

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

Снижение нагрузки на формульный движок

Опять же, обработчик формул понимает коды DAX и MDX.

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

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

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

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

Конечно, это также будет зависеть от того, как используется SUMMARIZE.

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

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

Инструменты, которые могут помочь оптимизировать DAX для LuckyTemplates

Оптимизировать DAX будет проще, если вы максимально используете инструменты, которые делают это возможным. DAX Studio — один из таких инструментов.

Давайте возьмем приведенный выше пример, когда механизм формул берет на себя всю нагрузку по завершению вычислений, когда используется функция СУММИЗИРОВАНИЕ. DAX Studio может помочь вам переписать код таким образом, чтобы SUMMARIZE переместился в подсистему хранения, разгружая нагрузку на подсистему формул. Это потенциально повышает производительность вашей модели данных и запросов.

Конечно, это должно работать без проблем для простых запросов. Есть и более сложные сценарии.

Например, вы можете создавать составные модели, которые используют два механизма хранения внутри самой модели данных. Один может быть для Vertipaq, а другой — для DirectQuery. В этом случае ваша база данных должна быть оптимизирована таким образом, чтобы генерируемые запросы строились для этой конкретной реляционной модели данных.

Допустим, у вас есть две таблицы внутри вашей модели даты — таблица «Продукты» и таблица «Продажи». Таблица «Продукты» находится в хранилище Vertipaq, а таблица «Продажи», будучи более крупной, хранится непосредственно в базе данных через соединение DirectQuery.

Предположим также, что вы перетаскиваете в матрицу столбец «Бренд», а также меру «Общий объем продаж», полученную из таблицы «Продажи» в соединении DirectQuery.

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

Во-первых, он извлечет столбцы «Ключ продукта» и «Бренд» из таблицы «Продукты». Затем он извлечет столбцы «Цена нетто», «Количество» и «Ключ продукта» из таблицы «Продажи». Получив кеш данных как от Vertipaq, так и от DirectQuery, обработчик формул должен будет взять кеш данных и попытаться соединить их, чтобы предоставить результаты конечному пользователю.

Методы оптимизации запросов DAX и уроки
Производительность запросов и настройка DAX Studio
Оптимизация DAX: где найти скрытую ловушку DAX

Заключение

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

Являясь механизмом верхнего уровня в архитектуре служб анализа, механизм формул должен выполнять множество операций. Но как только вы разберетесь во всех тонкостях механизма хранения, вы сможете понять, какую операцию вставить в механизм хранения, а какую оставить в механизме формул.

Мы углубимся в механизм хранения в отдельном руководстве.

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