Como saber se ocorreu uma operação de 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.
A minha consulta está a beneficiar de optimização externa?
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 rebaixamento de junções, a carga de trabalho na instância do SQL Server pode ser muito reduzida.
A computação pushdown do PolyBase pode melhorar significativamente o desempenho da consulta. Se uma consulta PolyBase estiver a ser executada lentamente, deve determinar se o pushdown da sua consulta PolyBase está a ocorrer.
Existem três cenários diferentes onde o pushdown pode ser observado no plano de execução:
- Pressão de predicado de filtro
- Junte-se ao pushdown
- Redução de agregação
Observação
Há limitações sobre o que pode ser empurrado para fontes de dados externas com cálculos de pushdown do PolyBase:
- Algumas funções do T-SQL podem impedir o pushdown, para mais informações, consulte recursos e limitações do PolyBase.
- Para obter uma lista de funções T-SQL que podem ser empurradas para baixo, consulte Pushdown computations in PolyBase.
Dois novos recursos do SQL Server 2019 (15.x) foram introduzidos para permitir que os administradores determinem se uma consulta PolyBase está sendo transferida para a fonte de dados externa:
- Exibir o Plano de Execução Estimado com o sinalizador de rastreamento 6408
- Visualizar o
read_commandna vista de gestão dinâmica 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.
Utilize 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 SQL Server Management Studio (SSMS):
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 só funciona com planos de execução estimados e não tem 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 está à direita de outro operador, diz-se que o "precede". Se um operador está à esquerda de outro operador, diz-se 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 seguintes cenários para determinar se o pushdown ocorreu.
Cada um dos exemplos abaixo inclui a saída do SSMS e do Azure Data Studio.
Redução do predicado de filtro (visualizar 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 estiver ocorrendo pushdown do predicado do filtro, o operador do filtro estará antes do operador externo. Quando o operador de filtro está antes do operador externo, a filtragem ocorreu antes de ser selecionado de volta da fonte de dados externa, indicando que o predicado do filtro foi empurrado para baixo.
Com a aplicação do predicado de filtro (vista com plano de execução)
Com o Sinalizador de Rastreamento 6408 habilitado, agora você vê 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 da consulta remota é representada como um plano de consulta único. Por exemplo:
Sem aplicação de predicado de filtro (vista com plano de execução)
Se a propagação do predicado do filtro não estiver ocorrendo, o filtro ficará posicionado 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 JUNÇÃO
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 empurrado para baixo para a fonte de dados externa, o operador Join estará antes do operador externo. Neste exemplo, [BusinessEntity] e [BusinessEntityAddress] são tabelas externas.
Com inserção para baixo de junção (visualizar com plano de execução)
O plano de execução estimado do SSMS:
O plano de execução estimado do Azure Data Studio:
Sem pushdown de junção (ver o plano de execução)
Se o JOIN não for empurrado para baixo para a fonte de dados externa, o operador Join estará atrás do operador externo. No SQL Server Management Studio (SSMS), o operador externo está no plano de consulta para o sp_execute_memo_node, que se encontra no operador de Consulta Remota da Consulta 1. No Azure Data Studio, o operador Join está após o(s) operador(es) externo(s).
O plano de execução estimado do SSMS:
O plano de execução estimado do Azure Data Studio:
Empurrar para baixo de agregação (vista com plano de execução)
Considere a seguinte consulta, que usa uma função agregada:
SELECT SUM([Quantity]) as Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];
Com agregação otimizada por pushdown (visualizar com plano de execução)
Se o 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 empurrada para baixo.
O plano de execução estimado do SSMS:
O plano de execução estimado do Azure Data Studio:
Sem pushdown para agregação (visualizar com plano de execução)
Se o pushdown da agregação não estiver ocorrendo, o operador de agregação estará após o operador externo.
O plano de execução estimado do SSMS:
O plano de execução estimado do Azure Data Studio:
Use o DMV
Com o SQL Server 2019 (15.x) e versões posteriores, a coluna read_command do DMV sys.dm_exec_external_work mostra a consulta enviada para a fonte de dados externa. Isso permite determinar se o pushdown está ocorrendo, mas não expõe o plano de execução. A visualização da consulta remota não requer TF6408.
Observação
Para o armazenamento do Hadoop e do Azure, o 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 no Detran é limitado a 4000 caracteres. Se a consulta for suficientemente longa, o read_command pode ser truncado antes que você veja a função WHERE/JOIN/agregação no read_command.
Pushdown do predicado do filtro (visualizar com DMV)
Considere a consulta usada no exemplo de predicado de filtro anterior:
SELECT *
FROM [Person].[BusinessEntity] be
WHERE be.BusinessEntityID = 17907;
Com pushdown de filtro (ver com DMV)
Você pode saber se o pushdown do predicado do filtro está ocorrendo verificando o read_command no Detran. Você verá algo como 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 do filtro está sendo avaliado na fonte de dados externa. A filtragem no conjunto de dados ocorreu na fonte de dados externa e apenas o conjunto de dados filtrado foi recuperado pelo PolyBase.
Sem pushdown de filtro (ver com 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 do filtro não é empurrado para baixo. 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 (ver com Vista de Gestão Dinâmica)
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 junção (visualizar com DMV)
Se o JOIN for empurrado para baixo 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 para a fonte de dados externa, portanto, a JOIN é empurrada 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 (ver 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 (ver com DMV)
Considere a seguinte consulta, que usa uma função agregada:
SELECT SUM([Quantity]) as Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];
Com aplicação de pushdown na agregação (ver com visões de gerenciamento dinâmico - DMV)
Se estiver ocorrendo pushdown da agregação, 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 para a fonte de dados externa, de modo que a agregação é empurrada para baixo. A agregação ocorreu na fonte de dados externa e apenas o conjunto de dados agregado foi recuperado pelo PolyBase.
Sem pushdown de agregação (ver com DGV)
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 realizada no SQL Server, depois que o conjunto de dados não agregados foi recuperado pelo PolyBase.