DirectQuery в Power BI

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

В этой статье рассматриваются следующие вопросы:

• Power BI режимы подключения к данным и место DirectQuery в них
• Когда использовать DirectQuery, импорт, гибридные таблицы, Direct Lake или динамическое подключение
• Ограничения, последствия и рекомендации по производительности
• Рекомендации по моделированию и проектированию отчетов
• Диагностика и повышение производительности

Краткое руководство по принятию решений

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

режимы подключения к данным Power BI

Power BI подключается ко многим источникам данных:

• Веб-службы, такие как Salesforce и Dynamics 365
• Базы данных, такие как SQL Server, PostgreSQL, MySQL, Oracle, Snowflake и Amazon Redshift
• Файлы (Excel, CSV, JSON, Parquet)
• Подсистемы больших данных и аналитики, такие как Spark и Databricks
• Другие источники, такие как веб-сайты и Microsoft Exchange

Импортируйте данные из этих источников. Некоторые также поддерживают DirectQuery. См. актуализированный список в разделе источники данных Power BI. Источники с поддержкой DirectQuery обычно обеспечивают производительность интерактивных агрегатных запросов.

Используйте импорт по умолчанию. Он использует высокопроизводительный модуль Power BI в памяти и предоставляет самый богатый набор функций. Переход за пределы импорта только в том случае, если требуются определенные ограничения (задержка, размер, управление, безопасность или архитектура).

Современные усовершенствования — гибридные таблицы, Direct Lake, автоматическая агрегация, составные модели и добавочное обновление— сокращают частоту использования чистого DirectQuery.

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

Импорт соединений

При импорте данных:

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

Подключения DirectQuery

При использовании DirectQuery:

• Получение данных устанавливает подключение к поддерживаемму источнику. Для реляционных источников можно по-прежнему выбирать таблицы или представления; для многомерных источников (например, SAP BW) вы выбираете исходную модель.
• Во время загрузки данные не импортируются. Каждый визуальный элемент активирует один или несколько запросов к базовому источнику.
• Задержка визуального обновления полностью зависит от базовой производительности источника (и нагрузки на сеть или шлюз, если это применимо).
• Изменения в исходных данных отображаются только после выполнения повторных запросов (навигация, срез или фильтрация изменений, обновление вручную).
• Публикация создает определение семантической модели (схема и метаданные) без импортированных данных.
• Отчеты в службе запрашивают источник. Для локальных источников может потребоваться шлюз.
• Плитки на панели мониторинга, построенные на моделях DirectQuery, обновляются по расписанию для кэширования результатов и обеспечения быстрого доступа к панели мониторинга.
• Плитки панели мониторинга отображают итоги последнего запланированного обновления, если плитки не были обновлены вручную.

Активные подключения

Живая связь подключает Power BI непосредственно к существующей семантической модели (например, моделям Analysis Services или другой опубликованной семантической модели Power BI). Он похож на DirectQuery (без импортированных данных), но семантика (например, принудительное применение ролей) обрабатывается вышестоящей моделью. При подключении в режиме реального времени:

• Появится полный список полей внешней модели — это не определение запроса Power Query.
• Живые подключения всегда передают удостоверение пользователя в Analysis Services или семантическую модель Power BI для проверки безопасности.
• Некоторые действия моделирования (например, добавление вычисляемых таблиц) недоступны, так как модель является внешней.

Где DirectQuery подходит среди новых вариантов

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

• Гибридные таблицы позволяют смешивать секции в памяти и DirectQuery в одной таблице (последние и исторические).
• Direct Lake (Fabric) позволяет практически в режиме реального времени получать доступ к таблицам Lakehouse без традиционных затрат на обновление.
• Автоматические агрегаты и мануальные таблицы агрегирования ускоряют выполнение частых запросов.
• Добавочное обновление с режимом реального времени позволяет последнему окну времени DirectQuery создавать источник, пока старые данные остаются импортированными.

Оцените эти параметры перед внедрением полностью модели DirectQuery.

Для рабочих нагрузок временных рядов с высоким объемом данных в режиме реального времени на Microsoft Fabric распространенным подходом является использование DirectQuery к базе данных KQL Fabric (Реальное Время Интеллекта) в сочетании с агрегатами на стороне источника и динамическими параметрами M. См. рекомендации по источникам на основе Kusto для информации об этой рабочей нагрузке.

Варианты использования DirectQuery

DirectQuery является наиболее полезным, когда:

• Слишком часто изменяются данные для импорта (даже при добавочном обновлении и максимальной частоте запланированного обновления), и требуется низкая задержка видимости.
• Ограничения объема данных или управления данными делают полную интеграцию непрактичной.
• Обеспечение безопасности источника (детальные правила на уровне строк) должно оставаться авторитетным через сквозную передачу.
• Суверенитет данных или нормативные правила ограничивают сохраняемые полные копии.
• Источник является многомерным или ориентированным на измерения (например, SAP BW), а определенные серверные измерения должны быть определены для каждого визуального представления.

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

Импортированные модели Pro могут запланировать до 8 обновлений в день (плюс триггеры по запросу). Премиум и PPU поддерживают до 48 запланированных обновлений в день, а также добавочное обновление и DirectQuery в режиме реального времени для последней секции (гибридной). Если требуемая задержка по-прежнему недостижима или полный импорт невозможен, используйте DirectQuery, гибридные таблицы или Direct Lake. Панели мониторинга DirectQuery могут обновлять плитки так же часто, как каждые 15 минут.

Большие данные

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

• Импортируйте только агрегированные или отфильтрованные подмножества.
• Использование добавочного обновления и агрегаций.
• Использование гибридных таблиц или Direct Lake для последних и высокозначных сегментов.

См. раздел Большие семантические модели в Power BI Premium для управления объемными данными в памяти.

Безопасность, обеспеченная источником

Импорт использует учетные данные Power BI, а также необязательную безопасность на уровне строк (RLS), заданную в семантической модели. Возможность DirectQuery передавать удостоверение пользователя (SSO) позволяет источнику использовать собственные правила безопасности, при наличии поддержки. См. в разделе Обзор единого входа (SSO) для локальных шлюзов данных в Power BI.

Ограничения на суверенитет данных

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

Источник с мерами, определенными сервером

Некоторые системы (например, SAP BW) содержат семантическую логику (метрики и иерархии), которые обрабатываются во время запроса. DirectQuery позволяет разрешение на уровне отдельных визуальных элементов. См. статью DirectQuery и SAP BW и DirectQuery и SAP HANA.

Рекомендации по источнику (включая PostgreSQL и MySQL)

Поведение и производительность отличаются в зависимости от движка.

• PostgreSQL: Идентификаторы в кавычках чувствительны к регистру. Убедитесь, что соответствующие индексы b-дерева для столбцов соединения и фильтрации. Избегайте функций, которые прерывают свертывание запросов на ранних стадиях. Проверьте наличие неявных приведений при работе с текстовыми и числовыми соединениями.
• MySQL: Используйте согласованные параметры сортировки и режимы SQL. Создайте составные индексы для общих шаблонов фильтров и соединений. Большие TEXT столбцы могут уменьшить складывание или вызвать необходимость постобработки.
• Snowflake, BigQuery и Databricks: Эластичное масштабирование повышает параллелизм, но задержка холодного запуска может повлиять на первый запрос. Отправить ping-сообщения для разогрева или запланировать периодическую активность.
• Azure Synapse, SQL и Fabric Warehouse: Индексы Columnstore и кэширование результирующих наборов обеспечивают сильное ускорение. Соедините их с автоматическими объединениями.
• Источники на основе Kusto (базы данных Azure Data Explorer и Fabric KQL): оптимизация проекции имеет значение. Выберите только необходимые столбцы и примените фильтры заранее. Для телеметрии временных рядов с большим объемом следует использовать агрегирование на стороне источника, а не группировку на стороне клиента: отправляйте make-series, summarize и series_decompose_anomalies в движок KQL и возвращайте агрегированные результаты визуальным элементам. Убедитесь, что шаги Power Query преобразуются в родной KQL, чтобы суммированные результаты, а не сырые данные, возвращались в Power BI.
• SAP BW и SAP HANA: Разрешение метрик и семантика иерархий формируют шаблоны запросов. Избегайте наложения преобразований, которые блокируют свертку.

Подтвердите свертывание запросов (выберите View Native Query в Редактор Power Query), чтобы преобразования были отправлены вниз.

Ограничения DirectQuery

Использование DirectQuery влияет на согласованность, производительность, безопасность, преобразования, моделирование и отчеты.

Общие последствия

Следующие общие последствия применяются при использовании DirectQuery в Power BI:

• Обновите, чтобы просмотреть последние данные. Кэши (визуальный, тайловый, результат) позволяют визуальным элементам отображать предыдущие результаты до их обновления. Выберите "Обновить" , чтобы принудительно выполнить запрос всех визуальных элементов на странице.
• Визуальные элементы не всегда согласованы во времени. Различные визуальные элементы (или внутренние запросы в одном визуальном элементе) могут выполняться немного иначе. Обновите страницу или создайте агрегированные моментальные снимки, если требуется строгая точность во времени.
• Для изменений схемы требуется обновление Power BI Desktop. Служба не обнаруживает автоматически удаленные или переименованные столбцы. Откройте модель в Power BI Desktop и обновите её, чтобы сверить метаданные модели.
• Ограничение промежуточного результата на одну миллионную строку. Любой запрос (или промежуточная операция), возвращающий более 1000 000 строк, завершается сбоем. Премиальная емкость может увеличить это ограничение — см. Максимальное число промежуточных наборов строк.
• Изменение режима хранения ограничено. Вы не можете перевести в глобальном масштабе модель, работающую только на импорт, на DirectQuery. См. следующий раздел.

Изменение режимов хранения (импорт ↔ DirectQuery)

Вы не можете переключить всю модель импорта в DirectQuery. Вместо:

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

Влияние на производительность и нагрузку

Интерактивная производительность зависит от задержки источника и параллелизма. Старайтесь, чтобы время обновления визуального элемента было менее 5 секунд, поскольку время более 30 секунд снижает удобство использования. Каждое действие пользователя активирует запросы. Большое количество обновлений пользователей, визуальных элементов и плиток может создавать значительную нагрузку — планируйте емкость соответствующим образом.

Последствия для безопасности

Если единый вход не настроен, DirectQuery использует настроенные сохраненные учетные данные для всех зрителей. При необходимости определите RLS в семантической модели. Несколько источников в составных моделях могут перемещать данные между источниками; оценка перемещения конфиденциальных данных— см. сведения о последствиях безопасности.

Ограничения преобразования данных

Преобразование Power Query необходимо для обеспечения масштабируемой производительности. Преобразования должны быть объединены в один нативный запрос. Сложные шаги (неразложимые операции, некоторые пользовательские функции, многоэтапная процедурная логика) могут вызвать ошибки, требующие упрощения или перехода к использованию функции Импорт. Источники OLAP, такие как SAP BW, запрещают преобразования в запросах из-за того, что вся внешняя модель открыта. Вызовы хранимых процедур и общие табличные выражения (CTEs) не поддерживаются в той мере, чтобы позволить свертывание в DirectQuery.

Ограничения моделирования

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

• Отсутствие автоматической иерархии дат (создайте явную таблицу дат).
• Точность времени ограничена секундами (удаление миллисекунд в источнике).
• Вычисляемые столбцы ограничены выражениями уровня строк, которые могут быть свернуты; неподдерживаемые функции исключены из автозаполнения.
• Нет функций PATH родитель-потомок.
• Кластеризация не поддерживается.

Ограничения при создании отчетов

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

• Длинные текстовые столбцы длиннее 32 764 символов не поддерживаются.
• Фильтры мер, фильтры TopN, Median, фильтры для расширенного текста, содержащие/начинающие, срезы с множественным выбором, а также итоги и промежуточные итоги (особенно с DistinctCount) могут добавлять дополнительные запросы или снизить производительность.
• Рассмотрите возможность упрощения проектирования или отключения определенных взаимодействий.

Пример (фильтр измерений):

Рекомендации DirectQuery

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

Производительность базового источника данных

Проверка базовых интерактивных запросов. Если они медленно, проверьте запросы с помощью Анализатор производительности и оптимизируйте исходную схему (индексы, статистику и columnstore, где это применимо). Предпочитайте целые ключи для соединений.

Проектирование модели

• Держите шаги Power Query простыми и сворачиваемыми. Часто используйте функцию «Просмотр собственного запроса».
• Начните с простых мер , а затем выполните итерацию.
• Избегайте соединения в столбцах вычисляемых выражений— материализуйтесь в источнике при необходимости.
• Избегайте присоединений uniqueidentifier где приведение типов разрушает использование индекса; материализуйте альтернативные типы ключей.
• Скрыть суррогатные или системные ключи; при необходимости создайте видимые псевдонимы для столбцов.
• Просмотрите вычисляемые таблицы и столбцы, в которых могут создаваться несворачиваемые выражения.
• Ограничение двунаправленных фильтров только в необходимых случаях. Проверьте влияние производительности.
• Рассмотрите возможность обеспечения целостности ссылок для INNER JOIN обеспечения использования.
• Избегайте фильтров относительных дат в Power Query. Вместо этого реализуйте относительную логику в модели или уровне отчетов.

Пример фильтрации:

Результирующий собственный запрос использует фиксированную литеральную дату.

Проектирование отчетов

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

• Используйте параметры сокращения запросов (используйте кнопку "Применить" для срезов и фильтров, а также отключите перекрестное выделение, когда задержка повредит интерфейсу).

  

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

• Ограничение визуальных элементов на страницу , чтобы свести к минимуму параллельные и сериализованные запросы.

• Отключите ненужные взаимодействия (перекрестная фильтрация или выделение), если они активируют дорогостоящие исходные запросы.

  

Максимальное число соединений

Настройте параллелизм DirectQuery (по умолчанию 10) в Файл > Параметры и настройки > Параметры > DirectQuery для текущего файла.

Скриншот настройки максимальных подключений DirectQuery для каждого источника данных в параметрах Power BI Desktop.

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

Функции устранения рисков производительности

Используйте эти функции для повышения производительности DirectQuery:

• Автоматические агрегации и таблицы агрегации вручную: Кэширование данных для снижения количества исходных запросов.
• Гибридные таблицы: Сохраняйте последние данные через DirectQuery, исторические данные с помощью импорта.
• Проектирование мер с поддержкой агрегирования: Убедитесь, что DAX оценивается на уровне агрегирования, когда это возможно.
• Параметры Dynamic M: Предварительное добавление выбора пользователей в исходные предикаты.
• Кэширование запросов и результатов (параметры емкости): Повторное использование последних результирующих наборов для повторяющихся визуальных элементов.
• Режим двойного хранилища для таблиц общих измерений: Уменьшение повторяющихся проверок удаленных измерений.

DirectQuery в службе Power BI

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

Производительность в службе зависит от:

• Число одновременных пользователей
• Сложность и количество визуальных элементов на страницу
• Наличие безопасности на уровне строк (может уменьшить повторное использование кэша)
• Расписания обновления плиток

Отчет о поведении в службе Power BI

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

Нюансы возможностей:

• Краткие сведения: Не поддерживается для семантических моделей DirectQuery.
• Explore в Excel / Анализ в Excel: Поддерживается, но может казаться медленнее. Рассмотрите возможность использования режима импорта или агрегаций для интенсивной работы с Excel.
• Иерархии в Excel: Некоторые иерархии семантической модели DirectQuery отображаются в Excel не так, как предполагалось.

Обновление панели мониторинга

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

Истечение времени выполнения запроса

Служба применяет 4-минутное время ожидания для каждого запроса. Визуалы, превышающие лимит, завершаются с ошибкой тайм-аута. Прежде чем выбрать DirectQuery, убедитесь, что базовые источники обеспечивают интерактивную производительность.

Диагностика производительности

Сначала диагностировать производительность в Power BI Desktop.

Используйте анализатор производительности для изоляции медленных визуальных элементов. Сосредоточьтесь на одном проблемном визуальном элементе за раз.

Использование профилировщика SQL Server для просмотра запросов

Power BI Desktop записывает трассировки сеансов, в том числе DirectQuery SQL для некоторых источников, в файл FlightRecorderCurrent.trc в папке AnalysisServicesWorkspaces.

Чтобы найти трассировку, выполните следующие действия.

1. В Power BI Desktop выберите Файл > Параметры и настройки > Параметры > Диагностика.

2. Выберите "Открыть папку аварийного дампа и трассировки".

   

3. Перейдите на один уровень в AnalysisServicesWorkspaces, откройте активную папку рабочей области, а затем Data и найдите FlightRecorderCurrent.trc.

4. В SQL Server Profiler откройте файл: File > Open > Trace File.

Профилировщик отображает сгруппированные события:

Столбцы событий:

• TextData: DAX (для начала и окончания запроса) или собственного SQL (для DirectQuery Begin/End).
• Длительность (мс) и EndTime помогают определить медленные этапы.
• ActivityID группирует связанные события.

Руководство по сбору:

• Держите сеансы короткими (≈10 секунд целевых действий).
• Повторно откройте файл трассировки, чтобы просмотреть только что промытые события.
• Избегайте нескольких одновременных экземпляров приложения Desktop, чтобы уменьшить путаницу.

Общие сведения о формате запросов

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

Пример логики запроса:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

Результирующее изображение:

Созданный SQL с подзапросами.

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

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

• Используйте DirectQuery в Power BI Desktop
• DirectQuery и SAP HANA
• DirectQuery и SAP BW
• Используйте DirectQuery для семантических моделей Power BI и служб Analysis Services
• Агрегации в Power BI
• Анализатор производительности
• Составные модели
• Обзор безопасности на уровне строк
• Единый вход (SSO)