Forum Discussion
DAX - Switch - Rendimiento
Hola a todos
Recientemente hemos tenido problemas con medidas complicadas que utilizan declaraciones de conmutación. Tenemos medidas individuales para cada uno de los tipos de período de tiempo que tenemos y una medida de envoltura final con un interruptor anidado para recuperar la medida correspondiente en función de las selecciones del usuario. Podemos ver los datos de estas medidas cuando se introducen en una visualización matricial individualmente. Pero cuando se utiliza la medida de envoltura para recuperarlos, arroja un error de asignación de memoria para exactamente las mismas selecciones.
Al analizar con DAX studio, hemos podido identificar que el motor DAX en realidad está calculando todas las medidas individuales dentro del conmutador en lugar de solo calcular la medida donde el caso del interruptor es verdadero.
Por ejemplo, tengo medidas Ingresos Corrientes, Ingresos YTD, Ingresos QTD, Ingresos FYTD, Ingresos móviles 2 años, Ingresos acumulados desde 2008, Ingresos Anualizados 2 años, Ingresos Anualizados desde 2008, Índice de Ingresos desde 2008. Cuando se tira contra una jerarquía, digamos jerarquía de geografía, todas estas medidas devuelven el valor correcto. Sin problemas.
También tengo una medida de envoltura como se muestra a continuación.
Ingresos := Switch( Selectedvalue(período de tiempo),
"Corriente", [Corriente de ingresos],
"YTD", [Ingresos YTD],
"QTD", [Ingreso qtd],
"FYTD", [Ingresos FYTD],
"Rolling 2 years", [Ingresos Rolling 2 años],
"Acumulado desde 2008" [Ingresos acumulados desde 2008],
"Anualizado 2 años", [Ingreso Anualizado 2 años],
"Anualizado desde 2008", [Ingresos anualizados desde 2008],
"Índice desde 2008", [Índice de ingresos desde 2008])
Ahora, cuando he seleccionado digamos Anualizado desde 2008 en el período de tiempo y saco la medida de ingresos contra la misma jerarquía de geografía, se sigue cargando durante 10 -15 minutos y luego dice falla de asignación de memoria. Así que analizando esto en el estudio DAX se muestra que en lugar de solo calcular la medida [Ingreso Anualizado desde 2008] ha calculado todas estas medidas:Ingresos Corrientes, Ingresos YTD, Ingresos QTD, Ingresos FYTD, Ingresos móviles 2 años, Ingresos acumulados desde 2008, Ingresos Anualizados 2 años, Ingresos Anualizados desde 2008, Índice de Ingresos desde 2008 y finalmente tratando de devolver [Ingresos Anualizados desde 2008] valor.
Este es un ejemplo simplificado del problema real. En realidad, el equivalente de la medida de la Corriente de Ingresos depende de un montón de otras medidas, la mayoría de las cuales son medidas envolventes. Y todas las demás medidas de ingresos como YTD, QTD, FYTD, rolling, acumulativo se calculan como sumx(products()). Los 2 años anualizados y anulados dependen del acumulado correspondiente desde y de las medidas móviles elevadas a la potencia de otra medida. Así que son realmente complejos.
Hemos probado muchas opciones diferentes, pero no hemos podido resolver completamente el problema. La solución que ha resuelto parcialmente el problema es usar variables similares a las siguientes para almacenar el valor de la medida cuando son válidas de lo contrario usando espacios en blanco. Esto ha ayudado a todas las medidas, excepto las anualizadas.
Ingresos :=
var cur = if(Selectedvalue(time period)= "Current", [Income Current], blank())
var ytd = if(Selectedvalue(time period)= "YTD", [Income YTD], blank())
Interruptor RETURN( Selectedvalue(período de tiempo),
"Actual", cur,
"YTD", ytd,
"QTD", [Ingreso qtd],
"FYTD", [Ingresos FYTD],
"Rolling 2 years", [Ingresos Rolling 2 años],
"Acumulado desde 2008" [Ingresos acumulados desde 2008],
"Anualizado 2 años", [Ingreso Anualizado 2 años],
"Anualizado desde 2008", [Ingresos anualizados desde 2008],
"Índice desde 2008", [Índice de ingresos desde 2008])
¿Alguna otra idea que pudiéramos probar? ¿Alguna vez se han enfrentado a este problema en alguno de sus proyectos e hicieron alguna solución que funcionó para ustedes? Estoy abierto a intentar cualquier cosa en este momento, ya que me he estado rompiendo la cabeza durante semanas en esto.
PD: Hemos levantado un ticket de soporte con Microsoft, pero ha sido un proceso lento.
Desafortunadamente, la fuente del informe es un modelo tabular y, como tal, los parámetros no ayudaron. Inicialmente comenzamos con grupos de cálculo, pero tampoco fueron útiles.
En las llamadas con soporte de Microsoft, mencionaron que han visto estos problemas con los grupos de cálculo y nos pidieron que evitáramos usarlos para cálculos complejos.
La última actualización que tenemos de Microsoft es que no hay ningún problema con la forma en que se escribe la medida, sino con la forma en que el servidor tabular está manejando el caso del conmutador. Estábamos usando SQL Analysis Server 2019 y, aparentemente, este es un problema conocido en esa versión del servidor. Han hecho una solución para ello en la versión SQL AS 2022 que está en modo de vista previa en este momento y no tienen planes de aplicar la corrección en el servidor 2019. Probaron el modelo en la versión 2022 y las mismas medidas parecen estar funcionando bien. Entonces, hasta que se lance oficialmente la versión 2022, tendremos que buscar otras soluciones.
2 Replies
- Syndicate_AdminAdministrator
¿Ha probado parámetros de campo o grupos de cálculo? Cualquiera de los dos enfoques le permitiría tener una cortadora con valores como Ingresos Corrientes, Ingresos YTD, etc. Cuando seleccione un valor en la segmentación de datos (por ejemplo, Corriente de ingresos), mostrará esa medida en el objeto visual.
Primero probaría los parámetros de campo, ya que son más fáciles de crear.
https://docs.microsoft.com/en-us/power-bi/create-reports/power-bi-field-parameters
https://www.sqlbi.com/articles/introducing-calculation-groups/
- Syndicate_AdminAdministrator
Desafortunadamente, la fuente del informe es un modelo tabular y, como tal, los parámetros no ayudaron. Inicialmente comenzamos con grupos de cálculo, pero tampoco fueron útiles.
En las llamadas con soporte de Microsoft, mencionaron que han visto estos problemas con los grupos de cálculo y nos pidieron que evitáramos usarlos para cálculos complejos.
La última actualización que tenemos de Microsoft es que no hay ningún problema con la forma en que se escribe la medida, sino con la forma en que el servidor tabular está manejando el caso del conmutador. Estábamos usando SQL Analysis Server 2019 y, aparentemente, este es un problema conocido en esa versión del servidor. Han hecho una solución para ello en la versión SQL AS 2022 que está en modo de vista previa en este momento y no tienen planes de aplicar la corrección en el servidor 2019. Probaron el modelo en la versión 2022 y las mismas medidas parecen estar funcionando bien. Entonces, hasta que se lance oficialmente la versión 2022, tendremos que buscar otras soluciones.