Come stabilire se si è verificato un pushdown esterno

Questo articolo illustra in dettaglio come determinare se una query PolyBase trae vantaggio dal pushdown all'origine dati esterna. Per altre informazioni sul pushdown esterno, vedere Calcoli con distribuzione in PolyBase.

La query trae vantaggio dal pushdown esterno?

Il calcolo con distribuzione migliora le prestazioni delle query su origini dati esterne. Alcune attività di calcolo vengono delegate all'origine dati esterna anziché essere trasportate in SQL Server. In particolare, nei casi di applicazione di filtri e pushdown di join, il carico di lavoro nell'istanza di SQL Server può venire notevolmente ridotto.

Il calcolo con distribuzione di PolyBase può migliorare significativamente le prestazioni della query. Se una query PolyBase viene eseguita lentamente, è necessario determinare se si sta eseguendo il pushdown della query PolyBase.

Esistono tre diversi scenari in cui è possibile osservare il pushdown nel piano di esecuzione:

• Pushdown del predicato filtro
• Pushdown join
• Pushdown dell'aggregazione

Sono state introdotte due nuove funzionalità di SQL Server 2019 (15.x) per consentire agli amministratori di determinare se viene eseguito il push di una query PolyBase nell'origine dati esterna:

• Visualizzare il piano di esecuzione stimato con il flag di traccia 6408
• Visualizzare read_command nella DMV sys.dm_exec_external_work

Questo articolo fornisce informazioni dettagliate su come usare ciascuno di questi due casi d'uso per ognuno dei tre scenari di pushdown.

Usare TF6408

Per impostazione predefinita, il piano di esecuzione stimato non espone il piano di query remota e viene visualizzato solo l'oggetto operatore di query remota. Ad esempio, un piano di esecuzione stimato di SQL Server Management Studio (SSMS):

Oppure in Azure Data Studio:

A partire da SQL Server 2019 (15.x), è possibile abilitare un nuovo flag di traccia 6408 a livello globale usando DBCC TRACEON. Ad esempio:

DBCC TRACEON (6408, -1);  

Questo flag di traccia funziona solo con i piani di esecuzione stimati e non ha alcun effetto sui piani di esecuzione effettivi. Questo flag di traccia espone informazioni sull'operatore di query remota che mostra cosa accade durante la fase di query remota.

I piani di esecuzione vengono letti da destra a sinistra, come indicato dalla direzione delle frecce. Se un operatore è a destra di un altro operatore, si dice che è "prima". Se un operatore è a destra di un altro operatore, si dice che è "dopo".

• In SSMS, evidenziare la query e selezionare Visualizza piano di esecuzione stimato sulla barra degli strumenti o premere CTRL+L.
• In Azure Data Studio, evidenziare la query e selezionare Spiega. Considerare quindi gli scenari seguenti per determinare se si è verificato il pushdown.

Ognuno degli esempi seguenti include l'output di SSMS e Azure Data Studio.

Pushdown del predicato di filtro (visualizzazione con piano di esecuzione)

Considerare la query seguente, che usa un predicato di filtro nella clausola WHERE:

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

Se si verifica il pushdown del predicato di filtro, l'operatore filtro è prima dell'operatore esterno. Quando l'operatore filtro è prima dell'operatore esterno, il filtro si è verificato prima di essere di nuovo selezionato dall'origine dati esterna, a indicare che è stato eseguito il push del predicato del filtro.

Con pushdown del predicato di filtro (visualizzazione con piano di esecuzione)

Con il flag di traccia 6408 abilitato, vengono ora visualizzate informazioni aggiuntive nell'output del piano di esecuzione stimato. L'output varia tra SSMS e Azure Data Studio.

In SSMS, il piano di query remota viene visualizzato nel piano di esecuzione stimato come Query 2 (sp_execute_memo_node_1) e corrisponde all'operatore di query remota 1. Ad esempio:

In Azure Data Studio, l'esecuzione di query remote viene invece rappresentata come un singolo piano di query. Ad esempio:

Senza eseguire il pushdown del predicato di filtro (visualizzazione con piano di esecuzione)

Se non si verifica il pushdown del predicato di filtro, il filtro è dopo l'operatore esterno.

Piano di esecuzione stimato da SSMS:

Piano di esecuzione stimato di Azure Data Studio:

Pushdown di JOIN

Considerare la query seguente che usa l'operatore di JOIN per due tabelle esterne nella stessa origine dati esterna:

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

Se viene eseguito il push di JOIN nell'origine dati esterna, l'operatore di Join sarà prima dell'operatore esterno. In questo esempio, sia [BusinessEntity] che [BusinessEntityAddress] sono tabelle esterne.

Con pushdown di join (visualizzazione con piano di esecuzione)

Piano di esecuzione stimato da SSMS:

Piano di esecuzione stimato di Azure Data Studio:

Senza eseguire il pushdown di join (visualizzazione con piano di esecuzione)

Se non viene eseguito il push di JOIN nell'origine dati esterna, l'operatore di Join sarà dopo l'operatore esterno. In SSMS, l'operatore esterno si trova nel piano di query per sp_execute_memo_node, che si trova nell'operatore di query remota in Query 1. In Azure Data Studio, l'operatore di Join si trova dopo gli operatori esterni.

Piano di esecuzione stimato da SSMS:

Piano di esecuzione stimato di Azure Data Studio:

Pushdown dell'aggregazione (visualizzazione con piano di esecuzione)

Considerare la query seguente, che usa una funzione di aggregazione:

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

Con il pushdown dell’aggregazione (visualizzazione con piano di esecuzione)

Se si verifica il pushdown dell'aggregazione, l'operatore di aggregazione è prima dell'operatore esterno. Quando l'operatore aggregazione è prima dell'operatore esterno, l’aggregazione si è verificata prima di essere di nuovo selezionata dall'origine dati esterna, a indicare che è stato eseguito il push del predicato dell’aggregazione.

Piano di esecuzione stimato da SSMS:

Piano di esecuzione stimato di Azure Data Studio:

Senza eseguire il pushdown dell'aggregazione (visualizzazione con piano di esecuzione)

Se il pushdown dell'aggregazione non si verifica, l'operatore di aggregazione sarà dopo l'operatore esterno.

Piano di esecuzione stimato da SSMS:

Piano di esecuzione stimato di Azure Data Studio:

Usare DMV

Con SQL Server 2019 (15.x) e versioni successive, la colonna read_command di sys.dm_exec_external_work DMV mostra la query inviata all'origine dati esterna. Ciò consente di determinare se si stia verificando il pushdown, ma non espone il piano di esecuzione. La visualizzazione della query remota non richiede TF6408.

È possibile eseguire la query seguente e usare start_time/end_time e read_command per identificare la query analizzata:

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

Pushdown del predicato di filtro (visualizzazione con DMV)

Considerare la query usata nell'esempio di predicato di filtro precedente:

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

Con pushdown del filtro (visualizzazione con DMV)

È possibile stabilire se il pushdown del predicato del filtro si stia verificando controllando il read_command nella DMV. Verrà visualizzato un campione simile al seguente:

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 clausola WHERE si trova nel comando inviato all'origine dati esterna, il che significa che il predicato di filtro viene valutato nell'origine dati esterna. Il filtro sul set di dati si è verificato nell'origine dati esterna e solo il set di dati filtrato è stato recuperato da PolyBase.

Senza pushdown del filtro (visualizzazione con DMV)

Se il pushdown non si verifica, verrà visualizzato qualcosa di simile al seguente:

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

Non esiste alcuna clausola WHERE nel comando inviato all'origine dati esterna, pertanto il predicato del filtro non inviato. Il filtro sull'intero set di dati si è verificato sul lato SQL Server, dopo il recupero del set di dati da parte di PolyBase.

Pushdown di JOIN (visualizzazione con DMV)

Considerare la query usata nell'esempio di JOIN precedente:

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

Con pushdown di join (visualizzazione con DMV)

Se viene eseguito il push di JOIN nell'origine dati esterna, verrà visualizzato un risultato simile al seguente:

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;

Non esiste alcuna clausola JOIN nel comando inviato all'origine dati esterna, pertanto il JOIN viene inviato. Il join sul set di dati si è verificato nell'origine dati esterna e solo il set di dati corrispondente alla condizione di join è stato recuperato da PolyBase.

Senza pushdown di join (visualizzazione con DMV)

Se il pushdown del join non si verifica, si noterà che sono presenti due query diverse eseguite sull'origine dati esterna:

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;

Il join dei due set di dati si è verificato sul lato SQL Server, dopo che entrambi i set di dati vengono recuperati da PolyBase.

Pushdown dell'aggregazione (visualizzazione con DMV)

Considerare la query seguente, che usa una funzione di aggregazione:

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

Con pushdown dell'aggregazione (visualizzazione con DMV)

Se si verifica il pushdown dell'aggregazione, la funzione di aggregazione viene visualizzata in read_command. Ad esempio:

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 funzione di aggregazione è nel comando inviato all'origine dati esterna, quindi l'aggregazione viene inviata. L'aggregazione si è verificata nell'origine dati esterna e solo il set di dati aggregato è stato recuperato da PolyBase.

Senza pushdown dell’aggregazione (visualizzazione con DMV)

Se il pushdown dell'aggregazione non si verifica, non verrà visualizzata la funzione di aggregazione in read_command. Ad esempio:

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

L'aggregazione è stata eseguita in SQL Server, dopo che il set di dati non aggregato è stato recuperato da PolyBase.

Passaggi successivi

• Risoluzione dei problemi di PolyBase
• Errori di PolyBase e possibili soluzioni