Partager via

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 délestage externe, consultez les calculs de délestage utilisés 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 à l’instance 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 pushdown PolyBase peut améliorer considérablement les performances de la requête. Si une requête PolyBase s’exécute lentement, vérifiez si le pushdown de votre requête PolyBase se produit.

Vous pouvez observer le pushdown dans le plan d’exécution à travers trois scénarios différents :

  • 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) permettent aux administrateurs de déterminer si une requête PolyBase est envoyée à la source de données externe :

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

Limites

Les limitations suivantes affectent ce que vous pouvez pousser vers des sources de données externes avec des calculs pushdown dans PolyBase :

Utiliser l’indicateur de trace 6408

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

Capture d’écran d’un plan d’exécution estimé dans SSMS.

À 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 la requête distante.

La vue d’ensemble du plan d’exécution est lue de droite à gauche, comme indiqué par la direction des flèches. Si un opérateur est à droite d’un autre opérateur, il est avant lui. Si un opérateur est à gauche d’un autre opérateur, il est après lui.

  • 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.

Chacun des exemples suivants inclut la sortie de SSMS.

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 le prédicat de filtre est poussé vers le bas, l’opérateur de filtre s’affiche avant l’opérateur externe dans le plan d’exécution. Lorsque l’opérateur de filtre est avant l’opérateur externe, le filtrage se produit avant que le moteur de requête récupère les données de la source de données externe, ce qui signifie que le prédicat de filtre est poussé vers le bas.

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

Lorsque vous activez l’indicateur de trace 6408, vous voyez des informations supplémentaires dans la sortie estimée du plan d’exécution.

Dans SSMS, le plan de requête distant apparaît sous la forme Requête 2 (sp_execute_memo_node_1) dans le plan d’exécution estimé. Cela correspond à l'opérateur de requête distante dans la requête 1. Par exemple:

Capture d’écran d’un plan d’exécution avec pushdown de prédicat de filtre depuis SSMS.

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

Si le prédicat de filtre n’est pas poussé vers le bas, l’opérateur de filtre apparaît après l’opérateur externe.

Plan d’exécution estimé de SSMS :

Capture d’écran d’un plan d’exécution sans application de critères de filtrage depuis SSMS.

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 le moteur de requête envoie (push) l’opération JOIN à la source de données externe, l’opérateur Join s’affiche 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 :

Capture d'écran d’un plan d’exécution avec join pushdown à partir de SSMS.

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

Si le moteur de requête n’envoie pas l’opération JOIN à la source de données externe, l’opérateur Join apparaît après l’opérateur externe. Dans SSMS, le plan de requête pour sp_execute_memo_node inclut l’opérateur externe. Cet opérateur fait partie de l'opérateur de requête distante dans la requête 1.

Plan d’exécution estimé de SSMS :

Capture d’écran d’un plan d’exécution sans poussée de jointure à partir de SSMS.

"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 l’agrégation est poussée vers le bas, l’opérateur d’agrégation s’affiche avant l’opérateur externe. Lorsque l’opérateur d’agrégation est avant l’opérateur externe, la requête effectue l’agrégation avant de sélectionner des données à partir de la source de données externe, ce qui signifie que l’agrégation est envoyée vers le bas.

Plan d’exécution estimé de SSMS :

Capture d’écran d’un plan d’exécution avec réduction d’agrégation depuis SSMS.

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

Si l’agrégation n’est pas poussée vers le bas, l’opérateur d’agrégation est après l’opérateur externe.

Plan d’exécution estimé de SSMS :

Capture d’écran d’un plan d’exécution sans descente d’agrégation à partir de SSMS.

Utiliser DMV

Dans SQL Server 2019 (15.x) et versions ultérieures, la read_command colonne de sys.dm_exec_external_work DMV affiche la requête que vous envoyez à la source de données externe. Vous pouvez vérifier si le pushdown est en cours, mais cela n'expose pas le plan d'exécution. Vous n’avez pas besoin de l’indicateur de trace 6408 pour afficher la requête distante.

Note

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

Exécutez la requête suivante et utilisez les valeurs start_time, /, end_time, et read_command pour identifier la requête que vous examinez :

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

Note

L’une des limites de la méthode sys.dm_exec_external_work est que le champ read_command dans le DMV est limité à 4 000 caractères. Si la requête est suffisamment longue, la read_command peut être tronquée avant que vous ne voyiez le WHERE, le JOIN ou la fonction d'agrégation dans le read_command.

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] AS be
WHERE be.BusinessEntityID = 17907;

Avec réduction de filtre (affichage avec DMV)

Vous pouvez vérifier la DMV dans read_command pour voir si le pushdown du prédicat de filtre se produit. Vous voyez un exemple similaire à la requête suivante :

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 commande envoyée à la source de données externe inclut la WHERE clause, 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 se produit sur la source de données externe et PolyBase récupère uniquement le jeu de données filtré.

Sans optimisation de filtre (affichage avec DMV)

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

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

La commande envoyée à la source de données externe n’inclut pas de WHERE clause. 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 se produit côté SQL Server, une fois que PolyBase a récupéré le jeu de données.

Réduction de JOIN (vue avec VGD)

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

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

Avec le pushdown de jointure (affichage avec DMV)

Si vous descendez JOIN vers la source de données externe, vous verrez quelque chose comme ceci :

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 commande que vous envoyez à la source de données externe inclut la clause JOIN, donc JOIN est transféré vers le bas. La source de données externe gère la jointure sur le jeu de données et PolyBase récupère uniquement le jeu de données qui correspond à la condition de jointure.

Sans pushdown de jointure (affichage avec DMV)

Si l'opération de pushdown pour la jointure ne se produit pas, vous observerez l'exécution de deux requêtes distinctes 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;

Le côté SQL Server gère la jonction des deux jeux de données après que PolyBase récupère les deux jeux de données.

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 pushdown de l’agrégation (vue avec DMV)

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;

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 se produit sur la source de données externe et PolyBase récupère uniquement le jeu de données agrégé.

Sans optimisation par pushdown de l'agrégation (vue avec DMV)

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

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

PolyBase récupère le jeu de données non agrégé et SQL Server effectue l’agrégation.

Contenu connexe

  • Last updated on