Optimización de modelos de DirectQuery con almacenamiento de nivel de tabla
DirectQuery es una forma de conseguir datos en Power BI Desktop. El método DirectQuery implica conectarse directamente a los datos en su repositorio de origen desde dentro de Power BI Desktop. Es una alternativa a la importación de datos en Power BI Desktop.
Cuando se usa el método DirectQuery, la experiencia global del usuario depende en gran medida del rendimiento del origen de datos subyacente. Un tiempo de respuesta alto para las consultas generará una experiencia de usuario negativa y, en el peor de los casos, las consultas podrían agotar el tiempo de espera. Además, la cantidad de usuarios que abren los informes en un momento dado afectará a la carga que se coloca en el origen de datos. Por ejemplo, si el informe tiene 20 objetos visuales y lo usan 10 personas, habrá 200 consultas o más en el origen de datos, ya que cada objeto visual emitirá una o más.
Por desgracia, el rendimiento de tu modelo de Power BI no solo se verá afectado por el rendimiento del origen de datos subyacente, sino también por otros factores que no es posible controlar; por ejemplo:
Latencia de red; las redes más rápidas devuelven datos con más rapidez.
El rendimiento del servidor del origen de datos y la cantidad de cargas de trabajo adicionales en ese servidor. Por ejemplo, piense en las implicaciones de una actualización de servidor que ocurre mientras cientos de usuarios utilizan el mismo servidor por distintos motivos.
Por tanto, el uso de DirectQuery supone un riesgo para la calidad del rendimiento del modelo. Para optimizar el rendimiento en esta situación, debe tener control sobre la base de datos de origen o tener acceso a ella.
Para obtener información más detallada, consulta Instrucciones del modelo de DirectQuery en Power BI Desktop.
Implicaciones del uso de DirectQuery
El procedimiento recomendado consiste en importar datos a Power BI Desktop, pero es posible que tu organización necesite usar el modo de conectividad de datos de DirectQuery debido a una de las siguientes razones (ventajas de DirectQuery):
Es adecuado cuando los datos cambian con frecuencia y hay que crear informes en tiempo real.
Puedes controlar datos de gran tamaño sin necesidad de agregarlos previamente.
Aplica las restricciones de soberanía de datos para cumplir con los requisitos legales.
Se puede utilizar con un origen de datos multidimensional que contenga medidas como SAP Business Warehouse (BW).
Si tu organización necesita utilizar DirectQuery, debe comprender claramente el comportamiento dentro de Power BI Desktop y ser consciente de las limitaciones que tiene. De ese modo, estará en la posición correcta para adoptar medidas a fin de optimizar el modelo de DirectQuery lo máximo posible.
Comportamiento de las conexiones de DirectQuery
Cuando utiliza DirectQuery para conectarse a datos en Power BI Desktop, esa conexión se comporta de la siguiente manera:
Cuando utilices por primera vez la característica Obtener datos en Power BI Desktop, deberás seleccionar el origen. Si se conecta a un origen relacional, puedes seleccionar un conjunto de tablas y cada una de ellas definirá una consulta que devuelve un conjunto de datos de forma lógica. Si selecciona un origen multidimensional, como SAP BW, solo puedes seleccionar el origen.
Al cargar los datos, estos no se importan a Power BI Desktop, solo se carga el esquema. Cuando crea un objeto visual dentro de Power BI Desktop, se envían consultas al origen subyacente para recuperar los datos necesarios. El tiempo que se tarda en actualizar el objeto visual depende del rendimiento del origen de datos subyacente.
Si se hacen cambios en los datos subyacentes, estos no se reflejarán inmediatamente en los objetos visuales existentes en Power BI, debido al almacenamiento en caché. Tendrá que hacer una actualización para ver esos cambios. Las consultas necesarias se muestran para cada uno de los objetos visuales, que se actualizan en consecuencia.
Cuando publique el informe en el servicio Power BI, se generará un modelo semántico en el servicio Power BI, lo mismo que para la importación. Sin embargo, no se incluirán datos en ese modelo semántico.
Cuando abres un informe existente en el servicio Power BI o crea uno nuevo, se consulta de nuevo al origen subyacente para recuperar los datos necesarios. En función de la ubicación del origen original, es posible que tengas que configurar una puerta de enlace de datos local.
Puedes anclar objetos visuales, o páginas de informe completas, como iconos del panel. Los iconos se actualizan de forma automática según una programación, por ejemplo, cada hora. Puedes controlar la frecuencia de esta actualización para ajustarla a tus necesidades. Al abrir un panel, los iconos reflejan los datos en el momento de la última actualización y es posible que no incluyan los últimos cambios realizados en el origen de datos subyacente. Siempre puedes actualizar un panel abierto para asegurarte de que esté actualizado.
Limitaciones de las conexiones de DirectQuery
El uso de DirectQuery puede tener implicaciones negativas. Las limitaciones varían en función del origen de datos específico que se use. Debes tener en cuenta lo siguiente:
Rendimiento: como se ha indicado antes, la experiencia global del usuario depende en gran medida del rendimiento del origen de datos subyacente.
Seguridad: si usas varios orígenes de datos en un modelo de DirectQuery, es importante comprender cómo se mueven los datos entre los orígenes de datos subyacentes y las implicaciones de seguridad asociadas. También debes identificar si las reglas de seguridad son aplicables a los datos de tu origen subyacente, ya que, en Power BI, todos los usuarios pueden ver esos datos.
Transformación de datos: en comparación con los datos importados, los datos que provienen de DirectQuery tienen limitaciones a la hora de aplicar técnicas de transformación dentro del editor de Power Query. Por ejemplo, si se conecta a un origen OLAP, como SAP BW, no puede hacer ninguna transformación; se toma el modelo externo completo del origen de datos. Si quieres realizar cualquier transformación en los datos, tendrás que hacerlo en el origen de datos subyacente.
Modelado: algunas de las funcionalidades de modelado que tienes con los datos importados no están disponibles, o están limitadas, al usar DirectQuery.
Generación de informes: casi todas las funcionalidades de generación de informes que tienes con los datos importados también se admiten para los modelos de DirectQuery, siempre que el origen subyacente ofrezca un nivel de rendimiento adecuado. Sin embargo, cuando el informe se publica en el servicio Power BI, las características Conclusiones rápidas y Preguntas y respuestas no se pueden emplear. Además, el uso de la característica Explorar en Excel probablemente generará un rendimiento más bajo.
Para obtener información más detallada sobre las limitaciones del uso de DirectQuery, consulta Implicaciones del uso de DirectQuery.
Ahora que tienes una breve comprensión de cómo funciona DirectQuery y las limitaciones que plantea, puedes adoptar medidas para mejorar el rendimiento.
Optimizar el rendimiento
Sigamos con el ejemplo de Tailwind Traders: durante la revisión del modelo semántico, descubre que la consulta utilizó DirectQuery para conectar Power BI Desktop a los datos de origen. Este uso de DirectQuery es el motivo por el que los usuarios experimentan un rendimiento deficiente con el informe. La carga de las páginas en el informe tarda demasiado y las tablas no se actualizan con la rapidez suficiente cuando se realizan determinadas selecciones. Tendrás que adoptar medidas para optimizar el rendimiento del modelo de DirectQuery.
Puedes examinar las consultas que se envían al origen subyacente e intentar identificar el motivo de tu bajo rendimiento. Luego, puedes hacer cambios en Power BI Desktop y el origen de datos subyacente para optimizar el rendimiento general.
Optimizar datos en Power BI Desktop
Cuando hayas optimizado el origen de datos tanto como sea posible, puedes tomar medidas adicionales dentro de Power BI Desktop empleando el Analizador de rendimiento, donde puedes aislar consultas para validar planes de consulta.
Puedes analizar la duración de las consultas que se envían al origen subyacente para identificar las que tardan mucho tiempo en cargarse. En otras palabras, puedes identificar dónde se producen cuellos de botella.
No es necesario usar una estrategia especial al optimizar un modelo de DirectQuery; puedes aplicar las mismas técnicas de optimización que ha usado en los datos importados para ajustar los datos del origen de DirectQuery. Por ejemplo, puedes reducir el número de objetos visuales en la página del informe o el número de campos que se usan en un objeto visual. También puedes quitar las columnas y filas innecesarias.
Para obtener instrucciones más detalladas sobre cómo optimizar una consulta de DirectQuery, consulta Instrucciones del modelo de DirectQuery en Power BI Desktop e Instrucciones para usar DirectQuery correctamente.
Optimización del origen de datos subyacente (base de datos conectada)
La primera parada es el origen de datos. Debes ajustar la base de datos de origen tanto como sea posible, ya que cualquier cosa que hagas para mejorar el rendimiento de esa base de datos de origen mejorará también DirectQuery en Power BI. Las medidas que tomes en la base de datos serán las que aporten el mayor valor.
Valora la posibilidad de usar los siguientes procedimientos estándar de base de datos aplicables a la mayoría de las situaciones:
Evita el uso de columnas calculadas complejas, ya que la expresión de cálculo se insertará en las consultas de origen. Es más eficaz volver a insertar la expresión en el origen porque evita la desactivación. También puedes valorar la posibilidad de agregar columnas de clave suplente a tablas de tipo de dimensión.
Revisa los índices y comprueba si la indexación actual es correcta. Si tiene que crear índices, asegúrate de que sean adecuados.
Consulta los documentos de instrucciones del origen de datos e implementa sus recomendaciones de rendimiento.
Personalización de las opciones de Reducción en consultas
Power BI Desktop te da la opción de enviar menos consultas y deshabilitar ciertas interacciones que generarán una mala experiencia si las consultas resultantes tardan mucho tiempo en ejecutarse. Al aplicar estas opciones, evitarás que las consultas visiten repetidamente el origen de datos, lo que mejorará el rendimiento.
En este ejemplo, modificarás la configuración predeterminada para aplicar las opciones de reducción de datos disponibles al modelo. Puedes acceder a la configuración seleccionando Archivo>Opciones y configuración>Opciones y desplazándote hacia abajo en la página; luego, selecciona la opción Reducción en consultas.
Estas son las opciones disponibles para la reducción en consultas:
Reducción del número de consultas enviadas: de forma predeterminada, cada objeto visual interactúa con todos los demás objetos visuales. Al activar esta casilla, se deshabilita la interacción predeterminada. Luego, puedes elegir qué objetos visuales interactúan entre sí mediante la característica Editar interacciones.
Segmentaciones: la opción Aplicar cambios en la segmentación al instante está seleccionada de manera predeterminada. Para forzar que los usuarios del informe apliquen manualmente los cambios de la segmentación, selecciona la opción Agrega un botón Aplicar a cada segmentación para aplicar los cambios cuando esté a punto.
Filtros: la opción Aplicar cambios en los filtros básicos al instante está seleccionada de manera predeterminada. Para forzar a los usuarios del informe a que apliquen manualmente los cambios en los filtros, selecciona una de las opciones alternativas:
Agregar botones Aplicar a todos los filtros básicos para aplicar los cambios cuando estés listo
Agregar un único botón Aplicar al panel de filtros para aplicar los cambios a la vez (versión preliminar)
