Поделиться через

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Снимок экрана в режиме отношений с выделенным раскрывающимся списком для изменения режима хранения.

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

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

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

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

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

Заметка

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

Ограничения на таблицы DirectQuery и таблицы Dual

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

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

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

Снимок экрана примерного представления связи для режима хранения.

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

снимок экрана: окно предупреждения, описывающее результаты изменения режима хранения на импорт.

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

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

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

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

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

Стол Режим хранения
Продажи DirectQuery
SurveyResponse Импорт
Дата Двойной
Клиент Двойной
География Двойной

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

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

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

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

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

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

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

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

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

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

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

снимок экрана с текстом запроса, который ссылается на таблицу Date.

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

снимок экрана с текстом запроса, который ссылается на таблицу Sales.

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

снимок экрана с текстом запроса, который ссылается как на таблицу Date, так и на таблицу Sales.

Заметка

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

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

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

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

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

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

снимок экрана, на котором выделен значок представления таблицы.

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

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

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

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

  • SAP HANA
  • SAP Business Warehouse

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

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

Связанное содержимое

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