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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

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

Используйте флаг трассировки 6408

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

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

DBCC TRACEON (6408, -1);

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

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

• В SSMS выделите запрос и выберите "Показать предполагаемый план выполнения " на панели инструментов или нажмите клавиши CTRL+L.

Каждый из следующих примеров включает выходные данные из SSMS.

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

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

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

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

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

При включении флага трассировки 6408 вы увидите дополнительные сведения в выходных данных предполагаемого плана выполнения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выполните следующий запрос и используйте 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;

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

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

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

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

Чтобы узнать, происходит ли pushdown предиката фильтра, можно проверить 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] AS be
     INNER JOIN [Person].[BusinessEntityAddress] AS bea
         ON be.BusinessEntityID = bea.BusinessEntityID;

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

Если вы отправляете JOIN вниз во внешний источник данных, вы увидите что-то подобное:

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 предложение, поэтому 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];

С оптимизацией агрегирования (представление с динамическим управлением)

Если происходит оптимизация агрегации, в 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";

PolyBase извлекает нерегрегированный набор данных, а SQL Server выполняет агрегирование.

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

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