Optimización de rendimiento en Power BI

En muchas ocasiones, las necesidades funcionales de las empresas en sus proyectos de analítica y visualización de datos requieren de soluciones que ponen a prueba los límites de las herramientas de inteligencia de negocio más avanzadas, como es el caso de Power BI. A menudo, las peculiaridades de negocio en los diferentes sectores traen consigo la necesidad de realizar elaboradas transformaciones en los datos de origen, los cuales a su vez tienen un volumen muy grande y creciente con el paso del tiempo debido al gran interés que despierta en las empresas el hecho de tener una amplia base de datos y a que estas empresas van adquiriendo una mayor capacidad para recoger la información. El reto, por tanto, no sólo consiste en obtener una solución que muestre datos correctos, sino que la solución debe ser capaz de lidiar adecuadamente con amplios volúmenes de información.

Algunas de las mejores acciones que se pueden llevar a cabo son comunes independientemente de las necesidades de cada empresa, por lo que es importante tener siempre en mente ciertos conceptos que marcan la diferencia en cualquier situación. Estas buenas prácticas genéricas se verán en la parte inicial de este post.

En función de los requisitos del cliente, se presentan escenarios claramente diferenciables, los cuales vienen determinados por la necesidad en mayor o menor medida de que la información se muestre en “near real time”, que se quiera almacenar una gran cantidad de datos en el informe o que se precise un informe rápido de manejar sin darle tanta importancia a la complejidad de los KPIs.

Dependiendo de estos escenarios, se debe optar correctamente por un modelo “Import”, “DirectQuery” o “Compuesto”. Cada uno de ellos trae consigo diferentes buenas prácticas que contribuyen a la optimización del rendimiento en el informe. En este post se hará referencia a muchas de estas buenas prácticas atendiendo a las necesidades del cliente, una vez se hayan revisado los conceptos generales.

Es importante tener en cuenta que las mejoras de rendimiento están relacionadas con diferentes capas de la solución. Como norma general, en este post se revisarán de forma ordenada desde el origen de datos hasta la capa puramente visual, dejando en último lugar las mejoras de rendimiento asociadas al entorno configurado en el servicio de Power BI.

Buenas prácticas generales

• Eliminación de columnas innecesarias: Esta es una de las recomendaciones más obvias, pero no por ello hay que pasarlo por alto. Es importante tener en cuenta que Power BI, en igualdad de condiciones, responde mejor a una gran cantidad de filas que a la abundancia de columnas. Las columnas utilizadas en la solución deben ser sólo las necesarias. Se consideran columnas necesarias aquellas que son utilizadas en las visualizaciones o que son ineludibles para crear el modelo, como por ejemplo columnas que ordenen otras columnas o que sirvan de puente para calcular otras que sí sean empleadas en las visualizaciones.

• Nivel adecuado de granularidad: Esta técnica consiste en no trabajar con datos de un nivel excesivo de detalle en aquellos casos en los que se sabe de antemano que la solución no los va a requerir. Por ejemplo, si se necesita una información a nivel agregado semanal, es preferible no incluir registros con información de fecha y hora.

• Tipos de datos adecuados: Es especialmente importante cuando se están importando los datos, sin embargo, se puede generalizar para cualquier otro modo de obtención. Como norma general, es mejor utilizar números enteros, debido a su codificación al efectuar el almacenamiento. Además, en las propiedades de las columnas se debe cuidar minuciosamente el tipo de resumen que se hace por defecto de los datos, teniendo en cuenta que la opción “No resumir” es la más óptima, y debe ser utilizada salvo que sepamos que se van a calcular valores agregados que requieran otro tipo de resumen.

• Creación adecuada de índices: En función del origen de datos que se esté utilizando para la solución, puede ser adecuada la introducción de índices. Los índices ayudan a optimizar las consultas nativas que emplean cláusulas tipo “WHERE”. Al utilizar índices, es importante tener en cuenta que se mejora el tiempo de búsqueda a costa de ralentizar el de inserción de datos, por lo que hay que evaluar qué es lo más adecuado. Otro aspecto a considerar consiste en tener en cuenta que las columnas no se pueden indexar más allá del origen de datos, por lo que es importante que en el caso de columnas que deban ser calculadas en función de otros dos campos, éstas vengan calculadas e indexadas desde el origen de datos. En modelos “DirectQuery” suele ser de especial interés, ya que en cada interacción con el informe se lanza al menos una consulta. Sin embargo, si se utiliza “Import” la única ventaja se produce en el tiempo de actualización del informe.

• Creación de una tabla de fechas: La mayoría de las soluciones en Power BI requieren de la utilización de un filtro de fechas en cada una de las páginas del informe, por lo que es importante contar con una tabla maestra de fechas. Idealmente, esta tabla debe contener el rango adecuado de fechas, es decir, las que pueden aparecer en el campo de fechas de las tablas de hechos relacionadas. Además, suele ser útil la adición de otros campos útiles para la explotación de datos. Esta tabla puede ser obtenida mediante “Import” o “DirectQuery”, dependiendo de distintas especificidades que requiera la solución.

• Examinar las consultas de Power Query: En casos en los que no se tiene acceso a la base de datos de origen, es posible que haya que efectuar transformaciones en los datos desde Power Query, el cual realiza una consulta nativa para obtener los datos. Es importante observar esta consulta nativa con la finalidad de evitar que ésta sea demasiado complejo, ya que posiblemente se pueda optimizar. Por ejemplo, es importante evitar los filtros de fecha relativa que proporciona por defecto Power Query, ya que dan lugar a consultas demasiado costosas. De nuevo, esta técnica suele ser más determinante en “DirectQuery” debido a las consultas que se envían al interaccionar con el informe.

• Limitar el uso de columnas calculadas por DAX todo lo posible: Siempre que sea posible, es ideal que las transformaciones de los datos vengan de antes. No obstante, en algunas ocasiones es inevitable su uso, en cuyo caso es importante resaltar que se debe evitar en la medida de lo posible emplear filtros mediante DAX. Además, si la escritura en DAX va a desembocar en un KPI global, es bastante mejor utilizar una medida antes que el agregado de una columna calculada.

• Introducir el campo del lado varios de la relación en las visualizaciones: Cua
  ndo se introduce un campo que viene determinado por una relación entre una tabla de dimensiones y una de hechos, es mejor emplear la columna correspondiente a la tabla de hechos a la hora de montar las visualizaciones, debido a que así se evita que las consultas realizadas internamente por Power BI o de forma nativa tengan que relacionar ambas tablas al interactuar con dicha visualización del informe.

• Evitar las relaciones bidireccionales siempre que se pueda: Este tipo de relaciones cargan de complejidad el modelo de datos, por lo que sólo se deben utilizar si es estrictamente necesario.

• Configurar de forma óptima la opción “Habilitar técnicas de reducción de consulta”: Desde esta ventana se puede determinar de forma predeterminada el nivel de interacción de las visualizaciones del informe entre sí, teniendo la capacidad de limitar las funciones de filtro y resaltado. Si el rendimiento es un problema, reducir estas interacciones puede ser una buena técnica a tener en cuenta. Además, en esta ventana se puede configurar la aparición de un botón de “Aplicar” en los filtros y segmentaciones. Esto último es especialmente útil en “DirectQuery”, además de por los motivos comentados en otros puntos, por el hecho de evitar la saturación del servidor del origen de datos, ya que al filtrar se pueden enviar muchas consultas innecesarias al origen de datos antes de tener el filtro definitivo que se piensa ejecutar.

• Utilizar el mínimo número de visualizaciones que sea posible: Es una buena práctica tratar de repartir los elementos del informe en distintas páginas en vez de acumular muchas visualizaciones en páginas grandes y densas. Esto se debe a que, al tener muchos elementos juntos, la cantidad de carga y el número de consultas es mayor, por lo que el rendimiento disminuye.

• Tener cuidado con los filtros que incluyan medidas o columnas de valores agregados: Es importante tener en cuenta que en visualizaciones categorizadas llevar asociado un filtro de este tipo puede generar consultas poco eficaces, pues estas deben asociar de forma única cada categoría con la medida o columna de valores agregados.

• Evitar visualizaciones con un “scroll” demasiado largo: Cuando la consulta resultante da lugar a un número muy elevado de filas, la visualización tarda mucho tiempo en cargarse, y salvo casos excepcionales, el usuario no querrá ver todos los registros. Por ese motivo, suele ser una buena idea filtrar por un “Top N” de modo que dicho usuario se pueda hacer una idea de los datos resultantes sin necesidad de cargarlos todos.

• Establecer el tipo de relación más adecuado entre cada par de tablas: Las relaciones “uno a varios” son un subtipo de las relaciones “varios a varios”, pero en el momento de configurar las relaciones entre tablas son bastante más eficientes en cuanto a su rendimiento, por lo que, si se puede confirmar que el lado “uno” de la relación siempre es único, es mejor que la relación establecida sea “uno a varios”.

• Prestar atención a la propia optimización de los “visuals”: No todas las visualizaciones son igual de eficientes, ni siquiera cuando muestran datos finales similares. En ese sentido, los “visuals” que aprecen por defecto en la interfaz de Power BI Desktop suelen ser los mejores. Al margen de estos, los verificados por Microsoft con un “check” suelen ser aceptables, aunque no aparezcan por defecto. Sin embargo, las visualizaciones sin verificar son más peligrosas, aunque hay excepciones que funcionan bien. Por último, los “visuals” pueden ser personalizados, en cuyo caso hay que prestar mucha atención y cuidar los pequeños detalles.

• Optimización de la capacidad del entorno de trabajo: En el caso de los usuarios con capacidad Premium, se tiene la posibilidad de escalar vertical y horizontalmente dicha capacidad. En el caso de este tipo de usuarios, es importante saber el coste de cada tipo de escalado y analizar minuciosamente cuál es el más adecuado, ya que se puede aumentar la capacidad “Premium” que ya se está utilizando o incorporar una nueva. Los dos aspectos más destacados cuando se trata de optimizar estas capacidades son la memoria y la CPU, que en el caso de informes con una gran volumetría pueden llegar a ser insuficientes.

• Encontrar la mejor conectividad en el entorno de Power BI: Es importante inten
• tar que la conectividad sea la mejor posible entre el servicio de Power BI y las puertas de enlace, así como entre éstas y los orígenes de datos. Siempre que sea posible, es muy recomendable reducir los saltos de máquina, además de incluir las máquinas virtuales dentro del servicio de Power BI en el caso de estar trabajando en Azure. A nivel de red, cuanto más cerca se encuentren el origen de datos, el servidor local y el servicio de Power BI, menor será la latencia de red. Con el fin de mejorar la conectividad, también se pueden incluir las puertas de enlace en clusters, de forma que se aumente la disponibilidad y se pueda llevar a cabo un equilibrio de carga que también mejore el rendimiento.

• Utlización del “Performance Analyzer”: Esta herramienta de Power BI permite chequear el rendimiento de cada consulta desde Power BI Desktop, y es muy recomendable aun en el caso de haber tenido en cuenta el resto de recomendaciones que se proporcionan en este post.

Optimización en modelos de tipo “Import”

En los modelos importados, el aspecto más determinante es que los datos una vez obtenidos puedan ser rápidamente calculados mediante el motor VertiPaq con el que trabaja Power BI. Por tanto, suele ser una buena idea llevar a cabo transformaciones más sofisticadas en la elaboración del modelo si éstas contribuyen a que las consultas en el informe sean más rápidas.

Por otro lado, es fundamental que los datos almacenados en Power BI no superen la capacidad asimilada por la herramienta, así que éste será otro punto clave a considerar en la solución.

Algunas de las consideraciones más importantes en estos modelos son las siguientes:

• Eliminación de filas innecesarias: Cuando el método de obtención de datos es “Import”, este punto es especialmente importante, tanto para la agilidad de las consultas como para ahorrar en el tamaño del informe. La idea consiste en filtrar los registros en el origen de datos o a través de “DirectQuery”. De esta forma, aunque el proceso se ralentice, el modelo de datos final será más agradable para el usuario, ya que éste no sufrirá apenas por el proceso de importación (más allá del coste de las “queries” en su propio servidor) y sin embargo tendrá una facilidad para interactuar con el informe mucho mayor.

• Preferencia de cálculos en Power Query respecto a DAX: Siempre que sea posible, es recomendable evitar el uso de DAX, esencialmente en el caso de las columnas calculadas, ya que ocupan menos espacio cuando ya vienen obtenidas de antes. Esto no es determinante en el rendimiento de las consultas, pero sí en el tiempo de actualización, que tiende a ser mayor utilizando DAX debido a que las transformaciones se llevan a cabo después de haber importado todo lo relativo a Power Query.

• Importar sólo las tablas necesarias de Power Query: Al llevar a cabo transformaciones desde Power Query, es posible que se generen consultas que simplemente sirvan para obtener algunas de las tablas. En este caso, se debe deshabilitar su carga desde Power Query con el fin de ahorrar en capacidad y en velocidad de actualización de datos.

Optimización en modelos de tipo “DirectQuery”

En estos modelos no hay que preocuparse por la capacidad de Power BI en cuanto al tamaño que pueda albergar, ya que los datos no se almacenan. Lo más importante en los modelos “DirectQuery” es que las consultas sean rápidas, por lo que es importante evitar transformaciones, filtros y que los datos desde su origen tengan una estructura apta para ser explotada en los informes.

Las particularidades más destacadas a tener en cuenta en este tipo de modelos son las siguientes:

• Habilitar la opción “Asumir integridad referencial” siempre que sea posible: Este punto es muy importante para este tipo de método de obtención de datos. Siempre que se tenga constancia de que las tablas del origen de datos cumplen con los requisitos necesarios para poder dar lugar al tipo de relación pertinente, es una buena técnica para acelerar las consultas. Cuando se habilita la opción “Asumir integridad referencial” se da por hecho que los datos son fieles al tipo de relación a la que dan lugar, por lo que las “queries” se ahorran esas comprobaciones y como resultado se obtiene una mejora en el rendimiento. No obstante, hay que tener mucho cuidado, ya que, si los datos no cumplen los requisitos indicados previamente, las visualizaciones mostrarían datos erróneos. 

• Configurar el número máximo de conexiones por origen de datos: Al interactuar con el informe, se establece un número máximo de consultas simultáneas que se pueden realizar contra cada origen de “DirectQuery”. Se debe tener en cuenta que una vez superado ese máximo, las consultas se pondrán en cola, y que dependiendo de la licencia este valor máximo será mayor o menor. A grandes rasgos, conviene que se maximice el valor límite de consultas simultáneas, si bien es cierto que esto puede tener otras consecuencias negativas relacionadas con el servidor del origen de datos o con la lentitud de cada “query” por separado, que podría llegar a ralentizar el tiempo total en la minoría de los casos.

Utilización de un modelo compuesto

En Power BI, dependiendo del origen de datos, existe la posibilidad de utilizar diferentes modos de importación para distintas tablas. Como ya se ha visto en otros puntos de este post, los modelos “Import” suelen ser útiles en escenarios en los que la volumetría no es excepcionalmente grande y se requiere una gran velocidad de interacción con el informe, mientras que los modelos “DirectQuery” se adecúan más a situaciones en las que se busca obtener información en tiempo real con grandes volúmenes de datos. Sin embargo, puede haber escenarios mixtos con determinadas peculiaridades que hagan óptimo un modelo compuesto. A continuación, se describe la distribución de las tablas en cuanto a su método de obtención según sus características:

• Tablas obtenidas mediante “Import”: Deben ser aquellas de dimensiones, en las que se espera que la información sea prácticamente estática, de forma que no se vulnere el principio de integridad comentado antes. Al ser tablas prácticamente estáticas, los datos se pueden obtener sin necesidad de hacer una consulta extra al origen de datos, por lo que se acota el tiempo de la “query” a costa de una leve carga almacenada en el archivo de Power BI. Esta carga es muy leve al tratarse de una tabla con pocos registros. 

• Tablas obtenidas mediante “DirectQuery”: Deben ser las de hechos, ya que estas tablas suelen ser bastante más pesadas que las de dimensiones. Al ser la obtención de datos de tipo “DirectQuery”, la información mostrada es en “near real time”.

Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial 4.0 Internación