Механизм хранения — его роль в оптимизации запросов DAX в LuckyTemplates

В этом уроке мы рассмотрим второй механизм внутри служб анализа — механизм хранения.

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

Основная цель механизма хранения — работать напрямую с базой данных.

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

Механизм хранения бывает двух типов — режим импорта и DirectQuery . Вы можете смешивать и сопоставлять оба типа в одной и той же модели данных, чтобы создать составную модель.

Оглавление

• Работа с режимом импорта в механизме хранения
• Работа с DirectQuery в механизме хранения
• Работа с составными моделями
• Другие важные моменты о механизме хранения
• Работа над сложными запросами
• Заключение

Работа с режимом импорта в механизме хранения

Во-первых, давайте поговорим о режиме импорта. Это также более известно как Vertipaq, но его также называют xVelocity или столбцовой базой данных в памяти.

Есть четыре важных момента, которые необходимо понять о том, как работает режим импорта.

Во-первых, Vertipaq создает копию данных прямо из источника данных и сохраняет ее в оперативной памяти в сжатом формате .

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

Допустим, у вас есть обновленная на прошлой неделе таблица «Товары» в режиме импорта. Что касается таблицы Sales, вы решили пройти через DirectQuery из-за ее размера. Давайте также предположим, что вы создаете отчет на основе обеих таблиц, в которые вы вводите столбец «Бренд» и создаете показатель «Общий объем продаж» для той же таблицы «Продажи». Вы также хотите визуализировать сумму продаж на основе бренда.

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

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

Наконец, механизм хранения представляет собой высокооптимизированную базу данных из-за столбчатой ​​структуры Vertipaq . Это означает, что все данные хранятся столбец за столбцом, а не строка за строкой. Благодаря этой структуре Vertipaq всегда будет быстрее, чем подключение DirectQuery, даже если вы создаете индексы в своей реляционной модели данных.

Работа с DirectQuery в механизме хранения

Следующим вариантом, который у нас есть в службах анализа LuckyTemplates, является DirectQuery. Если вы используете подключение DirectQuery, службы анализа действуют только как транзитные для запросов, отправляемых обработчиком формул.

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

Если запрос использует DirectQuery, ожидайте, что он будет постоянно обновляться. Не нужно беспокоиться о том, когда вы в последний раз обновляли данные.

Процесс оптимизации кода DAX и модели данных также будет зависеть от того, как была создана реляционная база данных. Если у вас есть индексы в столбцах, ваши запросы всегда будут оптимизированы. Но если ваша база данных не оптимизирована с точки зрения создания отчетов с помощью служб анализа или LuckyTemplates, вы можете столкнуться с рядом проблем с производительностью. Так что будьте преднамеренны в создании ваших баз данных для разработки отчетов.

Работа с составными моделями

Третий вариант — создать составную модель, чтобы одна таблица была в режиме импорта, а другая — в DirectQuery.

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

Итак, допустим, вы пытаетесь визуализировать объем продаж по бренду продукта в своем отчете. Механизм формулы отправит запрос в Vertipaq, где он получит продукт, марку и ключ продукта. Затем из DirectQuery он попытается получить продажи, чистую цену, количество продаж и ключ продукта продаж.

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

Другие важные моменты о механизме хранения

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

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

Язык xmSQL чем-то похож на SQL, но не полностью. Мы подробно поговорим о xmSWL, когда будем говорить о планах запросов в другом учебнике.

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

Допустим, у вас есть таблица в LuckyTemplates с 12 миллионами строк. Затем эта таблица будет разделена на 12 сегментов, поскольку и в Power Pivot, и в LuckyTemplates каждый сегмент соответствует 1 миллиону строк. Это отличается от сервисов анализа в целом, где один сегмент вмещает 8 миллионов строк.

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

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

Работа над сложными запросами

Ранее я упоминал, что режим импорта поддерживает только основные операции, такие как MIN, MAX, SUM, COUNT и GROUPBY. Так что же произойдет, если вы будете работать над более сложными запросами?

Допустим, вы решили использовать оператор IF в контексте строки или вложенную итерацию, такую ​​как SUMX, для таблиц Products и Sales.

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

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

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

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

DAX для LuckyTemplates: оптимизация с помощью обработчиков формул в DAX Studio
Методы оптимизации запросов DAX и уроки
Производительность запросов и настройка DAX Studio

Заключение

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

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

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