Jak sprawdzić, czy wystąpiło zewnętrzne wypychanie

W tym artykule szczegółowo opisano sposób określania, czy zapytanie PolyBase korzysta z wypychania do zewnętrznego źródła danych. Aby uzyskać więcej informacji na temat wypychania zewnętrznego, zobacz obliczenia pushdown w programie PolyBase.

Czy moje zapytanie korzysta z funkcji zewnętrznego przyspieszenia?

Komputacja z wypychaniem poprawia wydajność zapytań dotyczących zewnętrznych źródeł danych. Niektóre zadania obliczeniowe są delegowane do zewnętrznego źródła danych zamiast do programu SQL Server. Szczególnie w przypadku filtrowania oraz przenoszenia operacji złączenia można znacznie zmniejszyć obciążenie instancji SQL Server.

Obliczenia wypychane polyBase mogą znacznie poprawić wydajność zapytania. Jeśli zapytanie polyBase działa wolno, należy określić, czy występuje wypychanie zapytania PolyBase.

Istnieją trzy różne scenariusze, w których można zaobserwować przesunięcie w planie wykonania.

• Wypychanie predykatu filtru
• Operacja łączenia pushdown
• Wypychanie agregacji

Notatka

Istnieją ograniczenia dotyczące tego, co można wypchnąć do zewnętrznych źródeł danych przy użyciu obliczeń wypychanych PolyBase:

• Niektóre funkcje języka T-SQL mogą uniemożliwiać przeniesienie operacji, aby uzyskać więcej informacji, zobacz funkcje i ograniczenia technologii PolyBase.
• Aby uzyskać listę funkcji języka T-SQL, które w przeciwnym razie można wypchnąć, zobacz Obliczenia wypychane w programie PolyBase.

Wprowadzono dwie nowe funkcje programu SQL Server 2019 (15.x), aby umożliwić administratorom określenie, czy zapytanie PolyBase jest wypychane do zewnętrznego źródła danych:

• Wyświetl szacowany plan wykonania z flagą śledzenia 6408
• Wyświetl read_command w widoku dynamicznego zarządzania sys.dm_exec_external_work

Ten artykuł zawiera szczegółowe informacje na temat używania każdego z tych dwóch przypadków użycia dla każdego z trzech scenariuszy pushdown.

Korzystanie z serwera TF6408

Domyślnie szacowany plan wykonywania nie uwidacznia planu zapytania zdalnego i widzisz tylko obiekt operatora zapytania zdalnego. Na przykład szacowany plan wykonania z programu SQL Server Management Studio (SSMS):

Lub w narzędziu Azure Data Studio:

Począwszy od programu SQL Server 2019 (15.x), możesz włączyć nową flagę śledzenia 6408 globalnie przy użyciu TRACEON DBCC. Na przykład:

DBCC TRACEON (6408, -1);  

Ta flaga śledzenia działa tylko z szacowanymi planami wykonywania i nie ma wpływu na rzeczywiste plany wykonania. Ta flaga śledzenia uwidacznia informacje o operatorze zapytania zdalnego, który pokazuje, co dzieje się w fazie zapytania zdalnego.

plany wykonania są odczytywane od prawej do lewej, zgodnie z kierunkiem strzałek. Jeśli jeden operator jest po prawej stronie innego operatora, mówi się, że jest "przed" nim. Jeśli operator znajduje się po lewej stronie innego operatora, mówi się, że jest "za" nim.

• W programie SSMS wyróżnij zapytanie i wybierz pozycję Wyświetl szacowany plan wykonania na pasku narzędzi lub użyj Ctrl+L.
• W narzędziu Azure Data Studio wyróżnij zapytanie i wybierz pozycję Wyjaśnij. Następnie rozważ następujące scenariusze, aby określić, czy wystąpiło wypychanie.

Każdy z poniższych przykładów zawiera dane wyjściowe z programu SSMS i narzędzia Azure Data Studio.

Przesunięcie w dół predykatu filtra (widok z planem wykonania)

Rozważ następujące zapytanie, które używa predykatu filtru w klauzuli WHERE:

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

Jeśli zachodzi wypychanie predykatu filtru, operator filtrowania jest przed operatorem zewnętrznym. Gdy operator filtru znajduje się przed operatorem zewnętrznym, filtrowanie odbyło się przed ponownym wybraniem z zewnętrznego źródła danych, co wskazuje, że predykat filtru został przekazany dalej.

Z przesunięciem predykatu filtra (widok z planem wykonania)

Po włączeniu flagi śledzenia 6408 są teraz widoczne dodatkowe informacje w danych wyjściowych szacowanych planów wykonania. Dane wyjściowe różnią się w zależności od programu SSMS i narzędzia Azure Data Studio.

W SSMS plan zapytania zdalnego jest wyświetlany w ramach szacowanego planu wykonania jako Zapytanie 2 (sp_execute_memo_node_1) i odpowiada operatorowi Zapytania zdalnego w Zapytaniu 1. Na przykład:

W narzędziu Azure Data Studio zdalne wykonywanie zapytań jest reprezentowane jako pojedynczy plan zapytania. Na przykład:

Bez wypychania predykatu filtru (widok z planem wykonywania)

Jeśli wypchnięcie predykatu filtru nie występuje, filtr będzie po operatorze zewnętrznym.

Szacowany plan wykonania z programu SSMS:

Szacowany plan wykonania z usługi Azure Data Studio:

Optymalizacja operacji JOIN

Rozważ następujące zapytanie, które korzysta z operatora JOIN dla dwóch tabel zewnętrznych w tym samym źródle danych zewnętrznych:

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

Jeśli funkcja JOIN zostanie wypchnięta do zewnętrznego źródła danych, operator sprzężenia będzie przed operatorem zewnętrznym. W tym przykładzie zarówno [BusinessEntity], jak i [BusinessEntityAddress] są tabelami zewnętrznymi.

Z wypchnięciem sprzężenia (wyświetl z planem wykonania)

Szacowany plan wykonania z programu SSMS:

Szacowany plan wykonania z usługi Azure Data Studio:

Bez wypychania sprzężenia (widok z planem wykonywania)

Jeśli funkcja JOIN nie zostanie przekazana do zewnętrznego źródła danych, operator JOIN będzie po operatorze zewnętrznym. W programie SSMS operator zewnętrzny znajduje się w planie zapytania dla sp_execute_memo_node, który znajduje się w operatorze zapytania zdalnego w zapytaniu 1. W narzędziu Azure Data Studio operator "Join" jest po operatorach zewnętrznych.

Szacowany plan wykonania z programu SSMS:

Szacowany plan wykonania z usługi Azure Data Studio:

Wypychanie agregacji (przegląd z planem wykonawczym)

Rozważ następujące zapytanie, które używa funkcji agregującej:

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

Z wypchnięciem agregacji (widok z planem wykonywania)

Jeśli występuje wypychanie agregacji, operator agregacji jest przed operatorem zewnętrznym. Gdy operator agregacji znajduje się przed operatorem zewnętrznym, agregacja miała miejsce przed pobraniem danych z powrotem z zewnętrznego źródła, wskazując, że agregacja została przeprowadzona bezpośrednio.

Szacowany plan wykonania z programu SSMS:

Szacowany plan wykonania z usługi Azure Data Studio:

Bez odpychania agregacji (widok z planem wykonania)

Jeśli przesunięcie w dół agregacji nie występuje, operator agregacji będzie po operatorze zewnętrznym.

Szacowany plan wykonania z programu SSMS:

Szacowany plan wykonania z usługi Azure Data Studio:

Użyj DMV

W SQL Server 2019 (15.x) i nowszych wersjach kolumna read_command widoku DMV sys.dm_exec_external_work pokazuje zapytanie wysyłane do zewnętrznego źródła danych. Dzięki temu można określić, czy występuje wypychanie, ale nie uwidacznia planu wykonania. Wyświetlanie zdalnego zapytania nie wymaga TF6408.

Notatka

W przypadku Hadoop i Azure Storage read_command zawsze zwraca NULL.

Możesz wykonać następujące zapytanie i użyć start_time/end_time i read_command, aby zidentyfikować badane zapytanie:

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

Notatka

Jednym z ograniczeń metody sys.dm_exec_external_work jest to, że pole read_command w widoku DMV jest ograniczone do 4000 znaków. Jeśli zapytanie jest wystarczająco długie, read_command może zostać obcięta, zanim zobaczysz funkcję WHERE/JOIN/aggregation w read_command.

Wypychanie predykatu filtru (widok z dynamicznym widokiem)

Rozważ zapytanie użyte w poprzednim przykładzie predykatu filtru:

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

Z zastosowaniem wypchnięcia filtru (podgląd przy użyciu DMV)

Możesz określić, czy występuje wypychanie predykatu filtru, sprawdzając read_command w widoku DMV. Zobaczysz coś takiego jak w tym przykładzie:

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;

Klauzula WHERE znajduje się w poleceniu wysyłanym do zewnętrznego źródła danych, co oznacza, że predykat filtru jest oceniany w zewnętrznym źródle danych. Filtrowanie zestawu danych miało miejsce w zewnętrznym źródle danych i tylko filtrowany zestaw danych został pobrany przez program PolyBase.

Bez wypychania filtru (widok z dynamicznym widokiem)

Jeśli wypychanie nie występuje, zobaczysz coś takiego jak:

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

W poleceniu wysłanym do zewnętrznego źródła danych nie ma klauzuli WHERE, więc predykat filtrowania nie jest przekazywany w dół. Filtrowanie całego zestawu danych miało miejsce po stronie programu SQL Server po pobraniu zestawu danych przez program PolyBase.

Wypychanie funkcji JOIN (widok z dynamicznym widokiem)

Rozważmy zapytanie użyte w poprzednim przykładzie JOIN:

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

Z wypchnięciem sprzężenia (widok z dynamicznym widokem zarządzania)

Jeśli funkcja JOIN zostanie wypchnięta do zewnętrznego źródła danych, zobaczysz coś takiego jak:

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;

Klauzula JOIN jest zawarta w poleceniu wysyłanym do zewnętrznego źródła danych, więc klauzula JOIN jest przekazywana w dół. Sprzężenia w zestawie danych wystąpiły w zewnętrznym źródle danych, a tylko zestaw danych zgodny z warunkiem sprzężenia został pobrany przez program PolyBase.

Bez wypychania sprzężenia (widok z dynamicznym widokiem)

Jeśli wypychanie sprzężenia nie występuje, zobaczysz, że istnieją dwa różne zapytania wykonywane względem zewnętrznego źródła danych:

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;

Łączenie dwóch zestawów danych wystąpiło po stronie programu SQL Server, po pobraniu obu zestawów danych przez program PolyBase.

Wypychanie agregacji (widok z DMV)

Rozważ następujące zapytanie, które używa funkcji agregującej:

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

Wypychanie agregacji (widok z Dynamic Management View)

Jeśli występuje wypychanie agregacji, funkcja agregacji jest widoczna w read_command. Na przykład:

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

Funkcja agregacji jest w poleceniu wysyłanym do zewnętrznego źródła danych, więc agregacja jest przekazywana w dół. Agregacja wystąpiła w zewnętrznym źródle danych, a tylko zagregowany zestaw danych został pobrany przez program PolyBase.

Bez wypychania agregacji (widok z dynamicznym widokiem)

Jeśli wypychanie agregacji nie występuje, funkcja agregacji nie będzie widoczna w read_command. Na przykład:

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

Agregacja została wykonana w programie SQL Server po pobraniu nieagregowanego zestawu danych przez program PolyBase.

Następne kroki

• Rozwiązywanie problemów z PolyBase
• błędów technologii PolyBase i możliwych rozwiązań