Optimización del rendimiento de Power BI: DAX, modelos y consultas

Un informe de Power BI que tarda 15 segundos en cargarse es un informe que los usuarios dejan de usar. El rendimiento no es una sutileza técnica, es la diferencia entre la adopción y el abandono de BI. Cada segundo de tiempo de carga del informe reduce considerablemente la participación del usuario. Las investigaciones muestran consistentemente que los paneles interactivos (con un tiempo de carga de menos de 3 segundos) reciben entre 4 y 5 veces más vistas que los lentos (más de 10 segundos), y los usuarios que experimentan una lentitud constante vuelven a los procesos manuales en un plazo de 30 días.

La buena noticia es que los problemas de rendimiento de Power BI casi siempre tienen solución. En nuestra experiencia en la optimización de cientos de entornos Power BI, el 90 % de los problemas de rendimiento se deben a una de cinco causas fundamentales: medidas DAX ineficientes, modelos de datos sobredimensionados, diseño de relaciones deficiente, uso inadecuado de DirectQuery o capacidad insuficiente para la carga de trabajo. Esta guía proporciona un enfoque sistemático para diagnosticar y resolver cada uno de estos problemas.

Si su entorno de Power BI experimenta problemas de rendimiento que su equipo no puede resolver internamente, nuestros servicios de optimización del rendimiento de Power BI brindan análisis y soluciones prácticos.

Conclusiones clave

• El Analizador de rendimiento en Power BI Desktop identifica qué objetos visuales y consultas son lentos. Siempre comience aquí antes de optimizar.
• DAX Studio revela si las consultas lentas tienen cuellos de botella en el motor de almacenamiento (escaneo de datos) o en el motor de fórmulas (cálculo) --- la solución difiere dramáticamente
• Los errores de rendimiento de DAX más comunes son el anidamiento de CALCULATE innecesario, el uso de iteradores donde los agregadores son suficientes y la materialización de tablas intermedias grandes.
• El tamaño del modelo afecta directamente el rendimiento: eliminar columnas no utilizadas, reducir la cardinalidad y optimizar los tipos de datos pueden reducir los modelos entre un 40% y un 70%.
• Las tablas de agregación proporcionan mejoras de rendimiento de consultas de 10 a 100 veces mayores para conjuntos de datos grandes mediante el cálculo previo de datos resumidos
• DirectQuery es entre 10 y 100 veces más lento que el modo Importar para informes interactivos. Úselo solo cuando los requisitos de actualización de los datos realmente lo exijan.
• La evaluación comparativa antes/después con métricas documentadas es esencial para demostrar el impacto de la optimización y prevenir la regresión.

---

Herramientas y metodología de diagnóstico

Analizador de rendimiento

Performance Analyzer es la herramienta de diagnóstico integrada de Power BI Desktop. Registra el tiempo de ejecución de cada consulta generada por cada objeto visual en una página de informe, dividiendo el tiempo en tres componentes:

Cómo utilizar el Analizador de rendimiento:

1. Abra su informe en Power BI Desktop.
2. Vaya a Ver > Analizador de rendimiento.
3. Haga clic en "Iniciar grabación".
4. Interactuar con el informe (cambiar filtros, navegar por páginas, aplicar segmentaciones).
5. Haga clic en "Detener".
6. Revisa los resultados, ordenados por duración total.

Interpretación de resultados:

• Si domina el tiempo de consulta DAX, el problema está en sus medidas o modelo. Utilice DAX Studio para un análisis más profundo.
• Si domina el tiempo de visualización, el problema está en la configuración visual (demasiados puntos de datos, formato condicional complejo o un objeto visual personalizado con bajo rendimiento).
• Si domina "Otro" tiempo, el problema es la infraestructura (latencia de red para DirectQuery, cuellos de botella en la puerta de enlace o limitación de capacidad).

El paso crítico que la mayoría de la gente omite: Copie la consulta DAX de Performance Analyzer (haga clic derecho > "Copiar consulta") y péguela en DAX Studio. Performance Analyzer le indica qué objeto visual es lento. DAX Studio te dice por qué.

Estudio DAX

DAX Studio es una herramienta gratuita de código abierto que proporciona capacidades de diagnóstico profundas para el motor de Analysis Services subyacente a Power BI. Es la herramienta más importante en el conjunto de herramientas de cualquier ingeniero de rendimiento de Power BI.

Capacidades clave de DAX Studio:

Tiempos del servidor: Muestra el desglose entre el tiempo de consulta del motor de almacenamiento (SE) y del motor de fórmula (FE).

• Las consultas del motor de almacenamiento (SE) son escaneos de datos ejecutados en el almacenamiento en columnas (motor VertiPaq). Están altamente paralelizados y son rápidos. Las consultas SE aparecen como declaraciones xmSQL en el seguimiento.
• Las operaciones del motor de fórmula (FE) son cálculos de un solo subproceso realizados sobre los resultados de consultas SE. Las operaciones FE son el principal cuello de botella en la mayoría de las medidas DAX lentas.

El objetivo de optimización es impulsar la mayor cantidad de trabajo posible en Storage Engine y minimizar las operaciones de Formula Engine.

Planes de consulta: DAX Studio puede mostrar planes de consulta lógicos y físicos, mostrando exactamente cómo el motor procesa su medida. Para los usuarios avanzados, los planes de consulta revelan oportunidades de optimización invisibles únicamente en los datos de tiempo.

VertiPaq Analyzer: escanea todo el modelo de datos e informa el tamaño de las columnas, la cardinalidad, el tipo de codificación y el tamaño del diccionario para cada columna de cada tabla. Así es como identifica columnas y tablas de gran tamaño que están inflando su modelo.

Metodología de optimización sistemática

1. Línea de base: Registre los tiempos de carga de cada página utilizando Performance Analyzer. Tamaño del modelo de documento (Archivo > Información > Reducir tamaño de archivo > Analizar). Registre las métricas de capacidad si está en Premium/Fabric.

2. Identificar: Ordene los resultados del Analizador de rendimiento por duración total. Concéntrese en las 5 imágenes más lentas: estas generan el mayor impacto cuando se optimizan.

3. Diagnóstico: Copie cada consulta lenta a DAX Studio. Analizar el tiempo SE vs FE. Identifique patrones DAX específicos que causen cuellos de botella en FE.

4. Optimizar: Aplique correcciones específicas (que se describen en detalle a continuación). Pruebe cada cambio individualmente para medir su impacto.

5. Validar: Vuelva a ejecutar el Analizador de rendimiento y compárelo con la línea base. Documente la mejora para cada optimización.

6. Monitorizar: Configure un monitoreo continuo del rendimiento (métricas de capacidad, problemas informados por los usuarios, comprobaciones periódicas del Analizador de rendimiento) para evitar la regresión.

---

Patrones DAX lentos y correcciones

Patrón 1: CALCULATE Nesting innecesario

El problema:

Bad Measure =
CALCULATE(
    CALCULATE(
        SUM(Sales[Amount]),
        FILTER(ALL(Products), Products[Category] = "Electronics")
    ),
    Date[Year] = 2025
)

Las declaraciones CALCULATE anidadas no añaden potencia, añaden confusión y, a veces, sobrecarga de rendimiento. Cada CALCULATE crea un nuevo contexto de filtro y anidarlos puede producir resultados inesperados y forzar al motor de fórmulas a realizar transiciones de contexto redundantes.

La solución:

Good Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics",
    Date[Year] = 2025
)

Combine argumentos de filtro en un único CALCULATE. Se aplican varios argumentos de filtro simultáneamente (intersección). Esto produce el mismo resultado con una ejecución más limpia.

Patrón 2: FILTRAR con TODOS en lugar de filtros de columna directos

El problema:

Slow Measure =
CALCULATE(
    SUM(Sales[Amount]),
    FILTER(ALL(Products), Products[Category] = "Electronics")
)

FILTER(ALL(Productos), ...) obliga al motor a materializar toda la tabla Productos en el motor de fórmulas y luego itera a través de cada fila para aplicar el filtro. Para una tabla con millones de filas, esto es extraordinariamente lento.

La solución:

Fast Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics"
)

Los filtros de columna directos en CALCULATE se resuelven en Storage Engine, que es mucho más rápido. Utilice FILTRO solo cuando necesite aplicar una condición compleja que no se pueda expresar como una simple comparación de columnas (por ejemplo, filtrar por un valor de medida o una condición que involucre varias columnas).

Regla general: Si su condición FILTER hace referencia a una sola columna con una comparación simple, reemplácela con un argumento de filtro CALCULATE directo. Reserve FILTRO para condiciones realmente complejas.

Patrón 3: Iteradores donde los agregadores son suficientes

El problema:

Slow Total = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

SUMX recorre cada fila de la tabla Ventas y evalúa la expresión de cada fila en el motor de fórmulas. Para una tabla de Ventas con 10 millones de filas, esto significa 10 millones de operaciones FE.

La solución:

Si el cálculo es una simple multiplicación de dos columnas, calcule previamente como una columna calculada:

-- Add calculated column: Sales[LineTotal] = Sales[Quantity] * Sales[UnitPrice]
-- Then use aggregator:
Fast Total = SUM(Sales[LineTotal])

SUM opera en Storage Engine, que procesa datos en columnas en lotes altamente optimizados. La columna calculada aumenta el tamaño del modelo pero reduce drásticamente el tiempo de consulta.

Cuándo mantener SUMX: Utilice SUMX cuando necesite lógica condicional a nivel de fila (por ejemplo, SUMX(Sales, IF(Sales[Type] = "Return", -Sales[Amount], Sales[Amount]))) o cuando itere sobre una tabla pequeña (tablas de dimensiones con miles, no millones, de filas).

Patrón 4: Mesas intermedias grandes

El problema:

Slow Measure =
SUMX(
    SUMMARIZE(Sales, Products[Category], Date[Month]),
    [Complex Calculation]
)

RESUMEN crea una tabla intermedia en el motor de fórmulas. Si la combinación de Categoría y Mes produce 10 000 filas y [Cálculo complejo] activa consultas SE adicionales para cada fila, el resultado es más de 10 000 consultas, un patrón de rendimiento catastrófico conocido como "tormentas de consultas SE".

La solución:

Fast Measure =
VAR SalesTable =
    ADDCOLUMNS(
        SUMMARIZE(Sales, Products[Category], Date[Month]),
        "@SubTotal", CALCULATE(SUM(Sales[Amount]))
    )
RETURN
    SUMX(SalesTable, [@SubTotal] * [SomeMultiplier])

Al materializar el subtotal dentro de ADDCOLUMNS (que utiliza la transición de contexto de manera eficiente), las referencias posteriores a @SubTotal no activan consultas SE adicionales. Las variables (VAR) también garantizan que la tabla se evalúe solo una vez, incluso si se hace referencia a ella varias veces.

Patrón 5: Impacto en el rendimiento de la seguridad a nivel de fila

El problema:

RLS con expresiones DAX complejas evalúa cada consulta, agregando una sobrecarga que se agrava en los elementos visuales. Una regla RLS mal escrita puede duplicar o triplicar los tiempos de carga de informes.

Asesinos comunes del rendimiento del SPI:

• LOOKUPVALUE en filtros RLS (fuerza la evaluación FE por fila)
• CONTIENE o IN operadores en mesas grandes
• Reglas RLS que hacen referencia a medidas en lugar de simples filtros de columna.
• RLS de múltiples mesas con problemas de dirección de filtro cruzado

La solución:

• Utilice comparaciones de columnas simples: [TenantId] = USERNAME() o [Region] IN VALUES(SecurityTable[Region])
• Calcular previamente las asignaciones de seguridad en una tabla de dimensiones dedicada con relaciones directas
• Evite medidas en las reglas RLS: use filtros a nivel de columna únicamente
• Pruebe el rendimiento de RLS con DAX Studio comparando los tiempos de consulta con y sin RLS activo

---

Reducción del tamaño del modelo

Por qué es importante el tamaño del modelo

El modo de importación de Power BI almacena datos en un formato de columnas altamente comprimido (motor VertiPaq). El tamaño del modelo impacta directamente:

• Consumo de memoria: Todo el modelo debe caber en la memoria. En Premium/Fabric, los modelos más grandes consumen más capacidad y pueden provocar una limitación de la presión de la memoria.
• Duración de la actualización: Los modelos más grandes tardan más en actualizarse porque se deben procesar, comprimir y cargar más datos.
• Rendimiento de consultas: Los modelos más grandes producen escaneos más grandes, lo que aumenta el tiempo de consulta incluso para DAX bien optimizado.
• Tamaño de archivo: Los archivos PBIX con modelos grandes tardan en guardarse, publicarse y descargarse.

Identificación de los contribuyentes al tamaño del modelo

Utilice VertiPaq Analyzer de DAX Studio (Avanzado > Ver métricas) para identificar las tablas y columnas más grandes:

Técnicas de optimización

Eliminar columnas no utilizadas:

La optimización única de mayor impacto. Cada columna de su modelo consume memoria, ya sea que se use o no. Audite su modelo y elimine cualquier columna a la que no se haga referencia en un objeto visual, una medida, una relación o una regla RLS.

Impacto típico: reducción del tamaño del modelo entre un 20% y un 40%.

Reducir la cardinalidad de las columnas de texto:

Las columnas de texto con muchos valores únicos (descripciones, direcciones, notas) se comprimen mal. Si la columna solo se necesita para visualización (no para filtrar ni agrupar), considere moverla a una tabla de solo detalles o truncar los valores largos.

Para las columnas utilizadas en agrupación/filtrado, considere agrupar: en lugar de 50.000 nombres de productos únicos, agrúpelos en 500 categorías de productos con una tabla de búsqueda separada para detalles de productos individuales.

Optimizar tipos de datos:

• Utilice números enteros en lugar de decimales cuando los valores sean números enteros (ahorra un 50 % por columna)
• Utilice Fecha en lugar de Fecha y hora cuando no se necesita hora (reduce la cardinalidad)
• Evite almacenar valores numéricos como texto (el texto se comprime mucho peor que los números)
• Utilice valores booleanos en lugar de texto para columnas de sí/no o verdadero/falso

Impacto típico: reducción del tamaño del modelo entre un 10 y un 20 %.

Dividir mesas grandes:

Una tabla de hechos de 100 millones de filas se puede dividir en datos activos (año actual, cargados en cada actualización) y datos históricos (años anteriores, cargados con menos frecuencia o almacenados como agregaciones). Esto reduce tanto el tamaño del modelo como la duración de la actualización.

Tablas de agregación (que se describen en detalle a continuación):

Para tablas de hechos grandes, las tablas de agregación proporcionan la mayor mejora de rendimiento al calcular previamente los datos resumidos con granularidades comúnmente consultadas.

---

Tablas de agregación

¿Qué son las tablas de agregación?

Las tablas de agregación son tablas de resumen precalculadas que Power BI consulta en lugar de examinar la tabla de detalles completa. Cuando un usuario ve un gráfico que muestra los ingresos mensuales por región, Power BI consulta la tabla de agregación (que puede tener 120 filas: 10 regiones x 12 meses) en lugar de la tabla de detalles (que puede tener 50 millones de filas de transacciones).

El poder de las tablas de agregación es que son transparentes para informar a los consumidores. Los usuarios interactúan con las mismas imágenes y medidas. Power BI enruta automáticamente las consultas a la tabla de agregación cuando la granularidad de la consulta coincide y pasa a la tabla de detalles para consultas detalladas o de nivel de detalle.

Diseño de tablas de agregación

Paso 1: Identificar la granularidad de agregación.

Analice sus informes para determinar las granularidades de consultas más comunes. Para un panel de ventas:

• La mayoría de las consultas visuales ejecutivas a nivel de Mes + Región + Categoría de producto
• Consulta de imágenes del administrador a nivel Semana + Tienda + Producto
• Consulta de tablas de detalles a nivel de transacción individual.

Diseñe una o dos tablas de agregación con las granularidades más consultadas.

Paso 2: crear la tabla de agregación.

En Power Query, cree una nueva tabla que agrupe su tabla de hechos en la granularidad de agregación:

Paso 3: Configurar asignaciones de agregación.

En Power BI Desktop, seleccione la tabla de agregación, vaya a Propiedades > Administrar agregaciones y asigne cada columna de agregación a su función y columna de tabla de detalles correspondiente:

Paso 4: Ocultar la tabla de agregación.

Los usuarios no deben interactuar directamente con la tabla de agregación. Ocultarlo de la vista del informe. Power BI lo utiliza de forma automática y transparente.

Impacto en el rendimiento de la agregación

Estas mejoras se acumulan en las páginas del informe. Una página con 10 elementos visuales, cada uno de los cuales consulta la tabla de agregación en lugar de la tabla de detalles, podría cargarse en 1 segundo en lugar de 30 segundos.

Mantenimiento de la tabla de agregación

• Actualizar las tablas de agregación en el mismo cronograma que las tablas de detalles para mantener la coherencia.
• Supervisar las tasas de aciertos de agregación utilizando DAX Studio (los eventos de seguimiento muestran si las consultas llegan a la agregación o fracasan)
• Agregue nuevas tablas de agregación a medida que identifique patrones de consulta comunes adicionales
• Eliminar tablas de agregación cuya tasa de aciertos cae por debajo del 50% (consumen espacio sin beneficio suficiente)

---

Optimización de consulta directa

Cuando DirectQuery es necesario

DirectQuery consulta la base de datos de origen en tiempo real en lugar de importar datos al motor en memoria de Power BI. Es necesario cuando:

• Los requisitos de actualización de los datos exigen una latencia inferior a un minuto (negociación de acciones, monitoreo de IoT, detección de fraude)
• El conjunto de datos supera los límites de tamaño del modelo de Power BI (10 GB en Premium P1, 25 GB en P2, etc.)
• El cumplimiento o la seguridad requieren que los datos nunca abandonen el sistema fuente.
• La base de datos de origen ya cuenta con amplias vistas materializadas e infraestructura de agregación.

Para todos los demás escenarios, se prefiere el modo Importar. El modo de importación es entre 10 y 100 veces más rápido para consultas interactivas y proporciona una mejor experiencia de usuario.

Estrategias de rendimiento de DirectQuery

Reduzca la cantidad de imágenes por página.

Cada objeto visual en el modo DirectQuery genera una consulta independiente a la base de datos de origen. Una página con 20 elementos visuales genera 20 consultas simultáneas cuando se carga la página, además de consultas adicionales cuando cambian los filtros. Limite las páginas de DirectQuery a un máximo de 8 a 10 elementos visuales.

Optimizar la base de datos de origen.

Power BI envía consultas SQL (o consultas nativas para orígenes que no son SQL) al origen. El rendimiento de la base de datos de origen determina directamente el rendimiento del informe. Asegurar:

• Los índices existen en todas las columnas utilizadas en filtros, relaciones y medidas.
• Las estadísticas están actualizadas en las tablas consultadas.
• El servidor de la base de datos tiene suficiente CPU y memoria para consultas analíticas simultáneas junto con cargas de trabajo operativas.
• Considere la posibilidad de crear vistas materializadas o vistas indexadas para patrones de consulta comunes.

Habilitar opciones de reducción de consultas.

En Power BI Desktop > Opciones > Reducción de consultas, habilite:

• "Reducir el número de consultas enviadas al no enviar consultas con resaltado cruzado": evita que el filtrado cruzado entre elementos visuales genere consultas adicionales
• "Agregar un botón Aplicar a cada segmentación": los usuarios ajustan varias segmentaciones antes de que se ejecuten las consultas, lo que reduce el volumen total de consultas.
• "Agregar un botón Aplicar al panel de filtro": el mismo principio para el panel de filtro

Utilice estratégicamente el modo de almacenamiento dual.

Las tablas se pueden configurar en modo "Dual", que almacena datos en modo Importación (para consultas locales rápidas) y mantiene una conexión DirectQuery (para relaciones con tablas DirectQuery). Establezca tablas de dimensiones (Productos, Clientes, Fechas) en modo dual mientras mantiene tablas de hechos grandes en DirectQuery. Esto mejora drásticamente el rendimiento del filtro y la segmentación sin sacrificar la actualización de los datos en las tablas de hechos.

Implementar almacenamiento en caché de consultas.

Habilite el "almacenamiento en caché de consultas" en la configuración del conjunto de datos del servicio Power BI. Esto almacena en caché los resultados de las consultas durante un período configurable y ofrece resultados almacenados en caché para consultas idénticas. El almacenamiento en caché de consultas es particularmente efectivo para paneles vistos por muchos usuarios con los mismos filtros (por ejemplo, un panel ejecutivo que muestra métricas de toda la empresa).

---

Monitoreo del desempeño de la capacidad

Métricas clave de capacidad

Para las organizaciones con capacidad Premium o Fabric, el rendimiento de la infraestructura es tan importante como el diseño de informes. La limitación de la capacidad puede hacer que incluso los informes bien optimizados funcionen mal.

Métricas a monitorear:

La aplicación de métricas de capacidad de Microsoft Fabric

Microsoft proporciona una aplicación de supervisión de capacidad dedicada en el servicio Power BI. Instálelo desde AppSource y conéctelo a su capacidad. Proporciona:

• Utilización de CPU histórica y en tiempo real con desglose por tipo de carga de trabajo
• Análisis de limitación interactivo que muestra qué operaciones activaron la limitación
• Consumo de memoria por conjunto de datos con historial de desalojo
• Actualizar las tendencias de rendimiento.
• Consultar percentiles de rendimiento.

Revise esta aplicación semanalmente durante las fases de optimización y mensualmente durante el estado estable.

Capacidad de dimensionamiento adecuado

La capacidad insuficiente provoca limitaciones y una mala experiencia del usuario. La capacidad sobreaprovisionada es una pérdida de dinero. Para dimensionar correctamente es necesario comprender el patrón de su carga de trabajo:

• Horas de uso pico: La mayoría de las organizaciones ven una carga entre 2 y 3 veces mayor durante el horario comercial que durante la noche. Si elige el tamaño para el pico y tiene SKU de tela F, considere hacer una pausa durante la noche o reducir el tamaño fuera del horario laboral.
• Actualización versus conflicto interactivo: Las actualizaciones de datos y las consultas interactivas compiten por los mismos recursos de capacidad. Programe actualizaciones intensas fuera de las horas pico de interacción. Si esto no es posible, considere capacidades separadas para cargas de trabajo interactivas y de actualización.
• Proyección de crecimiento: Planifique entre 6 y 12 meses de crecimiento. El tamaño del modelo, el número de usuarios y la complejidad de las consultas tienden a aumentar con el tiempo. Genere entre un 30 y un 50 % de espacio libre en el dimensionamiento de la capacidad.

---

Antes/Después de la evaluación comparativa

Por qué es importante la evaluación comparativa

La optimización sin medición son conjeturas. La evaluación comparativa antes/después demuestra que los cambios mejoraron el desempeño, cuantifica la mejora para las partes interesadas y crea una línea de base para detectar regresiones futuras.

Metodología de evaluación comparativa

Paso 1: Definir métricas.

Paso 2: Registrar la línea base.

Antes de realizar cualquier cambio, registre todas las métricas. Ejecute Performance Analyzer 10 veces para tener en cuenta el calentamiento y la variabilidad de la caché. Registre la mediana (P50) y el percentil 95 (P95) para cada métrica.

Paso 3: implementar los cambios de forma incremental.

Realice una optimización a la vez y vuelva a medir después de cada cambio. Esto identifica qué optimizaciones tuvieron el mayor impacto y evita enmascarar una regresión con una mejora en otro lugar.

Paso 4: registrar métricas posteriores a la optimización.

Después de todas las optimizaciones, registre las mismas métricas utilizando la misma metodología. Presentar resultados en una tabla comparativa:

Paso 5: Programe un seguimiento continuo.

El rendimiento se degrada con el tiempo a medida que crecen los datos, se agregan nuevas medidas y se crean nuevos elementos visuales. Programe revisiones de desempeño trimestrales utilizando la misma metodología para detectar la regresión temprano.

Para las organizaciones que necesitan una optimización sistemática del rendimiento con métricas documentadas de antes y después, ECOSIRE proporciona servicios integrales de rendimiento de Power BI que incluyen análisis de DAX Studio, optimización de modelos y ajuste de capacidad.

---

Técnicas avanzadas de optimización

Grupos de cálculo

Los grupos de cálculo reemplazan las variantes de medidas repetitivas con una lógica de cálculo reutilizable. En lugar de crear medidas separadas para MTD, QTD, YTD, año anterior y crecimiento interanual para cada medida base, un grupo de cálculo aplica estas transformaciones dinámicamente.

Beneficio de rendimiento: Menos medidas en el modelo significa una huella de metadatos más pequeña y una carga del modelo más rápida. Más importante aún, los grupos de cálculo fomentan medidas base más simples, que tienden a funcionar mejor que las medidas complejas todo en uno.

Modelos compuestos

Los modelos compuestos combinan el modo Importación y tablas DirectQuery en un solo modelo. Utilice el modo Importar para tablas de dimensiones y tablas de hechos consultadas con frecuencia, DirectQuery para tablas muy grandes que cambian con demasiada frecuencia para Importar.

Beneficio de rendimiento: Las búsquedas de dimensiones y las operaciones de filtrado se ejecutan a velocidad de importación (microsegundos), mientras que las consultas de tablas de hechos se ejecutan a velocidad de DirectQuery (cientos de milisegundos a segundos). El resultado neto es significativamente mejor que DirectQuery puro.

Actualización incremental

La actualización incremental carga solo datos nuevos y modificados durante la actualización, en lugar de recargar todo el conjunto de datos. Para una tabla de 100 millones de filas donde solo cambian 100.000 filas diariamente, la actualización incremental reduce el tiempo de actualización en un 99 %.

Configuración: Defina un parámetro RangeStart y RangeEnd en Power Query. Configure la política de actualización incremental para especificar cuántos días/meses de datos actualizar y cuántos datos históricos retener. Power BI particiona automáticamente el conjunto de datos y actualiza solo las particiones activas.

Beneficio de rendimiento: Reducción drástica en la duración de la actualización y el consumo de capacidad durante la actualización. También permite la actualización en tiempo real con particiones DirectQuery en la capacidad de Fabric.

Plegado de consultas

El plegado de consultas devuelve las transformaciones de Power Query a la base de datos de origen, ejecutándolas como SQL nativo en lugar de en el motor de Power Query. Las consultas plegadas se ejecutan mucho más rápido porque el motor de la base de datos las optimiza y ejecuta de forma nativa.

Cómo verificar: Haga clic derecho en cualquier paso en Power Query Editor y verifique si "Ver consulta nativa" está disponible. Si es así, la consulta pasa a ese paso. Si está atenuado, el plegado se rompió en un paso anterior.

Interruptores de plegado comunes: Columnas personalizadas con expresiones M, combinación de tablas de diferentes fuentes, ciertas transformaciones (pivotantes, conversiones de tipos complejos). Al plegar pausas, todas las transformaciones posteriores se ejecutan en el motor Power Query, que es significativamente más lento para conjuntos de datos grandes.

---

Preguntas frecuentes

¿Cuál es un buen objetivo para el tiempo de carga de los informes de Power BI?

Apunte a menos de 3 segundos para paneles de control de uso frecuente y a menos de 5 segundos para informes analíticos detallados. Estos objetivos se alinean con las expectativas de los usuarios de las aplicaciones web y mantienen una alta participación. Se debe priorizar la optimización de los informes que superen constantemente los 10 segundos. Mida el tiempo de carga desde la perspectiva del usuario (incluida la red y el renderizado), no solo el tiempo de consulta DAX. El tiempo de consulta DAX del Analizador de rendimiento más el tiempo de representación visual deben totalizar menos de 2 segundos para cada objeto visual para lograr una carga de página de 3 segundos con 8 a 10 objetos visuales.

¿Debería preferir siempre el modo Importar a DirectQuery?

Para los informes interactivos consumidos por usuarios empresariales, sí. El modo de importación casi siempre es la mejor opción. El modo de importación es entre 10 y 100 veces más rápido para las consultas, no depende del rendimiento de la base de datos de origen durante la visualización de informes y admite toda la gama de funciones DAX y características de IA. Utilice DirectQuery solo cuando tenga un requisito genuino de actualización de datos en menos de un minuto, cuando su conjunto de datos exceda los límites de tamaño de importación o cuando el cumplimiento exija que los datos permanezcan en el sistema de origen. Considere los modelos compuestos como un término medio: importe las dimensiones y los hechos consultados con frecuencia, realice consultas directas solo en las tablas que realmente necesitan actualización en tiempo real.

¿Con qué frecuencia debo ejecutar auditorías de rendimiento en mis informes de Power BI?

Realizar una auditoría integral de desempeño trimestralmente para los informes de producción. Entre auditorías, supervise las métricas de capacidad semanalmente e investigue rápidamente cualquier lentitud informada por los usuarios. Los principales eventos que deberían desencadenar una auditoría inmediata incluyen: crecimiento significativo del volumen de datos (aumento de más del 25%), adición de nuevas páginas de informes o medidas DAX complejas, cambios en la concurrencia de usuarios (crecimiento de usuarios posterior al lanzamiento) y cambios de capacidad (actualización, degradación o migración).

¿Puedo optimizar el rendimiento de Power BI sin cambiar mis informes?

Sí, hasta cierto punto. Las optimizaciones a nivel de infraestructura incluyen: actualizar la SKU de capacidad, habilitar el almacenamiento en caché de consultas en la configuración del servicio, programar actualizaciones intensas fuera de las horas pico, configurar la agrupación de puertas de enlace para un mejor rendimiento y optimizar la base de datos de origen (índices, estadísticas, vistas materializadas). Estos cambios mejoran el rendimiento sin tocar los archivos de informes. Sin embargo, las optimizaciones más impactantes suelen implicar cambios a nivel de informe: reescritura de medidas DAX, reducción del tamaño del modelo, tablas de agregación y reducción del recuento visual. La optimización de la infraestructura aborda las limitaciones de capacidad; La optimización de informes aborda la eficiencia.

¿Qué causa que los informes de Power BI se vuelvan más lentos con el tiempo?

Cinco causas comunes: (1) Crecimiento del volumen de datos: las mismas consultas tardan más a medida que las tablas crecen de 1 millón a 10 millones de filas. (2) Acumulación de medidas: se agregan nuevas medidas sin optimizar las existentes, y las interacciones entre medidas crean una complejidad agravante. (3) Expansión visual: los usuarios agregan más imágenes por página, cada una de las cuales genera consultas adicionales. (4) Inflación del modelo: se agregan nuevas columnas y tablas sin eliminar las no utilizadas. (5) Crecimiento simultáneo de usuarios: más usuarios compiten por los mismos recursos de capacidad. Aborde estos problemas con auditorías de desempeño trimestrales, políticas de gobernanza que limiten el recuento visual y midan la complejidad, y un monitoreo proactivo de la capacidad.