¡Jueves de post! Seguimos con la serie de post de las variables. Si no viste el post anterior en el que hacía la introducción al por qué usar las variables, te dejo aquí el enlace.
Bien, como resumen, vimos que el uso de las variables nos aportaba una mejora en la legibilidad del código, además de poder trocear el código en caso de necesidad. Otro punto que vimos, aunque sólo fue el caramelito para dar pie a este post, es la mejora del rendimiento. ¿Y cómo podemos ver si el rendimiento es mejor con variables que sin variables? Pues para eso necesitamos de la herramienta externa gratuita y maravillosa como es DAX Studio (https://daxstudio.org/)
Antes de entrar con la herramienta a fondo, y dejando claro que estamos trabajando siempre en modo Import, lo primero que debemos saber es que tenemos dos motores DAX, que son el Formula Engine y el Storage Engine que son los responsables de enviar las consultas al modelo Tabular que tengamos. Las funcionalidades de los dos motores son:
· El motor de fórmulas (Formula Engine o FE), es el motor encargado de procesar la solicitud de la necesidad y generar y realizar plan de consulta necesario.
· El motor de almacenamiento (Storage Engine o SE), es el motor encargado de recuperar los datos del modelo Tabular para así poder responder a las solicitudes que le realizar el motor Formula Engine. Además el SE tiene dos modos de implementación, que son:
1. VertiPaq aloja una copia de los datos en memoria comprimidos (muy bien comprimidos) que se actualizan cada vez que se refresca el dataset del modelo. Mientras no se actualice, los datos permanecen inalterables en nuestro modelo.
2. DirectQuery envía consultas directamente a la fuente de datos original para cada solicitud que realiza el usuario. Con DirectQuery NO se crean copias en nuestro equipo.
Por decirlo con otras palabras, el motor FE es el motor de cálculo mientras que el SE es el motor de almacenamiento. Bien, una vez visto por encima los dos tipos de motores que tenemos en DAX, vamos ahora a DAX Studio. Para ello, desde Power BI Desktop vamos a la barra de menús a la opción de Herramientas Externas y seleccionamos DAX Studio:
Otra opción que podemos hacer es abrir DAX Studio desde su acceso directo en el PC y conectarnos al modelo que tenemos abierto.
Ahora una vez dentro de DAX Studio, lo que tenemos que hacer es copiar la consulta que realiza nuestro modelo. ¿Y cómo lo hacemos? Para eso, volvemos a Power BI y abrimos el analizador de rendimiento:
A continuación, le damos a Iniciar Grabación:
Y acto seguido hacemos click en Actualizar objetos visuales:
Y obtenemos ya de primeras la duración en ms de lo que ha tardado el objeto visual en devolver el resultado. Bien, comentar que no siempre este analizador de rendimiento nos va a arrojar el resultado de duración correcto, ya que va a influir otros muchos parámetros en él. Por ejemplo, el mismo modelo y mismo análisis en otro momento:
Por eso, lo más fiable es irnos a DAX Studio y analizarlo allí. Para eso, hacemos click en el + de SinVariables y vemos un desglose de los tiempos y la opción que nos interesa, que es Copiar Consulta:
Ahora en DAX Studio, pegamos la consulta copiada, y sí, es DAX aunque no lo parezca:
Vamos trocear un poco este código para no asustarnos, que yo el primer día que lo vi mi pensamiento fue… O es no es DAX o yo no sé DAX J.
Lo primero que tenemos es el __DS0FilterTable que es una variable con los filtros definidos en nuestro informe y estos son las categorías de Audio, Electrodomésticos, Equipos y TV y Video.
Lo siguiente que tenemos es otra variable __DS0Core, y esta representa la tabla que vemos, pero esta NO es la tabla que ejecuta, ya que, si continuamos leyendo el código, vemos que hay otra variable __DS0PrimaryWindowed que llama a __DS0Core y es la que ejecuta. Pero os estaréis preguntando… Javi está hoy que no da una ya que en esa variable hay un TOPN y en la métrica no ha puesto el ninguno. Pues no, no lo he puesto, pero Power BI todos los visuales que nos devuelven datos, hacen un TOPN para no tirar el modelo abajo por rendimiento.
Y ya, por último, evalúa la última variable que contiene el TOP más los filtros que hayamos indicado. ¿Se entiende? Espero que sí, sino me comentáis.
Ahora podemos ejecutar la consulta dándolo a Run y vemos que nos devuelve exactamente los mismo valores que en Power BI ( y menos mal que sino… J ):
Y podemos ver que nos ha creado una columna IsGrandTotalRowTotal en la que nos muestra el resultado del total ya que está como True. Bueno, continúo con el tema del rendimiento que me desvío… ¿Cómo podemos saber cuánto de eficiente es la consulta? Para ello, sobre la barra de menú Home hacemos click en Server Timings:
Y vemos que, en la parte de abajo, justo encima del
resultado de la consulta, se nos ha colocado el símbolo de grabación:
Hasta aquí, no he hablado nada de rendimientos ni tiempos, sólo os he soltado un “ladrillo” sobre DAX Studio, pues voy a ello. Ahora hacemos click sobre el Clear Cache para que nos borre lo que esté cacheado:
Y le damos a Run:
Y para ver los resultados hacemos click sobre el botón que nos ha aparecido en la parte inferior con el símbolo de grabar:
Y vemos muchísima más información que en Analizador
de rendimiento de Power BI Desktop. Vamos por partes, vemos en que el total de
tiempo requerido por la expresión sin variables es de 60 ms (tiempo bueno,
estamos en la base de datos de Contoso claro…) de los cuales ha estado 54 ms en
el SE, es decir, el 90% del tiempo y 6 ms en el FE, el 10% del tiempo:
Y nos ejecuta 5 consultas del SE para devolvernos el resultado de la métrica de las cuales se ha cacheado 1 consulta. Si hacemos click sobre la propia línea en la parte derecha nos muestra la consulta realizada:
Si ahora, repetimos el mismo proceso para la consulta con variables, el resultado que nos arroja, ¿cuál creéis que va a ser? ¿Mejor o peor? Mejor, y como siempre, lo vamos a ver con datos:
En este caso, el tiempo total empleado es de 21 ms, o lo que es lo mismo casi un 300% más rápida con la base de datos de Contoso. En el FE ha estado 5 ms mientras que el SE 16 ms y SÓLO nos ha ejecutado una única consulta al SE y sin ninguna consulta cacheada.
Por lo que como podemos ver, el uso de variables en nuestras métricas nos aporta una gran mejora en el rendimiento de nuestro modelo.
Y hasta aquí el tema de las variables... el siguiente post hablaremos de rendimiento pero entraremos cuando tenemos los llamados CallbackID y como intentar evitarlos.
¡Nos vemos en los datos!
