Режим хранения таблиц в семантических моделях Power BI

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

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

Режимы хранения таблиц

Режим хранения таблиц	Когда доступно	Преимущества	Заметка
Импорт	В Power BI Desktop и веб-моделировании Power BI, для почти всех источников данных, при выборе команды "Получить данные" используйте Power Query.	Моментальный снимок данных хранится в собственном хранилище для быстрого загрузки визуальных элементов в отчетах.	Чтобы получить последние данные из источника данных, обновите семантику модели или таблицы.
Direct Lake на OneLake	В Power BI Desktop и веб-моделировании Power BI для источников данных Microsoft Fabric при выборе каталога OneLake.	Данные сканируются из разностных таблиц Microsoft OneLake для быстрого загрузки визуальных элементов в отчетах.	По умолчанию загружаются последние данные. Чтобы получить доступ к последним данным, обновив его вручную, отключите автоматическую синхронизацию на странице параметров запланированного обновления. Обновление также называется рефреймированием для Direct Lake. Дополнительные сведения о Direct Lake см. в обзоре Direct Lake.
Direct Lake в SQL	В конечных точках аналитики SQL элементов Fabric при выборе новой семантической модели.	Данные сканируются из разностных таблиц OneLake для быстрой загрузки в отчетах.	В этом режиме Power BI использует режим хранения DirectQuery для доступа к данным в следующих случаях: Используется представление. — Включен подробный доступ к SQL. - Достигается Direct Lake guardrail.
DirectQuery	В Power BI Desktop для некоторых источников данных, таких как базы данных SQL, когда вы выбираете Получить данные и используете Power Query.	Данные запрашиваются из источника данных при загрузке визуальных элементов и не хранятся в семантической модели.	Запрос — это перевод из запроса выражений анализа данных Power BI (DAX), используемых визуальными элементами, в собственный язык запросов источника данных, например SQL-запрос.
DirectQuery в семантических моделях Power BI	В Power BI Desktop при подключении к семантической модели Power BI и выборе параметра "Внести изменения в эту модель" или при добавлении таблицы Import или DirectQuery.	Запросы DAX из новой модели выполняются в исходной модели и могут использовать меры из обоих типов. Некоторые свойства столбцов удаленной модели можно переопределить в новой модели. Эта настройка включает строки форматирования и отображаемые имена.	Используйте этот режим хранения, если необходимо внести небольшое изменение в существующую семантику для конкретного отчета.
Двойной	В Power BI Desktop, при преобразовании таблицы DirectQuery в импортный режим. Откроется диалоговое окно с параметрами преобразования оставшихся таблиц DirectQuery в двойной режим.	Связи между Таблицами DirectQuery и Import ограничены. Переключение с DirectQuery на двойной режим может помочь сохранить эти отношения регулярными.
Гибридный	В сценариях добавочного обновления импортной таблицы. Последняя секция таблицы может находиться в режиме DirectQuery, чтобы обеспечить доступность последних данных между обновлениями импорта.	Создание секций и управление ими автоматизировано для уменьшения объема данных, которые необходимо обновить.	Дополнительные сведения см. в разделе "Настройка добавочного обновления" и данных в режиме реального времени для семантических моделей Power BI.

Заметка

Режим динамического подключения используется в следующих случаях:

Подключение к семантической модели Power BI в Power BI Desktop для создания отчета
Создание отчета из семантической модели Power BI в Интернете

Отчет Live Connect не имеет локальной семантической модели и иногда называется тонким отчетом. Удаленная семантическая модель Power BI может использовать любой режим хранения таблиц. Как автор отчета, вы можете видеть модель в представлении Модели, но доступна только ограниченная информация. Создаваемые меры хранятся в отчете.

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

Просмотр режима хранения таблицы

Каждая таблица имеет Storage mode свойство. Чтобы просмотреть режим хранения таблицы, сделайте следующее:

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

Для большинства таблиц можно задать режим хранения только при добавлении таблицы. Режим хранения можно изменить только в том случае, если таблица находится в режиме DirectQuery или Direct Lake в режиме OneLake при создании:

Вы можете изменить таблицу DirectQuery на таблицу Import или Dual. После задания этого свойства нельзя задать режим обратно в DirectQuery. Исключения — это веб-моделирование Power BI и динамическое редактирование в Power BI Desktop. В этих средах есть управление версиями, которое можно использовать для отмены измененного режима хранения.
Вы можете преобразовать таблицы Direct Lake на OneLake в таблицы импорта с помощью Semantic Link Labs в записных книжках Fabric.

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

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

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

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

Снимок экрана: представление модели Power BI Desktop, в котором показаны связи между пятью таблицами: Date, Sales, SurveyResponse, Customer и Geography.

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

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

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

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

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

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

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

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

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

Power BI Desktop кэширует таблицы измерений, date, Customer и Geography, чтобы сократить время загрузки начальных отчетов при получении значений среза для отображения.
Power BI Desktop не кэширует таблицу продаж.
- Не кэширование этой таблицы помогает улучшить время обновления данных и сократить потребление памяти.
- Запросы отчетов, основанные на таблице Sales , выполняются в режиме DirectQuery. Эти запросы могут занять больше времени, чем запросы импорта. Но результаты запросов DirectQuery ближе к результатам в режиме реального времени, так как задержка кэширования не появилась.
Запросы отчетов, основанные на таблице SurveyResponse , относительно быстры, так как они возвращаются из кэша в памяти.

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

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

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

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

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

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

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

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

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

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

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

Заметка

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

Поддерживайте кэши в синхронизированном состоянии

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

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

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

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

Снимок экрана: представление таблицы в Power BI Desktop. Выделен значок представления таблицы, и в таблице отображаются несколько строк данных.

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-10-17