Como saber se ocorreu o pushdown externo

Este artigo detalha como determinar se uma consulta do PolyBase está se beneficiando do pushdown para a fonte de dados externa. Para obter mais informações sobre o pushdown externo, confira Computações de pushdown no PolyBase.

Minha consulta está se beneficiando do pushdown externo?

A computação de aplicação aprimora o desempenho de consultas em fontes de dados externas. Determinadas tarefas de computação são delegadas à fonte de dados externa em vez de serem levadas para o SQL Server. Especialmente em casos de pushdown de filtragem e junção, a carga de trabalho na instância do SQL Server pode ser muito reduzida.

A computação de pushdown do PolyBase pode aprimorar significativamente o desempenho da consulta. Se uma consulta do PolyBase estiver com a execução lenta, determine se o pushdown da consulta está ocorrendo.

Há três cenários diferentes em que o pushdown pode ser observado no plano de execução:

• Pushdown de predicado de filtro
• Pushdown de junção
• Pushdown de agregação

Observação

Há limitações quanto ao que pode sofrer pushdown para fontes de dados externas com as Computações de pushdown do PolyBase:

• Algumas funções T-SQL podem impedir o pushdown. Para saber mais, confira limitações Recursos e limitações do PolyBase.
• Para ver uma lista de funções T-SQL que podem sofrer pushdown, confira Computações de pushdown no PolyBase.

Dois novos recursos do SQL Server 2019 (15.x) foram introduzidos para permitir que os administradores determinem se uma consulta no PolyBase está sendo enviada para a fonte de dados externa:

• Ver o Plano de Execução Estimado com o sinalizador de rastreamento 6408
• Ver o read_command na exibição de gerenciamento dinâmico sys.dm_exec_external_work

Este artigo fornece detalhes sobre como usar cada um desses dois casos de uso, para cada um dos três cenários de pushdown.

Usar TF6408

Por padrão, o plano de execução estimado não expõe o plano de consulta remota e você vê apenas o objeto do operador de consulta remota. Por exemplo, um plano de execução estimado do SSMS (SQL Server Management Studio):

Ou, no Azure Data Studio:

A partir do SQL Server 2019 (15.x), você pode habilitar um novo sinalizador de rastreamento 6408 globalmente usando DBCC TRACEON. Por exemplo:

DBCC TRACEON (6408, -1);  

Esse sinalizador de rastreamento funciona apenas com planos de execução estimados e não tem nenhum efeito sobre planos de execução reais. Este sinalizador de rastreamento expõe informações sobre o operador Consulta Remota que mostra o que está acontecendo durante a fase de Consulta Remota.

Os planos de execução são lidos da direita para a esquerda, conforme indicado pela direção das setas. Se um operador está à direita de outro, dizemos que está "antes" dele. Se um operador está à esquerda de outro, dizemos que está "depois" dele.

• No SSMS, realce a consulta e selecione Exibir Plano de Execução Estimado na barra de ferramentas ou use Ctrl+L.
• No Azure Data Studio, realce a consulta e selecione Explicar. Em seguida, considere os cenários a seguir para determinar se o pushdown ocorreu.

Cada um dos exemplos abaixo incluirá a saída do SSMS e do Azure Data Studio.

Pushdown do predicado de filtro (exibição com o plano de execução)

Considere a seguinte consulta, que usa um predicado de filtro na cláusula WHERE:

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

Se o pushdown do predicado de filtro estiver ocorrendo, o operador de filtro estará antes do operador externo. Quando o operador de filtro está antes do operador externo, a filtragem ocorreu antes de ser selecionado novamente na fonte de dados externa, indicando que o predicado de filtro sofreu pushdown.

Com pushdown do predicado de filtro (exibição com o plano de execução)

Com o Sinalizador de Rastreamento 6408 habilitado, você verá informações adicionais na saída do plano de execução estimado. A saída varia entre o SSMS e o Azure Data Studio.

No SSMS, o plano de consulta remota é exibido no plano de execução estimado como Consulta 2 (sp_execute_memo_node_1) e corresponde ao operador de Consulta Remota na Consulta 1. Por exemplo:

No Azure Data Studio, a execução da consulta remota é representada como um só plano de consulta. Por exemplo:

Sem pushdown do predicado de filtro (exibição com o plano de execução)

Se o pushdown do predicado de filtro não estiver ocorrendo, o filtro estará depois do operador externo.

O plano de execução estimado no SSMS:

O plano de execução estimado no Azure Data Studio:

Pushdown de JOIN

Considere a seguinte consulta que utiliza o operador JOIN para duas tabelas externas na mesma fonte de dados externa:

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

Se JOIN sofrer pushdown para a fonte de dados externa, o operador de junção estará antes do operador externo. Neste exemplo, tanto [BusinessEntity] como [BusinessEntityAddress] são tabelas externas.

Com pushdown de junção (exibição com o plano de execução)

O plano de execução estimado no SSMS:

O plano de execução estimado no Azure Data Studio:

Sem pushdown de junção (exibição com o plano de execução)

Se JOIN não sofrer pushdown para a fonte de dados externa, o operador de junção estará depois do operador externo. No SSMS, o operador externo está no plano de consulta para sp_execute_memo_node, que está no operador de Consulta Remota na Consulta 1. No Azure Data Studio, o operador de junção está depois dos operadores externos.

O plano de execução estimado no SSMS:

O plano de execução estimado no Azure Data Studio:

Pushdown de agregação (exibição com o plano de execução)

Considere a seguinte consulta, que usa uma função de agregação:

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

Com pushdown de agregação (exibição com o plano de execução)

Se o pushdown de agregação estiver ocorrendo, o operador de agregação estará antes do operador externo. Quando o operador de agregação está antes do operador externo, a agregação ocorreu antes de ser selecionada novamente na fonte de dados externa, indicando que a agregação sofreu pushdown.

O plano de execução estimado no SSMS:

O plano de execução estimado no Azure Data Studio:

Sem pushdown de agregação (exibição com o plano de execução)

Se o pushdown de agregação não estiver ocorrendo, o operador de agregação estará depois do operador externo.

O plano de execução estimado no SSMS:

O plano de execução estimado no Azure Data Studio:

Usar DMV

No SQL Server 2019 (15.x) e versões posteriores, a coluna read_command da DMV sys.dm_exec_external_work mostra a consulta enviada à fonte de dados externa. Isto permite determinar se o pushdown está ocorrendo, mas não expõe o plano de execução. A exibição da consulta remota não requer o TF6408.

Observação

Para o Hadoop e o armazenamento do Azure, read_command sempre retorna NULL.

Você pode executar a seguinte consulta e usar o start_time/end_time e read_command para identificar a consulta que está sendo investigada:

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

Observação

Uma limitação do método sys.dm_exec_external_work é que o campo read_command na DMV é limitado a quatro mil caracteres. Se a consulta for suficientemente longa, o read_command poderá ser truncado antes que você veja a função de agregação/WHERE/JOIN no read_command.

Pushdown do predicado de filtro (exibição com a DMV)

Considere a consulta usada no exemplo de predicado de filtro anterior:

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

Com o pushdown de filtro (exibição com a DMV)

Se o pushdown do predicado de filtro estiver ocorrendo, você saberá verificando o read_command na DMV. Você verá algo semelhante a este exemplo:

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;

A cláusula WHERE está no comando enviado para a fonte de dados externa, o que significa que o predicado de filtro está sendo avaliado na fonte de dados externa. A filtragem no conjuntos de dados ocorreu na fonte de dados externa, e apenas o conjuntos de dados filtrado foi recuperado pelo PolyBase.

Sem o pushdown de filtro (exibição com a DMV)

Se o pushdown não estiver ocorrendo, você verá algo como:

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

Não há nenhuma cláusula WHERE no comando enviado para a fonte de dados externa, portanto, o predicado de filtro não sofreu pushdown. A filtragem no conjuntos de dados inteiro ocorreu no lado do SQL Server, após o conjuntos de dados ter sido recuperado pelo PolyBase.

Pushdown de JOIN (exibição com a DMV)

Considere a consulta usada no exemplo anterior com JOIN:

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

Com pushdown de junção (exibição com a DMV)

Se JOIN tiver sofrido pushdown para a fonte de dados externa, você verá algo como:

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;

A cláusula JOIN está no comando enviado à fonte de dados externa, portanto, JOIN sofreu pushdown. A junção no conjunto de dados ocorreu na fonte de dados externa e apenas o conjunto de dados que corresponde à condição de junção foi recuperado pelo PolyBase.

Sem pushdown de junção (exibição com a DMV)

Se o pushdown da junção não estiver ocorrendo, você verá que há duas consultas diferentes executadas na fonte de dados externa:

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;

A junção dos dois conjuntos de dados ocorreu no lado do SQL Server, após ambos os conjuntos de dados serem recuperados pelo PolyBase.

Pushdown de agregação (exibição com a DMV)

Considere a seguinte consulta, que usa uma função de agregação:

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

Com pushdown de agregação (exibição com a DMV)

Se o pushdown de agregação estiver ocorrendo, você verá a função de agregação no read_command. Por exemplo:

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

A função de agregação está no comando enviado à fonte de dados externa, portanto, a agregação sofreu pushdown. A agregação ocorreu na fonte de dados externa e somente o conjunto de dados agregado foi recuperado pelo PolyBase.

Sem pushdown de agregação (exibição com a DMV)

Se o pushdown de agregação não estiver ocorrendo, você não verá a função de agregação no read_command. Por exemplo:

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

A agregação foi realizada no SQL Server, após o conjunto de dados não agregado ter sido recuperado pelo PolyBase.

Próximas etapas

• Solução de problemas do PolyBase
• Erros do PolyBase e possíveis soluções