Como saber se ocorreu a compressão externa

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

Minha consulta está se beneficiando do pushdown externo?

A computação pushdown melhora 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 trazidas para o SQL Server. Especialmente nos casos de filtragem e pushdown de junção, a carga de trabalho na instância do SQL Server pode ser significativamente reduzida.

A computação de pushdown do PolyBase tem potencial para melhorar significativamente o desempenho da consulta. Se uma consulta PolyBase estiver sendo executada lentamente, você deve determinar se está ocorrendo o "pushdown" da consulta PolyBase.

Há três diferentes situações em que o pushdown pode ser observado no plano de execução.

• Filtrar pushdown do predicado
• Rebaixamento de junção
• Pushdown de agregação

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

• Exibir o Plano de Execução Estimado com o sinalizador de rastreamento 6408
• Visualize o read_command na visualizaçã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ê só vê 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 os planos de execução reais. Esse sinalizador de rastreamento expõe informações sobre o operador de 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 estiver à direita de outro operador, é considerado "anterior" a ele. Se um operador estiver à esquerda de outro operador, será dito que ele 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 abaixo para determinar se ocorreu "pushdown" (ou transferência de carga).

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

Aplica-se o predicado de filtro no nível inferior (visualização com 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 sendo realizado, o operador de filtro se posiciona antes do operador externo. Quando o operador de filtro está antes do operador externo, a filtragem ocorreu antes de ser selecionada de volta da fonte de dados externa, indicando que o predicado de filtro foi empurrado para baixo.

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

Com o sinalizador de rastreamento 6408 habilitado, agora você verá informações adicionais na saída estimada do plano de execução. 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 de consulta remota é representada como um único plano de consulta. Por exemplo:

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

Se a transferência do predicado de filtro não estiver sendo aplicada, o filtro será executado após o operador externo.

O plano de execução estimado do SSMS:

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

Propagação 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 o JOIN for propagado para a fonte de dados externa, o operador JOIN antecederá o operador externo. Neste exemplo, ambas [BusinessEntity] e [BusinessEntityAddress] são tabelas externas.

Com pushdown de união (visualização com plano de execução)

O plano de execução estimado do SSMS:

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

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

Se o JOIN não for propagado para a fonte de dados externa, o operador JOIN estará atrás do operador externo. No SSMS, o operador externo está no plano de execução da consulta para sp_execute_memo_node, que está no operador de consulta remota na Consulta 1. No Azure Data Studio, o operador Join está atrás dos operadores externos.

O plano de execução estimado do SSMS:

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

"Implementação em baixo nível de agregação (visualização com 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 o pushdown de agregação (visualização com plano de execução)

Se a pushdown da 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 de volta da fonte de dados externa, indicando que a agregação foi enviada por push para baixo.

O plano de execução estimado do SSMS:

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

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

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

O plano de execução estimado do SSMS:

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

Usar DMV

Com o SQL Server 2019 (15.x) e versões posteriores, a read_command coluna de sys.dm_exec_external_work DMV mostra a consulta enviada à fonte de dados externa. Isso 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 TF6408.

Você pode executar a consulta a seguir e usar os start_time, /, end_time e read_command para identificar qual consulta está sendo investigada.

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

Aplicação Direta do predicado de filtro (visualização com DMV)

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

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

Com aplicação de filtro (exibição com DMV)

Você pode saber se o pushdown do predicado de filtro está ocorrendo verificando o read_command DMV. Você verá algo parecido com 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 à fonte de dados externa, o que significa que o predicado de filtro está sendo avaliado na fonte de dados externa. A filtragem no conjunto de dados ocorreu na fonte de dados externa e somente o conjunto de dados filtrado foi recuperado pelo PolyBase.

Sem aplicação de filtro (exibição com DMV)

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

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

Não há cláusula WHERE no comando enviado à fonte de dados externa, portanto, o predicado de filtro não é propagado. A filtragem em todo o conjunto de dados ocorreu no lado do SQL Server, depois que o conjunto de dados foi recuperado pelo PolyBase.

Pushdown de JOIN (visualização com DMV)

Considere a consulta usada no exemplo join anterior:

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

Com pushdown de join (visualização com DMV)

Se o JOIN for transferido 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, o JOIN é enviado por push para baixo. A junção no conjunto de dados ocorreu na fonte de dados externa e somente o conjunto de dados que corresponde à condição de junção foi recuperado pelo PolyBase.

Sem pushdown de junção (exibição com 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, depois que ambos os conjuntos de dados são recuperados pelo PolyBase.

Pushdown de agregação (visualização com DMV)

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

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

Com otimização de agregação (exibição com VMD)

Se a pushdown da 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 é deslocada para baixo. A agregação ocorreu na fonte de dados externa e somente o conjunto de dados agregado foi recuperado pelo PolyBase.

Sem pushdown para agregação (visualização com DMV)

Se o pushdown da 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 executada no SQL Server, depois que o conjunto de dados não agregado foi recuperado pelo PolyBase.

Próximas etapas

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