Использование DirectQuery в Power BI

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

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

Следуйте рекомендациям по использованию импорта и DirectQuery.

  • Импортируйте данные в Power BI всякий раз, когда это возможно. Можно использовать преимущества высокоэффективного обработчика запросов в Power BI, а также получить широкие возможности взаимодействия и расширенную функциональность.
  • Если же импорт не может удовлетворить ваши цели в полной мере, используйте DirectQuery. Например, если данные часто меняются, а отчеты должны отображать последние данные, лучше выбрать DirectQuery. Тем не менее использование DirectQuery целесообразно, только если базовый источник данных может обеспечить интерактивные запросы (менее чем через 5 секунд) для обычного статистического запроса, а также может обработать сформированную загрузку запросов. Кроме того, необходимо тщательно рассмотреть список ограничений по использованию DirectQuery.

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

Здесь рассматривается DirectQuery в контексте Power BI, а не служб SQL Server Analysis Services. DirectQuery также является функцией SQL Server Analysis Services. Многие сведения, описанные в этой статье, относятся к этой функции. Между ними есть важные различия. Сведения об использовании DirectQuery со службами SQL Server Analysis Services см. в разделе DirectQuery в службах SQL Server 2016 Analysis Services.

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

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

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

  • веб-службы (Salesforce, Dynamics 365 и другие);
  • базы данных (SQL Server, Access, Amazon Redshift и другие);
  • простые файлы (Excel, JSON и другие);
  • другие источники данных (Spark, веб-сайты, Microsoft Exchange и другие).

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

Службы SQL Server Analysis Services нужно рассмотреть отдельно. При подключении к службам SQL Server Analysis Services вы можете либо импортировать данные, либо использовать активное подключение. Использование активного подключения похоже на DirectQuery. Данные не импортируются, и базовый источник данных всегда запрашивается для обновления визуального элемента. Активное подключение во многом отличается, поэтому используется другой термин, активное подключение в отличие от DirectQuery.

Это три варианта подключения к данным: импорт, DirectQuery и активное подключение.

Подключения с помощью импорта

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

  • Во время первоначального получения данных набор таблиц, выбранных каждым из них, определяет запрос, возвращающий набор данных. Эти запросы можно изменять перед загрузкой данных, например для применения фильтров, статистической обработки данных или объединения разных таблиц.
  • При загрузке все данные, определенные этими запросами, будут импортированы в кэш Power BI.
  • При создании визуализации в рамках Power BI Desktop будут запрашиваться импортированные данные. Хранилище Power BI гарантирует, что запрос будет работать быстро. Все изменения визуального элемента немедленно отражаются.
  • Любые изменения базовых данных не будут отражаться в визуальных элементах. Необходимо обновить, чтобы повторно импортировать данные.
  • При публикации отчета (PBIX-файла) в службе Power BI создается набор данных, который затем отправляется в эту службу. С этим набором данных также отправляются импортируемые данные. Затем можно запланировать обновление данных, например чтобы ежедневно повторно импортировать данные. В зависимости от расположения исходного источника данных может потребоваться настроить локальный шлюз данных.
  • При открытии существующего отчета в Службе Power BI или создании нового отчета импортируемые данные запрашиваются снова, что обеспечивает интерактивность.
  • Визуальные элементы или все страницы отчета могут быть прикреплены в качестве плиток к панели мониторинга. Плитки будут автоматически обновляться при каждом обновлении базового набора данных.

Подключения с помощью DirectQuery

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

  • Во время получения данных на начальном этапе выбирается источник. Для реляционных источников набор выбранных таблиц по-прежнему определяет запрос, который логически возвращает набор данных. Для многомерных источников, таких как SAP BW, выбирается только источник.
  • Однако при загрузке данные не импортируются в хранилище Power BI. Вместо этого при создании визуализации в рамках Power BI Desktop запросы будут отправляться в базовый источник данных для получения необходимых данных. Время для обновления визуального элемента будет зависеть от производительности базового источника данных.
  • Любые изменения базовых данных отражаются в существующих визуальных элементах не сразу. Все равно необходимо выполнить обновление. Необходимые запросы отправляются для каждого визуального элемента, а визуальный элемент обновляется по мере необходимости.
  • При публикации отчета в службе Power BI также будет создан набор данных, как и при использовании режима импорта. Однако данные с этим набором данных не отправляются.
  • При открытии существующего отчета в службе Power BI или создании нового для получения необходимых данных снова запрашивается базовый источник данных. В зависимости от расположения исходного источника данных может потребоваться настроить локальный шлюз данных, как и для режима импорта в случае обновления данных.
  • Визуальные элементы или все страницы отчета могут быть прикреплены в качестве плиток к панели мониторинга. Чтобы обеспечить быстрое открытие панели мониторинга, плитки обновляются согласно расписанию (например, каждый час). Этой частотой обновления можно управлять, чтобы видеть все последние обновления данных. Таким образом, при открытии панели мониторинга плитки будут отражать данные по состоянию на момент последнего обновления, а не последние изменения базового источника. Вы можете обновить открытую панель мониторинга, чтобы убедиться, что она актуальна.

Динамические подключения

При подключении к службам SQL Server Analysis Services вы можете либо импортировать данные из выбранной модели данных, либо динамически подключиться к этой модели. Если вы используете импорт, вам нужно определить запрос применительно к этому внешнему источнику служб SQL Server Analysis Services, что обеспечит импорт данных в обычном режиме. Если вы используете динамическое подключение, запрос не определяется и внешняя модель отображается в списке полей.

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

  • наборам данных Power BI (например, при подключении к набору данных Power BI, который был ранее создан и опубликован в службе, для создания нового отчета).
  • Microsoft Dataverse.

Режим работы отчетов через службы SQL Server Analysis Services при публикации в службе Power BI аналогичен режимам работы отчетов DirectQuery в следующем.

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

Между ними есть важные различия. Например, для активных подключений идентификатор пользователя, открывающего отчет, всегда передается в базовый источник SQL Server Analysis Services.

Не будем углубляться в сравнения, а сосредоточимся только на DirectQuery.

Когда лучше использовать DirectQuery?

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

Ограничение Описание
Данные часто меняются, и требуется создание отчета в режиме реального времени Модели с импортированными данными можно обновлять не чаще, чем раз в час (чаще с подпиской Power BI Pro или Power BI Premium). Если данные постоянно меняются, а отчеты должны содержать последние данные, тогда импорта с обновлением по расписанию может быть недостаточно. Можно также выполнить потоковую передачу данных непосредственно в Power BI, хотя предусмотрены ограничения объемов данных.

И напротив, с помощью DirectQuery при открытии или обновлении отчета и панели мониторинга в источнике всегда отображаются последние данные. Кроме того, плитки панели мониторинга могут обновляться чаще (например, каждые 15 минут).
Слишком большой объем данных Если объем данных слишком большой, тогда импорт совсем нецелесообразен. И напротив, DirectQuery не требует передачи большого объема данных, так как запрашивается на месте.

Однако большие объемы данных могут также подразумевать, что производительность запросов применительно к этому базовому источнику слишком низкая (что рассматривается в разделе о влиянии DirectQuery). Не всегда нужно импортировать полные подробные данные. Вместо этого данные можно предварительно агрегировать во время импорта. Редактор Power Query упрощает предварительное агрегирование данных во время импорта. В крайнем случае можно импортировать именно объединенные данные, необходимые для каждого визуального элемента. Итак, учитывая, что для больших объемов данных лучше всего использовать DirectQuery, импорт объединенных данных — отличное решение для базового источника с низкой производительностью.
Правила безопасности определены в базовом источнике После импорта данных Power BI будет подключаться к источнику данных с помощью текущих учетных данных пользователей (из Power BI Desktop) или учетных данных, определенных как часть настройки запланированного обновления (в службе Power BI). Таким образом, при публикации и совместном использовании такого отчета с данными в режиме импорта необходимо обеспечить совместное использование отчета с пользователями, которые могут видеть те же данные, или определить безопасность на уровне строк в наборе данных.

DirectQuery позволяет передавать учетные данные средства просмотра отчетов в базовый источник и правила безопасности, которые будут применены. Единый вход поддерживается для источников данных SQL Azure, а также через шлюз управления данными на локальных серверах SQL Server. Это подробно описано в разделе Общие сведения о едином входе (SSO) для шлюзов в Power BI.
применение ограничений к независимости данных; В некоторых организациях предусмотрены политики для независимости данных, что означает, что данные нельзя передать из локальной среды организации. Импорт не рассматривается как подходящее решение. С DirectQuery же эти данные остаются в базовом источнике.

Однако даже при использовании DirectQuery некоторые кэши данных на уровне визуализации сохраняются в службе Power BI (из-за запланированного обновления плиток).
Базовый источник данных представляет собой источник OLAP, содержащий меры Если базовый источник данных содержит меры (например, SAP HANA или SAP Business Warehouse), тогда импорт данных приведет к другим проблемам. Это значит, что импортированные данные находятся на определенном уровне статистической обработки в соответствии с запросом. Например, меры TotalSales по классу, году и расположению. Затем, если созданный визуальный элемент запрашивает данные на более высоком уровне статистической обработки (например, TotalSales по году), выполняется дальнейшая статистическая обработка агрегированного значения. Агрегирование подходит для аддитивных мер (например, Sum и Min) и не подходит для неаддитивных мер (например, Average, DistinctCount).

Чтобы упростить получение правильных агрегатных данных (необходимых для конкретного визуального элемента) непосредственно из источника, было бы необходимо отправлять запросы для каждого визуального элемента, как в DirectQuery.

При подключении к SAP Business Warehouse (BW) с помощью DirectQuery можно обрабатывать меры таким образом. Сведения о SAP BW см. в разделе DirectQuery и SAP BW.

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

Поэтому в целом, учитывая текущие возможности DirectQuery в Power BI, этот режим предоставляет преимущества в следующих сценариях:

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

Сведения из списка выше связаны с использованием одной службы Power BI. Дополнительные сведения об использовании больших моделей в Power BI см. в больших наборах данных в Power BI Premium. Нет никаких ограничений на частоту обновления данных.

Ограничения использования DirectQuery

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

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

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

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

Последствия для безопасности при комбинировании источников данных

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

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

Есть также ограничения для преобразования данных, которые можно применить в Редакторе Power Query. Для режима импорта перед созданием визуальных элементов можно также легко применить расширенный набор преобразований для очистки данных или их повторного формирования (например, анализ документов JSON или сведение данных из столбца в форму с поддержкой строк). С DirectQuery используются большие ограничения для таких преобразований.

Во-первых, при подключении к источнику OLAP, например SAP Business Warehouse, определить преобразования вообще невозможно и отдельная внешняя модель берется из источника. Для реляционных источников, например SQL Server, все еще можно определить набор преобразований для каждого запроса, но эти преобразования ограничены из соображений производительности.

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

Кроме того, запрос, полученный из диалогового окна Получение данных или Редактора Power Query, будет использоваться в подзапросе в рамках запросов, созданных и отправленных для получения необходимых данных для визуального элемента. Таким образом, запрос, определенный в Редакторе Power Query, должен быть допустимым в данном контексте. В частности, невозможно использовать запрос с обобщенными табличными выражениями или запрос, содержащий вызовы хранимых процедур.

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

Термин моделирование в данном контексте означает процесс уточнения и расширения необработанных данных в рамках создания отчета. Примеры моделирования включают:

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

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

  • Отсутствие встроенной иерархии по дате: при импорте данных для каждого столбца даты и времени будет доступна встроенная иерархия по дате. Например, если импортировать таблицу заказов на продажу, включая столбец OrderDate, тогда при использовании OrderDate в визуальном элементе можно будет выбрать соответствующий уровень (год, месяц, день). При использовании DirectQuery эта иерархия недоступна. Тем не менее обратите внимание, что если в базовом источнике есть таблица Дата (что характерно для многих хранилищ данных), тогда функции логики операций со временем в DAX можно использовать в обычном режиме.
  • Поддержка даты и времени только до секундной точности При использовании столбцов времени в наборе данных Power BI отправляет запросы к базовому источнику только до секундного уровня детализации. Запросы не отправляются в источник DirectQuery для миллисекунд. Удалить эту часть значений времени из исходных столбцов.
  • Ограничения в вычисляемых столбцах: вычисляемые столбцы ограничены возможностью выполнения операций в пределах строки, то есть они могут только ссылаться на значения из других столбцов одной таблицы без возможности использования агрегатных функций. Кроме того, скалярные функции DAX, такие как LEFT(), являются ограниченными функциями, которые могут быть переданы в базовый источник. Функции зависят от конкретных возможностей источника. Неподдерживаемые функции не будут перечисляться в автозаполнении при создании DAX для вычисляемого столбца, и использование этих функций завершится ошибкой.
  • Отсутствие поддержки функций DAX типа "родители — потомки": в модели DirectQuery невозможно использовать семейство функций DAX PATH(), которое обычно обрабатывает структуры типа "родители — потомки" (например, диаграмму учетных записей или иерархии сотрудников).
  • Вычисляемые таблицы: Вычисляемые таблицы можно использовать в DirectQuery при использовании составных моделей.
  • Фильтрация связей: Дополнительные сведения о двунаправленной фильтрации см. в разделе Двунаправленная перекрестная фильтрация. В этом техническом документе представлены примеры в контексте SQL Server Analysis Services. Фундаментальные точки применяются так же, как Power BI.
  • Отсутствие кластеризации: при использовании DirectQuery возможность кластеризации для автоматического обнаружения групп отсутствует.

Ограничения отчетности

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

  • Отсутствие поддержки краткой аналитики: Краткая аналитика в Power BI быстро ищет различные подмножества наборов данных, применяя ряд сложных алгоритмов для обнаружения интересующих комбинаций. учитывая необходимость выполнения высокопроизводительных запросов, при использовании DirectQuery эта возможность недоступна.
  • Использование функции обзора в Excel снижает производительность: вы можете исследовать данные с помощью функции обзора в Excel для набора данных. Этот подход позволит создать в Excel сводные таблицы и диаграммы. Хотя DirectQuery и поддерживает эту возможность для наборов данных, производительность становится значительно ниже, чем при создании визуальных элементов в Power BI. Поэтому, если использование Excel важно для сценариев, это следует учесть при решении использовать DirectQuery.
  • Иерархии не отображаются в Excel. При подключении с помощью DirectQuery из Excel к модели Azure Analysis Services или к набору данных Power BI, например, с помощью функции анализа в Excel, любые иерархии, определенные в модели или наборе данных, не отображаются.
  • Максимальная длина для текстовых столбцов: максимальная длина данных в текстовом столбце для наборов данных, использующих DirectQuery, составляет 32 764 символа. Создание отчетов с более длинными текстами приведет к ошибке.

Безопасность

Как уже было описано выше, отчет DirectQuery всегда будет использовать те же самые основные учетные данные для подключения к базовому источнику данных после публикации в службе Power BI. Это поведение относится именно к DirectQuery, а не к динамическим подключениям к службам SQL Server Analysis Services. Для них этот аспект отличается. Сразу после публикации отчета DirectQuery следует настроить необходимые учетные данные пользователя. До настройки учетных данных открытие отчета в службе Power BI завершится ошибкой.

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

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

Как работает отчет в службе Power BI

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

Отчеты: их открытие, взаимодействие с ними и редактирование

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

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

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

Существует некоторое кэширование результатов. Это обеспечивает мгновенное обновление визуального элемента, если некоторые результаты соответствуют результатам в кэше. Если безопасность на уровне строк определена, такие кэши не являются общими для разных пользователей.

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

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

Если в модели не определена безопасность на уровне строк, каждая плитка будет обновлена один раз, а результаты будут доступны всем пользователям. В противном случае может быть применен большой множитель. Каждая плитка требует, чтобы отдельные запросы для каждого пользователя отправлялись в базовый источник.

Таким образом, панель мониторинга с 10 плитками, доступная 100 пользователям, созданная в наборе данных с помощью DirectQuery с определенной безопасностью на уровне строк, а также настроенная на обновление каждые 15 минут, приведет как минимум к 1000 запросам, которые каждые 15 минут будут отправляться во внутренний источник.

Нужно уделить внимание использованию безопасности на уровне строк, а также настройке расписания обновления.

Время ожидания

Для отдельных запросов в службе Power BI применяется время ожидания, равное четырем минутам. Запросы, которые занимают больше времени, завершатся ошибкой. Как подчеркнуто выше, рекомендуется использовать DirectQuery для источников, обеспечивающих производительность практически интерактивных запросов. Это ограничение предназначено для предотвращения проблем с превышением длительного времени выполнения.

Другие ограничения

Ниже перечислены некоторые другие ограничения использования DirectQuery.

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

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

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

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

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

  • Ограничение в один миллион строк, возвращаемых для любого запроса: для максимального числа строк, возвращаемых в любом запросе к базовому источнику, установлено фиксированное значение — один миллион. Это ограничение обычно не приводит ни к каким результатам, и визуальные элементы сами по себе не отображают многие значения. Тем не менее столкнуться с этим ограничением можно в случаях, когда Power BI не полностью оптимизирует переданные запросы и запрашивается некоторый промежуточный результат, превышающий установленное ограничение. Это ограничение актуально также при создании визуального элемента — при выполнении действий для получения соответствующего конечного состояния. Например, добавление столбцов Customer и TotalSalesQuantity превысило бы это ограничение, если бы число клиентов было больше 1 миллиона (если, конечно, не применить соответствующий фильтр).

    Возвращенная ошибка будет выглядеть следующим образом: «Набор результатов запроса к внешнему источнику данных превышает максимально допустимое количество строк: 1 000 000».

    Примечание

    Ограничение в 1 миллион строк может быть превышено в емкостях Premium. Дополнительные сведения см. в разделе "Максимальное число промежуточных наборов строк".

  • Невозможно изменить режим импорта на режим DirectQuery: Хотя модель можно переключить из режима DirectQuery в режим импорта, при этом нужно импортировать все необходимые данные. Однако невозможно выполнить обратное переключение (из режима импорта на режим DirectQuery), так как в режиме DirectQuery не поддерживается некоторый набор функций. Модели DirectQuery для многомерных источников, таких как SAP BW, также невозможно переключить из DirectQuery на режим импорта из-за различных подходов к обработке внешних мер.

DirectQuery в службе Power BI

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

Непосредственно в службе доступны только два источника для DirectQuery:

  • Spark
  • Azure Synapse Analytics (прежнее название — Хранилище данных SQL)

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

Руководство по успешному использованию DirectQuery

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

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

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

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

  • Связи, основанные на столбцах с целыми числами, обычно имеют лучшую производительность, чем соединения в столбцах других типов данных.
  • Должны быть созданы соответствующие индексы. Необходимо создать соответствующие индексы, что обычно означает использование индексов хранилищ столбцов в источниках, которые поддерживают эти индексы (например, SQL Server).
  • Должны быть обновлены все необходимые в источнике статистические данные.

Руководство по проектированию модели

При определении модели учитывайте следующее.

  • Избегайте сложных запросов в Редакторе Power Query. Редактор Power Query преобразует сложный запрос в отдельный SQL-запрос. Один запрос отображается в подзапросе выборки каждого запроса, отправленного в эту таблицу. Если этот запрос будет сложным, это может привести к проблемам производительности каждого отправленного запроса. Фактический SQL-запрос для набора действий можно получить, если выбрать последнее действие в Редакторе Power Query, а также выбрать в контекстном меню пункт Просмотреть машинный запрос.

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

  • Избегайте связей в вычисляемых столбцах. Это руководство относится к базам данных, в которых необходимо выполнять объединения с несколькими столбцами. На сегодняшний день в Power BI не предусмотрена связь на основе нескольких столбцов, как FK/PK. Наиболее распространенным решением является объединение столбцов с помощью вычисляемого столбца и установка объединения для этого столбца. Хотя это решение является разумным для импортируемых данных, для DirectQuery это приводит к объединению с выражением. Этот результат обычно не позволяет использовать индексы и приводит к снижению производительности. Единственное решение — фактически материализовать несколько столбцов в один столбец в базовой базе данных.

  • Избегайте связей в столбцах с данными типа uniqueidentifier. Power BI не поддерживает тип данных uniqueidentifier. Поэтому определение связи между столбцами типа uniqueidentifier приведет к запросу с соединением, включающим Cast. Это снова вызовет снижение производительности. Пока для этого случая не найдется оптимальное решение, единственным выходом остается материализовать столбцы альтернативного типа в базовой базе данных.

  • Скройте в связях столбец "к". Столбец к для связей обычно является первичным ключом в таблице к. Этот столбец должен быть скрытым. Если он скрыт, он не отображается в списке полей и не может использоваться в визуальных элементах. Часто столбцы, на которых основаны связи, являются по сути системными столбцами (например, суррогатными ключами в хранилище данных). Скрывать такие столбцы все же рекомендуется. Если столбец не имеет смысла, тогда представьте видимый вычисляемый столбец, который содержит простое выражение, равное значению первичного ключа, как в следующем примере.

        ProductKey_PK   (Destination of a relationship, hidden)
        ProductKey (= [ProductKey_PK],   visible)
        ProductName
        ...
    
  • Изучите все случаи использования вычисляемых столбцов и изменений типов данных. Использование этих возможностей не обязательно является вредоносным. В результате запросы отправляются в базовый источник, содержащий выражения, а не простые ссылки на столбцы. Это может привести к тому, что индексы не будут использоваться.

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

  • Попробуйте установить флажок Предполагать целостность данных. Если для связей установить флажок "Предполагать целостность данных", запросы смогут использовать операторы INNER JOIN вместо OUTER JOIN. Это указание улучшит производительность запроса, хотя она и зависит в большей степени от конкретных параметров источника данных.

  • Не используйте относительную фильтрацию данных в Редакторе Power Query. Вы можете определить относительную фильтрацию данных в Редакторе Power Query. Например, чтобы выполнить фильтрацию строк, содержащих данные за последние 14 дней.

    Filter rows for last 14 days

    Однако при этом будет использоваться фильтрация на основе установленной даты на момент создания запроса. Это можно увидеть, если просмотреть исходный запрос.

    Filter rows in native SQL query

    Вероятно, это не то, что нужно. Чтобы обеспечить применение фильтра на основе даты на момент выполнения отчета, примените параметр "Фильтр отчета". На сегодняшний день это можно сделать, создав вычисляемый столбец, вычисляющий количество прошедших дней (с помощью функции DAX DATE()), а затем используя этот вычисляемый столбец в фильтре.

Руководство по проектированию отчета

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

  • Используйте параметры для сокращения числа запросов: Power BI позволяет настроить в отчете меньше запросов для отправки и отключить определенные взаимодействия, которые могут привести к снижению производительности, если выполнение полученного запроса занимает много времени. Чтобы получить доступ к этим параметрам в Power BI Desktop, последовательно выберите Файл>Параметры и настройки>Параметры и выберите Сокращение числа запросов.

    Query reduction options

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

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

  • Сначала примените фильтры: при создании визуального элемента всегда применяйте все возможные фильтры. Например, вместо того чтобы выполнять ряд действий со столбцами TotalSalesAmount и ProductName, а затем выполнять фильтрацию по году, примените фильтр по году сразу же при создании визуального элемента. Каждый этап создания визуального элемента отправляет запрос. Хотя существует возможность выполнения других действий (до непосредственного завершения выполнения первого запроса), на базовый источник создается ненужная нагрузка. Изначальное применение фильтров делает менее затратными промежуточные запросы. Игнорирование изначального применения фильтров может привести к превышению ограничения в 1 миллион строк.

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

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

    Multiple visuals with cross-filtering and cross-highlighting

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

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

  • Фильтры мер: визуальные элементы, содержащие меры (или статистические выражения столбцов), могут содержать фильтры в этих мерах. Например, визуальный элемент ниже отображает столбец SalesAmount в параметре Категория, но при этом включает категории с количеством продаж, превышающих 20 млн.

    Visual showing measures that contain filters

    Этот подход может привести к отправке двух запросов в базовый источник данных.

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

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

  • Фильтры "Ведущие N": Можно определить дополнительные фильтры для фильтрации по первым (или последним) N значениям с ранжированием по мере. Например, фильтры могут включать 10 основных категорий в предыдущем визуальном элементе. Этот подход может привести к отправке двух запросов в базовый источник данных. Однако первый запрос вернет все категории из базового источника, и фильтры TopN будут применены на основе возвращенных результатов. В зависимости от количества включенных столбцов этот подход может привести к проблемам с производительностью (или сбоям запросов из-за ограничения строк в один миллион).

  • Медиана: В общем случае любое агрегирование, например Sum или Count Distinct, передается в базовый источник. Но к медиане это не относится, так как это статистическое выражение обычно не поддерживается базовым источником. В таких случаях подробные данные извлекаются из базового источника и медиана вычисляется на основе возвращенных результатов. Этот подход имеет смысл, когда медиана вычисляется по относительно небольшому количеству результатов. Проблемы с производительностью или сбои запросов из-за ограничения количества строк в 1 млн, если количество элементов велико. Например, оптимально использовать медиану населения страны, а не медиану цены продажи.

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

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

  • Отключите отображение итогов в визуальных элементах: по умолчанию в таблицах и матрицах отображаются итоги и промежуточные итоги. Часто для получения таких итогов нужно отправлять отдельные запросы к базовому источнику. Например, при каждом применении агрегирования DistinctCount или во всех случаях использования DirectQuery в SAP BW или SAP HANA. Если такие итоги не требуются, отключите их на панели Формат.

Параметр "Максимальное число подключений" для DirectQuery

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

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

Setting maximum DirectQuery connections

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

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

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

Среда Верхний предел
Power BI Pro 10 активных подключений на источник данных
Power BI Premium 30 активных подключений на источник данных
Сервер отчетов Power BI 10 активных подключений на источник данных

Примечание

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

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

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

Мы рекомендуем выполнять любую диагностику проблем производительности в Power BI Desktop, а не в службе Power BI. Проблемы с производительностью часто основываются на производительности базового источника. Вы можете легко выявить и диагностировать проблемы в более изолированной среде Power BI Desktop. Такой подход изначально устраняет некоторые компоненты, например шлюз Power BI. Если проблемы с производительностью отсутствуют в Power BI Desktop, проверьте особенности отчета в службе Power BI. Анализатор производительности — полезный инструмент для выявления проблем в рамках этого процесса.

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

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

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

Определение запросов, отправленных Power BI Desktop

По умолчанию Power BI Desktop записывает события во время определенного сеанса в файл трассировки, который называется FlightRecorderCurrent.trc.

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

  • SQL Server
  • База данных SQL Azure
  • Azure Synapse Analytics (прежнее название — Хранилище данных SQL)
  • Oracle;
  • Teradata
  • SAP HANA

Файл трассировки можно найти в папке AppData для текущего пользователя:

<User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces

В Power BI Desktop выберите Файл>Параметры и настройки>Параметры, а затем выберите Диагностика. Появится представленное ниже диалоговое окно.

A link to open traces folder

При выборе папки open crash dump/traces в разделе "Параметры диагностики" откроется следующая папка: <User>\AppData\Local\Microsoft\Power BI Desktop\Traces.

Когда вы перейдете к родительской папке, отобразится папка, содержащая AnalysisServicesWorkspaces, которая будет содержать одну папку рабочей области для каждого открытого экземпляра Power BI Desktop. Эти папки содержат в имени суффикс целого числа, например AnalysisServicesWorkspace2058279583.

Внутри этой папки находится папка \Data . В этой папке находится файл трассировки FlightRecorderCurrent.trc для текущего сеанса Power BI. Соответствующая папка рабочей области удаляется по завершении связанного сеанса Power BI Desktop.

Файлы трассировки можно читать с помощью инструмента SQL Server Profiler. Получите его бесплатно, загрузив SQL Server Management Studio (SSMS).

После скачивания и установки SQL Server Management Studio запустите SQL Server Profiler.

SQL Server Profiler

Чтобы открыть файл трассировки, сделайте следующее:

  1. В SQL Server Profiler выберите Файл>Открыть>Файл трассировки.

  2. Введите путь к файлу трассировки для открытого сеанса Power BI, например C:\Usersuser<>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data.

  3. Откройте файл FlightRecorderCurrent.trc.

Отобразятся все события текущего сеанса. Ниже приведен пример с пометками, в котором выделены группы событий. Каждая группа включает следующие события:

  • событие Query Begin и Query End, которые представляют отправку и завершение запроса DAX, созданного интерфейсом пользователя (например, визуальным элементом, заполнением списка значений в пользовательском интерфейсе фильтра);
  • одну или несколько пар событий DirectQuery Begin и DirectQuery End, которые представляют запрос, отправленный в базовый источник данных, как часть оценки запроса DAX.

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

SQL Server Profiler with Query Begin and Query End events

Другие столбцы, которые следует рассмотреть:

  • TextData: текстовые сведения о событии. Для событий Query Begin/End сведениями является запрос DAX. Для событий DirectQuery Begin/End в качестве подробностей используется SQL-запрос, отправляемый в базовый источник. Столбец TextData для текущего выбранного события также отображается в нижней области.
  • EndTime: Время завершения события.
  • Duration: время, затраченное на выполнение запроса SQL или DAX, в мс.
  • Error: событие, сообщающее об ошибке (в этом случае событие также отображается красным цветом).

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

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

  • Откройте отдельный сеанс Power BI Desktop (чтобы избежать путаницы с несколькими папками рабочей области).
  • Выполните необходимые действия в Power BI Desktop. Выполните несколько дополнительных действий, чтобы убедиться, что нужные события записываются в файл трассировки.
  • Откройте SQL Server Profiler и найдите файл трассировки, как описано выше. Помните, что файл трассировки после закрытия Power BI Desktop будет удален. Кроме того, дальнейшие действия в Power BI Desktop не отображаются немедленно. Файл трассировки должен быть закрыт и открыт заново для просмотра новых событий.
  • Отдельные сеансы должны быть относительно небольшие, возможно, 10 секунд или событий, а не сотни. Такой подход упрощает интерпретацию файла трассировки. Также существует ограничение на размер файла трассировки. Для длинных сеансов существует вероятность удаления ранних событий.

Основные сведения о форме запроса, отправленного Power BI Desktop

Общий формат запросов, созданных и отправленных Power BI Desktop, использует подзапросы для каждой связанной таблицы. Запрос в Редакторе Power Query определяет подзапрос. Предположим, в SQL Server есть следующие таблицы TPC-DS:

TPC-DS tables in SQL Server

Обратите внимание на следующий запрос:

A sample query

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

Visual result of a query

Обновление этого визуального элемента приведет к SQL-запросу, показанному ниже. Как вы видите, у нас три подзапроса, Web Sales, Item, и Date_dim, каждый из которых возвращает все столбцы соответствующей таблицы, несмотря на то что визуальный элемент ссылается на четыре столбца. Эти запросы в подзапросах (которые затенены) — это точный результат запросов, определенных в Редакторе Power Query. Использование подзапросов таким образом не повлияло на производительность для источников данных, поддерживаемых для DirectQuery на сегодняшний день. Такие источники данных, как SQL Server, оптимизируют ссылки на другие столбцы.

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

SQL query used as provided

Дальнейшие действия

В этой статье описываются аспекты DirectQuery, общие для всех источников данных. Существуют аспекты, касающиеся только отдельных источников. Дополнительные сведения об отдельных источниках см. в следующих статьях.

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