Cuánto tarda cada paso en Power Query: Guía de Diagnóstico
Optimizar una consulta de Power Query sin medir es, básicamente, jugar a las adivinanzas. He visto proyectos de retail donde se perdían horas tratando de simplificar un filtrado, cuando el verdadero cuello de botella estaba en un tipo de datos mal asignado que rompía el Query Folding tres pasos atrás. El problema es que el motor de Power Query (Mashup Engine) es opaco por naturaleza. A diferencia de DAX, donde el Performance Analyzer nos da respuestas inmediatas, en Power Query necesitamos herramientas específicas para ver qué ocurre bajo el capó.
En este artículo no vamos a hablar de buenas prácticas teóricas. Vamos a centrarnos en cómo abrir la caja negra y extraer las métricas de rendimiento. El objetivo es que, antes de tocar una sola línea de código M, sepas exactamente qué paso se lleva el 90% del tiempo de procesamiento. Esto no solo ahorra tiempo de desarrollo, sino que evita la frustración de aplicar parches que no mejoran la velocidad de refresco final.
El coste de la ceguera técnica en el ETL
Cuando un informe de Power BI tarda demasiado en refrescar, la reacción habitual es culpar al volumen de datos o a la conexión. Sin embargo, en escenarios de industria o sector público con los que trabajo, el culpable suele ser un paso de transformación mal planteado que fuerza al motor local a descargar millones de filas para procesarlas en memoria. Si no mides, podrías estar intentando optimizar una consulta que ya es eficiente, ignorando el paso de Agrupamiento o Combinación que está estrangulando el rendimiento.
La telemetría es la base de cualquier decisión de arquitectura de datos seria. Antes de pasar a la fase de visualización o de preocuparte por la Optimización de Modelos Semánticos en Power BI: VertiPaq & Storage Engine, debes asegurar que tu capa de extracción es sólida. Medir el tiempo por paso te permite decidir si un proceso debe quedarse en Power Query o si debe delegarse al origen mediante SQL (Query Folding) o incluso si requiere una reestructuración desde la base siguiendo principios de Conformed dimensions y bus matrix para simplificar las uniones.
Query Diagnostics: El Performance Analyzer de Power Query
La herramienta definitiva para este análisis es Diagnóstico de consultas, disponible en la cinta de opciones de ‘Herramientas’ del Editor de Power Query. Esta funcionalidad no solo cuenta segundos; genera trazas detalladas de cada operación que el motor M envía al origen y de lo que procesa internamente.
Diagnóstico de pasos frente a Diagnóstico de sesión
Existen dos formas de ejecutar esta herramienta:
- Diagnosticar paso: Ideal cuando ya sospechas de una transformación concreta (como un
Table.NestedJoin). Al seleccionarlo, Power Query evalúa ese paso específico y todos sus antecedentes necesarios. - Iniciar diagnóstico: Registra toda la actividad mientras interactúas con el editor. Es la mejor opción para entender el flujo completo desde que conectas a
Ventas_Historicohasta que aplicas los tipos de datos finales.
Al detener el diagnóstico, se crean varias consultas nuevas en una carpeta llamada ‘Diagnostics’. Las dos más importantes son Diagnostics_Detailed y Diagnostics_Aggregated. En la tabla detallada, verás columnas críticas como Exclusive Duration, que representa el tiempo que el motor pasó ejecutando ese paso específico, restando el tiempo de sus dependencias. Si una consulta tarda 10 segundos y un paso tiene una duración exclusiva de 9 segundos, ahí tienes tu problema.
// Ejemplo de un paso de unión que suele ser problemático
let
Origen = Sql.Database("ServidorProduccion", "DB_Ventas"),
Ventas = Origen{[Schema="dbo",Item="Fact_Ventas"]}[Data],
// Este paso de combinación podría romper el folding si el origen no es SQL
JoinProductos = Table.NestedJoin(Ventas, {"Id_Producto"}, Dim_Producto, {"Id_Producto"}, "Producto", JoinKind.LeftOuter),
ExpandirProducto = Table.ExpandTableColumn(JoinProductos, "Producto", {"Nombre_Producto", "Categoria"})
in
ExpandirProductoInterpretación de trazas: ¿Por qué este paso tarda tanto?
Una vez que tienes la tabla de diagnóstico, debes buscar patrones. El error más común es encontrar una duración excesiva en pasos que aparentemente son sencillos, como un filtro. Esto suele indicar que el Query Folding se ha roto. Cuando el plegado de consultas falla, Power Query tiene que descargar todos los datos del servidor (por ejemplo, de una tabla de 50 millones de filas de Lecturas_Energia) para aplicar el filtro localmente.
Busca en la columna Operation del diagnóstico términos como DbDataReader o RemoteQuery. Si ves que el tiempo se consume en operaciones locales (indicadas habitualmente por la ausencia de una consulta SQL enviada al origen), es que estás procesando en el motor Mashup local. En estos casos, integrar Tablas de referencia y parámetros en Power Query para limitar los datos desde el inicio puede ser la diferencia entre un refresco de 2 minutos o uno de 2 horas.
La trampa del Data Preview
Es vital recordar que el Editor de Power Query solo trabaja con una muestra (normalmente las primeras 1000 filas). El tiempo que ves en la interfaz mientras desarrollas no es el tiempo de ejecución real. Un diagnóstico realizado sobre el ‘Preview’ puede ser engañoso. Para obtener datos reales de producción, el diagnóstico debe ejecutarse sobre la carga completa o mediante el registro de trazas de la puerta de enlace (Gateway) si trabajas en el servicio de Power BI.
Perfilado de columnas como indicador de rendimiento
Mucha gente ignora que el Perfilado de columnas (Column Quality, Column Distribution, Column Profile) consume recursos. Aunque es una herramienta fantástica para la calidad de datos, tenerla activada permanentemente en tablas masivas ralentiza el editor.
Sin embargo, podemos usarlo a nuestro favor para diagnosticar. Si el perfilado de una columna de Importe_Neto tarda demasiado en cargar, nos está dando una pista sobre la latencia de la red o la velocidad del disco del origen. Además, detectar una alta cardinalidad en columnas que no necesitamos es el primer paso para eliminarlas y reducir la carga de memoria del motor VertiPaq. La gestión de la calidad es esencial, como explicamos en la Gestión proactiva de errores en Power Query: el patrón de la tabla de control, pero debe hacerse con equilibrio.
| Herramienta | Cuándo usarla | Métrica clave |
|---|---|---|
| Diagnostics (Aggregated) | Visión general del rendimiento total por consulta. | Total Duration (%) |
| Diagnostics (Detailed) | Análisis profundo de un paso específico sospechoso. | Exclusive Duration |
| Perfilado de Columnas | Identificar sesgos en los datos y volumen real. | Distinct / Unique values |
| Performance Analyzer | Solo si el problema parece estar en el visual, no en el ETL. | DAX Query / Other |
Casos reales: El impacto del Query Folding
En un proyecto reciente para una entidad pública, el proceso de carga de Fact_Presupuestos tardaba 40 minutos. Al activar el diagnóstico detallado, descubrimos que el 95% del tiempo se perdía en un paso de Texto.Mayusculas aplicado a una columna de descripción. Este paso impedía que los filtros posteriores se enviaran al servidor SQL.
Al mover esa transformación al final de la consulta, o mejor aún, realizarla mediante una vista en el origen, el tiempo bajó a 3 minutos. Este es el tipo de decisiones que solo puedes tomar cuando tienes los datos de diagnóstico delante. No se trata de programar mejor en M, se trata de entender cómo el motor interactúa con el origen de datos.
-- Lo que queremos ver en el diagnóstico (Query Folding activo)
SELECT [Id_Cliente], UPPER([Nombre_Cliente]) as [Nombre], [Monto]
FROM [dbo].[Clientes]
WHERE [Monto] > 1000
-- Lo que sucede si el diagnóstico muestra lentitud local
-- El motor descarga TODA la tabla y filtra en local.
SELECT * FROM [dbo].[Clientes]Checklist: Antes de optimizar, mide
- ¿Has activado el Diagnóstico de Consultas para el paso más lento?
- ¿Has revisado la columna ‘Exclusive Duration’ en el informe detallado?
- ¿El paso problemático permite el Query Folding (botón derecho ‘Ver consulta nativa’)?
- ¿Has desactivado el perfilado de columnas de fondo para mejorar la respuesta del editor?
- ¿Estás realizando transformaciones pesadas (agregaciones, uniones) antes que los filtros?
Preguntas frecuentes
¿Por qué el diagnóstico genera tantas tablas nuevas?
Power Query desglosa la telemetría en niveles de granularidad: detallado, agregado y contadores. Esto permite desde ver el tiempo de CPU hasta las consultas SQL exactas enviadas. Una vez terminado el análisis, puedes borrar estas consultas de diagnóstico sin miedo.
¿Es normal que el diagnóstico haga que la consulta tarde más?
Sí, el proceso de instrumentación añade una sobrecarga (overhead). Lo importante no es el tiempo absoluto durante el diagnóstico, sino la proporción de tiempo que consume cada paso comparado con los demás.
¿Puedo ver estos diagnósticos en Power BI Service?
No directamente con esta herramienta. En el servicio debes recurrir a los registros del On-premises Data Gateway o a las métricas de capacidad (Premium/Fabric), aunque el Editor de Power Query Online está empezando a incorporar funciones de visualización de rendimiento similares.
¿Qué significa una duración exclusiva de cero en algunos pasos?
Significa que ese paso es puramente metadatos (como renombrar una columna) o que se ha plegado completamente en la operación anterior. No consume tiempo de procesamiento real del motor M.
