Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Este artículo explica cómo determinar si una consulta de PolyBase se beneficia del pushdown a la fuente de datos externa. Para obtener más información sobre el pushdown externo, consulte Cálculos de pushdown en PolyBase.
¿Se beneficia mi consulta de la delegación externa?
La computación de empuje mejora el rendimiento de las consultas en fuentes de datos externas. Algunas tareas de cálculo se delegan en el origen de datos externo en lugar de incorporarse a la instancia de 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 pushdown de PolyBase puede mejorar significativamente el rendimiento de la consulta. Si una consulta de PolyBase se ejecuta lentamente, compruebe si se está produciendo el pushdown de su consulta de PolyBase.
Puede observar el pushdown en el plan de ejecución en tres escenarios diferentes:
- Delegación del predicado de filtro
- Delegación de la combinación
- Delegación de la agregación
Dos nuevas características de SQL Server 2019 (15.x) permiten a los administradores determinar si se inserta una consulta de PolyBase en el origen de datos externo:
- Ver el plan de ejecución estimado con la marca de seguimiento 6408
- Vista de
read_commanden 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.
Limitaciones
Las siguientes limitaciones afectan a lo que se puede transferir a fuentes de datos externas con Cálculos de pushdown en PolyBase:
Algunas funciones T-SQL pueden impedir el pushdown. Para obtener más información, consulte Características y limitaciones de PolyBase.
Para obtener una lista de las funciones de T-SQL que se pueden delegar, consulte Cálculos delegados en PolyBase.
Utilice la marca de seguimiento 6408
De forma predeterminada, el plan de ejecución estimado no expone el plan de consulta remota. Solo verá el objeto del operador de consulta remota. Por ejemplo, un plan de ejecución estimado de SQL Server Management Studio (SSMS):
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.
La información general del plan de ejecución se lee de derecha a izquierda, como se indica en la dirección de las flechas. Si un operador está a la derecha de otro operador, está antes que él. Si un operador se encuentra a la izquierda de otro operador, está después de él.
- En SSMS, resalte la consulta y seleccione Mostrar plan de ejecución estimado en la barra de herramientas o use Ctrl+L.
Cada uno de los ejemplos siguientes incluye la salida de SSMS.
Delegación del predicado de filtro (vista con plan de ejecución)
Tenga en cuenta la consulta siguiente, que usa un predicado de filtro en la cláusula WHERE:
SELECT *
FROM [Person].[BusinessEntity] AS be
WHERE be.BusinessEntityID = 17907;
Si se aplica el pushdown del predicado de filtro, el operador de filtro aparece antes del operador externo en el plan de ejecución. Cuando el operador de filtro se encuentra antes del operador externo, el filtrado se lleva a cabo antes de que el motor de consultas recupere los datos de la fuente de datos externa, lo que significa que se ha aplicado el pushdown del predicado de filtro.
Con delegación del predicado de filtro (vista con plan de ejecución)
Cuando habilitas la marca de traza 6408, ves información adicional en la salida del plan de ejecución estimado.
En SSMS, el plan de consulta remota aparece como Consulta 2 (sp_execute_memo_node_1) en el plan de ejecución estimado. Corresponde al operador Remote Query de la Consulta 1. Por ejemplo:
Sin delegación del predicado de filtro (vista con plan de ejecución)
Si no se aplica el pushdown del predicado de filtro, el operador de filtro aparece después del operador externo.
El plan de ejecución estimado de SSMS:
Delegación de JOIN
Tenga en cuenta la siguiente consulta que usa el JOIN operador 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 el motor de consultas transfiere la operación JOIN al origen de datos externo, el operador Join aparece antes del operador externo. En este ejemplo, tanto [BusinessEntity] como [BusinessEntityAddress] son tablas externas.
Con delegación de la combinación (vista con plan de ejecución)
El plan de ejecución estimado de SSMS:
Sin delegación de la combinación (vista con plan de ejecución)
Si el motor de consultas no desplaza la operación JOIN a la fuente de datos externa, el operador de unión aparece después del operador externo. En SSMS, el plan de consulta para sp_execute_memo_node incluye el operador externo. Este operador forma parte del operador Remote Query en query 1.
El plan de ejecución estimado de SSMS:
Delegación de la agregación (vista con plan de ejecución)
Tenga en cuenta la consulta siguiente, 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 la agregación se traslada hacia abajo, el operador de agregación aparece antes del operador externo. Cuando el operador de agregación se encuentra antes del operador externo, la consulta realiza la agregación antes de seleccionar datos de la fuente de datos externa, lo que significa que la agregación se ha desplazado hacia abajo.
El plan de ejecución estimado de SSMS:
Sin delegación de la agregación (vista con plan de ejecución)
Si la agregación no se desplaza hacia abajo, el operador de agregación aparece después del operador externo.
El plan de ejecución estimado de SSMS:
Uso de DMV
En SQL Server 2019 (15.x) y versiones posteriores, la read_command columna de sys.dm_exec_external_work DMV muestra la consulta que envía al origen de datos externo. Se puede determinar si se está produciendo el pushdown, pero esto no se refleja en el plan de ejecución. No necesita el indicador de seguimiento 6408 para ver la consulta remota.
Nota:
En el caso de Hadoop y Azure Storage, siempre read_command devuelve NULL.
Ejecute la consulta siguiente y use los start_time/end_time valores y read_command para identificar la consulta que 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 read_command campo de la DMV está limitado a 4000 caracteres. Si la consulta es lo suficientemente larga, es posible que el read_command se trunque antes de que se vean el WHERE, el JOIN o la función de agregación en el read_command.
Delegación del predicado de filtro (vista con DMV)
Considere la consulta usada en el ejemplo de predicado de filtro anterior:
SELECT *
FROM [Person].[BusinessEntity] AS be
WHERE be.BusinessEntityID = 17907;
Con delegación del filtro (vista con DMV)
Puedes comprobar el read_command en el DMV para ver si se está produciendo el pushdown del predicado de filtro. Verá un ejemplo similar a la consulta 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;
El comando enviado al origen de datos externo incluye la WHERE cláusula , lo que significa que el predicado de filtro se evalúa en el origen de datos externo. El filtrado del conjunto de datos se produce en el origen de datos externo y PolyBase solo recupera el conjunto de datos filtrado.
Sin delegación del filtro (vista con DMV)
Si no se produce el pushdown, verás algo como esto:
SELECT "BusinessEntityID",
"rowguid",
"ModifiedDate"
FROM "AdventureWorks2022"."Person"."BusinessEntity";
El comando enviado a la fuente de datos externa no incluye una cláusula WHERE, por lo que el predicado de filtro no se aplica. El filtrado de todo el conjunto de datos se produce en el lado de SQL Server, después de que PolyBase recupere el conjunto de datos.
Delegación de JOIN (vista con DMV)
Considere la consulta usada en el ejemplo anterior JOIN :
SELECT be.BusinessEntityID,
bea.AddressID
FROM [Person].[BusinessEntity] AS be
INNER JOIN [Person].[BusinessEntityAddress] AS bea
ON be.BusinessEntityID = bea.BusinessEntityID;
Con delegación de la combinación (vista con DMV)
Si lleva JOIN hacia abajo al origen de datos externo, verá algo parecido a:
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;
El comando que envías a la fuente de datos externa incluye la cláusula JOIN, por lo que el JOIN se aplica. El origen de datos externo controla la combinación en el conjunto de datos y PolyBase solo recupera 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 transferencia de la unión, verá que se ejecutan dos consultas diferentes en la fuente de datos externa:
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;
El lado de SQL Server controla la unión de los dos conjuntos de datos después de que PolyBase recupere ambos conjuntos de datos.
Delegación de la agregación (vista con DMV)
Tenga en cuenta la consulta siguiente, que usa una función de agregado:
SELECT SUM([Quantity]) AS Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];
Con transferencia de la agregación (vista con DMV)
Si se produce la transferencia de la agregación, verá la función de agregación en el 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 produce en el origen de datos externo y PolyBase solo recupera el conjunto de datos agregado.
Sin delegación de la agregación (vista con DMV)
Si no se produce la transferencia de la agregación, no verá la función de agregación en el read_command. Por ejemplo:
SELECT "Quantity"
FROM "AdventureWorks2022"."Production"."ProductInventory";
PolyBase recupera el conjunto de datos no agregado y SQL Server realiza la agregación.