Cómo saber si se ha producido una delegación externa

En este artículo se detalla cómo se puede determinar si una consulta de PolyBase se beneficia de la delegación al origen de datos externo. Para obtener más información sobre la delegación externa, vea Cálculos de delegación en PolyBase.

¿Se beneficia mi consulta de la delegación externa?

El cálculo de aplicación mejora el rendimiento de las consultas en los orígenes de datos externos. Ciertas tareas de cálculo se delegan en el origen de datos externo, en lugar de llevarse a SQL Server. Especialmente en los casos de delegación del filtrado y de la combinación, la carga de trabajo en la instancia de SQL Server se puede reducir considerablemente.

El cálculo de delegación de PolyBase puede mejorar en gran medida el rendimiento de la consulta. Si una consulta de PolyBase se ejecuta con lentitud, debe determinar si se está produciendo la delegación de la consulta.

Hay tres escenarios diferentes en los que se puede observar una delegación en el plan de ejecución:

• Delegación del predicado de filtro
• Delegación de la combinación
• Delegación de la agregación

Nota:

Existen limitaciones en lo que respecta a lo que se puede delegar en orígenes de datos externos con cálculos de delegación de PolyBase:

• Algunas funciones de T-SQL pueden impedir la delegación. Para obtener más información, vea Características y limitaciones de PolyBase.
• Para obtener una lista de las funciones de T-SQL que se pueden delegar, vea Cálculos de delegación en PolyBase.

Se han introducido dos nuevas características de SQL Server 2019 (15.x) para permitir a los administradores determinar si una consulta de PolyBase se está delegando en el origen de datos externo:

• Vista del plan de ejecución estimado con la marca de seguimiento 6408
• Vista de read_command en la vista de administración dinámica (DMV) sys.dm_exec_external_work

En este artículo se proporciona información sobre cómo se emplean estos dos casos de uso para cada uno de los tres escenarios de delegación.

Uso de TF6408

De manera predeterminada, el plan de ejecución estimado no expone el plan de consulta remota y solo se ve el objeto del operador de consulta remota. Por ejemplo, este es un plan de ejecución estimado de SQL Server Management Studio (SSMS):

O en Azure Data Studio:

A partir de SQL Server 2019 (15.x), puede habilitar una nueva marca de seguimiento 6408 globalmente mediante DBCC TRACEON. Por ejemplo:

DBCC TRACEON (6408, -1);  

Esta marca de seguimiento solo funciona con planes de ejecución estimados y no tiene ningún efecto en los planes de ejecución reales. Esta marca de seguimiento expone información sobre el operador Remote Query que muestra lo que sucede durante la fase de consulta remota.

Los planes de ejecución se leen de derecha a izquierda, como indica la dirección de las flechas. Si un operador está a la derecha de otro operador, se dice que está "antes". Si un operador está a la izquierda de otro operador, se dice que está "después".

• En SSMS, resalte la consulta y seleccione Mostrar plan de ejecución estimado en la barra de herramientas o use Ctrl+L.
• En Azure Data Studio, resalte la consulta y seleccione Explicar. Tenga en cuenta los escenarios siguientes para determinar si se ha producido la delegación.

Cada uno de los ejemplos siguientes incluye la salida de SSMS y Azure Data Studio.

Delegación del predicado de filtro (vista con plan de ejecución)

Considere la consulta siguiente, en la que se usa un predicado de filtro en la cláusula WHERE:

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

Si se produce la delegación del predicado de filtro, el operador de filtro está antes del operador externo. Cuando el operador de filtro aparece delante del operador externo, el filtrado se produjo antes de que se seleccionara desde el origen de datos externo, lo que indica que el predicado de filtro se ha delegado.

Con delegación del predicado de filtro (vista con plan de ejecución)

Con la marca de seguimiento 6408 habilitada, ahora verá información adicional en la salida del plan de ejecución estimado. La salida varía entre SSMS y Azure Data Studio.

En SSMS, el plan de consulta remota se muestra en el plan de ejecución estimado como Query 2 (sp_execute_memo_node_1) y se corresponde con el operador Remote Query en Query 1. Por ejemplo:

En Azure Data Studio, la ejecución de consultas remotas se representa como un plan de consulta único. Por ejemplo:

Sin delegación del predicado de filtro (vista con plan de ejecución)

Si no se produce la delegación del predicado de filtro, el filtro estará después del operador externo.

Plan de ejecución estimado en SSMS:

Plan de ejecución estimado en Azure Data Studio:

Delegación de JOIN

Observe la siguiente consulta, que utiliza el operador de combinación para dos tablas externas en el mismo origen de datos externo:

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

Si JOIN se delega en el origen de datos externo, el operador JOIN estará antes del operador externo. En este ejemplo, [BusinessEntity] y [BusinessEntityAddress] son tablas externas.

Con delegación de la combinación (vista con plan de ejecución)

Plan de ejecución estimado en SSMS:

Plan de ejecución estimado en Azure Data Studio:

Sin delegación de la combinación (vista con plan de ejecución)

Si JOIN no se delega en el origen de datos externo, el operador JOIN estará después del operador externo. En SSMS, el operador externo se encuentra en el plan de consulta para sp_execute_memo_node, que está en el operador Remote Query en Query 1. En Azure Data Studio, el operador JOIN está después de los operadores externos.

Plan de ejecución estimado en SSMS:

Plan de ejecución estimado en Azure Data Studio:

Delegación de la agregación (vista con plan de ejecución)

Considere la siguiente consulta, que usa una función de agregado:

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

Con delegación de la agregación (vista con plan de ejecución)

Si se produce la delegación de la agregación, el operador de agregación está antes del operador externo. Cuando el operador de agregación aparece delante del operador externo, la agregación se produjo antes de que se seleccionara desde el origen de datos externo, lo que indica que la agregación de filtro se ha delegado.

Plan de ejecución estimado en SSMS:

Plan de ejecución estimado en Azure Data Studio:

Sin delegación de la agregación (vista con plan de ejecución)

Si no se produce la delegación de la agregación, el operador de agregación estará después del operador externo.

Plan de ejecución estimado en SSMS:

Plan de ejecución estimado en Azure Data Studio:

Uso de DMV

En SQL Server 2019 (15.x) y versiones posteriores, la columna read_command de la DMV sys.dm_exec_external_work muestra la consulta que se envía al origen de datos externo. Esto le permite determinar si se está produciendo la delegación, pero no expone el plan de ejecución. Para ver la consulta remota, no se requiere TF6408.

Nota:

Para Hadoop y Azure Storage, read_command siempre devuelve NULL.

Puede ejecutar la consulta siguiente y usar start_time/end_time y read_command para identificar la consulta que se está investigando:

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

Nota:

Una limitación del método sys.dm_exec_external_work es que el campo read_command de la DMV no acepta más de 4000 caracteres. Si la consulta es lo bastante larga, read_command podría truncarse antes de que se vea la función de agregación, WHERE o JOIN en read_command.

Delegación del predicado de filtro (vista con DMV)

Considere la consulta que se usó en el anterior ejemplo de predicado de filtro:

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

Con delegación del filtro (vista con DMV)

Para detectar si se produce la delegación del predicado de filtro, consulte read_command en la DMV. Verá algo parecido al ejemplo siguiente:

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 cláusula WHERE está en el comando que se envía al origen de datos externo, lo que significa que el predicado de filtro se está evaluando en el origen de datos externo. El filtrado del conjunto de datos se produjo en el origen de datos externo y PolyBase solo recuperó el conjunto de datos filtrado.

Sin delegación del filtro (vista con DMV)

Si no se produce la delegación, verá algo parecido a lo siguiente:

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

No hay ninguna cláusula WHERE en el comando que se envía al origen de datos externo, por lo que el predicado de filtro no se delega. El filtrado de todo el conjunto de datos se produjo en SQL Server, después de que PolyBase recuperara el conjunto de datos.

Delegación de JOIN (vista con DMV)

Considere la consulta que se usó en el anterior ejemplo de JOIN:

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

Con delegación de la combinación (vista con DMV)

Si JOIN se delega en el origen de datos externo, verá algo parecido a lo siguiente:

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;

La cláusula JOIN está en el comando que se envía al origen de datos externo, por lo que JOIN se delega. La combinación del conjunto de datos se produjo en el origen de datos externo y PolyBase solo recuperó el conjunto de datos que coincide con la condición de combinación.

Sin delegación de la combinación (vista con DMV)

Si no se produce la delegación de la combinación, verá que hay dos consultas diferentes que se ejecutan en el origen de datos externo:

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;

La combinación de los dos conjuntos de datos se produjo en SQL Server, después de que PolyBase recuperara ambos conjuntos de datos.

Delegación de la agregación (vista con DMV)

Considere la siguiente consulta, que usa una función de agregado:

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

Con delegación de la agregación (vista con DMV)

Si se produce la delegación de la agregación, verá la función de agregación en read_command. Por ejemplo:

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 función de agregación está en el comando que se envía al origen de datos externo, por lo que la agregación se delega. La agregación se produjo en el origen de datos externo y PolyBase solo recuperó el conjunto de datos agregado.

Sin delegación de la agregación (vista con DMV)

Si no se produce la delegación de la agregación, no verá la función de agregación en read_command. Por ejemplo:

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

La agregación se realizó en SQL Server, después de que PolyBase recuperara el conjunto de datos sin agregar.

Pasos siguientes

• Solución de problemas de PolyBase
• Errores de PolyBase y posibles soluciones