Управление режимом хранения в Power BI Desktop

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

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

• Производительность запросов. При взаимодействии пользователей с визуальными элементами в отчетах Power BI запросы выражений анализа данных (DAX) отправляются в семантику модели. Кэширование данных в память путем правильного задания режима хранения может повысить производительность запросов и интерактивность отчетов.

• Большие семантические модели: таблицы, которые не кэшируются, не используют память для кэширования. Вы можете включить интерактивный анализ над большими семантические модели, которые слишком большие или дорогостоящие, чтобы полностью кэшировать в память. Вы можете выбрать, какие таблицы стоит кэширование, и которые не нужны.

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

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

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

Параметр режима хранения в Power BI Desktop является одним из трех связанных функций:

• Составные модели: позволяет отчету иметь два или более подключений к данным, включая подключения DirectQuery или Import, в любом сочетании. Дополнительные сведения см. в статье "Использование составных моделей в Power BI Desktop".

• Связи "многие ко многим": с составными моделями можно установить связи "многие ко многим" между таблицами . В связи "многие ко многим" требования удаляются для уникальных значений в таблицах. Кроме того, он удаляет предыдущие обходные пути, такие как введение новых таблиц только для установления связей. Дополнительные сведения см. в разделе "Многие ко многим" в Power BI Desktop.

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

Использование свойства режима служба хранилища

Свойство режима служба хранилища — это свойство, которое можно задать для каждой таблицы в модели и определяет, как Power BI кэширует данные таблицы.

Чтобы задать свойство режима служба хранилища или просмотреть его текущий параметр:

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

2. В области "Свойства" разверните раздел "Дополнительно" и разверните раскрывающийся список режима служба хранилища.

   

Для свойства режима служба хранилища задано одно из следующих трех значений:

• Импорт: импортированные таблицы с этим параметром кэшируются. Запросы, отправленные в семантику Power BI, возвращающие данные из таблиц импорта, могут выполняться только из кэшированных данных.

• DirectQuery: таблицы с этим параметром не кэшируются. Запросы, которые вы отправляете в семантику Power BI, например запросы DAX, и возвращающие данные из таблиц DirectQuery, могут выполняться только путем выполнения запросов по запросу в источник данных. Запросы, которые вы отправляете в источник данных, используют язык запросов для этого источника данных, например SQL.

• Двойное: таблицы с этим параметром могут выступать как кэшированные, так и не кэшированные в зависимости от контекста запроса, отправленного в семантику Power BI. В некоторых случаях выполняется выполнение запросов из кэшированных данных. В других случаях выполнение запросов выполняется путем выполнения запроса по запросу к источнику данных.

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

Примечание.

Вы можете использовать режим двойного хранилища как в Power BI Desktop, так и в служба Power BI.

Ограничения на таблицы DirectQuery и Двойные таблицы

Две таблицы имеют одинаковые функциональные ограничения, что и таблицы DirectQuery. Эти ограничения включают ограниченные преобразования M и ограниченные функции DAX в вычисляемых столбцах. Дополнительные сведения см. в разделе об ограничениях DirectQuery.

Распространение двойного параметра

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

Предположим, что все таблицы в этой модели изначально заданы как DirectQuery. Если вы измените режимслужба хранилища таблицы SurveyResponse на import, отобразится следующее предупреждение:

Таблицы измерений (Customer, Geography и Date) можно задать для двойного размера, чтобы уменьшить количество ограниченных связей в семантической модели и повысить производительность. Ограниченные отношения обычно включают по крайней мере одну таблицу DirectQuery, в которой логика соединения не может быть отправлена в исходные системы. Так как двойные таблицы могут выступать в качестве таблиц DirectQuery или Import, эта ситуация избегается.

Логика распространения предназначена для работы с моделями, содержащими множество таблиц. Предположим, что у вас есть модель с 50 таблицами и необходимо кэшировать только определенные таблицы фактов (транзакционных). Логика в Power BI Desktop вычисляет минимальный набор таблиц измерений, которые должны иметь значение "Двойной", поэтому вам не нужно.

Логика распространения проходит только к одной стороне связей "один ко многим".

Пример использования режима служба хранилища

Представьте, что применяются следующие параметры свойства режима хранения:

Таблица	Режим хранения
Продажи	DirectQuery
SurveyResponse	Import
Date	Двойной
Customer	Двойной
Географический регион	Двойной

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

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

• Power BI Desktop не кэширует таблицу Sales . Power BI Desktop предоставляет следующие результаты, не кэширование этой таблицы:

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

• Запросы отчетов, основанные на таблице SurveyResponse , возвращаются из кэша в памяти и поэтому относительно быстры.

Запросы, которые ударили или пропустили кэш

При подключении SQL Profiler к порту диагностика для Power BI Desktop можно увидеть, какие запросы попали в кэш в памяти или пропустили, выполнив трассировку, основанную на следующих событиях:

• Запросы событий\начало запроса
• Начало запроса "Обработка запросов\Vertipaq SE Query"
• Обработка запросов\Начало DirectQuery

Для каждого события "Начало запроса" проверка другие события с одинаковым идентификатором activityID. Например, если не существует события DirectQuery Begin , но есть событие Vertipaq SE Query Begin , запрос отвечает из кэша.

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

Следующий запрос продолжается из предыдущей таблицы. Он относится только к столбцу из таблицы Date , которая находится в двойном режиме. Поэтому запрос должен попасть в кэш:

Следующий запрос ссылается только на столбец из таблицы Sales , которая находится в режиме DirectQuery . Поэтому он не должен попасть в кэш:

Следующий запрос интересен, так как он объединяет оба столбца. Этот запрос не попадает в кэш. Изначально он может получить значения CalendarYear из кэша и SalesAmount из источника, а затем объединить результаты, но этот подход менее эффективен, чем отправка операции SUM/GROUP BY в исходную систему. Если операция отправляется в источник, число возвращаемых строк, скорее всего, будет гораздо меньше:

Примечание.

Это поведение отличается от связей "многие ко многим" в Power BI Desktop при объединении кэшированных и не кэшированных таблиц.

Кэши должны храниться в синхронизации

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

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

Представление данных

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

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

Рекомендации и ограничения

Существует несколько ограничений для текущего выпуска режима хранения и его корреляции с составными моделями.

Следующие источники динамического подключения (многомерные) нельзя использовать с составными моделями:

• SAP HANA
• Хранилище SAP для бизнеса

При подключении к этим многомерным источникам с помощью DirectQuery невозможно подключиться к другому источнику DirectQuery или объединить его с импортированными данными.

Существующие ограничения использования DirectQuery по-прежнему применяются при использовании составных моделей. Многие из этих ограничений теперь зависят от режима хранения таблицы. Например, вычисляемый столбец импортированной таблицы может ссылаться на другие таблицы, но вычисляемый столбец таблицы DirectQuery по-прежнему ограничен ссылкой только на столбцы в той же таблице. Другие ограничения применяются к модели в целом, если какая-либо из таблиц в модели — DirectQuery.

Связанный контент

Дополнительные сведения о составных моделях и DirectQuery см. в следующих статьях:

• Работа с составными моделями в Power BI Desktop
• Применение связей "многие ко многим" в Power BI Desktop
• DirectQuery в Power BI
• Источники данных Power BI