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 transfert externe, consultez les calculs de transfert dans PolyBase.

Ma requête tire-t-elle parti d’un pushdown externe ?

Le calcul pushdown améliore les performances des requêtes sur des 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 apportées à SQL Server. En particulier dans les cas de filtrage et de poussée de jointure, la charge de travail sur l’instance SQL Server peut être considérablement réduite.

Le calcul de poussée vers le bas PolyBase peut optimiser fortement les performances de la requête. Si une requête PolyBase s’exécute lentement, vous devez déterminer si le pushdown de votre requête PolyBase se produit.

Il existe trois scénarios différents où le pushdown peut être observé dans le plan d’exécution :

• Pushdown de prédicat de filtrage
• Optimisation de jointure par pushdown
• Pushdown d’agrégation

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 :

• Afficher le plan d’exécution estimé avec l’indicateur de trace 6408
• Afficher 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’opérateur de requête distant. Par exemple, un plan d’exécution estimé de SQL Server Management Studio (SSMS) :

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 la direction des flèches. Si un opérateur est à droite d'un autre opérateur, on dit qu'il le précède. Si un opérateur est à gauche d’un autre opérateur, il est dit qu’il est « derrière ».

• 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 du prédicat de filtre (affichage avec plan d’exécution)

Considérez 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 précède l’opérateur externe, le filtrage a lieu avant la sélection depuis la source de données externe, ce qui indique que le prédicat de filtre a été appliqué en amont.

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

Avec l’indicateur de trace 6408 activé, vous voyez maintenant des informations supplémentaires dans la sortie estimée du plan d’exécution. 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 requête distante est plutôt représentée en tant que plan de requête unique. Par exemple:

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

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

Plan d’exécution estimé de SSMS :

Plan d’exécution estimé d’Azure Data Studio :

Réduction 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 est envoyée vers la source de données externe, l’opérateur de jointure sera placé avant l’opérateur externe. Dans cet exemple, [BusinessEntity] et [BusinessEntityAddress] sont des tables externes.

Avec optimisation par pushdown de l'opération de jointure (visualisation avec plan d'exécution)

Plan d’exécution estimé de SSMS :

Plan d’exécution estimé d’Azure Data Studio :

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

Si la jointure n’est pas envoyée vers la source de données externe, l’opérateur de jointure sera 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 Join est après le ou les opérateurs externes.

Plan d’exécution estimé de SSMS :

Plan d’exécution estimé d’Azure Data Studio :

"Intégration descendante des agrégations (exécution planifiée)"

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

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

Avec optimisation de l’agrégation (affichage du plan d’exécution)

Si une opération de "pushdown" de l’agrégation a lieu, l’opérateur d’agrégation se trouve 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.

Plan d’exécution estimé de SSMS :

Plan d’exécution estimé d’Azure Data Studio :

Sans application d’agrégation en priorité (visualisation avec plan d’exécution)

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

Plan d’exécution estimé de SSMS :

Plan d’exécution estimé 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.

Vous pouvez exécuter la requête suivante et utiliser les start_time/end_time ainsi que read_command pour identifier la requête en cours d'examen :

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

Cascadage du filtre de prédicat (vue avec DMV)

Considérez 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 réduction de filtre (affichage avec DMV)

Vous pouvez savoir si le pushdown du prédicat de filtre se produit en vérifiant le read_command DMV. Vous verrez quelque chose comme cet exemple :

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 se trouve dans la commande envoyée à la source de données externe, ce qui signifie que le prédicat de filtre est évalué à la source de données externe. Le filtrage sur le jeu de données s’est produit à la source de données externe, et seul le jeu de données filtré a été récupéré par PolyBase.

Sans optimisation de filtre (affichage avec DMV)

Si le pushdown ne se produit pas, vous verrez quelque chose comme suit :

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

Il n’existe aucune clause WHERE dans la commande envoyée à la source de données externe. Par conséquent, le prédicat de filtre n’est pas poussé vers le bas. Le filtrage sur l’ensemble du jeu de données s’est produit côté SQL Server, après la récupération du jeu de données par PolyBase.

Réduction de JOIN (vue avec VGD)

Considérez la requête utilisée dans l’exemple JOIN précédent :

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

Avec le pushdown de jointure (affichage avec DMV)

Si la jointure est envoyée à la source de données externe, vous verrez quelque chose comme suit :

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;

La clause JOIN se trouve dans la commande envoyée à la source de données externe. La clause JOIN est donc envoyée vers le bas. La jointure sur le jeu de données s’est produite à 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 DMV)

Si le pushdown de la jointure ne se produit pas, vous constaterez que deux requêtes distinctes 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.

Propagation des agrégations (vue avec DMV)

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

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

Avec exécution poussée d'agrégation (affichage avec DMV)

Si le déplacement vers la base 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

La fonction d’agrégation se trouve dans la commande envoyée à la source de données externe, de sorte que l’agrégation est envoyée vers le bas. 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 optimisation par pushdown de l'agrégation (vue avec DMV)

Si le pushdown de l’agrégation ne se produit pas, vous ne verrez pas la fonction d’agrégation dans le 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 de PolyBase
• Erreurs PolyBase et solutions possibles