DAX CALCULABLE Vs Función FILTRO

Tanto como son herramientas poderosas para manipular y analizar datos en consultas DAX, pero tienen algunas diferencias clave que es importante comprender.

En este blog, repasaremos la función CALCULATETABLE y su plan de consulta en DAX Studio , y comprenderemos en qué se diferencia de la función FILTER . Al final, comprenderá mejor cómo elegir la función adecuada para sus necesidades de análisis de datos.

Para demostrarlo, usaremos el código DAX a continuación.

Cuando ejecute este código, obtendrá una tabla que muestra la marca y el color.

En la pestaña Planes de consulta , obtendrá un código correspondiente al operador CrossApply en Formula Engine .

Al mismo tiempo, puede ver que el código solo recupera el color y la marca del producto en la pestaña Tiempos del servidor .

Tabla de contenido

• Resultado de los tiempos del servidor de DAX Studio para CALCULATETABLE
• Plan de consulta CALCULATETABLE en DAX Studio
• Transición de contexto para funciones DAX similares
  • Tiempos del servidor
  • Plan de consulta
• Conclusión

Resultado de los tiempos del servidor de DAX Studio para CALCULATETABLE

Como ejemplo, filtremos el color del producto para mostrar solo rojo y/o negro.

Puede hacerlo utilizando la función FILTRO. Cuando lo ejecute, Server Timings mostrará que el argumento FILTER no se aplica al código xmSQL .

Pero si usa la función CALCULATETABLE, la consulta en la pestaña Tiempos del servidor mostrará que los resultados han sido filtrados por color del producto.

Plan de consulta CALCULATETABLE en DAX Studio

Veamos el Plan de consulta para cada función.

CALCULATETABLE está en la primera línea del plan de consulta lógica porque es una función de nivel superior en el código y, por lo tanto, no depende de ningún requisito.

Cuando lee el plan de consulta de una función CALCULATETABLE, no comienza con el primer argumento. Primero debe comprender el contexto del filtro utilizado. Así que vamos a la línea 5.

Puede ver que el operador VertiPaq requiere la columna de color del producto debido al filtro aplicado. Luego escanea esta columna y usa la combinación de filtro No está vacío para verificar el color del producto en cada fila.

Una vez preparado el contexto del filtro, se ejecuta el argumento

En retrospectiva, si usa la función FILTRO, verá un plan de consulta diferente, por lo que el argumento CROSSJOIN se realiza antes de identificar el contexto del filtro.

La desventaja de este enfoque es que no envía la condición de filtro al motor de almacenamiento. No podrá usar la cláusula WHERE dentro de xmSQL, lo que supondrá una gran carga para Formula Engine.

Y cuando trabaje con varias tablas, la combinación de filtros de la función CROSSJOIN será enorme. Esto ralentiza el rendimiento del código DAX. Por lo tanto, en la mayoría de los casos, se recomienda utilizar la función CALCULATETABLE.

Entonces, en lugar de realizar todos los cálculos en Formula Engine, puede inyectar la condición de filtro dentro de la clase WHERE del código XMSQL.

Transición de contexto para funciones DAX similares

Tiempos del servidor

Este concepto también es aplicable a la función CALCULAR. Usemos el código DAX a continuación como ejemplo.

Una medida tiene automáticamente una función CALCULAR a su alrededor.

Cuando ejecute este código, obtendrá una tabla que muestra el monto de Ventas totales para cada color.

En la pestaña Tiempos del servidor, puede ver que el código está ejecutando dos consultas. La primera consulta está calculando la suma del monto de Ventas de la tabla Ventas con respecto a la tabla Productos.

Por otro lado, la segunda consulta vuelve a recuperar el color del producto de la tabla Productos. Corresponde a la función en el código DAX.

Formula Engine coloca las cachés de datos de las dos consultas una al lado de la otra. Comienza recuperando los valores del segundo caché de datos y luego realiza una búsqueda en el primer caché de datos.

Plan de consulta

En la pestaña Plan de consulta, el Plan de consulta lógica escanea el color del producto debido al argumento .

Luego, VertiPaq suma el monto de Ventas totales según el color del producto. Realiza la transición de contexto que convierte el valor de color del producto en un contexto de filtro equivalente.

El filtro creado por la transición de contexto se traduce en una propiedad DependOnCols en el Plan de consulta. Después de que VertiPaq escanea las columnas requeridas para calcular las Ventas totales, multiplica la Cantidad de ventas por el Precio neto.

Las Ventas totales luego se devuelven como resultado en forma de un tipo de datos de moneda. Y finalmente, ADDCOLUMNS devuelve una tabla con dos columnas que contienen el monto de Color y Ventas totales.

Conclusión

El plan de consulta puede tener un impacto significativo en el rendimiento de una consulta, ya que diferentes planes de consulta pueden tener diferentes niveles de eficiencia.

Al usar las funciones CALCULATETABLE y FILTER en una consulta DAX, el plan de consulta puede diferir según el escenario específico y una variedad de factores, como la expresión de fórmula específica que se usa y las capacidades del motor de consulta.

En general, es una buena idea probar y comparar el rendimiento de diferentes planes de consulta para determinar el enfoque más eficiente para un escenario determinado.

Mis mejores deseos,