Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En los modelos semánticos de Power BI, el modo de almacenamiento de una tabla depende de su origen de datos. Puede usar el modo de almacenamiento para controlar si Power BI almacena los datos de tabla en memoria para los informes o recupera los datos del origen de datos cuando se cargan los objetos visuales.
En este artículo se presentan los distintos modos de almacenamiento de tablas y se describe cómo afectan al comportamiento del informe.
Modos de almacenamiento de tablas
| Modo Table Storage | Cuando esté disponible | Ventajas | Nota |
|---|---|---|---|
| Importación | En Power BI Desktop y el modelado web de Power BI, para casi todos los orígenes de datos, al seleccionar Obtener datos y usar Power Query. | Una instantánea de los datos se almacena en el almacenamiento nativo para la carga rápida de objetos visuales en informes. | Para obtener los datos más recientes del origen de datos, actualice el modelo semántico o la tabla. |
| Direct Lake en OneLake | En Power BI Desktop y en el modelado web de Power BI, para los orígenes de datos de Microsoft Fabric, al seleccionar el catálogo de OneLake. | Los datos se examinan desde tablas delta de Microsoft OneLake para cargar rápidamente visuales en informes. | De forma predeterminada, se cargan los datos más recientes. Para acceder a los datos más recientes actualizando manualmente, desactive la sincronización automática en la página de configuración de actualización programada. Una actualización también se denomina reenraming para Direct Lake. Para obtener más información sobre Direct Lake, consulte Introducción a Direct Lake. |
| Direct Lake en SQL | En los puntos finales analíticos de SQL para elementos de Fabric, al seleccionar Nuevo modelo semántico. | Los datos se escanean desde tablas delta de OneLake para habilitar la rápida carga en los informes. | En este modo, Power BI usa el modo de almacenamiento DirectQuery para acceder a los datos en los casos siguientes: - Se usa una vista. - El acceso granular de SQL está activado. - Se alcanza una barrera de seguridad de Direct Lake. |
| DirectQuery | En Power BI Desktop, para algunos orígenes de datos como bases de datos SQL, al seleccionar Obtener datos y usar Power Query. | Los datos se consultan desde el origen de datos cuando los objetos visuales se cargan y no se almacenan en el modelo semántico. | La consulta es una traducción de la consulta DAX (expresiones de análisis de datos) de Power BI, que los objetos visuales utilizan, al lenguaje de consulta nativo del origen de datos, como una consulta SQL. |
| DirectQuery en modelos semánticos de Power BI | En Power BI Desktop, cuando se conecta a un modelo semántico de Power BI y, a continuación, selecciona Realizar cambios en este modelo o cuando ya se agrega una tabla Import o DirectQuery. | Las consultas DAX del nuevo modelo se ejecutan en el modelo de origen y pueden usar medidas de ambos. Algunas propiedades de columna del modelo remoto se pueden invalidar en el nuevo modelo. Esta personalización incluye cadenas de formato y nombres para mostrar. | Use este modo de almacenamiento cuando necesite realizar un pequeño cambio en un modelo semántico existente para un informe específico. |
| Dual | En Power BI Desktop, al convertir una tabla directQuery en modo de importación. Aparece un cuadro de diálogo con opciones para convertir las tablas de DirectQuery restantes al modo Dual. | Las relaciones entre las tablas DirectQuery e Import están limitadas. Cambiar de DirectQuery al modo Dual puede ayudar a mantener esas relaciones normales. | |
| Híbrido | En escenarios de actualización incremental de una tabla de importación. La última partición de la tabla puede estar en modo DirectQuery para ayudar a garantizar que los datos más recientes estén disponibles entre las actualizaciones de importación. | La creación y administración de particiones se automatizan para reducir la cantidad de datos que se deben actualizar. | Para más información, consulte Configuración de la actualización incremental y los datos en tiempo real para los modelos semánticos de Power BI. |
Nota
El modo de conexión dinámica se usa en los casos siguientes:
- Para conectarse a un modelo semántico de Power BI en Power BI Desktop para crear un informe
- Para crear un informe a partir de un modelo semántico de Power BI en la web
Un informe de Live Connect no tiene ningún modelo semántico local y a veces se denomina informe fino. El modelo semántico remoto de Power BI puede usar cualquier modo de almacenamiento de tablas. Como autor del informe, puede ver el modelo en la vista Modelo , pero solo hay disponible información limitada. Las medidas que cree se almacenan en el informe.
Un modelo semántico compuesto es un modelo semántico con tablas en más de un modo de almacenamiento. Para más información, consulte Uso de modelos compuestos en Power BI.
Consulte el modo de almacenamiento de una tabla.
Cada tabla tiene una Storage mode propiedad . Para ver el modo de almacenamiento de una tabla, siga estos pasos:
En la vista Modelo , seleccione la tabla.
En el panel Propiedades , expanda la sección Avanzadas y, a continuación, expanda la lista Modo de almacenamiento .
Para la mayoría de las tablas, solo puede establecer el modo de almacenamiento al agregar la tabla. Solo puede cambiar el modo de almacenamiento si la tabla está en modo DirectQuery o Direct Lake en modo OneLake cuando se crea:
- Puede cambiar una tabla DirectQuery a una tabla Import o Dual. Después de establecer esta propiedad, no se puede cambiar el modo de nuevo a DirectQuery. Las excepciones son el modelado web de Power BI y la edición en vivo en Power BI Desktop. Estos entornos tienen control de versiones, que puede usar para invertir un modo de almacenamiento cambiado.
- Puede convertir las tablas de Direct Lake en OneLake a tablas de Importación mediante los laboratorios de enlaces semánticos en cuadernos de Fabric.
Restricciones en las tablas DirectQuery y Dual
Las tablas duales tienen las mismas restricciones funcionales que las tablas directQuery. Estas restricciones incluyen transformaciones M limitadas y funciones DAX restringidas en columnas calculadas. Para obtener más información, consulte Limitaciones de DirectQuery.
Propagación de la configuración Dual
Tenga en cuenta el siguiente modelo. Todas las tablas proceden de un único origen que admite los modos Import y DirectQuery.
Supongamos que todas las tablas de este modelo se establecen inicialmente en DirectQuery. Si cambia el modo de almacenamiento de la tabla SurveyResponse a Importar, se muestra la siguiente ventana de advertencia:
Puede establecer las tablas de dimensiones, Customer, Geography y Date en modo Dual para reducir el número de relaciones limitadas en el modelo semántico y ayudar a mejorar el rendimiento. Normalmente, las relaciones limitadas implican al menos una tabla DirectQuery en la que JOIN la lógica no se puede trasladar a los sistemas de origen. Dado que las tablas duales pueden actuar ya sea como tablas DirectQuery o como tablas de importación, se evita esta situación.
La lógica de propagación está diseñada para ayudar con modelos que contienen muchas tablas. Supongamos que tiene un modelo con 50 tablas y solo es necesario almacenar en caché determinadas tablas de hechos (transaccionales). La lógica de Power BI Desktop calcula el conjunto mínimo de tablas de dimensiones que se deben establecer en modo Dual, por lo que no es necesario.
La lógica de propagación atraviesa únicamente hacia el lado de las relaciones uno-a-muchos.
Ejemplo de uso del modo de almacenamiento
Considere un ejemplo que implique las siguientes tablas y modos de almacenamiento:
| Tabla | Modo de almacenamiento |
|---|---|
| Ventas | DirectQuery |
| SurveyResponse | Importación |
| Fecha | Dual |
| Cliente | Dual |
| Geografía | Dual |
El uso de estos modos de almacenamiento da como resultado el siguiente comportamiento, suponiendo que la tabla Sales tiene un volumen de datos significativo:
Power BI Desktop almacena en caché las tablas de dimensiones, Date, Customer y Geography, para ayudar a reducir los tiempos de carga de los informes iniciales cuando recuperan valores de segmentación de datos que se van a mostrar.
Power BI Desktop no almacena en caché la tabla Sales.
- No almacenar en caché esta tabla ayuda a mejorar los tiempos de actualización de datos y a reducir el consumo de memoria.
- Las consultas de informe basadas en la tabla Sales se ejecutan en modo DirectQuery. Estas consultas pueden tardar más que las consultas de importación. Pero los resultados de las consultas de DirectQuery están más cerca de los resultados en tiempo real, ya que no se introduce ninguna latencia de almacenamiento en caché.
Las consultas de informe basadas en la tabla SurveyResponse son relativamente rápidas, ya que se devuelven de la memoria caché en memoria.
Consultas que aciertan o pierden la memoria caché
Puede usar SQL Server Profiler para ver qué consultas impactan o no a la caché en memoria. Si conecta esta herramienta al puerto de diagnóstico para Power BI Desktop, puede realizar un seguimiento basado en los siguientes eventos:
- Eventos de consultas\Inicio de consulta
- Procesamiento de consultas\Inicio de consulta Vertipaq SE
- Procesamiento de consultas\DirectQuery Begin
Para cada evento Query Begin , compruebe otros eventos con el mismo ActivityID valor. Por ejemplo, si no hay un evento DirectQuery Begin, pero hay un evento Vertipaq SE Query Begin, la consulta se responde desde la memoria caché.
Las consultas que hacen referencia a tablas duales devuelven datos de la memoria caché, si es posible. De lo contrario, vuelven al modo DirectQuery.
Tenga en cuenta algunas consultas DAX que hacen referencia a las tablas de la sección anterior. Por ejemplo, la consulta siguiente hace referencia solo a una columna de la tabla Date , que está en modo Dual. Por lo tanto, la consulta debe alcanzar la memoria caché:
La consulta siguiente hace referencia solo a una columna de la tabla Sales , que está en modo DirectQuery. Por tanto, no debe alcanzar la memoria caché:
La consulta siguiente es interesante porque combina ambas columnas. Esta consulta no alcanza la memoria caché. Inicialmente, puede esperar que recupere los valores CalendarYear de la memoria caché y los valores SalesAmount del origen y, a continuación, combine los resultados. Pero este enfoque es menos eficaz que enviar una SUM operación o GROUP BY al sistema de origen. Si el origen realiza la operación, solo se devuelve la suma de las ventas de cada año. Es probable que ese resultado contenga mucho menos filas que si se devuelven todos los valores SalesAmount .
Nota
Este comportamiento es diferente de las relaciones de varios a varios en Power BI Desktop cuando las tablas almacenadas en caché se combinan con tablas que no están almacenadas en caché.
Mantener sincronizadas las memorias caché
Las consultas de la sección anterior muestran que las tablas duales a veces alcanzan la memoria caché y, a veces, no. Como resultado, los valores que se devuelven de una caché obsoleta pueden diferir de los valores devueltos por el origen. La ejecución de consultas no intenta enmascarar problemas de datos, por ejemplo, filtrando los resultados de DirectQuery para que coincidan con los valores almacenados en caché. Es responsabilidad suya conocer los flujos de datos y debe diseñarlos en consecuencia. Existen técnicas establecidas para controlar estos casos en el origen, si es necesario.
El modo de almacenamiento dual es una optimización del rendimiento. Solo debe usarlo de maneras que no pongan en peligro la capacidad de cumplir los requisitos empresariales. Para un comportamiento alternativo, considere la posibilidad de usar las técnicas descritas en Descripción de las relaciones de varios a varios en Power BI Desktop.
Vista de tabla
Si al menos una tabla del modelo semántico tiene un modo de almacenamiento de Importar o Dual, la pestaña Vista tabla de Power BI está disponible.
Al seleccionar una tabla Dual o Import en la vista Tabla , se muestran sus datos almacenados en caché. No se muestra ningún dato para las tablas directQuery. En su lugar, aparece un mensaje que indica que no se pueden mostrar las tablas de DirectQuery.
Consideraciones y limitaciones
Actualmente existen algunas limitaciones para los modos de almacenamiento de tablas y el uso de determinados modos en modelos compuestos:
Los siguientes orígenes de conexión dinámica (multidimensionales) no se pueden usar con modelos compuestos:
- SAP HANA
- SAP Business Warehouse
Cuando se conecta a esos orígenes multidimensionales mediante el modo DirectQuery, no se puede conectar a otro origen de DirectQuery ni combinarlo con datos importados.
Las limitaciones del uso del modo DirectQuery se siguen aplicando al usar modelos compuestos. Muchas de esas limitaciones se aplican en el nivel de tabla y dependen del modo de almacenamiento de la tabla. Por ejemplo, una columna calculada de una tabla importada puede hacer referencia a otras tablas, pero una columna calculada en una tabla DirectQuery solo puede hacer referencia a columnas de la misma tabla. Otras limitaciones se aplican al modelo en su conjunto, si alguna de las tablas del modelo está en modo DirectQuery.
Contenido relacionado
Para obtener más información sobre los modelos compuestos y el modo DirectQuery, consulte los siguientes artículos: