Power BI: Cómo crear informes más rápidos y eficientes

Power BI y su importancia en la toma de decisiones

Seguramente ya sabéis qué es Power BI, la herramienta más poderosa de Microsoft en cuanto la inteligencia de negocios (BI). Su capacidad para convertir datos en paneles visuales e interactivos ha cambiado la forma en que muchas empresas analizan su información, ayudándolas a identificar patrones y medir el rendimiento con mayor claridad.

Sin embargo, el valor de Power BI puede verse afectado si los informes no están optimizados.

Desafíos en el rendimiento de los informes

Cuando los informes crecen en complejidad, es común sufrir enfrentar desafíos de rendimiento, como páginas que tardan demasiado en cargar, consultas que tardan mucho por el gran volumen de datos o visualizaciones de gráficos que ralentizan la experiencia del usuario.

Si un gerente debe esperar minutos para ver las últimas ventas en un informe/panel, es probable que pierda confianza en la herramienta o que incluso deje de usarla. Por eso, optimizar la velocidad de los informes no solo mejora la usabilidad, sino que tiene un impacto directo en la agilidad del negocio.

¿Aún no sabes crear buenos informes en Power BI? Aprende a crear tu primer dashboard en Power BI: Guía paso a paso en este completo artículo.

Diseño eficiente del modelo de datos

Un modelo de datos bien diseñado es la piedra angular para lograr informes rápidos. Antes de pensar en medidas DAX o en optimizar visuales, debemos asegurarnos de que la estructura semántica (el modelo) sea lo más sencilla y eficiente posible.

Una buena base asegura que el análisis fluya rápidamente. Aquí te dejo algunos consejos clave:

Usar el modelo en estrella en lugar del modelo en copo de nieve

En Power BI (y en data warehousing en general) se recomienda utilizar un modelo en estrella siempre que sea viable, en lugar de un modelo en copo de nieve. ¿Qué significa esto? Un modelo en estrella tiene una tabla central de hechos (fact table) rodeada de tablas de dimensiones independientes, cada una directamente relacionada con la tabla de hechos.

En cambio, un modelo copo de nieve normaliza las dimensiones en múltiples tablas (es decir, una dimensión que a su vez se conecta con subdimensiones). Por ejemplo, si tienes productos clasificados por categoría y subcategoría, un modelo copo de nieve tendría tablas separadas para Producto, Categoría y Subcategoría todas enlazadas, mientras que en un esquema estrella podrías tener una única tabla de Producto con columnas de categoría y subcategoría incluidas.

El beneficio del modelo en estrella es la simplicidad. Power BI solo tiene que hacer joins de la tabla de hechos con cada dimensión, en lugar de navegar por cadenas de varias tablas. Esto suele traducirse en consultas más rápidas y modelos más fáciles de entender para los desarrolladores de informes.

Cuando optamos por un modelo copo de nieve, Power BI carga más tablas, lo cual es menos eficiente en cuanto a almacenamiento y rendimiento, y obliga a recorrer cadenas de relaciones más largas.

Reducir la cantidad de columnas y evitar cálculos innecesarios

Una práctica prioritaria de optimización es aplicar el principio de “menos es más” en el modelo semántico. Cada columna que incluyes en una tabla ocupa memoria en el archivo del archivo de Power BI (él .pbix) y potencialmente incrementa el tiempo de procesamiento de datos. Por ello, revisa cada tabla de tu modelo y pregúntate:

¿Realmente necesito todas estas columnas para mi análisis?

Si hay columnas que no vas a usar en ninguna visualización, medida, ni para filtrar datos, es mejor quitarlas desde el origen o al menos en Power Query. Esto no solo libera memoria, sino que simplifica el conjunto de datos para otros desarrolladores. Del mismo modo, evita traer columnas calculadas desde el origen si luego vas a recalcularlas en Power BI, o viceversa; es decir, no dupliques cálculos en varios sitios, y de hacerlo mejor que ya venga de BBDD bien procesado.

Uso de relaciones optimizadas entre tablas

Las relaciones son el tejido conectivo de nuestro modelo. Para garantizar un buen rendimiento, debemos elegir correctamente la cardinalidad, la dirección del filtro y evitar en lo posible, configuraciones complejas que ralenticen las consultas. Aquí te dejo algunas recomendaciones:

• Define relaciones de uno a muchos siempre que la naturaleza de los datos lo permita, colocando la tabla de dimensión en el lado del “uno” y la de hechos en el lado del “muchos”. Power BI maneja muy bien este esquema clásico. Evita las relaciones muchos a muchos nativas salvo que no haya más remedio, ya que requieren un trabajo adicional del motor (crea internamente combinaciones que pueden ser costosas con muchos datos).

• Configura la dirección del filtro de las relaciones normalmente como simple (unidireccional). Es decir, las dimensiones filtran a la tabla de hechos, pero no al revés. El filtro bidireccional puede ser útil para situaciones específicas (como roles de jerarquía u operaciones de análisis inusuales), pero en general añade complejidad y puede causar cálculos ambiguos o más lentos. Si necesitas filtrar en ambos sentidos en casos puntuales, considera usar medidas DAX con funciones como CROSSFILTER o USERELATIONSHIP en lugar de dejar siempre activa la bidireccionalidad.

• Utiliza campos clave lo más simples posible para relacionar. Si tienes una clave compuesta de múltiples columnas, quizás valga la pena crear una clave única (por ejemplo, concatenando campos en Power Query) para reducir la cantidad de comparaciones que hace Power BI al relacionar tablas. Además, asegúrate de que los campos relacionados estén indexados o sean de tipo entero si vienen de la fuente, ya que las relaciones numéricas suelen evaluarse más rápido que las de texto.

Optimización de consultas y transformación de datos

Delegar toda la transformación en Power BI puede afectar el rendimiento. Si las consultas M (Power Query) no aprovechan el Query Folding, traerá más datos de los necesarios y filtrará después, consumiendo memoria y tiempo. Además, medidas DAX mal estructuradas pueden recalcularse más veces de lo debido, ralentizando el informe.

Filtrar datos en la fuente antes de importarlos

Regla de oro: no traigas a Power BI más datos de los que realmente necesitas.

Si tu BBDD de ventas tiene 10 años de históricos, pero tu informe solo analiza los últimos 2 años, aplica filtros para limitar la extracción a ese período. Esto se puede hacer de varias formas, la más sencilla es filtrar las fechas (u otros campos) en el propio Power Query. Si la conexión lo soporta, Power Query intentará plegar la consulta (Query Folding) al origen de datos.

Query Folding es la capacidad de Power Query de convertir los pasos de transformación (como agrupaciones o uniones) en una instrucción nativa de la fuente de datos, como consultas SQL. Esto evita traer toda la tabla y luego filtrar en memoria, ya que el propio origen de datos ejecuta los filtros y solo devuelve la información necesaria.

Lo ideal es delegar el máximo de procesamiento a la fuente, y traer únicamente las columnas y filas necesarias.

Usar la carga incremental para grandes volúmenes de datos

Cuando trabajas con grandes volúmenes de datos que se actualizan periódicamente, necesitas usar la característica de Carga Incremental (incremental refresh). Esta te permite actualizar solo la porción de datos que ha cambiado (por ejemplo, las ventas de los últimos X días) en lugar de recargar la tabla completa en cada refresh.

Configurarla implica definir un rango de fechas (parámetros RangeStart y RangeEnd en Power Query) y luego, en Power BI Desktop, establecer la política de actualización incremental indicando cuántos períodos históricos mantener y qué período es el incremental.

Una vez publicado el conjunto de datos en el Power BI Service, este automáticamente gestionará particiones de datos.

Evitar columnas calculadas en Power Query si no son necesarias

Ya comentamos antes la importancia de no traer columnas inútiles, y en Power Query esto es aún más crítico. Cada transformación en el editor tiene un coste, por lo que crear columnas calculadas puede ser útil, pero revísalas con mucho ojo. ¿Son necesarias todas? ¿Se pueden calcular mejor en la fuente de datos antes de la importación? ¿O quizá conviene calcularlo en DAX como medida si es un valor derivado utilizado solo en visualizaciones?

Filtra en origen, usa query folding, considera la carga incremental y aligera las transformaciones. Esto asegurará que los datos que llegan a tu modelo lo hacen rápido y ya en un estado óptimo para ser usados, sin cargas extras adicionales.

Mejorando el rendimiento de las medidas en DAX

El siguiente frente de batalla son las medidas DAX, esas fórmulas que agregan y calculan nuestros indicadores en tiempo de ejecución. Un informe de Power BI habitualmente tiene decenas de medidas (sumas, conteos, ratios, cálculos de porcentaje del total, etc.), y su eficiencia impacta directamente en la velocidad para poder visualizar los resultados al cambiar un filtro o actualizar los datos.

A continuación, veremos cómo podemos mejorar el rendimiento de las medidas DAX.

Uso eficiente de funciones iterativas como SUMX, COUNTX y AVERAGEX

DAX nos ofrece dos tipos de funciones para agregaciones: las agregaciones rápidas (SUM, COUNT, AVERAGE, MIN, MAX…) y las iterativas con “X” (SUMX, COUNTX, AVERAGEX, etc.). Las funciones iterativas recorren fila por fila una tabla evaluando una expresión, mientras que las agregaciones simples delegan gran parte del trabajo al motor de almacenamiento de Power BI que está altamente optimizado en columna. Por lo tanto, siempre que puedas usar una función simple, hazlo.

Por ejemplo, si quieres sumar ventas, usar SUM(Ventas[Importe]) será más eficiente que usar SUMX(Ventas, Ventas[Importe]), aunque den el mismo resultado, porque la versión no iterativa aprovecha cálculos en modo columna mucho más rápido.

Las funciones iterativas son poderosas cuando necesitas hacer cálculos más complejos (por ejemplo, sumar un cálculo por fila que no existe directamente como columna), pero úsalas con precaución. Un uso ineficiente típico es anidar muchos iteradores o usarlos sobre tablas muy grandes sin filtrarlas primero. Si, por ejemplo, necesitas un AVERAGEX sobre millones de filas haciendo una expresión costosa, considera si puedes precalcular parte de esa expresión en el modelo o si puedes limitar el contexto.

Estas funciones son útiles, pero también intensivas. Aplica filtros previos para minimizar la cantidad de filas evaluadas. Por ejemplo, antes de usar SUMX, usa CALCULATE con filtros específicos.

Otro fallo común es abusar de FILTER + agregaciones cuando a veces se pueden lograr con cálculos más directos. Por ejemplo, calcular un recuento de algo con COUNTROWS(FILTER(Tabla, condición)) suele ser menos eficiente que usar directamente CALCULATE(COUNTROWS(Tabla), condición) o incluso mejor, crear una medida de conteo básica y usar la condición en CALCULATE.

El motor de fórmulas de DAX (Formula Engine) es rápido, pero el motor de almacenamiento (Storage Engine, que maneja agregaciones de columnas) es mucho más rápido en operaciones simples. Cuantas más operaciones fila a fila le pidas a la Formula Engine, más lento será el resultado.

Optimización de cálculos con variables en DAX

Una de las optimizaciones más sencillas y efectivas en DAX es introducir variables (VAR) dentro de tus medidas. Las variables permiten almacenar resultados intermedios y reutilizarlos, evitando cálculos repetidos. Esto mejora tanto la legibilidad del código como, en muchos casos, el rendimiento.

Por ejemplo, imagina que tienes una medida de crecimiento anual que calcula las ventas del año actual y las del año anterior para luego sacar el porcentaje de variación. Un enfoque sin variables podría recalcular las ventas del año anterior dos veces (una para restar y otra para el divisor).

Veámoslo con un ejemplo práctico: Sin utilizar variables, podríamos definir la medida así:

Ventas YoY % =
DIVIDE(

    ([Ventas] - CALCULATE([Ventas], PARALLELPERIOD('Fecha'[Date], -12, MONTH))),
    CALCULATE([Ventas], PARALLELPERIOD('Fecha'[Date], -12, MONTH))
)

Aquí estamos llamando dos veces a CALCULATE([Ventas], PARALLELPERIOD(...)) para obtener las ventas del año anterior, una en el numerador y otra en el denominador del DIVIDE. Esto obliga a Power BI a calcular esa misma cifra dos veces. En un modelo grande, esa redundancia penaliza.

Ahora la versión optimizada con VAR:

Ventas YoY % =
VAR PreviousYearSales = CALCULATE([Ventas], PARALLELPERIOD('Fecha'[Date], -12, MONTH))
RETURN
    DIVIDE([Ventas] - PreviousYearSales, PreviousYearSales)

Con este patrón, calculamos una sola vez las ventas del año previo, las guardamos en la variable PreviousYearSales y luego simplemente las reutilizamos. El resultado numérico es el mismo, pero internamente la consulta DAX es mucho más eficiente, se logra aproximadamente el doble de rendimiento (mitad de tiempo de respuesta) en la medida optimizada respecto a la versión original.

Evitar cálculos excesivos en medidas de agregación complejas

No sobrecargues una medida con demasiada lógica. Si un cálculo combina varios indicadores, como ventas sobre objetivo o rotación de inventario, es mejor dividirlo en medidas intermedias y luego combinarlas en la final. Esto hace que Power BI optimice el procesamiento, reutilizando resultados en caché en lugar de recalcular todo cada vez, lo que mejora tanto el rendimiento como la claridad del modelo.

Optimización de visualizaciones y elementos gráficos

Llegados a este punto, hemos afinado el modelo, los datos y las medidas. Ahora toca cuidar la capa más llamativa, las visualizaciones (gráficos, tablas, tarjetas y demás elementos en pantalla).

Un error común es pensar que las visualizaciones “no pesan”, cuando en realidad usar cada gráfico implica consultas y renderizado que se suman a la carga total. Optimizar cómo diseñamos la página del informe es crucial para mejorar la experiencia del usuario. Aquí te dejo algunas recomendaciones:

Reducir el número de visualizaciones en un solo informe

Menos es más, también en la interfaz. Cada visualización genera consultas DAX y carga de renderizado, por lo que llenar una página con demasiados gráficos, tablas y filtros ralentizan el informe. Es tentador mostrarlo todo en un solo vistazo, pero a costa de tiempos de carga elevados y una peor experiencia para el usuario. Prioriza lo esencial, usa drill-through para el detalle y apuesta por un diseño minimalista que haga el informe más rápido y fácil de interpretar.

Ok, pero ¿cómo sabemos si realmente estamos siguiendo las mejores prácticas en el diseño del informe?

Para eso contamos con 2 herramientas:

• DAX Studio es una aplicación gratuita de código abierto que se integra con Power BI Desktop y permite conectarse al modelo de datos para analizar el rendimiento de las medidas, evaluar funciones como CALCULATE, FILTER, SUMX, revisar el plan de ejecución y detectar posibles cuellos de botella en las consultas. También facilita la exportación de datos y la depuración de cálculos complejos.

• Performance Analyzer, disponible en Power BI Desktop, te permite medir cuánto tarda cada visual en renderizarse y desglosar ese tiempo en diferentes categorías:

Desde el Performance Analyzer de Power BI puedes analizar el tiempo de carga de los elementos visuales de un informe. Con esta herramienta, puedes ver cuánto tiempo tarda cada visual en renderizarse y desglosar ese tiempo en diferentes categorías:

1. DAX Query: Tiempo que tardan las consultas DAX en ejecutarse.
2. Visual Display: Tiempo que tarda Power BI en procesar y mostrar el gráfico en la pantalla.
3. Other: Incluye tiempos adicionales como la preparación del modelo de datos o la ejecución de scripts personalizados.

Si notas que un visual tarda demasiado en la sección DAX Query, puede ser una consulta optimizable. Si el problema está en Visual Display, podría ser un problema de diseño del gráfico o de la cantidad de datos procesados.

Evitar el uso excesivo de tablas y matrices con demasiados datos

¿De verdad necesitas 5000 filas y 30 columnas a la vez?

Es muy poco práctico para un usuario ver tantos datos de golpe y, además, sobrecarga el informe. Lo ideal es habilitar la paginación o, si alguien requiere el detalle completo, ofrecer la exportación a CSV/Excel. En la página principal, céntrate en mostrar un resumen o un Top N de datos relevantes. Si quieres un desglose más profundo, aprovecha visualizaciones jerárquicas que se expandan solo cuando sea nece