Cómo encontrar las columnas calculadas más costosas de cálculo

[Syndicate_Admin]

Por lo tanto, en el modelo de datos que heredé, hay una serie de columnas calculadas en la tabla principal. Por casualidad, me di cuenta de que si eliminaba esta columna de "cliente final" en particular, reduciría el tiempo para abrir el .pbix a la mitad (~ seis minutos a tres minutos).

De acuerdo con las métricas de DAX Studio, no hubo nada particularmente notable en esta columna de "cliente final". Por ejemplo, en términos de tamaño y cardinalidad, es mucho más pequeño que otras columnas de la misma tabla. Sin embargo, la lógica de este "cliente final" estaba mal escrita (comprueba si el related(other_table_column) está en blanco y si no, devuelve ese valor) y de ahí mi teoría de que eliminar este cálculo aceleraría drásticamente el modelo.

Mi pregunta principal: aparte de eliminar manualmente las columnas de 1 en 1 y luego cronometrar manualmente el tiempo para abrir el archivo, ¿hay una forma más rápida de encontrar estas costosas columnas de cálculo? Como mencioné, nada parece llamarme la atención mirando las métricas del estudio dax.

[Syndicate_Admin]

En primer lugar, puede usar Performance Analyzer para ver el impacto en la experiencia de usuario

Y, a continuación, puede usar DAX Studio para comprobar el plan de consulta de la columna (o medida)

Compruebe la longitud del plan de consulta, pero también el número máximo de registros.

[Syndicate_Admin]

Así que hice lo que me sugeriste. Esta es la columna calculada problemática (end_customer).

Sin embargo, aquí hay otra columna (transaction_id_order). Eliminar esto del modelo de datos casi no supone ninguna diferencia en la velocidad. Mientras que eliminar end_customer hace una gran diferencia. Una vez más, no veo nada diferente entre los 2 planes de consulta, aparte del problema end_customer tener menos registros.

Así es como se ve la lógica end_customer. Básicamente, se trata de comprobar el related(XXX) para un número de tablas y devuelve la primera que no está en blanco.

[Syndicate_Admin]

Me sorprende que la primera consulta funcione peor que la segunda. ¿Cómo son los tiempos de los motores para ambos?

[Syndicate_Admin]

Por tiempos de motor, ¿te refieres a tiempos de servidor? De nuevo, el primero (end_customer) es el cálculo intensivo de la CPU.

No estoy 100% seguro de haber hecho esto correctamente, pero todo lo que hice fue colocar cada columna calculada en una tabla (una tabla separada para cada columna). Hizo una "actualización de objetos visuales" y luego una "consulta de copia". Pegó el DAX en DAX Studio y pulsó "ejecutar" con "plan de consulta" y "temporizaciones del servidor" activadas.

[Syndicate_Admin]

Sí, ese es el proceso correcto. Pero se supone que debe evaluar el DAX para la columna calculada, no para el resultado final.

Es bastante intrigante que ambas consultas pasen todo su tiempo en el motor de fórmulas. Una simple extracción de columna debe realizarse completamente en el motor de almacenamiento.

[Syndicate_Admin]

Pero, ¿cómo evalúo el DAX para la columna en DAX Studio?

End_Customer =
VAR customer_number = [Customer Number]
VAR int_sales_brid_0_ship_to_num =
    RELATED ( Internal_Sales_Bridge[Ship_To_Number] )
VAR lift_table_brid_0_cus_num =
    RELATED ( Lift_Table_Bridge[Customer Number] )
VAR output =
    IF (
        ISBLANK ( int_sales_brid_0_ship_to_num ),
        IF (
            ISBLANK ( lift_table_brid_0_cus_num ),
            "customer_number",
            "lift_table_brid_0_cus_num"
        ),
        "int_sales_brid_0_ship_to_num"
    )
RETURN
    output

Por ejemplo, ¿cómo pongo lo anterior en DAX Studio? (Para su información, esta es una versión corta de una fórmula similar de un modelo relacionado)

[Syndicate_Admin]

Todo en DAX es una tabla. Puedes usar

EVALUATE ROW("nombre de la columna", )

o

EVALUAR {}

o cualquier otra variante que produzca una tabla.

[Syndicate_Admin]

Probé ambas opciones y obtuve 2 mensajes de error diferentes

[Syndicate_Admin]

EVALUATE ROW necesita un nombre de columna.

EVALUATE ROW("nombre de la columna", )

[Syndicate_Admin]

Estoy atascado recibiendo el mismo error

[Syndicate_Admin]

var checkSource = VALUES(Fact_Table[Fuente])

[Syndicate_Admin]

mismo error. Solo he incluido una parte de la lógica real.

[Syndicate_Admin]

Está intentando devolver una tabla dentro de una fila.

Elimine las líneas 2, 3 y 12

[Syndicate_Admin]

Entonces, cuando vuelvo a agregar las variables relacionadas, recibo este mensaje. Para su información, esta es solo 1 de las muchas variables relacionadas en esta lógica)

[Syndicate_Admin]

recuerde que EVALUATE debe devolver una tabla. RELATED siempre devolverá un valor escalar para una sola columna. Estás mezclando demasiados conceptos a la vez.

Compruebe el modelo de datos y, a continuación, formule el DAX adecuado. También puede dejar que la "Vista de consulta de DAX" haga el trabajo pesado por usted cuando le pida que cree el código para una columna calculada o una medida, etc.

[Syndicate_Admin]

El objetivo de este ejercicio era comparar diferentes columnas y por qué algunas columnas tienen un mayor efecto en la eficiencia/velocidad del modelo. La lógica anterior es el DAX correcto para mi caso de negocio.

[Syndicate_Admin]

gracias. He estado ocupado esta última semana. Lo intentaré de nuevo cuando esté libre

[Syndicate_Admin]

En DAX Studio, compruebe el plan de consulta de ese DAX, especialmente la columna Registros. Los números altos allí indican cartesianos.

[Syndicate_Admin]

No estoy familiarizado con el uso del plan de consulta. ¿Hay algún vídeo o página web en particular que explique cómo se usa el plan de consulta en relación con el análisis de columnas calculadas?

[Syndicate_Admin]

Sí, entiendo que es preferible usar medidas, pero este modelo de datos es un desastre (es decir, tiene 82 columnas de ancho. > el 50% de las columnas son columnas calculadas). Idealmente, mi pregunta original sería respondida y entonces sabría qué columnas puedo proritizar mi esfuerzo para posiblemente convertirlas en una medida.