¿Dashboard de Power BI lento? Guía de optimización — Parte 1: conexión y transformación de datos

Un dashboard de Power BI lento casi nunca tiene una sola causa: el problema puede estar en la conexión a las fuentes, en las transformaciones de Power Query, en el modelo de datos, en las fórmulas DAX, en los visuales o en la infraestructura. Diagnosticarlo requiere revisar cada etapa de forma sistemática — y eso es exactamente lo que hace esta serie: una hoja de ruta completa para auditar y optimizar tu solución, con las mismas técnicas que usamos con nuestros clientes.

Resolver problemas de rendimiento en Power BI se parece a resolver un caso policial. Los cuellos de botella pueden aparecer en cualquier etapa del desarrollo, y encontrar la causa raíz —reportes que tardan en cargar, actualizaciones eternas, visuales que no responden— exige un enfoque estructurado en lugar de probar cambios al azar.

Por ejemplo, un reporte que carga lento puede deberse a:

• Consultas ineficientes contra la fuente de datos

• Un modelo de datos mal diseñado

• Cálculos DAX sin optimizar

• Páginas sobrecargadas de visualizaciones

Y estos son solo algunos ejemplos. Los problemas de rendimiento pueden originarse en cualquier parte de la solución:

✅ Conexión a la fuente y transformación de datos (esta parte)

✅ Modelo de datos (parte 2)

✅ Fórmulas DAX (parte 3)

✅ Visualización de datos (parte 4)

✅ Entorno: infraestructura, despliegue y red

En esta primera parte cubrimos las mejores prácticas para optimizar la conexión y transformación de datos: query folding, modos de conexión y reducción de datos. Trabajar bien esta etapa reduce los tiempos de carga y de actualización, minimiza el uso de memoria y CPU, y garantiza que al reporte solo llegue la información necesaria.

1. Reduce el volumen y la granularidad de los datos

Aunque estas técnicas suelen asociarse a la optimización del modelo de datos, las incluyo aquí para subrayar algo importante: conviene adoptarlas desde el principio, en la fase de conexión y transformación. Así garantizas que al modelo solo entren los datos necesarios, lo que reduce el uso de memoria, acelera el procesamiento y sienta las bases de un modelo eficiente.

Carga solo las tablas necesarias

Al construir un modelo es común importar tablas a Power Query para cálculos intermedios. Si esas tablas no se necesitan en los reportes finales, evita que inflen el tamaño y la complejidad del modelo: desmarca la opción "Habilitar carga" (Enable Load) en Power Query para las tablas que solo son pasos intermedios.

Incluye solo las columnas esenciales

Cada columna suma procesamiento y memoria. Excluye columnas como GUIDs, logs de auditoría o metadata que no se usan en el análisis. Ten presente este principio: es mucho más fácil agregar columnas después que eliminar las innecesarias. A medida que el modelo crece y más reportes se conectan a él, quitar columnas sin romper nada se vuelve cada vez más complejo.

Divide las columnas de alta cardinalidad

La alta cardinalidad (muchos valores únicos) aumenta significativamente el tamaño del modelo y ralentiza los cálculos DAX. Dividir estas columnas en componentes más pequeños mejora la compresión, reduce la memoria y acelera todo.

Mejores prácticas:

• Divide columnas decimales: separa la parte entera y la fraccionaria en dos columnas.

• Divide columnas datetime: si necesitas fecha y hora, guárdalas en dos columnas separadas.

• Divide IDs de alta cardinalidad: columnas como TransactionID o UserID suelen componerse de partes con significado (prefijos, regiones, números de lote). Extraer esos componentes en columnas separadas reduce los valores únicos por columna y mejora la compresión. Por ejemplo:

Filtra los datos temprano

Aplica filtros en Power Query para cargar solo las filas relevantes — por ejemplo, filtra por fecha o región antes de importar.

Reduce la granularidad con agregaciones

Reducir la granularidad es una técnica potente para achicar los datos antes de cargarlos. Puedes agrupar y resumir con Power Query o con SQL en la fuente: una tabla de ventas con líneas de transacción individuales puede agregarse por cliente, producto o mes. El trade-off es que sacrificas el detalle transaccional — asegúrate de que el nivel de agregación cubre las necesidades analíticas de tus reportes.

2. Evita transformaciones complejas en Power BI

Realiza las transformaciones pesadas en la fuente de datos, usando herramientas de ETL, vistas de base de datos o stored procedures. Esto reduce la carga computacional de Power BI, optimiza los tiempos de actualización y produce soluciones eficientes y escalables.

3. Optimiza los tipos de datos de las columnas

Usa el tipo de dato más eficiente. Por ejemplo:

• Convierte texto o tipos grandes (como strings) a tipos más chicos cuando corresponda: enteros o booleanos.

• Evita decimales de alta precisión si no son necesarios; prefiere decimal fijo o números enteros.

4. Consolida los pasos aplicados en Power Query

Combina transformaciones similares —como renombrar o eliminar varias columnas— en un solo paso, para evitar procesamiento redundante.

5. Aprovecha el query folding

El query folding delega las transformaciones a la fuente de datos, optimizando el rendimiento al reducir el procesamiento local. Lo soportan las bases de datos relacionales (SQL Server, Oracle), las bases cloud (Snowflake, Amazon Redshift), las fuentes OData (como listas de SharePoint) y Active Directory. No está disponible para archivos planos (Excel, CSV), blobs ni fuentes web — ahí todas las transformaciones se procesan localmente.

Cómo verificar si hay query folding

• En el editor de Power Query:

Haz clic derecho sobre un paso en el panel de pasos aplicados.

• Si "Ver consulta nativa" (View Native Query) está habilitado, ese paso se está plegando a la fuente.

• Si está en gris, el folding se cortó y ese paso se procesa localmente.

• Con los indicadores de query folding (Power Query Online):

• Con la vista de plan de consulta (Power Query Online):

Usa el Query Plan para visualizar qué pasos se pliegan a la fuente y cuáles se procesan localmente, y optimiza el diseño de la consulta en función de eso.

Buenas prácticas de query folding

• Busca el folding completo siempre que sea posible: el objetivo es que todas las transformaciones las ejecute la fuente de datos y Power BI reciba directamente el resultado final, reduciendo el consumo de recursos y acelerando la consulta.

• Si el folding completo no es alcanzable, ordena los pasos estratégicamente:

Coloca al principio todas las transformaciones que soportan query folding.

• Mueve los pasos que no se pliegan al final, para minimizar el procesamiento local.

• Consultas nativas con folding: si usas Value.NativeQuery en Power Query, incluye todas las transformaciones necesarias dentro de la consulta nativa. Evita agregar pasos después de una consulta nativa: no se pliegan y se procesan localmente, degradando el rendimiento.

• Cuando el folding no es posible: para consultas con muchas transformaciones que no se pliegan, lo más recomendable es aplicar esas transformaciones directamente en la fuente (punto 2): herramientas ETL, vistas o stored procedures.

6. Configuración de Power BI

Desactiva la descarga de datos en segundo plano

Por defecto, Power Query en Power BI Desktop cachea hasta 1.000 filas de vista previa por cada consulta. Esa vista previa ayuda a inspeccionar rápidamente los datos, pero se almacena aparte del archivo y puede aumentar significativamente los tiempos de actualización, sobre todo con muchas consultas.

Ve a Opciones > Archivo actual > Carga de datos > Datos en segundo plano > desmarca la opción "Permitir que las vistas previas de datos se descarguen en segundo plano".

Ignora los niveles de privacidad (con cuidado)

Los niveles de privacidad de Power Query definen el aislamiento entre fuentes de datos para controlar la visibilidad y prevenir transferencias no autorizadas:

• Ninguno: sin aislamiento; apto para entornos controlados, con riesgo de fuga de datos.

• Privado: aislamiento estricto para datos sensibles; impide combinarlos con otras fuentes.

• Organizacional: permite compartir dentro de grupos de confianza, pero no con fuentes públicas.

• Público: accesible para todos y combinable con otras fuentes.

Ignorar los niveles de privacidad puede potencialmente mejorar el rendimiento, pero podría exponer datos sensibles o confidenciales a personas no autorizadas. No actives esta opción salvo que tengas certeza de que la fuente no contiene datos sensibles.

Ve a Opciones > Archivo actual > Privacidad > selecciona "Ignorar los niveles de privacidad y mejorar potencialmente el rendimiento".

Nota: los niveles de privacidad ignorados no aplican a los reportes publicados en el servicio de Power BI.

Herramienta de análisis: Query Diagnostics

Query Diagnostics analiza el comportamiento de Power Query durante las transformaciones, las vistas previas y las actualizaciones. Identifica demoras, explica las evaluaciones en segundo plano y muestra cómo interactúan las consultas con las fuentes. Ofrece dos niveles:

• Vista resumida: panorama general de dónde se va el tiempo durante la ejecución, combinando operaciones relacionadas.

• Vista detallada: análisis línea por línea para troubleshooting avanzado.

Pasos para usarlo:

1. En el editor de Power Query, selecciona Iniciar diagnóstico en la cinta Herramientas.

2. Realiza las acciones a medir (actualizar la vista previa o la consulta).

3. Analiza los resultados en las consultas de diagnóstico generadas.

Tip: concéntrate en la columna Exclusive Duration y suma sus valores para entender qué pasos consumen más recursos o más tiempo.

Preguntas frecuentes

¿Por qué mi dashboard de Power BI está lento? Las causas más comunes: se cargan más datos de los necesarios (columnas y filas que nadie usa), transformaciones que no se pliegan a la fuente (sin query folding), un modelo de datos sin esquema estrella, medidas DAX ineficientes o demasiados visuales por página. Esta serie recorre cada causa con su solución.

¿Por dónde empiezo a optimizar? Por la etapa más temprana: la conexión y transformación. De nada sirve optimizar DAX si el modelo carga millones de filas que no se usan. Reduce datos primero, verifica el query folding, y recién después pasa al modelo (parte 2) y a las medidas (parte 3).

¿El query folding aplica si mi fuente es Excel o CSV? No — los archivos planos no soportan query folding: todas las transformaciones se procesan localmente. En esos casos, reduce el tamaño del archivo de origen y minimiza los pasos de transformación, o considera migrar la fuente a una base de datos.

Conclusión

Optimizar la conexión y la transformación de datos es el primer paso para lograr reportes de alto rendimiento. Reduciendo datos innecesarios, aprovechando el query folding y organizando los pasos de consulta con criterio, construyes la base de una solución rápida, responsiva y escalable.

¿Tu reporte sigue lento y no encuentras la causa? Nuestro Power BI Clarity Check es una auditoría integral de tu entorno de Power BI que identifica exactamente estos cuellos de botella — con plan de acción priorizado.