Comment savoir si un pushdown externe s’est produit

Cet article explique comment déterminer si une requête PolyBase tire parti d’un pushdown vers la source de données externe. Pour plus d’informations sur le pushdown externe, consultez Calculs pushdown dans PolyBase.

Ma requête bénéficie-t-elle d’un pushdown externe ?

Le calcul pushdown améliore les performances des requêtes sur les sources de données externes. Certaines tâches de calcul sont déléguées à la source de données externe au lieu d’être dirigées vers SQL Server. En particulier dans les cas de filtrage et de pushdown des jointures, la charge de travail sur l’instance SQL Server peut être considérablement réduite.

Le calcul pushdown PolyBase peut améliorer considérablement les performances de la requête. Si l’exécution d’une requête PolyBase est lente, vous devez déterminer si un pushdown de votre requête PolyBase se produit.

Il existe trois scénarios différents dans lesquels il est possible d’observer un pushdown dans le plan d’exécution :

• Pushdown de prédicat de filtre
• Pushdown de jointure
• Pushdown d’agrégation

Note

Il existe des limitations sur ce qui peut faire l’objet d’un push vers des sources de données externes avec des calculs pushdown PolyBase :

• Certaines fonctions T-SQL peuvent empêcher le pushdown. Pour plus d’informations, consultez Fonctionnalités et limitations de PolyBase.
• Pour obtenir la liste des fonctions T-SQL qui peuvent faire l’objet d’un pushdown, consultez Calculs pushdown dans PolyBase.

Deux nouvelles fonctionnalités de SQL Server 2019 (15.x) ont été introduites pour permettre aux administrateurs de déterminer si une requête PolyBase est envoyée vers la source de données externe :

• Consulter le Plan d’exécution estimé avec l’indicateur de trace 6408
• Consulter read_command dans la vue de gestion dynamique sys.dm_exec_external_work

Cet article fournit des détails sur l’utilisation de chacun de ces deux cas d’usage, pour chacun des trois scénarios pushdown.

Utiliser TF6408

Par défaut, le plan d’exécution estimé n’expose pas le plan de requête distant et vous ne voyez que l’objet d’opérateur de requête distant. Par exemple, un plan d’exécution estimé issu de SSMS (SQL Server Management Studio) :

Ou dans Azure Data Studio :

À compter de SQL Server 2019 (15.x), vous pouvez activer un nouvel indicateur de trace 6408 globalement à l’aide de DBCC TRACEON. Par exemple :

DBCC TRACEON (6408, -1);  

Cet indicateur de trace fonctionne uniquement avec les plans d’exécution estimés et n’a aucun effet sur les plans d’exécution réels. Cet indicateur de trace expose des informations sur l’opérateur De requête distante qui montre ce qui se passe pendant la phase de requête distante.

Les plans d’exécution sont lus de droite à gauche, comme indiqué par le sens des flèches. Si un opérateur se trouve à droite d’un autre opérateur, il est dit qu’il est « avant » celui-ci. Si un opérateur se trouve à gauche d’un autre opérateur, il est dit qu’il est « après » celui-ci.

• Dans SSMS, mettez en surbrillance la requête et sélectionnez Afficher le plan d’exécution estimé dans la barre d’outils ou utilisez Ctrl+L.
• Dans Azure Data Studio, mettez en surbrillance la requête et sélectionnez Expliquer. Prenez ensuite en compte les scénarios suivants pour déterminer si le pushdown s’est produit.

Chacun des exemples ci-dessous inclut la sortie de SSMS et d’Azure Data Studio.

Pushdown de prédicat de filtre (affichage avec le plan d’exécution)

Examinez la requête suivante, qui utilise un prédicat de filtre dans la clause WHERE :

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

Si un pushdown du prédicat de filtre se produit, l’opérateur de filtre est avant l’opérateur externe. Lorsque l’opérateur de filtre est avant l’opérateur externe, le filtrage s’est produit avant d’être sélectionné à partir de la source de données externe, indiquant que le prédicat de filtre a été poussé vers le bas.

Avec un pushdown de prédicat de filtre (affichage avec le plan d’exécution)

Lorsque l’indicateur de trace 6408 est activé, vous voyez maintenant des informations supplémentaires dans la sortie du plan d’exécution estimé. La sortie varie entre SSMS et Azure Data Studio.

Dans SSMS, le plan de requête distant s’affiche dans le plan d’exécution estimé en tant que requête 2 (sp_execute_memo_node_1) et correspond à l’opérateur de requête distante dans la requête 1. Par exemple :

Dans Azure Data Studio, l’exécution de la requête distante est représentée sous la forme d’un plan de requête unique. Par exemple :

Sans pushdown de prédicat de filtre (affichage avec le plan d’exécution)

Si aucun pushdown de prédicat de filtre ne se produit, le filtre sera après l’opérateur externe.

Le plan d’exécution estimé issu de SSMS :

Le plan d’exécution estimé issu d’Azure Data Studio :

Pushdown de JOIN

Considérez la requête suivante qui utilise l’opérateur JOIN pour deux tables externes sur la même source de données externe :

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

Si la jointure (JOIN) fait l’objet d’un pushdown vers la source de données externe, l’opérateur de jointure est placé avant l’opérateur externe. Dans cet exemple, les deux [BusinessEntity] sont [BusinessEntityAddress] des tables externes.

Avec un pushdown de jointure (affichage avec le plan d’exécution)

Le plan d’exécution estimé issu de SSMS :

Le plan d’exécution estimé issu d’Azure Data Studio :

Sans pushdown de jointure (affichage avec le plan d’exécution)

Si la jointure (JOIN) ne fait pas l’objet d’un pushdown vers la source de données externe, l’opérateur de jointure est placé après l’opérateur externe. Dans SSMS, l’opérateur externe se trouve dans le plan de requête pour sp_execute_memo_node, qui se trouve dans l’opérateur De requête distante dans La requête 1. Dans Azure Data Studio, l’opérateur de jointure est après le ou les opérateurs externes.

Le plan d’exécution estimé issu de SSMS :

Le plan d’exécution estimé issu d’Azure Data Studio :

Pushdown d’agrégation (affichage avec le plan d’exécution)

Examinez la requête suivante, qui utilise une fonction d’agrégation :

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

Avec pushdown d’agrégation (affichage avec le plan d’exécution)

Si le pushdown de l’agrégation se produit, l’opérateur d’agrégation est avant l’opérateur externe. Lorsque l’opérateur d’agrégation est avant l’opérateur externe, l’agrégation s’est produite avant d’être sélectionnée à partir de la source de données externe, indiquant que l’agrégation a été poussée vers le bas.

Le plan d’exécution estimé issu de SSMS :

Le plan d’exécution estimé issu d’Azure Data Studio :

Sans pushdown d’agrégation (affichage avec le plan d’exécution)

Si un pushdown de l’agrégation ne se produit pas, l’opérateur d’agrégation est après l’opérateur externe.

Le plan d’exécution estimé issu de SSMS :

Le plan d’exécution estimé issu d’Azure Data Studio :

Utiliser DMV

Avec SQL Server 2019 (15.x) et versions ultérieures, la read_command colonne de sys.dm_exec_external_work DMV affiche la requête envoyée à la source de données externe. Cela vous permet de déterminer si le pushdown se produit, mais n’expose pas le plan d’exécution. L’affichage de la requête distante ne nécessite pas TF6408.

Note

Pour le stockage Hadoop et Azure, read_command retourne toujours NULL.

Vous pouvez exécuter la requête suivante et utiliser start_time/end_time et read_command pour identifier la requête actuellement examiné :

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

Note

Une limitation de la méthode sys.dm_exec_external_work est que le champ read_command dans la vue de gestion dynamique est limité à 4 000 caractères. Si la requête est suffisamment longue, la valeur read_command peut être tronquée avant que la fonction WHERE/JOIN/agrégation ne s’affiche dans read_command.

Pushdown de prédicat de filtre (affichage avec la vue de gestion dynamique)

Examinez la requête utilisée dans l’exemple de prédicat de filtre précédent :

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

Avec pushdown de filtre (affichage avec la vue de gestion dynamique)

Vous pouvez savoir si le pushdown du prédicat de filtre se produit en vérifiant le read_command DMV. Un résultat semblable à cet exemple s’affiche :

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;

La clause WHERE est dans la commande envoyée à la source de données externe, ce qui signifie que le prédicat de filtre est évalué au niveau de la source de données externe. Le filtrage sur le jeu de données s’est produit au niveau de la source de données externe, et seul le jeu de données filtré a été récupéré par PolyBase.

Sans pushdown de filtre (affichage avec la vue de gestion dynamique)

Si aucun pushdown ne se produit, vous devez voir quelque chose semblable à ceci :

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

Comme il n’y a pas de clause WHERE dans la commande envoyée à la source de données externe, le prédicat de filtre ne fait pas l’objet d’un pushdown. Le filtrage sur l’ensemble du jeu de données s’est produit côté SQL Server, après récupération du jeu de données par PolyBase.

Pushdown de jointure (JOIN) (affichage avec la vue de gestion dynamique)

Examinez la requête utilisée dans l’exemple de jointure (JOIN) précédent :

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

Avec pushdown de jointure (affichage avec la vue de gestion dynamique)

Si la jointure (JOIN) fait l’objet d’un pushdown vers la source de données externe, un résultat semblable à ce qui suit s’affiche :

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;

Comme la clause JOIN est dans la commande envoyée à la source de données externe, la jointure (JOIN) fait l’objet d’un pushdown. La jointure sur le jeu de données s’est produite au niveau de la source de données externe, et seul le jeu de données qui correspond à la condition de jointure a été récupéré par PolyBase.

Sans pushdown de jointure (affichage avec la vue de gestion dynamique)

Si le pushdown de la jointure ne se produit pas, vous constatez que deux requêtes différentes sont exécutées sur la source de données externe :

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;

La jointure des deux jeux de données s’est produite côté SQL Server, une fois les deux jeux de données récupérés par PolyBase.

Pushdown d’agrégation (affichage avec la vue de gestion dynamique)

Examinez la requête suivante, qui utilise une fonction d’agrégation :

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

Avec pushdown d’agrégation (affichage avec la vue de gestion dynamique)

Si le pushdown de l’agrégation se produit, vous voyez la fonction d’agrégation dans le read_command. Par exemple :

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

Comme la fonction d’agrégation se trouve dans la commande envoyée à la source de données externe, l’agrégation fait l’objet d’un pushdown. L’agrégation s’est produite au niveau de la source de données externe, et seul le jeu de données agrégé a été récupéré par PolyBase.

Sans pushdown d’agrégation (affichage avec la vue de gestion dynamique)

Si le pushdown de l’agrégation ne se produit pas, la fonction d’agrégation ne s’affiche pas dans read_command. Par exemple :

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

L’agrégation a été effectuée dans SQL Server, après la récupération du jeu de données non agrégé par PolyBase.

Étapes suivantes

• Résolution des problèmes liés à PolyBase
• Erreurs de configuration de PolyBase et solutions possibles