Cada transformación que aplicas en el editor de Power Query queda registrada como un paso en el panel de pasos aplicados. Lo que mucha gente no revisa es si esos pasos se están ejecutando en el motor de Power Query o si, por el contrario, Power BI ha sido lo bastante listo como para mandárselos al origen de datos. A eso se le llama query folding, y marca una diferencia enorme en el tiempo de actualización de tus informes.
Qué son los pasos aplicados
Cada clic que haces en el editor de Power Query (quitar una columna, filtrar filas, cambiar un tipo de dato, agrupar) genera una línea de código M y aparece como un paso en el panel lateral, en orden. Puedes seleccionar cualquier paso y ver el estado intermedio de los datos en ese punto exacto de la transformación, lo cual es muy útil para depurar una consulta que no da el resultado esperado.
Qué es el query folding
El query folding es el mecanismo por el que Power Query traduce las transformaciones M que soporta en operaciones equivalentes que el propio origen de datos puede ejecutar, en vez de traer todos los datos en bruto y transformarlos localmente en el motor de Power Query. Cuando el origen es algo con motor de consultas propio (una base de datos SQL Server, un feed OData), Power Query intenta empujar el máximo trabajo posible hacia ese origen y solo procesa en su propio motor lo que no puede traducir.
El resultado puede ser plegado total (todos los pasos viajan al origen como una única consulta nativa), plegado parcial (una parte se traduce y el resto se procesa localmente) o sin plegado (el origen solo entrega los datos en crudo y todo el trabajo lo hace Power Query). Fuentes sin motor de consultas propio, como un archivo CSV o Excel, no pueden ofrecer query folding real: no hay a quién delegarle el trabajo.
Qué pasos suelen romper el plegado
No todas las transformaciones tienen un equivalente en el lenguaje nativo del origen. Funciones M personalizadas, ciertas combinaciones de columnas, algunas transformaciones de texto o pasos que dependen de evaluar filas en memoria (por ejemplo, índices de fila añadidos manualmente) suelen ser puntos donde el plegado se detiene: todo lo que va después de ese paso ya se ejecuta en el motor de Power Query, aunque lo anterior se hubiera podido plegar perfectamente.
Cómo comprobarlo: haz clic con el botón derecho sobre un paso del panel de pasos aplicados y busca la opción Ver consulta nativa (View Native Query) o el icono de plegado junto a cada paso. Si la opción aparece disponible, ese paso —y todo lo anterior— se está plegando en el origen; si está deshabilitada, el plegado ya se ha roto en algún punto anterior de la cadena.
Por qué importa tanto en Power BI
En modelos DirectQuery, el query folding no es opcional: cada visual del informe dispara una consulta al origen en tiempo real, así que si tus pasos no pliegan, el rendimiento se resiente de forma directa y notoria. En modelos de importación, el impacto se nota sobre todo en la actualización de datos: una consulta bien plegada en un origen con buenos índices puede tardar segundos; la misma consulta sin plegar, arrastrando millones de filas en bruto hasta el motor de Power Query, puede tardar minutos.
- Aplica los filtros y las selecciones de columnas lo antes posible en la secuencia de pasos: cuanto antes reduzcas el volumen, más fácil es que todo lo posterior siga plegando.
- Revisa el estado del plegado tras cada paso nuevo con «ver consulta nativa», no solo al final de la consulta.
- Si necesitas una transformación compleja que rompe el plegado, valora si tiene sentido crear una vista en la base de datos origen en vez de resolverlo en Power Query.
- Para consultas muy exigentes, la función
Value.NativeQuery()permite enviar SQL nativo directamente, aunque en DirectQuery solo admite sentencias SELECT simples. - En incrementally refreshed tables (actualización incremental), el plegado de los filtros de rango de fechas es especialmente crítico: sin él, cada actualización vuelve a traer todo el histórico.
Una vez los datos llegan limpios y bien optimizados gracias al plegado, el siguiente reto es entender cómo el motor de DAX evalúa cada medida sobre ellos.
Leer el artículo sobre contexto de fila y contexto de filtro en DAX