Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 die SQL Server-Instanz zu übertragen. Dadurch kann die Workload auf der SQL Server-Instanz insbesondere bei Filtervorgängen und Join-Pushdowns erheblich reduziert werden.
Die PolyBase-Pushdownberechnung kann die Leistung der Abfrage erheblich verbessern. Wird eine PolyBase-Abfrage langsam ausgeführt, prüfen Sie, ob für die PolyBase-Abfrage ein Pushdown erfolgt.
Sie können Pushdown im Ausführungsplan in drei verschiedenen Szenarien beobachten:
- Filter-Prädikat-Pushdown
- Am Pushdown teilnehmen
- Pushdown der Aggregation
Mit zwei neuen Features von SQL Server 2019 (15.x) können Administratoren ermitteln, ob eine PolyBase-Abfrage an die externe Datenquelle übertragen wird:
- Anzeigen Sie den geschätzten Ausführungsplan mit Traceflag 6408
- Anzeigen von
read_commandin der dynamischen Verwaltungssicht sys.dm_exec_external_work
Dieser Artikel stellt Details bereit, wie Sie diese beiden Anwendungsfälle in jedem der drei Pushdownszenarios verwenden.
Einschränkungen
Die folgenden Einschränkungen wirken sich darauf aus, was Sie mit Pushdownberechnungen in PolyBase auf externe Datenquellen übertragen können:
Einige T-SQL-Funktionen können Pushdown verhindern. Weitere Informationen finden Sie unter PolyBase-Features und -Einschränkungen.
Eine Liste der T-SQL-Funktionen, die andernfalls gedrückt werden können, finden Sie unter Pushdownberechnungen in PolyBase.
Trace-Flag 6408 verwenden
Standardmäßig macht der geschätzte Ausführungsplan den Remoteabfrageplan nicht verfügbar. Sie sehen nur das Remoteabfrageoperatorobjekt. Beispiel: ein geschätzter Ausführungsplan aus SQL Server Management Studio (SSMS):
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);
Dieses Ablaufverfolgungsflag funktioniert nur mit geschätzten Ausführungsplänen und hat keine Auswirkungen auf tatsächliche Ausführungspläne. Dieses Ablaufverfolgungsflag macht Informationen über den Remote-Query-Operator verfügbar, die zeigen, was während der Remote-Query-Phase geschieht.
Die Übersicht über den Ausführungsplan wird von rechts nach links gelesen, wie durch die Richtung der Pfeile angegeben. Wenn sich ein Operator rechts von einem anderen Operator befindet, steht er vor ihm. Wenn sich ein Operator links von einem anderen Operator befindet, steht er nach ihm.
- Markieren Sie in SSMS die Abfrage, und wählen Sie " Geschätzten Ausführungsplan anzeigen " auf der Symbolleiste aus, oder verwenden Sie STRG+L.
Jedes der folgenden Beispiele enthält die Ausgabe von SSMS.
Pushdown des Filterprädikats (mit Ausführungsplan anzeigen)
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 das Filter-Prädikat nach unten geschoben wird, erscheint der Filteroperator im Ausführungsplan vor dem externen Operator. Wenn sich der Filteroperator vor dem externen Operator befindet, erfolgt die Filterung, bevor das Abfragemodul Daten aus der externen Datenquelle abruft, was bedeutet, dass das Filter-Prädikat nach unten verschoben wird.
Erfolgter Pushdown des Filterprädikats (mit Ausführungsplan anzeigen)
Wenn Sie das Ablaufverfolgungskennzeichnung 6408 aktivieren, werden zusätzliche Informationen in der Ausgabe des geschätzten Ausführungsplans angezeigt.
In SSMS wird der Remoteabfrageplan im geschätzten Ausführungsplan als Abfrage 2 (sp_execute_memo_node_1) angezeigt. Er entspricht dem Remote-Query-Operator in Abfrage 1. Beispiel:
Nicht erfolgter Pushdown des Filterprädikats (mit Ausführungsplan anzeigen)
Wenn das Filter-Prädikat nicht gedrückt wird, wird der Filteroperator nach dem externen Operator angezeigt.
Der geschätzte Ausführungsplan von SSMS:
JOIN-Pushdown
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 das Abfragemodul den JOIN Vorgang an die externe Datenquelle überträgt, wird der Verknüpfungsoperator vor dem externen Operator angezeigt. In diesem Beispiel sind sowohl [BusinessEntity] als auch [BusinessEntityAddress] externe Tabellen.
Erfolgter Pushdown von JOIN (mit Ausführungsplan anzeigen)
Der geschätzte Ausführungsplan von SSMS:
Nicht erfolgter Pushdown von JOIN (mit Ausführungsplan anzeigen)
Wenn das Abfragemodul den JOIN Vorgang nicht an die externe Datenquelle überträgt, wird der Verknüpfungsoperator nach dem externen Operator angezeigt. In SSMS umfasst der Abfrageplan sp_execute_memo_node den externen Operator. Dieser Operator ist Teil des Remote Query Operators in Abfrage 1.
Der geschätzte Ausführungsplan von SSMS:
Pushdown der Aggregation (mit Ausführungsplan anzeigen)
Betrachten Sie die folgende Abfrage, die eine Aggregatfunktion verwendet:
SELECT SUM([Quantity]) AS Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];
Erfolgter Pushdown der Aggregation (mit Ausführungsplan anzeigen)
Wenn die Aggregation nach unten verschoben wird, wird der Aggregationsoperator vor dem externen Operator angezeigt. Wenn sich der Aggregationsoperator vor dem externen Operator befindet, wird die Aggregation ausgeführt, bevor Daten aus der externen Datenquelle ausgewählt werden, was bedeutet, dass die Aggregation nach unten verschoben wird.
Der geschätzte Ausführungsplan von SSMS:
Ohne Pushdown der Aggregation (Ansicht mit Ausführungsplan)
Wenn die Aggregation nicht nach unten verschoben wird, liegt der Aggregationsoperator hinter dem externen Operator.
Der geschätzte Ausführungsplan von SSMS:
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 Sie an die externe Datenquelle senden. Sie können feststellen, ob ein Pushdown stattfindet, aber der Ausführungsplan wird dabei nicht offengelegt. Sie benötigen das Ablaufverfolgungsflag 6408 nicht, um die Remote-Abfrage anzuzeigen.
Hinweis
Für Hadoop und Azure Storage gibt die read_command immer NULL zurück.
Führen Sie die folgende Abfrage aus und verwenden Sie die Werte start_time/end_time und read_command, um die Abfrage zu identifizieren, die Sie untersuchen.
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 4.000 Zeichen beschränkt ist. Wenn die Abfrage lang genug ist, könnte read_command abgeschnitten werden, bevor Sie die WHERE, JOIN oder eine Aggregationsfunktion in read_command sehen.
Pushdown des Filter-Prädikats (Ansicht mit DMV)
Betrachten Sie die abfrage, die im vorherigen Filter-Prädikatbeispiel verwendet wird:
SELECT *
FROM [Person].[BusinessEntity] AS be
WHERE be.BusinessEntityID = 17907;
Erfolgter Pushdown des Filters (mit DMV anzeigen)
Sie können read_command im DMV überprüfen, um festzustellen, ob der Pushdown des Filterprädikats erfolgt. Es wird ein ähnliches Beispiel für die folgende Abfrage angezeigt:
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;
Der an die externe Datenquelle gesendete Befehl enthält die WHERE Klausel, was bedeutet, dass das Filter-Prädikat an der externen Datenquelle ausgewertet wird. Das Filtern nach dem Dataset erfolgt in der externen Datenquelle, und PolyBase ruft nur das gefilterte Dataset ab.
Nicht erfolgter Pushdown des Filters (mit DMV anzeigen)
Wenn der Pushdown nicht stattfindet, sehen Sie etwas wie:
SELECT "BusinessEntityID",
"rowguid",
"ModifiedDate"
FROM "AdventureWorks2022"."Person"."BusinessEntity";
Der an die externe Datenquelle gesendete Befehl enthält keine WHERE-Klausel, sodass das Filterprädikat nicht durchgeleitet wird. Das Filtern des gesamten Datasets erfolgt auf der SQL Server-Seite, nachdem PolyBase das Dataset abgerufen hat.
Pushdown von JOIN (mit DMV anzeigen)
Betrachten Sie die im vorherigen JOIN Beispiel verwendete Abfrage:
SELECT be.BusinessEntityID,
bea.AddressID
FROM [Person].[BusinessEntity] AS be
INNER JOIN [Person].[BusinessEntityAddress] AS bea
ON be.BusinessEntityID = bea.BusinessEntityID;
Erfolgter Pushdown von JOIN (mit DMV anzeigen)
Wenn Sie JOIN nach unten zu der externen Datenquelle schieben, 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;
Der Befehl, den Sie an die externe Datenquelle senden, enthält die JOIN-Klausel, sodass die JOIN gedrückt wird. Die externe Datenquelle verarbeitet die Verknüpfung im Dataset, und PolyBase ruft nur das Dataset ab, das der Verknüpfungsbedingung entspricht.
Nicht erfolgter Pushdown von JOIN (mit DMV anzeigen)
Wenn das Pushdown des Joins nicht erfolgt, sehen Sie zwei verschiedene Abfragen, die auf der externen Datenquelle ausgeführt werden:
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 SQL Server-Seite behandelt das Verknüpfen der beiden Datasets, nachdem PolyBase beide Datasets abgerufen hat.
Pushdown der Aggregation (mit DMV anzeigen)
Betrachten Sie die folgende Abfrage, die eine Aggregatfunktion verwendet:
SELECT SUM([Quantity]) AS Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];
Erfolgter Pushdown der Aggregation (mit DMV anzeigen)
enn ein Pushdown der Aggregation stattfindet, 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 erfolgt in der externen Datenquelle, und PolyBase ruft nur das aggregierte Dataset ab.
Nicht erfolgter Pushdown der Aggregation (mit DMV anzeigen)
Wenn kein Pushdown der Aggregation erfolgt, sehen Sie die Aggregationsfunktion nicht im read_command. Beispiel:
SELECT "Quantity"
FROM "AdventureWorks2022"."Production"."ProductInventory";
PolyBase ruft das nicht aggregierte Dataset ab, und SQL Server führt die Aggregation aus.