Jak zjistit, jestli došlo k externímu snížení úrovně
Tento článek podrobně popisuje, jak určit, jestli dotaz PolyBase využívá výhod odsazení do externího zdroje dat. Další informace o externím pushdownu najdete v pushdown výpočtech v PolyBase.
Má můj dotaz výhod externího nabízení?
Zpracování s využitím pushdown zlepšuje výkon dotazů na externí zdroje dat. Některé výpočetní úlohy se delegují na externí zdroj dat místo přenesení na SQL Server. Zejména v případech filtrování a přenesení spojení může být zátěž na instanci SQL Serveru výrazně snížena.
Výpočet odsdílení změn PolyBase může výrazně zlepšit výkon dotazu. Pokud dotaz PolyBase funguje pomalu, měli byste zjistit, jestli dochází k posunu dotazu PolyBase.
Existují tři různé scénáře, kdy je možné v plánu provádění pozorovat posun:
- Využití predikátu filtru pro efektivnější zpracování dat
- Připojit se ke snižování
- Optimalizace agregace
Poznámka
Existují omezení toho, co je možné odeslat do externích zdrojů dat pomocí výpočtů PolyBase pushdown:
- Některé funkce T-SQL mohou zabránit pushdownu, pro více informací se podívejte na funkce a omezení PolyBase.
- Seznam funkcí T-SQL, které lze dále zpracovat, najdete v části Pushdown výpočty v PolyBase.
Byly zavedeny dvě nové funkce SQL Serveru 2019 (15.x), které správcům umožňují určit, jestli se dotaz PolyBase odesílá do externího zdroje dat:
- Zobrazení odhadovaného plánu provádění s příznakem trasování 6408
- Zobrazit
read_commandv dynamickém zobrazení správy sys.dm_exec_external_work
Tento článek obsahuje podrobnosti o tom, jak používat každý z těchto dvou případů použití pro každý ze tří scénářů prosazení.
Použití TF6408
Ve výchozím nastavení odhadovaný plán provádění nezpřístupňuje plán vzdáleného dotazu a zobrazí se pouze objekt operátoru vzdáleného dotazu. Například odhadovaný plán provádění ze sady SQL Server Management Studio (SSMS):
Nebo v Azure Data Studio:
Počínaje SQL Serverem 2019 (15.x) můžete globálně povolit nový příznak trasování 6408 pomocí DBCC TRACEON. Například:
DBCC TRACEON (6408, -1);
Tento příznak trasování funguje pouze s odhadovanými plány provádění a nemá žádný vliv na skutečné plány provádění. Tento příznak trasování zveřejňuje informace o operátoru vzdáleného dotazu, který ukazuje, co se děje během fáze vzdáleného dotazu.
plány provádění se čtou zprava doleva, jak ukazuje směr šipek. Pokud je operátor napravo od jiného operátoru, se říká, že je 'před ním'. Pokud je operátor nalevo od jiného operátoru, říká se, že přichází "po" něm.
- V nástroji SSMS zvýrazněte dotaz a na panelu nástrojů vyberte Zobrazit odhadovaný plán provádění nebo použijte Ctrl+L.
- V Azure Data Studio zvýrazněte dotaz a vyberte Vysvětlit. Pak zvažte následující scénáře, abyste zjistili, jestli došlo k posunu.
Každý z následujících příkladů zahrnuje výstup z SSMS a Azure Data Studia.
Posun predikátu filtru (zobrazení s plánem provádění)
Představte si následující dotaz, který v klauzuli WHERE používá predikát filtru:
SELECT *
FROM [Person].[BusinessEntity] AS be
WHERE be.BusinessEntityID = 17907;
Pokud dochází k posunu predikátu filtru, je operátor filtru před externím operátorem. Pokud je operátor filtru před externím operátorem, došlo k filtrování před výběrem zpět z externího zdroje dat, což označuje, že predikát filtru byl vložen.
S odsdílením predikátu filtru (zobrazení s plánem provádění)
S povoleným příznakem trasování 6408 teď uvidíte další informace v odhadovaném výstupu plánu provádění. Výstup se liší mezi SSMS a Azure Data Studio.
V nástroji SSMS se plán vzdáleného dotazu zobrazí v odhadovaném plánu provádění jako dotaz 2 (sp_execute_memo_node_1) a odpovídá operátoru vzdáleného dotazu v dotazu 1. Například:
V Nástroji Azure Data Studio je vzdálené spouštění dotazů místo toho reprezentováno jako jeden plán dotazu. Například:
Bez přenesení predikátu filtru (prohlédnutí s prováděcím plánem)
Pokud nedochází k propadání filtru predikátu, bude filtr následovat za externím operátorem.
Odhadovaný plán provádění z SSMS:
Odhadovaný plán provádění ze sady Azure Data Studio:
Snížení úrovně zpracování spojení
Představte si následující dotaz, který využívá operátor JOIN pro dvě externí tabulky ve stejném externím zdroji dat:
SELECT be.BusinessEntityID, bea.AddressID
FROM [Person].[BusinessEntity] AS be
INNER JOIN [Person].[BusinessEntityAddress] AS bea
ON be.BusinessEntityID = bea.BusinessEntityID;
Pokud je funkce JOIN vložena do externího zdroje dat, operátor Join bude před externím operátorem. V tomto příkladu jsou externí tabulky [BusinessEntity] i [BusinessEntityAddress].
S využitím pushdownu spojení (zobrazení s plánem provádění)
Odhadovaný plán provádění z SQL Server Management Studio (SSMS):
Odhadovaný plán provádění ze sady Azure Data Studio:
Bez přenosu spojení (zobrazení s plánem provádění)
Pokud není JOIN přesunut do externího zdroje dat, operátor JOIN bude umístěn za externím operátorem. V nástroji SSMS je externí operátor v plánu dotazu pro sp_execute_memo_node, který je v operátoru vzdáleného dotazu v dotazu 1. V Nástroji Azure Data Studio je operátor Join za externími operátory.
Odhadovaný plán provádění z nástroje SSMS:
Odhadovaný plán provádění ze sady Azure Data Studio:
Posun agregace (zobrazení s plánem provádění)
Představte si následující dotaz, který používá agregační funkci:
SELECT SUM([Quantity]) as Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];
S posunem agregace (zobrazení s plánem provádění)
Pokud dochází k posunu agregace, operátor agregace je před externím operátorem. Pokud je operátor agregace před externím operátorem, k agregaci došlo před tím, než byly data znovu vybrána z externího zdroje, což znamená, že agregace byla přenesena dolů.
Odhadovaný plán provádění z SSMS (SQL Server Management Studio):
Odhadovaný plán provádění ze sady Azure Data Studio:
Bez poklesu agregace (zobrazení s plánem provádění)
Pokud se posun agregace nevyskytuje, operátor agregace bude umístěn za externím operátorem.
Odhadovaný plán provádění z nástroje SSMS:
Odhadovaný plán provádění ze sady Azure Data Studio:
Použijte DMV
Ve verzi SQL Server 2019 (15.x) a novějších verzích sloupec read_commandsys.dm_exec_external_work DMV zobrazuje dotaz odeslaný do externího zdroje dat. To vám umožní určit, jestli dochází k "pushdown", ale nezpřístupňuje výkonný plán. Zobrazení vzdáleného dotazu nevyžaduje TF6408.
Poznámka
V případě hadoopu a úložiště Azure read_command vždy vrací NULL.
Můžete spustit následující dotaz a použít start_time/end_time a read_command k identifikaci vyšetřovaného dotazu:
SELECT execution_id, start_time, end_time, read_command
FROM sys.dm_exec_external_work
ORDER BY execution_id desc;
Poznámka
Jedním z omezení metody sys.dm_exec_external_work je, že pole read_command v zobrazení dynamické správy (DMV) je omezeno na 4 000 znaků. Pokud je dotaz dostatečně dlouhý, může dojít ke zkrácení read_command předtím, než se funkce WHERE/JOIN/agregace v read_commandzobrazí.
Posun predikátu filtru (zobrazení s DMV)
Představte si dotaz použitý v předchozím příkladu predikátu filtru:
SELECT *
FROM [Person].[BusinessEntity] be
WHERE be.BusinessEntityID = 17907;
S odsadnutím filtru (zobrazení s dmV)
To, jestli se nachází posun predikátu filtru, zjistíte tak, že zkontrolujete read_command v zobrazení dynamické správy. Zobrazí se něco podobného jako v této ukázce:
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;
Klauzule WHERE je v příkazu odeslaném do externího zdroje dat, což znamená, že predikát filtru se vyhodnocuje v externím zdroji dat. Filtrování datové sady proběhlo v externím zdroji dat a PolyBase načetl pouze filtrovanou datovou sadu.
Bez odsunutí filtru (zobrazení s DMV)
Pokud k použití zásobníku nedochází, uvidíte něco jako:
SELECT "BusinessEntityID","rowguid","ModifiedDate" FROM "AdventureWorks2022"."Person"."BusinessEntity"
V příkazu odeslaném do externího zdroje dat není klauzule WHERE, takže predikát filtru není přenesen. Filtrování celé datové sady probíhalo na úrovni SQL Serveru po jejím načtení pomocí PolyBase.
Odsadení funkce JOIN (zobrazení s zobrazením dynamické správy)
Představte si dotaz použitý v předchozím příkladu JOIN:
SELECT be.BusinessEntityID, bea.AddressID
FROM [Person].[BusinessEntity] be
INNER JOIN [Person].[BusinessEntityAddress] bea ON be.BusinessEntityID = bea.BusinessEntityID;
S prosunutím spojení (zobrazení s DMV)
Pokud je JOIN přesunut na externí zdroj dat, zobrazí se něco takového:
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;
Klauzule JOIN je v příkazu odeslaném do externího zdroje dat, takže funkce JOIN se odešle dolů. Spojení s datovou sadou proběhlo u externího zdroje dat a PolyBase načetl pouze tu datovou sadu, která odpovídá podmínce spojení.
Bez optimalizace spojení (zobrazení s DMV)
Pokud nedochází k prosazení spojení, můžete vidět, že pro externí zdroj dat jsou spuštěny dva různé dotazy:
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;
Ke spojení těchto dvou datových sad došlo na straně SQL Serveru po načtení obou datových sad PolyBase.
Posun agregace (zobrazení s zobrazením dynamické správy)
Představte si následující dotaz, který používá agregační funkci:
SELECT SUM([Quantity]) as Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];
S posunem agregace (zobrazení pomocí DMV)
Pokud dochází k posunu agregace, zobrazí se v read_commandfunkce agregace . Například:
SELECT [T1_1].[col] AS [col] FROM (SELECT SUM([T2_1].[Quantity]) AS [col]
FROM [AdventureWorks2022].[Production].[ProductInventory] AS T2_1) AS T1_1
Agregační funkce je v příkazu odeslaném do externího zdroje dat, takže je agregace posunutá dolů. K agregaci došlo u externího zdroje dat a PolyBase načetla pouze agregovanou datovou sadu.
Bez odsouvání agregace (zobrazení s DMV)
Pokud k poklesu agregace nedojde, v read_commandse funkce agregace nezobrazí. Například:
SELECT "Quantity" FROM "AdventureWorks2022"."Production"."ProductInventory"
Agregace byla provedena na SQL Serveru poté, co PolyBase načetla neagregovanou datovou sadu.