Как определить, произошло ли внешнее снижение

В этой статье рассматривается, как определить, извлекает ли запрос PolyBase выгоду из помещения обработки на внешний источник данных. Дополнительные сведения о внешнем pushdown см. в вычисления pushdown в PolyBase.

Улучшает ли мой запрос производительность за счет внешнего выполнения pushdown?

Pushdown-вычисления улучшают производительность запросов к внешним источникам данных. Некоторые вычислительные задачи делегируются внешнему источнику данных, а не передаются в SQL Server. Особенно в случаях отфильтровки и объединения рабочих нагрузок в экземпляре SQL Server может быть значительно сокращено.

Вычисление с использованием функции PolyBase pushdown может значительно повысить производительность запроса. Если запрос PolyBase выполняется медленно, следует определить, происходит ли отправка запроса PolyBase.

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

• Применение предикатов фильтра на ранних этапах
• Принудительная отправка соединения
• Углубление агрегирования

Заметка

Существуют ограничения на то, что можно отправить в внешние источники данных с вычислениями pushdown PolyBase:

• Некоторые функции T-SQL могут препятствовать отправке, дополнительные сведения см. в функциях и ограничениях PolyBase.
• Список функций T-SQL, которые могут быть перенесены, см. в разделе Переносимые вычисления в PolyBase.

Появились две новые функции SQL Server 2019 (15.x), позволяющие администраторам определить, отправляется ли запрос PolyBase в внешний источник данных:

• Просмотрите предполагаемый план выполнения с флагом трассировки 6408
• Просмотр read_command в динамическом представлении управления sys.dm_exec_external_work

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

Используйте TF6408

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

Или в Azure Data Studio:

Начиная с SQL Server 2019 (15.x), можно включить новый флаг трассировки 6408 глобально с помощью DBCC TRACEON. Например:

DBCC TRACEON (6408, -1);  

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

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

• В SSMS выделите запрос и выберите "Показать предполагаемый план выполнения" на панели инструментов или используйте CTRL+L.
• В Azure Data Studio выделите запрос и выберите Пояснить. Затем рассмотрите следующие сценарии, чтобы определить, произошло ли перемещение вниз.

Каждый из приведенных ниже примеров включает выходные данные из SSMS и Azure Data Studio.

Оптимизация предиката фильтра (просмотр с планом выполнения)

Рассмотрим следующий запрос, который использует предикат фильтра в предложении WHERE:

SELECT *
FROM [Person].[BusinessEntity] AS be
WHERE be.BusinessEntityID = 17907;

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

С помощью pushdown предиката фильтра (просмотр с планом выполнения)

С включенным флагом трассировки 6408 теперь вы увидите дополнительные сведения в выходных данных предполагаемого плана выполнения. Выходные данные зависят от SSMS и Azure Data Studio.

В SSMS план удаленного запроса отображается в предполагаемом плане выполнения в виде запроса 2 (sp_execute_memo_node_1) и соответствует оператору удаленного запроса в запросе 1. Например:

В Azure Data Studio вместо этого выполняется удаленный запрос в виде одного плана запроса. Например:

Без применения операции pushdown для предиката фильтра (просмотр с планом выполнения)

Если не происходит pushdown предиката фильтра, фильтр будет находиться после внешнего оператора.

Оценочный план выполнения из SSMS:

Предполагаемый план выполнения из Azure Data Studio:

Понижение уровня операции JOIN

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

SELECT be.BusinessEntityID, bea.AddressID
FROM [Person].[BusinessEntity] AS be
INNER JOIN [Person].[BusinessEntityAddress] AS bea
ON be.BusinessEntityID = bea.BusinessEntityID;

Если соединение отправляется к внешнему источнику данных, оператор Join будет перед внешним оператором. В этом примере [BusinessEntity] и [BusinessEntityAddress] являются внешними таблицами.

С помощью pushdown соединения (представление с планом выполнения)

Оценочный план выполнения из SSMS:

Предполагаемый план выполнения из Azure Data Studio:

Без использования pushdown при соединении (просмотр с планом выполнения)

Если соединение не передается во внешний источник данных, оператор соединения будет следовать за внешним оператором. В SSMS внешний оператор присутствует в плане выполнения для sp_execute_memo_node, который находится в операторе удаленного запроса в запросе 1. В Azure Data Studio оператор Join находится после внешних операторов.

Предполагаемый план выполнения из SSMS:

Предполагаемый план выполнения из Azure Data Studio:

Оптимизация агрегации (просмотр с планом выполнения)

Рассмотрим следующий запрос, который использует агрегатную функцию:

SELECT SUM([Quantity]) as Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];

При переносе агрегирования вглубь (вид с планом выполнения)

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

Оценочный план выполнения из SSMS:

Предполагаемый план выполнения из Azure Data Studio:

Без выноса агрегирования (просмотр с планом выполнения)

Если проталкивание агрегирования не происходит, оператор агрегирования будет следовать за внешним оператором.

Оценочный план выполнения из SQL Server Management Studio (SSMS):

Предполагаемый план выполнения из Azure Data Studio:

Используйте DMV

В SQL Server 2019 (15.x) и более поздних версиях столбец read_command в sys.dm_exec_external_work DMV отображает запрос, отправляемый во внешний источник данных. Это позволяет определить, происходит ли «pushdown», но не раскрывает план выполнения. Просмотр удаленного запроса не требует TF6408.

Заметка

Для Hadoop и хранилища Azure read_command всегда возвращает NULL.

Вы можете выполнить следующий запрос и использовать start_time/end_time и read_command для идентификации исследуемого запроса:

SELECT execution_id, start_time, end_time, read_command
FROM sys.dm_exec_external_work
ORDER BY execution_id desc;

Заметка

Одним из ограничений метода sys.dm_exec_external_work является то, что поле read_command в dmV ограничено 4000 символами. Если запрос достаточно длинный, read_command может быть усечен до того, как вы увидите функцию WHERE/JOIN/агрегирования в read_command.

Перенос фильтрующего предиката (вид с динамическим управлением представлений)

Рассмотрим запрос, используемый в предыдущем примере предиката фильтра:

SELECT *
FROM [Person].[BusinessEntity] be
WHERE be.BusinessEntityID = 17907;

С помощью фильтрации (представление с использованием DMV)

Вы можете определить, происходит ли применение фильтрующего предиката, проверив read_command в DMV. Вы увидите примерно следующий пример:

SELECT [T1_1].[BusinessEntityID] AS [BusinessEntityID], [T1_1].[rowguid] AS [rowguid], 
  [T1_1].[ModifiedDate] AS [ModifiedDate] FROM 
  (SELECT [T2_1].[BusinessEntityID] AS [BusinessEntityID], [T2_1].[rowguid] AS [rowguid], 
    [T2_1].[ModifiedDate] AS [ModifiedDate] 
FROM [AdventureWorks2022].[Person].[BusinessEntity] AS T2_1 
WHERE ([T2_1].[BusinessEntityID] = CAST ((17907) AS INT))) AS T1_1;

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

Без упрощения фильтрации (с использованием представления DMV)

Если pushdown не происходит, вы увидите примерно следующее:

SELECT "BusinessEntityID","rowguid","ModifiedDate" FROM "AdventureWorks2022"."Person"."BusinessEntity"

Предложение WHERE в команде, отправленной во внешний источник данных, отсутствует, поэтому предикат фильтра не отправляется вниз. Фильтрация по всему набору данных произошла на стороне SQL Server после получения набора данных PolyBase.

Понижение JOIN (просмотр с DMV)

Рассмотрим запрос, используемый в предыдущем примере JOIN:

SELECT be.BusinessEntityID, bea.AddressID
FROM [Person].[BusinessEntity] be
INNER JOIN [Person].[BusinessEntityAddress] bea ON be.BusinessEntityID = bea.BusinessEntityID;

С использованием pushdown соединения (представление с DMV)

Если соединение отправляется в внешний источник данных, вы увидите следующее:

SELECT [T1_1].[BusinessEntityID] AS [BusinessEntityID], [T1_1].[AddressID] AS [AddressID] 
FROM (SELECT [T2_2].[BusinessEntityID] AS [BusinessEntityID], [T2_1].[AddressID] AS [AddressID] 
FROM [AdventureWorks2022].[Person].[BusinessEntityAddress] AS T2_1 
INNER JOIN  [AdventureWorks2022].[Person].[BusinessEntity] AS T2_2  
ON ([T2_1].[BusinessEntityID] = [T2_2].[BusinessEntityID])) AS T1_1;

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

Без проталкивания соединения (представление с DMV)

Если pushdown соединения не происходит, вы увидите, что на внешнем источнике данных выполняются два разных запроса:

SELECT [T1_1].[BusinessEntityID] AS [BusinessEntityID], [T1_1].[AddressID] AS [AddressID] 
FROM [AdventureWorks2022].[Person].[BusinessEntityAddress] AS T1_1;

SELECT [T1_1].[BusinessEntityID] AS [BusinessEntityID] FROM [AdventureWorks2022].[Person].[BusinessEntity] AS T1_1;

Присоединение двух наборов данных произошло на стороне SQL Server после извлечения обоих наборов данных PolyBase.

Понижение уровня агрегирования (доступ через DVM)

Рассмотрим следующий запрос, который использует агрегатную функцию:

SELECT SUM([Quantity]) as Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];

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

Если выполняется принудительное удаление агрегирования, в read_commandотображается функция агрегирования. Например:

SELECT [T1_1].[col] AS [col] FROM (SELECT SUM([T2_1].[Quantity]) AS [col] 
FROM [AdventureWorks2022].[Production].[ProductInventory] AS T2_1) AS T1_1

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

Без использования агрегации (представление с DMV)

Если передача операций агрегирования не происходит, функция агрегации не отображается в read_command. Например:

SELECT "Quantity" FROM "AdventureWorks2022"."Production"."ProductInventory"

Агрегирование было выполнено в SQL Server после извлечения нерегрегированного набора данных PolyBase.

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

• устранение неполадок с PolyBase
• ошибки PolyBase и возможные решения