Tipos de Data model: ejemplos y consejos para Power BI (Parte 1)

• Decide cómo vas a almacenar tus datos en Power BI. Es una decisión crucial que conviene tomar al principio de tu proyecto de Power BI.
  
• Tomar la decisión equivocada puede tener consecuencias desastrosas, y no es raro verlo en equipos y proyectos.
• Hay distintos tipos de modos de almacenamiento: Import, DirectQuery, Direct Lake y modelos compuestos. También hay configuraciones especiales de tablas, como tablas duales o híbridas.
• En general, Import debería considerarse el modo predeterminado y preferido para conectarte a los datos y almacenarlos en Power BI. En función del caso, puede que quieras – o necesites – usar otros tipos de modos de almacenamiento.
• Antes de decidir, valida con una prueba de concepto o comprueba las consecuencias del modo de almacenamiento en tu escenario en términos de funcionalidad, rendimiento y coste.

En Power BI, necesitas crear un modelo semántico (también llamado Data model) para dar soporte a análisis con informes o paneles, tablas dinámicas e IA. Una de las primeras decisiones que tomas al conectarte a los datos en Power BI es cómo los vas a almacenar. De forma predeterminada, Power BI importará esos datos en memoria. Esto significa que Power BI carga una copia de los datos que consultas en los objetos visuales del Report (que generan consultas DAX entre bastidores). Este modo de almacenamiento de importación es la forma más sencilla y cómoda de conectarte a los datos, pero no es la única opción. Elegir entre los distintos tipos de modo de almacenamiento es una de las decisiones más tempranas e importantes que puedes tomar en un proyecto de Power BI, y puede tener efectos significativos en el diseño o la funcionalidad de tu modelo. 

Hay varios modos de almacenamiento distintos para Power BI, que se resumen a grandes rasgos y en términos de capacidades en la documentación de Microsoft. Como estos modos de almacenamiento se determinan por tabla, en algunos escenarios también puedes combinarlos en un único modelo: un modelo compuesto. Más adelante en este artículo hablamos de los modelos compuestos. 

El siguiente diagrama ofrece una visión rápida de los distintos tipos de modos de almacenamiento: 

En este artículo describimos brevemente cada uno de estos modos de almacenamiento y aportamos algunos consejos o ejemplos sobre cómo elegir entre ellos y cómo usarlos en un proyecto de Power BI. En resumen: 

• Import es el valor predeterminado preferido y es adecuado para la mayoría de escenarios donde cargas datos en memoria. 

• DirectQuery es cuando consultas datos directamente en un sistema de origen compatible, y en general se considera más lento y más caro. Aun así, permite datos casi en tiempo real si los necesitas, por lo que puede ser adecuado en casos concretos si no puedes usar Direct Lake. DirectQuery también es útil para combinar datos de un modelo semántico existente con otros datos en un modelo compuesto. 

• Direct Lake solo está disponible en Microsoft Fabric. Los datos por columnas se cargan rápido y bajo demanda desde OneLake en memoria, en lugar de cargar todas las columnas de la tabla durante una actualización del modelo, como en importación. Así, Direct Lake es una optimización técnica de Import con un rendimiento de consulta comparable. Es adecuado cuando tienes mayores volúmenes de datos u otros retos de rendimiento en las actualizaciones, y la madurez de proceso para configurar y administrar tablas Delta en OneLake. En general, deberías usar Direct Lake sobre OneLake en lugar de Direct Lake sobre SQL Endpoint, pero ten en cuenta que, a fecha de octubre de 2025, Direct Lake sobre OneLake sigue en versión preliminar pública. Además, Direct Lake suele ser preferible a DirectQuery en la mayoría de escenarios. Direct Lake es más complejo y tiene más matices técnicos que los otros modos de almacenamiento. 

• Modelos compuestos es cuando combinas varios modos de almacenamiento en el mismo modelo. Puede ser útil en circunstancias concretas para resolver problemas específicos, pero añade complejidad al diseño, desarrollo y distribución del modelo por diversos motivos. 

• Configuraciones especiales de tablas como duales o tablas híbridas son útiles en casos concretos cuando las necesitas en modelos compuestos o en la actualización incremental, respectivamente. Las tablas híbridas no están admitidas en Workspaces Pro. 

Es importante que consideres el modo de almacenamiento con cuidado; no decidas a la ligera qué modo usar, o te causará muchos dolores de cabeza (y potencialmente bastante dinero) más adelante. Las siguientes secciones entran en más detalle. 

Import es el modo de almacenamiento más común y más simple, y el preferido para la mayoría de escenarios. Está admitido por todas las fuentes de datos y tipos de archivo. Con el modo de almacenamiento de importación, obtienes el mejor rendimiento, porque los datos se almacenan en memoria. Sin embargo, cuando quieras actualizar tu Data model para incluir los datos más recientes, necesitas hacer una actualización. Con grandes volúmenes de datos o mucha complejidad, esta actualización puede convertirse en una carga para algunos equipos: los procesos de actualización se alargan o ponen presión sobre los sistemas de origen. En muchos casos, esto puede evitarse siguiendo prácticas recomendadas, como: 

• Reducción de datos: tomar solo los datos que necesitas y filtrar o quitar los que no. 

• Configurar la actualización incremental para obtener solo filas nuevas o modificadas en una tabla, en lugar de intentar actualizar toda la tabla de una vez. 

• Optimización de Power Query: por ejemplo, asegurarte de que las consultas se pliegan al origen (para que el trabajo pesado lo haga el origen de datos y no Power BI).   

• Gestión adecuada de los procesos, por ejemplo, evitar actualizar varios modelos a la vez sobre el mismo origen de datos. 

• Gestión adecuada de los recursos, por ejemplo, configurar los Gateways de datos que necesitas para comunicarte con los datos en determinados orígenes o escenarios.  

El modo de almacenamiento Import es apropiado en escenarios como los siguientes: 

• Estás creando un Data model estándar de Power BI que, en la práctica, no tiene requisitos específicos para las conexiones al origen, los volúmenes de datos, la frescura o la complejidad. Esto ocurre en la mayoría de los Data model de Power BI. 

• Estás realizando un análisis acotado de archivos locales (como Excel o archivos .csv) en Power BI Desktop. Estos archivos pueden estar en tu equipo, pero si quieres configurar una actualización programada para obtener automáticamente los datos más recientes, tendrías que mover esos archivos a una ubicación en la nube, como SharePoint u OneDrive, o usar un Gateway local con acceso a esos archivos. 

• Tienes el requisito o la intención de crear una columna calculada o una tabla calculada, que en general no están admitidas en DirectQuery o Direct Lake (descritos más adelante). 
• Eres nuevo o estás al principio de tu implementación de Power BI, y no tienes requisitos específicos que obliguen a usar DirectQuery o Direct Lake (descritos más adelante), que añaden complejidad, limitaciones y consideraciones adicionales que debes gestionar.  

DirectQuery es un modo de almacenamiento alternativo en el que consultas datos directamente en un origen compatible (como una base de datos Azure SQL, Snowflake o Databricks). Con Import, los objetos visuales consultan los datos en memoria con DAX. Con DirectQuery, hay un paso adicional: ese DAX se traduce a SQL y se envía al sistema de origen. 

Esto significa que, cuando un usuario ve por primera vez un Report conectado a un modelo semántico en modo DirectQuery, verá datos relativamente recientes a fecha de la última actualización de página o interacción. En cambio, si el modelo semántico estuviera en Import, los datos solo reflejarían la situación a fecha de la última actualización del modelo semántico. Por tanto, DirectQuery puede ser adecuado para algunas situaciones en las que necesitas informes casi en tiempo real o mayores exigencias de frescura de datos. 

Sin embargo, como los datos no se almacenan en memoria, las consultas suelen tardar más en completarse cuando usas DirectQuery. Esto hace que tus informes tarden más en mostrar datos, y aumenta el coste indirecto de optimizar Data model y cálculos. Tienes que considerar configuraciones especiales y optimizaciones que solo aplican a modelos DirectQuery, algunas exclusivas de PPU, Premium o capacidades de Fabric, como las agregaciones automáticas y las agregaciones definidas por el usuario  Además, consultar el sistema de origen puede tener un coste directo, así que un mayor uso de los informes puede traducirse en facturas más altas. Un ejemplo de esto sería el aumento de costes en un data warehouse basado en consumo como Snowflake o Databricks. 

DirectQuery puede ser adecuado en escenarios como los siguientes: 

• Tienes una necesidad explícita y real de datos casi en tiempo real o una gran exigencia de frescura de datos que no puedes cubrir con el modo Import, y no lo vas a resolver con la carga de trabajo Real-Time Intelligence en Microsoft Fabric. 

• En conclusión