Как определить, произошел ли внешний pushdown
В этой статье описано, как определить, используется ли запрос PolyBase от pushdown к внешнему источнику данных. Дополнительные сведения о внешнем pushdown см. в статье Вычисления pushdown в PolyBase.
Выигрывает ли мой запрос от внешнего pushdown?
Вычисление pushdown повышает производительность запросов во внешних источниках данных. Некоторые вычислительные задачи делегируются внешнему источнику данных, а не передаются в SQL Server. В частности, на рабочей нагрузке в экземпляре SQL Server могут существенно сказаться операции pushdown для фильтрации и объединения.
Вычисление pushdown в PolyBase может значительно повысить производительность запроса. Если запрос PolyBase выполняется медленно, необходимо определить, происходит ли его pushdown.
Существует три разных сценария, в которых может наблюдаться pushdown в плане выполнения:
- pushdown предиката фильтра;
- pushdown объединения;
- pushdown агрегата.
Заметка
Существуют ограничения на то, что можно передавать во внешние источники данных с помощью вычислений pushdown PolyBase.
- Некоторые функции T-SQL могут препятствовать выполнению pushdown. Дополнительные сведения см. в разделе о функциях и ограничениях PolyBase.
- Список функций T-SQL, которые поддерживают pushdown, см. в статье Вычисления pushdown в 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.
Pushdown предиката фильтра (представление с планом выполнения)
Рассмотрим следующий запрос, использующий предикат фильтра в предложении WHERE:
SELECT *
FROM [Person].[BusinessEntity] AS be
WHERE be.BusinessEntityID = 17907;
Если выполняется pushdown предиката фильтра, оператор фильтра находится перед внешним оператором. Когда оператор фильтра находится перед внешним оператором, фильтрация произошла перед тем, как вернуться из внешнего источника данных, указывая, что предикат фильтра был отправлен вниз.
Pushdown предиката фильтра (представление с планом выполнения)
Если включен флаг трассировки 6408, вы увидите дополнительные сведения в выходных данных предполагаемого плана выполнения. Выходные данные из SSMS и Azure Data Studio различаются.
В SSMS план удаленного запроса отображается в предполагаемом плане выполнения в виде запроса 2 (sp_execute_memo_node_1) и соответствует оператору удаленного запроса в запросе 1. Например:
В Azure Data Studio выполнение удаленного запроса представлено в виде одного плана запроса. Например:
Без pushdown предиката фильтра (представление с планом выполнения)
Если pushdown предиката фильтра не происходит, фильтр будет следовать за внешним оператором.
Предполагаемый план выполнения из SSMS:
Предполагаемый план выполнения из Azure Data Studio:
Pushdown оператора JOIN
Рассмотрим следующий запрос, который использует оператор JOIN для двух внешних таблиц в одном и том же внешнем источнике данных:
SELECT be.BusinessEntityID, bea.AddressID
FROM [Person].[BusinessEntity] AS be
INNER JOIN [Person].[BusinessEntityAddress] AS bea
ON be.BusinessEntityID = bea.BusinessEntityID;
Если оператор JOIN передается во внешний источник данных посредством pushdown, он будет предшествовать внешнему оператору. В этом примере оба [BusinessEntity] [BusinessEntityAddress] и являются внешними таблицами.
С pushdown объединения (представление с планом выполнения)
Предполагаемый план выполнения из SSMS:
Предполагаемый план выполнения из Azure Data Studio:
Без pushdown объединения (представление с планом выполнения)
Если оператор JOIN не передается во внешний источник данных посредством pushdown, он будет следовать за внешним оператором. В SSMS внешний оператор находится в плане запроса, который sp_execute_memo_nodeнаходится в операторе удаленного запроса в запросе 1. В Azure Data Studio оператор соединения находится после внешних операторов.
Предполагаемый план выполнения из SSMS:
Предполагаемый план выполнения из Azure Data Studio:
Pushdown агрегата (представление с планом выполнения)
Рассмотрим следующий запрос, использующий агрегатную функцию:
SELECT SUM([Quantity]) as Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];
С pushdown агрегата (представление с планом выполнения)
Если выполняется принудительное удаление агрегата, оператор агрегирования находится перед внешним оператором. Когда оператор агрегирования находится перед внешним оператором, агрегирование произошло перед тем, как вернуться из внешнего источника данных, указывая, что агрегирование было отправлено вниз.
Предполагаемый план выполнения из SSMS:
Предполагаемый план выполнения из Azure Data Studio:
С pushdown агрегата (представление с планом выполнения)
Если pushdown агрегата не происходит, оператор агрегирования будет следовать за внешним оператором.
Предполагаемый план выполнения из SSMS:
Предполагаемый план выполнения из Azure Data Studio:
Использование DMV
В sql Server 2019 (15.x) и более поздних версиях столбец sys.dm_exec_external_work DMV показывает запрос, read_command который отправляется во внешний источник данных. Это позволяет определить, происходит ли pushdown, но не предоставляет план выполнения. Для просмотра удаленного запроса не требуется флаг трассировки 6408.
Заметка
Для 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 в динамическом административном представлении ограничено 4000 символов. Если запрос достаточно длинный, команда read_command может быть усечена до того, как в read_command будет отображена функция WHERE, JOIN или функция агрегирования.
Pushdown предиката фильтра (динамическое административное представление)
Рассмотрим запрос, использовавшийся в предыдущем примере предиката фильтра:
SELECT *
FROM [Person].[BusinessEntity] be
WHERE be.BusinessEntityID = 17907;
С pushdown фильтра (динамическое административное представление)
Вы можете определить, происходит ли pushdown предиката фильтра, проверив read_command его в динамическом административном представлении. Должно отобразиться примерно следующее:
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 был возвращен отфильтрованный набор данных.
Без pushdown фильтра (динамическое административное представление)
Если pushdown не происходит, результат будет примерно следующим:
SELECT "BusinessEntityID","rowguid","ModifiedDate" FROM "AdventureWorks2022"."Person"."BusinessEntity"
В команде, отправляемой во внешний источник данных, отсутствует предложение WHERE, поэтому предикат фильтра не передается посредством pushdown. Фильтрация всего набора данных выполнялась на стороне SQL Server после получения набора данных с помощью PolyBase.
Pushdown оператора JOIN (динамическое административное представление)
Рассмотрим запрос, использовавшийся в предыдущем примере оператора JOIN:
SELECT be.BusinessEntityID, bea.AddressID
FROM [Person].[BusinessEntity] be
INNER JOIN [Person].[BusinessEntityAddress] bea ON be.BusinessEntityID = bea.BusinessEntityID;
С pushdown оператора JOIN (динамическое административное представление)
Если оператор JOIN передается во внешний источник данных посредством pushdown, вы увидите следующее:
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 находится в команде, отправляемой во внешний источник данных, поэтому оно передается посредством pushdown. Объединение набора данных происходило во внешнем источнике, и в PolyBase был возвращен набор данных, соответствующий условию соединения.
Без pushdown оператора JOIN (динамическое административное представление)
Если 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.
Pushdown агрегата (динамическое административное представление)
Рассмотрим следующий запрос, использующий агрегатную функцию:
SELECT SUM([Quantity]) as Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];
С pushdown агрегата (динамическое административное представление)
Если выполняется отправка агрегирования, в ней 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
Функция агрегирования находится в команде, отправляемой во внешний источник данных, поэтому агрегат передается посредством pushdown. Агрегирование произошло во внешнем источнике данных, и только агрегированный набор данных был получен PolyBase.
Без pushdown агрегата (динамическое административное представление)
Если pushdown агрегата не происходит, в read_command не будет функции агрегирования. Например:
SELECT "Quantity" FROM "AdventureWorks2022"."Production"."ProductInventory"
Агрегирование было выполнено в SQL Server после извлечения нерегрегированного набора данных PolyBase.