Агрегированная таблица может быть слоем поверх исходной таблицы DirectQuery. В этой таблице должны быть установлены правильные отношения с другими таблицами, а также правильная конфигурация режима хранения. Конфигурация режима хранения (Storage Mode) составной модели, по сути, является важной конфигурацией и важной частью настройки агрегации. Конфигурация режима хранения данных импорта и DirectQuery не требует пояснений, но что можно сказать о режиме двойного хранения? Мы подробно объясним, что такое режим Dual. Давайте заглянем. Это третья статья об агрегации, в первой статье вы узнали, что такое агрегация, а во второй статье вы узнали, как создать агрегированную таблицу. В этой статье рассказывается о следующем шаге, который представляет собой конфигурацию режима хранения в модели.

Пример модели

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

Sales Agg - это агрегированная таблица, созданная на предыдущем шаге, а FactInternetSales - это таблица с источником DirectQuery. Все таблицы в этой модели (кроме Sales Agg) являются таблицами с поддержкой DirectQuery.

Что такое Storage Mode

Режим хранения в таблицах Power BI определяет, где хранятся данные этой таблицы и как запросы будут отправляться в источник данных. Режим хранения таблицы можно найти либо путем наведения мыши на нее в Power BI Desktop в разделе полей;

Или щелкнув правой кнопкой мыши по таблице и выбрав свойства:

В области свойств вы можете увидеть раскрывающийся список параметров режима хранения:

• Import
• DirectQuery
• Dual

Import

Import и DirectQuery являются очевидными опциями в приведенном выше списке. Например, если режим хранения в таблице - Import, то это означает, что данные этой таблицы будут храниться в памяти в памяти сервера Power BI (машина, на которой запущен движок Power BI), и каждый запрос к данным будет запрос к структуре внутри памяти, а не к источнику данных.

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

DirectQuery

Таблицы с режимом хранения DirectQuery будут хранить данные в источнике данных. В нашем примере набора данных FactInternetSales хранит данные в источнике данных SQL Server. Если у нас есть визуализация из таблицы с этим режимом хранения, Power BI отправит запрос T-SQL в источник данных и вернет результат. Например, ниже визуализация в отчете Power BI - это только визуальная карта в поле SalesAmount в FactInternetSales;

Поскольку эта таблица имеет режим хранения DirectQuery, если мы одновременно запускаем SQL Profiler (для захвата запросов, отправленных источнику данных), то запрос, полученный в базу данных SQL Server, будет следующим:

Запрос из нескольких таблиц DirectQuery

Если у нас есть несколько таблиц с режимом хранения в режиме DirectQuery, результатом будет запрос, отправленный источнику данных для этой комбинации. Здесь у нас есть диаграмма столбцов SalesAmount из FactInternetSales (DirectQuery) и CalendarYear из DimDate (DirectQuery):

И вот запрос, посылаемый для этого:

Внимание: объединение DirectQuery и Import

Пока что с приведенными выше примерами все было ожидаемо. Ничего странного не произошло. Но странное начнется, если вы объедините поля из таблиц источников DirectQuery с таблицами режимов хранения Import. В качестве примера: таблица Sales Agg - таблица Import. Вся цель создания этой таблицы заключалась в том, чтобы быстрее запросить запрос из структуры в памяти. Если вы создаете визуал, который просто содержит что-то из таблицы Sales Agg, запрос не будет отправляться в источник данных. Все это происходит в памяти. Как и ожидалось, конечно.

И SQL Profiler не улавливает никаких запросов, отправленных источнику данных;

Однако, поведение отличается. Если у нас есть визуальные данные из таблицы Sales Agg и таблица DirectQuery, такая как DimDate;

Однако, на этот раз мы видим запрос T-SQL, отслеживаемый в SQL Profiler, и он запрашивает DimDate в базе данных SQL Server.

Это не то, что мы на самом деле ожидаем увидеть. Вся цель Sales Agg table - ускорить процесс из режима DirectQuery, но мы все еще запрашиваем DimDate из базы данных. Итак, каково решение? Можем ли мы изменить режим хранения DimDate на Import? Если мы это сделаем, то как насчет связи между DimDate и FactInternetSales? Мы хотим, чтобы эта связь работала как DirectQuery, конечно.

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

Режим хранения Dual

Режим хранения Dual построен для покрытия описанного выше сценария. В режиме Dual одна таблица может действовать как DirectQuery или Import, соответственно отношениям с другими таблицами. Режим хранения Dual - секретная смесь режима Composite и агрегации в Power BI. Посмотрим, как работает этот режим.

Если мы изменим режим хранения DimDate на Import, мы получим проблему отправки запроса в источник данных, когда мы запрашиваем FactInternetSales. Если мы изменим режим хранения DimDate на DirectQuery, то даже для Sales Agg мы по-прежнему отправляем запрос в источник данных. Решение состоит в том, чтобы изменить режим хранения общих таблиц измерений на Dual.

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

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

Каким будет влияние этого в отчетности? Тот же визуал, что и раньше, в предыдущем примере, теперь работает через движок в памяти:

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

Поскольку эта таблица связана с таблицей Import (Sales Agg), и в результате режим Dual storage действует как хранилище таблицы Import, все будет запрашиваться из памяти.

Если у вас есть таблица режимов Dual storage, используемая при визуализации рядом с таблицей DirectQuery, аналогичная следующей:

Эта визуализация отправит запрос к источнику данных, как вы можете видеть на следующем треке SQL Profiler:

В этом случае режим Dual storage действует как DirectQuery, потому что он идет с подключением к таблице источников DirectQuery;

Итак, надеемся, вы теперь поняли, почему этот режим называется Dual. Иногда он действует как  Import, а иногда, как и DirectQuery, в зависимости от таблицы, которая сочетается с визуализацией.

Это слишком технично, что мне делать для настройки для агрегации?

Ну, это был длинный пост, и описание было довольно техническим. Вы можете сказать: “Меня не интересуют детали, просто скажите мне, как заставить агрегации работать?” Ответ довольно прост: все таблицы, которые связаны с Sales Agg (наша таблица агрегации Import), и FactInternetSales (наша большая таблица фактов DirectQuery), должны быть установлены в режим хранения Dual. Таким образом, они могут действовать в обоих направлениях, в зависимости от ситуации, в которой они используются.

Все таблицы, связанные как с таблицей Import (агрегацией), так и с таблицей DirectQuery (таблица больших фактов), должны быть установлены как режим хранения Dual.

В нашем примере мы должны установить режим Dual: DimDate, DimProductSubcategory, DimCustomer. Однако, когда вы применяете это в DimCustomer, вы заметите, что появляется сообщение о том, что DimGeography будет также задан как режим хранения. Это верно. Другие таблицы, связанные с этим через Many to One, также должны быть Dual.

Тот же процесс будет происходить с DimProductSubcategory и DimProductCategory. В нашей примерной диаграмме и модели все таблицы, выбранные ниже, являются Dual Storage Mode;

Теперь ваша модель готова выполнить Шаг 3: Настройка агрегации. Следите за появлением этой статьи.

No Comments