Teilen über

Erkennen, ob ein externer Pushdown aufgetreten ist

In diesem Artikel wird erläutert, wie Sie ermitteln können, ob eine PolyBase-Abfrage von Pushdown auf die externe Datenquelle profitiert. Weitere Informationen zum externen Pushdown finden Sie unter Pushdownberechnungen in PolyBase.

Profitiert meine Abfrage von externem Pushdown?

Die Pushdown-Komputation verbessert die Leistung von Abfragen für externe Datenquellen. Bestimmte Berechnungsaufgaben werden an die externe Datenquelle delegiert, anstatt an den SQL Server zu übertragen. Insbesondere in den Fällen von Filter- und Join-Pushdown kann die Arbeitsauslastung der SQL Server-Instanz erheblich verringert werden.

Die PolyBase-Pushdownberechnung kann die Leistung der Abfrage erheblich verbessern. Wenn eine PolyBase-Abfrage langsam ausgeführt wird, sollten Sie feststellen, ob ein Pushdown in Ihrer PolyBase-Abfrage erfolgt.

Es gibt drei verschiedene Szenarien, in denen Pushdown im Ausführungsplan beobachtet werden kann:

  • Filter-Prädikat-Pushdown
  • Am Pushdown teilnehmen
  • Aggregations-Pushdown

Hinweis

Es gibt Einschränkungen, was mit PolyBase-Pushdownberechnungen auf externe Datenquellen übertragen werden kann:

Es wurden zwei neue Features von SQL Server 2019 (15.x) eingeführt, damit Administratoren ermitteln können, ob eine PolyBase-Abfrage an die externe Datenquelle übertragen wird:

Dieser Artikel enthält Details zur Verwendung dieser beiden Anwendungsfälle für jedes von drei Pushdownszenarien.

Verwenden Sie TF6408

Standardmäßig macht der geschätzte Ausführungsplan den Remoteabfrageplan nicht verfügbar, und es wird nur das Remoteabfrageoperatorobjekt angezeigt. Beispiel: ein geschätzter Ausführungsplan aus SQL Server Management Studio (SSMS):

Screenshot eines geschätzten Ausführungsplans in SSMS.

Oder in Azure Data Studio:

Screenshot eines geschätzten Ausführungsplans aus Azure Data Studio.

Ab SQL Server 2019 (15.x) können Sie ein neues Trace-Flag 6408 global mit dem DBCC TRACEON aktivieren. Beispiel:

DBCC TRACEON (6408, -1);

Diese Ablaufverfolgungskennzeichnung funktioniert nur mit geschätzten Ausführungsplänen und hat keine Auswirkungen auf tatsächliche Ausführungspläne. Dieses Ablaufverfolgungsflag offenbart Informationen über den Remoteabfrageoperator, der zeigt, was während der Remoteabfragephase geschieht.

Ausführungspläne werden von rechts nach links gelesen, wie durch die Richtung der Pfeile angegeben. Wenn ein Operator rechts von einem anderen Operator steht, wird er als "vorgeordnet" bezeichnet. Wenn sich ein Operator links von einem anderen Operator befindet, wird gesagt, dass er diesem "folgt".

  • Markieren Sie in SSMS die Abfrage, und wählen Sie "Geschätzten Ausführungsplan anzeigen" auf der Symbolleiste aus, oder verwenden Sie STRG+L.
  • Markieren Sie in Azure Data Studio die Abfrage, und wählen Sie "Erläutern" aus. Betrachten Sie die folgenden Szenarien, um festzustellen, ob ein Pushdown stattgefunden hat.

Jedes der folgenden Beispiele enthält die Ausgabe von SSMS und Azure Data Studio.

Pushdown des Filter-Prädikats (Ansicht mit Ausführungsplan)

Betrachten Sie die folgende Abfrage, die ein Filter-Prädikat in der WHERE-Klausel verwendet:

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

Wenn ein Pushdown des Filterprädikats stattfindet, befindet sich der Filteroperator vor dem externen Operator. Wenn sich der Filteroperator vor dem externen Operator befindet, ist die Filterung aufgetreten, bevor die Auswahl aus der externen Datenquelle erfolgt ist, die angibt, dass das Filter-Prädikat nach unten verschoben wurde.

Mit Pushdown des Filter-Prädikats (Ansicht mit Ausführungsplan)

Mit aktiviertem Ablaufverfolgungskennzeichen 6408 werden nun zusätzliche Informationen in der Ausgabe des geschätzten Ausführungsplans angezeigt. Die Ausgabe variiert zwischen SSMS und Azure Data Studio.

In SSMS wird der Remoteabfrageplan im geschätzten Ausführungsplan als Abfrage 2 (sp_execute_memo_node_1) angezeigt und entspricht dem Remoteabfrageoperator in Abfrage 1. Beispiel:

Screenshot eines Ausführungsplans mit Filter-Prädikat-Pushdown in SSMS.

In Azure Data Studio wird die Remoteabfrageausführung stattdessen als einzelner Abfrageplan dargestellt. Beispiel:

Screenshot eines Ausführungsplans mit Filterprädikat-Pushdown aus Azure Data Studio.

Ohne Pushdown des Filter-Prädikats (Ansicht mit Ausführungsplan)

Wenn das Pushdown des Filter-Prädikats nicht auftritt, liegt der Filter hinter dem externen Operator.

Der geschätzte Ausführungsplan von SSMS:

Screenshot eines Ausführungsplans ohne Filter-Prädikat-Pushdown von SSMS.

Der geschätzte Ausführungsplan von Azure Data Studio:

Ein Screenshot eines Ausführungsplans ohne Prädikatenfilter-Pushdown aus Azure Data Studio.

Verarbeitungsvorverlagerung von JOIN

Betrachten Sie die folgende Abfrage, die den JOIN-Operator für zwei externe Tabellen in derselben externen Datenquelle verwendet:

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

Wenn der Join-Vorgang an die externe Datenquelle verschoben wird, befindet sich der Join-Operator vor dem externen Operator. In diesem Beispiel sind sowohl [BusinessEntity] als auch [BusinessEntityAddress] externe Tabellen.

Mit Pushdown der Verknüpfung (Ansicht mit Ausführungsplan)

Der geschätzte Ausführungsplan von SSMS:

Ein Screenshot eines Ausführungsplans mit Join-Pushdown aus SSMS.

Der geschätzte Ausführungsplan von Azure Data Studio:

Screenshot eines Ausführungsplans mit Join-Pushdown aus Azure Data Studio.

Ohne Pushdown der Verknüpfung (Ansicht mit Ausführungsplan)

Wenn der JOIN nicht zur externen Datenquelle hinuntergeschoben wird, kommt der Join-Operator nach dem externen Operator. In SSMS befindet sich der External Operator im Abfrageplan für sp_execute_memo_node, der sich im Remote Query Operator in Abfrage 1 befindet. In Azure Data Studio liegt der Join-Operator hinter dem externen Operator(n).

Der geschätzte Ausführungsplan von SSMS:

Ein Screenshot eines Ausführungsplans ohne Join-Pushdown von SSMS.

Der geschätzte Ausführungsplan von Azure Data Studio:

Ein Screenshot eines Ausführungsplans ohne Join-Pushdown aus Azure Data Studio.

Verlagerung der Aggregation (Darstellung mit Ausführungsplan)

Betrachten Sie die folgende Abfrage, die eine Aggregatfunktion verwendet:

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

Mit Pushdown der Aggregation (Ansicht mit Ausführungsplan)

Wenn der Pushdown der Aggregation erfolgt, liegt der Aggregationsoperator vor dem externen Operator. Wenn sich der Aggregationsoperator vor dem externen Operator befindet, fand die Aggregation statt, bevor die Auswahl erneut aus der externen Datenquelle abgerufen wurde, was darauf hinweist, dass die Aggregation nach unten verschoben wurde.

Der geschätzte Ausführungsplan von SSMS:

Screenshot eines Ausführungsplans mit aggregiertem Pushdown von SSMS.

Der geschätzte Ausführungsplan von Azure Data Studio:

Screenshot eines Ausführungsplans mit aggregiertem Pushdown aus Azure Data Studio.

Ohne Pushdown der Aggregation (Ansicht mit Ausführungsplan)

Wenn der Pushdown der Aggregation nicht erfolgt, liegt der Aggregationsoperator nach dem externen Operator.

Der geschätzte Ausführungsplan von SSMS:

Screenshot eines Ausführungsplans ohne aggregierten Pushdown von SSMS.

Der geschätzte Ausführungsplan von Azure Data Studio:

Screenshot eines Ausführungsplans ohne aggregierten Pushdown von Azure Data Studio.

Verwende DMV

In sql Server 2019 (15.x) und höheren Versionen zeigt die read_command Spalte sys.dm_exec_external_work DMV die Abfrage an, die an die externe Datenquelle gesendet wird. Auf diese Weise können Sie ermitteln, ob ein Pushdown auftritt, allerdings wird der Ausführungsplan nicht angezeigt. Das Anzeigen der Remoteabfrage erfordert keine TF6408.

Hinweis

Für Hadoop und Azure Storage gibt die read_command immer NULL zurück.

Sie können die folgende Abfrage ausführen und die Tags start_time, /, end_time sowie read_command verwenden, um die zu untersuchende Abfrage zu identifizieren.

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

Hinweis

Eine Einschränkung der sys.dm_exec_external_work-Methode besteht darin, dass das read_command Feld im DMV auf 4000 Zeichen beschränkt ist. Wenn die Abfrage ausreichend lang ist, kann die read_command abgeschnitten werden, bevor die WHERE-, JOIN- oder Aggregationsfunktion im read_command-Bereich dargestellt wird.

Pushdown des Filter-Prädikats (Ansicht mit DMV)

Betrachten Sie die abfrage, die im vorherigen Filter-Prädikatbeispiel verwendet wird:

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

Mit Pushdown des Filters (Ansicht mit DMV)

Sie können feststellen, ob der Pushdown des Filter-Prädikats erfolgt, indem Sie das read_command des DMVs prüfen. Sie sehen etwas wie dieses Beispiel:

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;

Die WHERE-Klausel befindet sich im Befehl, der an die externe Datenquelle gesendet wird, was bedeutet, dass das Filter-Prädikat an der externen Datenquelle ausgewertet wird. Das Filtern des Datasets erfolgte in der externen Datenquelle, und nur das gefilterte Dataset wurde von PolyBase abgerufen.

Ohne Pushdown des Filters (Ansicht mit DMV)

Wenn der Pushdown nicht erfolgt, sehen Sie etwas wie:

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

Es gibt keine WHERE-Klausel im Befehl, der an die externe Datenquelle gesendet wird, sodass das Filter-Prädikat nicht nach unten verschoben wird. Das Filtern des gesamten Datasets erfolgte auf der SQL Server-Seite, nachdem das Dataset durch PolyBase abgerufen wurde.

Pushdown von JOIN (Ansicht mit DMV)

Betrachten Sie die Abfrage, die im vorherigen JOIN-Beispiel verwendet wird:

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

Mit Pushdown der Verknüpfung (Ansicht mit DMV)

Wenn das JOIN an die externe Datenquelle delegiert wird, sehen Sie etwas wie:

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;

Die JOIN-Klausel befindet sich im Befehl, der an die externe Datenquelle gesendet wird, sodass die JOIN-Taste gedrückt wird. Die Verknüpfung mit dem Dataset ist in der externen Datenquelle aufgetreten, und nur das Dataset, das der Verknüpfungsbedingung entspricht, wurde von PolyBase abgerufen.

Ohne Pushdown der Verknüpfung (Ansicht mit DMV)

Wenn der Pushdown des Joins nicht erfolgt, werden zwei verschiedene Abfragen gegen die externe Datenquelle ausgeführt:

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;

Die Verknüpfung der beiden Datasets ist auf der SQL Server-Seite aufgetreten, nachdem beide Datasets von PolyBase abgerufen wurden.

Pushdown der Aggregation (Ansicht mit DMV)

Betrachten Sie die folgende Abfrage, die eine Aggregatfunktion verwendet:

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

Mit der Pushdown-Technik für Aggregationen (Ansicht mit DMV)

Wenn der Pushdown der Aggregation erfolgt, sehen Sie die Aggregationsfunktion in der read_command. Beispiel:

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

Die Aggregationsfunktion befindet sich im Befehl, der an die externe Datenquelle gesendet wird, sodass die Aggregation nach unten verschoben wird. Die Aggregation ist an der externen Datenquelle aufgetreten, und nur das aggregierte Dataset wurde von PolyBase abgerufen.

Ohne Pushdown der Aggregation (Ansicht mit DMV)

Wenn der Aggregation-Pushdown nicht erfolgt, sehen Sie die Aggregationsfunktion nicht in der read_command. Beispiel:

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

Die Aggregation wurde in SQL Server durchgeführt, nachdem das nicht aggregierte Dataset von PolyBase abgerufen wurde.

Nächste Schritte

  • Last updated on