Modelos compuestos en Power BI: combinación de importación y DirectQuery

Durante años, los profesionales de Power BI tuvieron que elegir: modo de importación (rápido, pero los datos están tan actualizados como la última actualización) o DirectQuery (siempre actualizado, pero potencialmente lento y con consultas limitadas). Los modelos compuestos cambiaron este cálculo al permitir que ambos modos de almacenamiento coexistan en un solo modelo, con relaciones que cruzan el límite del modo.

Esta capacidad desbloquea escenarios que antes eran imposibles: un panel que muestra el historial completo de transacciones de ayer desde una partición de importación junto con los datos en tiempo real de hoy desde una fuente DirectQuery, todo unido a una tabla de oportunidades de Salesforce en vivo consultada bajo demanda. Comprender cómo funcionan los modelos compuestos (y cuándo crean más problemas de los que resuelven) es un conocimiento esencial para cualquier profesional avanzado de Power BI.

Conclusiones clave

• Los modelos compuestos combinan modos de importación, DirectQuery y almacenamiento dual dentro de un único modelo semántico
• El modo de importación proporciona compresión VertiPaq y rendimiento de consultas en memoria para datos históricos
• El modo DirectQuery consulta la fuente en tiempo real; la actualización es excelente, pero el rendimiento depende de la fuente
• Las tablas de modo dual pueden actuar como importación o DirectQuery según el contexto de la consulta.
• Las relaciones que cruzan los límites del modo de almacenamiento añaden complejidad a las consultas y pueden causar problemas de rendimiento.
• Las tablas de agregación en modelos compuestos mejoran drásticamente el rendimiento de las consultas DirectQuery
• DirectQuery para conjuntos de datos de Power BI (encadenamiento) permite modelos compuestos creados sobre modelos semánticos compartidos
• Las relaciones limitadas entre las tablas de importación y DirectQuery restringen ciertas funciones DAX

---

Modos de almacenamiento: Importación, DirectQuery y Dual

Antes de comprender los modelos compuestos, cada modo de almacenamiento debe comprenderse individualmente.

El modo de importación carga datos del sistema de origen en el motor de almacenamiento VertiPaq en memoria de Power BI. Los datos se comprimen (a menudo 10:1 o mejor) y se almacenan como datos en columnas que ejecutan consultas analíticas extremadamente rápido (generalmente milisegundos para la mayoría de las consultas en conjuntos de datos de hasta cientos de millones de filas). La limitación: los datos están tan actualizados como la última actualización programada o manual.

El modo DirectQuery consulta el sistema de origen en tiempo real cada vez que un usuario interactúa con un informe. El motor Power BI traduce consultas DAX en consultas de origen nativo (SQL para bases de datos relacionales, etc.) y las ejecuta en el origen. Los datos siempre están actualizados, pero el rendimiento depende completamente del rendimiento de las consultas del sistema de origen. Una base de datos analítica dedicada y bien indexada manejará bien las consultas de DirectQuery; una base de datos de producción OLTP con una gran carga transaccional puede producir resultados lentos e inconsistentes.

Modo dual es un híbrido especial disponible en modelos compuestos. Una tabla de modo dual se almacena físicamente como importación (datos cargados en VertiPaq), pero también se puede consultar a través de DirectQuery cuando el contexto de la consulta lo requiere. Esto se utiliza principalmente para tablas de dimensiones compartidas que necesitan participar en relaciones con tablas de hechos de importación y de DirectQuery.

---

Cuándo utilizar modelos compuestos

Los modelos compuestos son apropiados para escenarios específicos. Añaden una complejidad que no se justifica cuando arquitecturas más simples cumplen los requisitos.

Utilice modelos compuestos cuando:

No utilice modelos compuestos cuando:

• Un modelo de importación completo se actualiza lo suficientemente rápido y la latencia de datos es aceptable (en la mayoría de los casos)
• La fuente de DirectQuery no puede manejar la carga de consultas (bases de datos OLTP de producción)
• Se necesitan cálculos DAX complejos: los modelos compuestos limitan ciertas funciones DAX
• La seguridad a nivel de fila debe abarcar el límite del modo de almacenamiento (implementación compleja)

---

Configurar modos de almacenamiento

En Power BI Desktop, el modo de almacenamiento se establece por tabla. Haga clic derecho en una tabla en la vista Modelo → Propiedades → Avanzado → Modo de almacenamiento.

Para un modelo compuesto típico con una tabla de hechos grande en DirectQuery y dimensiones en Import:

1. Configure FactSales → Modo de almacenamiento: DirectQuery
2. Configure DimDate → Modo de almacenamiento: Dual (sirve consultas de importación y DirectQuery)
3. Configure DimProduct → Modo de almacenamiento: Importar (tabla pequeña, completamente en caché)
4. Configure DimCustomer → Modo de almacenamiento: Dual (usado en relaciones entre fuentes)
5. Configure RealtimeSales (datos de hoy) → Modo de almacenamiento: DirectQuery

Cuando configura una tabla como DirectQuery o cambia los modos de almacenamiento, Power BI muestra advertencias sobre relaciones y posibles limitaciones. Revíselos detenidamente: indican dónde el comportamiento del modelo puede diferir de un modelo de importación pura.

---

Relaciones en modelos compuestos

Las relaciones entre tablas de diferentes modos de almacenamiento se comportan de manera diferente a las relaciones del mismo modo, y comprender estas diferencias es fundamental para crear modelos que produzcan resultados correctos.

Relaciones regulares conectan dos tablas donde el lado "muchos" puede usar el lado "uno" para filtrar. En los modelos de importación, ambas tablas están en la memoria y la relación se realiza en la memoria rápidamente. En los modelos compuestos con una tabla de importación y una tabla de DirectQuery, la relación provoca un escaneo de una tabla que luego se usa para filtrar la otra, generando potencialmente grandes consultas entre modos.

Las relaciones limitadas se crean automáticamente cuando una tabla de DirectQuery tiene una relación de muchos a muchos con una tabla de importación o en otros escenarios de modo cruzado. Las relaciones limitadas no admiten filtros bidireccionales y restringen determinadas funciones DAX (por ejemplo, funciones que dependen de la ruta del filtro de relaciones). Power BI informa relaciones limitadas en la vista del modelo con una línea de puntos en lugar de una línea continua.

Relaciones entre fuentes conectan tablas de fuentes de datos completamente diferentes (por ejemplo, una tabla de SQL Server conectada a través de DirectQuery y una tabla de Salesforce conectada a través de otra conexión de DirectQuery). Estas relaciones requieren que un lado sea una tabla de modo dual: Power BI debe poder materializar un lado de la relación en la memoria para unirse al otro.

El impacto práctico de estos tipos de relaciones: las medidas DAX que funcionan correctamente en un modelo de importación pura pueden producir resultados inesperados o errores en un modelo compuesto. Pruebe todas las medidas cuidadosamente después de cambiar los modos de almacenamiento, particularmente aquellas que involucran USERELATIONSHIP, CROSSFILTER, CALCULATE con funciones de filtro relacionadas con relaciones y agregaciones sobre tablas relacionadas.

---

Tablas de agregación: el patrón del modelo compuesto central

El patrón de modelo compuesto más valioso combina una gran tabla de hechos de DirectQuery con una tabla de agregación en modo de importación que resume previamente los datos en un nivel más alto.

El problema: una tabla de datos de ventas de 500 millones de filas en DirectQuery es demasiado grande para que la mayoría de los sistemas de origen realicen consultas interactivas: cada gráfico tarda más de 10 segundos mientras el origen ejecuta costosas consultas agregadas.

La solución: cree previamente una tabla de resumen que agregue el hecho a un grano diario/mensual/categoría de producto e importe esa tabla de resumen a Power BI. La mayoría de las consultas (que son a nivel mensual, trimestral o de categoría) llegan a la agregación de importación rápida. Solo las consultas que profundizan hasta el nivel de transacción individual regresan a DirectQuery.

Configuración de agregaciones:

Primero, cree la tabla de agregación en su almacén de datos:

CREATE TABLE SalesByDayProduct AS
SELECT
    SaleDateKey,
    ProductKey,
    CustomerSegmentKey,
    RegionKey,
    SUM(SalesAmount) as SalesAmount,
    SUM(Quantity) as Quantity,
    SUM(Cost) as Cost,
    COUNT(*) as TransactionCount
FROM FactSales
GROUP BY SaleDateKey, ProductKey, CustomerSegmentKey, RegionKey;

Importe esta tabla a Power BI y establezca el modo de almacenamiento en Importar.

Luego, configure la agregación en Power BI:

• Haga clic derecho en SalesByDayProduct → Administrar agregaciones
• Asigne cada columna a su relación con la tabla de detalles y la función de resumen (Suma, Promedio, Conteo, etc.)
• Establezca la columna "Resumen" (SalesAmount → Suma se asigna a FactSales[SalesAmount] → Suma)

El motor de consultas de Power BI ahora enruta automáticamente las consultas a la tabla de agregación cuando es posible y recurre a la tabla de detalles de DirectQuery solo cuando la consulta requiere detalles a nivel de fila que la agregación no proporciona.

El resultado del rendimiento es espectacular: las agregaciones a nivel de categoría y de tiempo que antes tomaban 15 segundos ahora regresan en menos de 1 segundo, mientras que la opción de profundizar en transacciones individuales sigue estando disponible.

---

DirectQuery para conjuntos de datos de Power BI

Power BI introdujo DirectQuery para conjuntos de datos de Power BI (también llamado "conexión en vivo con modelos compuestos" o simplemente "modelos compuestos en conjuntos de datos compartidos"). Esto permite a un desarrollador crear un nuevo informe o conjunto de datos que utiliza un conjunto de datos de Power BI publicado existente como origen de DirectQuery, al mismo tiempo que agrega nuevas tablas, medidas calculadas y datos de importación local.

Caso de uso clave: una organización tiene un modelo semántico empresarial certificado que cubre datos básicos de finanzas y ventas. Un equipo que trabaja en un análisis específico necesita agregar algunos datos locales (un archivo CSV con códigos de proyecto, un archivo Excel con objetivos) sin modificar el modelo empresarial certificado. Al utilizar DirectQuery para conjuntos de datos de Power BI, crean un modelo compuesto que hace referencia al modelo empresarial a través de DirectQuery y agrega sus tablas locales como datos de importación.

Esto permite una arquitectura analítica gobernada donde:

• El equipo de datos central mantiene conjuntos de datos empresariales certificados.
• Los equipos empresariales amplían estos conjuntos de datos con el contexto local sin crear modelos separados e inconsistentes.
• El modelo empresarial sigue siendo la única fuente de verdad para las métricas compartidas.

Limitaciones: DirectQuery para conjuntos de datos de Power BI hereda todas las limitaciones de DirectQuery normal: algunas funciones DAX están restringidas, la seguridad a nivel de fila debe configurarse correctamente para propagarse a través del modelo compuesto y la conexión al conjunto de datos de origen agrega una capa de procesamiento de consultas.

---

Optimización del rendimiento para modelos compuestos

Los modelos compuestos requieren un ajuste de rendimiento más cuidadoso que los modelos puramente importados. Las siguientes optimizaciones son las más impactantes:

Reducir las consultas entre modos: cada recorrido de relación que cruza un límite de modo de almacenamiento agrega latencia. Minimícelos manteniendo las tablas de dimensiones en modo dual (pueden atender consultas de importación y DirectQuery sin un recorrido entre modos) y estructurando el modelo para que la mayoría de las consultas permanezcan en un solo modo.

Agregación previa en el origen: no solicite al origen de DirectQuery que realice agregaciones que Power BI podría realizar de manera más eficiente. Cree vistas o vistas materializadas en la base de datos de origen que se preagregen según el detalle que sus informes realmente necesitan.

Supervisar el plan de consultas con el Analizador de rendimiento: en Power BI Desktop, Ver → Analizador de rendimiento registra el tiempo necesario para la consulta DAX de cada objeto visual y la consulta de origen posterior (si es DirectQuery). Esto revela qué objetos visuales son lentos y si la consulta lenta está en la capa DAX o en la capa de consulta de origen.

Usar configuración de reducción de consultas: en Power BI Desktop → Opciones → Reducción de consultas, habilite las opciones para agregar botones Aplicar a segmentaciones y filtros. Esto evita que cada interacción de segmentación active inmediatamente una consulta de origen, lo que es especialmente importante para los informes de DirectQuery donde cada consulta tiene latencia de ejecución de origen y de red.

Limitar el número de conexiones de DirectQuery: cada origen de DirectQuery diferente en un modelo compuesto crea un grupo de conexiones independiente. Limite a 1 o 2 fuentes de DirectQuery cuando sea posible; más de 3 aumenta significativamente la complejidad del modelo y los posibles problemas de rendimiento.

---

Seguridad a nivel de fila en modelos compuestos

La seguridad a nivel de fila (RLS) en modelos compuestos requiere una planificación cuidadosa, particularmente cuando RLS se define en una tabla de importación que tiene una relación con una tabla de DirectQuery.

Cuando un usuario con un filtro RLS consulta un informe, Power BI aplica el filtro a la tabla adecuada. Si la tabla filtrada está en modo de importación y tiene una relación con una tabla de DirectQuery, Power BI debe traducir el filtro de importación en un filtro que se pueda enviar al origen de DirectQuery. Esto funciona en la mayoría de los casos, pero puede producir resultados inesperados con jerarquías de filtros complejas.

Práctica recomendada: defina RLS en las tablas de dimensiones del modo de importación (no en las tablas de hechos de DirectQuery). El filtro se propaga de dimensión a hecho a través de la relación, lo que funciona de manera confiable. Es posible definir RLS directamente en tablas de DirectQuery, pero es más difícil de probar y depurar.

Para los modelos compuestos que usan DirectQuery para conjuntos de datos de Power BI, el RLS definido en el conjunto de datos de origen se aplica automáticamente cuando se consulta ese conjunto de datos. Se pueden definir RLS adicionales en la capa del modelo compuesto. Este enfoque RLS en capas requiere pruebas cuidadosas para garantizar que los filtros se compongan correctamente.

---

Preguntas frecuentes

¿Puedo mezclar datos de plataformas de bases de datos completamente diferentes en un modelo compuesto?

Sí. Un modelo compuesto puede contener tablas de SQL Server (DirectQuery), Salesforce (DirectQuery), un archivo de Azure Blob Storage (Import) y Snowflake (DirectQuery) simultáneamente. Cada fuente mantiene su propia conexión. Las relaciones entre tablas de diferentes fuentes deben tener al menos una tabla de modo dual para facilitar las uniones entre fuentes. El rendimiento y la complejidad aumentan con cada fuente adicional; limitar a 2 o 3 fuentes es práctico para la mayoría de las implementaciones.

¿Qué funciones DAX no funcionan en modelos compuestos?

Algunas funciones DAX están restringidas o se comportan de manera diferente en modelos compuestos con tablas DirectQuery. Las funciones que no funcionan con relaciones limitadas incluyen SUMMARIZE (en determinados contextos), TOPN (en tablas de DirectQuery) y algunas funciones de inteligencia de tiempo. USERELATIONSHIP funciona pero puede provocar consultas entre modos. La lista completa de limitaciones está documentada en la documentación de Power BI de Microsoft en "Limitaciones de DirectQuery". Se recomienda encarecidamente probar todas las medidas críticas después de agregar tablas de DirectQuery.

¿Cómo funciona la actualización incremental con modelos compuestos?

La actualización incremental se aplica a las particiones en modo de importación dentro de un modelo compuesto. Las tablas configuradas como DirectQuery no utilizan actualización incremental: consultan el origen en tiempo real en cada interacción. La combinación más común es usar actualización incremental en particiones históricas en modo de importación y al mismo tiempo tener DirectQuery para los datos del período actual; esta es la característica de tablas híbridas, que es una forma específica de modelado compuesto dentro de una sola tabla.

¿Cuál es el impacto en el rendimiento de los modelos compuestos frente a la importación pura?

Los modelos compuestos con componentes DirectQuery siempre serán más lentos que los modelos de importación pura equivalentes para consultas equivalentes. La brecha de rendimiento depende del rendimiento del sistema de origen y de la proporción de consultas que llegan a DirectQuery frente a las particiones de importación. Con tablas de agregación bien diseñadas, la mayoría de las consultas de los usuarios llegan a la agregación de importación y regresan en menos de 1 segundo, lo que hace que el rendimiento sea aceptable. Las consultas que exploran los detalles de DirectQuery pueden tardar entre 3 y 15 segundos, según el rendimiento de la fuente.

¿Debo utilizar modelos compuestos o simplemente programar actualizaciones más frecuentes?

Las actualizaciones más frecuentes (cada 15 minutos para el modo de importación) son suficientes para la mayoría de los casos de uso en los que "casi en tiempo real" es aceptable. Los modelos compuestos con DirectQuery agregan una complejidad significativa: utilícelos solo cuando: (a) necesite datos que estén realmente actualizados al minuto o segundo, (b) el conjunto de datos sea demasiado grande para actualizarse dentro de la ventana disponible incluso con una actualización incremental, o (c) necesite combinar datos de fuentes que no se pueden consolidar en una única actualización del almacén.

---

Próximos pasos

Los modelos compuestos son una herramienta poderosa para arquitecturas sofisticadas de Power BI, pero requieren un diseño cuidadoso para evitar problemas de rendimiento y corrección. Las implementaciones más exitosas utilizan modelos compuestos para escenarios específicos y justificados en lugar de una arquitectura predeterminada.

Los servicios de modelado de datos Power BI de ECOSIRE incluyen diseño de modelos compuestos, implementación de tablas de agregación y optimización del rendimiento. Contáctenos para evaluar si los modelos compuestos son la solución adecuada para sus requisitos específicos de rendimiento y actualización de datos.