Consulta simple, rendimiento de FE excepcionalmente lento

Realmente estoy luchando con un rendimiento excepcionalmente lento en el escritorio y necesito ayuda para averiguar dónde está el problema

Se necesitan 300 ms para calcular una medida, con el 80% del tiempo en el motor de fórmulas (si eso hace alguna diferencia en la solución). Hay 42 millones de registros en la línea más grande del plan de consulta.

No es una gran cantidad de datos y no puede ser un DAX ineficiente lo que hace que tarde 5 minutos. Tiene que haber algo más, pero no sé qué más hacer.

Donde miro

Este es el SQL para el paso más lento medido por los tiempos de SE: no puedo ver los tiempos de FE en DAX Studio

SELECT TOP (1000001) 

[t5].[Created Date],[t5].[Appointment Start],[t5].[Activity ID],[t5].[Adviser Relationship Type],[t5].[Appointment Subject],[t5].[Appointment Description],[t5].[Appointment Status],[t5].[Created By],[t5].[Owner],[t5].[Owner Region],[t5].[Appointment Duration],[t5].[Associated Parties],[t5].[Associated Party Count],[t5].[Organiser Region],[t5].[Adviser CON],[t5].[Adviser Name],[t5].[Booked By],[t5].[Hub],[t5].[Owner Memeber Type],

COUNT_BIG(*) AS [a0]

FROM 
(
(select [activity_created_date] as [Created Date],
    [activity_due_date] as [Appointment Start],
    [activity_id] as [Activity ID],
    [activity_contact_adviser_relationship_type] as [Adviser Relationship Type],
    [activity_subject] as [Appointment Subject],
    [appointment_description] as [Appointment Description],
    [activity_status] as [Appointment Status],
    [activity_createdby] as [Created By],
    [activity_owner] as [Owner],
    [activity_owner_region] as [Owner Region],
    [activity_scheduled_duration_minutes] as [Appointment Duration],
    [activity_associatedparty] as [Associated Parties],
    [activity_associatedcount] as [Associated Party Count],
    [activity_organiser_region] as [Organiser Region],
    [activity_contact_code] as [Adviser CON],
    [activity_contact_name] as [Adviser Name],
    [activity_booked_by] as [Booked By],
    [member_type] as [Member Type],
    [owner_member_type] as [Owner Memeber Type],
    [hub] as [Hub]
from [mart].[sales__appointments] as [$Table])
)
 AS [t5]
WHERE 
(
(
([t5].[Member Type] IN (N'bda',N'ebdm',N''))
)
 AND 
(
1 = 1
)
)

GROUP BY [t5].[Created Date],[t5].[Appointment Start],[t5].[Activity ID],[t5].[Adviser Relationship Type],[t5].[Appointment Subject],[t5].[Appointment Description],[t5].[Appointment Status],[t5].[Created By],[t5].[Owner],[t5].[Owner Region],[t5].[Appointment Duration],[t5].[Associated Parties],[t5].[Associated Party Count],[t5].[Organiser Region],[t5].[Adviser CON],[t5].[Adviser Name],[t5].[Booked By],[t5].[Hub],[t5].[Owner Memeber Type]

Los problemas aquí fueron la configuración de Azure y el uso incorrecto de medidas en lugar de columnas personalizadas o calculadas. Mejoramos la distribución de datos y el almacenamiento en caché en el dwh y reescribimos un par de medidas como columnas calculadas (estamos aprendiendo …) y el problema desapareció.

Los problemas aquí fueron la configuración de Azure y el uso incorrecto de medidas en lugar de columnas personalizadas o calculadas. Mejoramos la distribución de datos y el almacenamiento en caché en el dwh y reescribimos un par de medidas como columnas calculadas (estamos aprendiendo …) y el problema desapareció.

@charliedata Estoy abierto a verlo si puede compartir el archivo pbix, eliminar cualquier información confidencial antes de compartir, también compartir lo que está tratando de lograr.

Hola @ parry2k, eso es muy generoso, gracias.

Estamos usando DirectQuery: ¿eso tiene algún impacto en su capacidad para replicar el problema, dado que no puedo compartir los permisos de seguridad para consultar el almacén de datos?

Hola @charliedata,

Podemos intentar utilizar la siguiente fórmula que evita el uso de MAXX:

Number of appointments attended previous day =
// get the date of the current row in the output table
VAR _date =
    MAX ( Appointments[Appointment Start] )
VAR _type =
    DISTINCT ( Appointments[Member Type] ) // get the most recent prior date from the whole appointments table
VAR _prevdate =
    CALCULATE (
        MAX ( Appointments[Appointment Start] ),
        ALLSELECTED ( Appointments ),
        Appointments[Member Type] IN _type,
        Appointments[Appointment Start] < _date
    )
RETURN
    CALCULATE (
        [Number of appointments],
        ALLSELECTED ( Appointments ),
        Appointments[Member Type] IN _type,
        Appointments[Appointment Start] = _prevdate
    )

Si no cumple con sus requisitos, ¿podría compartir la fórmula de medida? [Number of appointments] ?

Atentamente,

Gracias @ v-lid-msft. Le agradezco que me escriba para ayudarme con esto.

Escuché en otra publicación que ALLEXCEPT es una mala función de usar porque es muy ineficiente, así que me estoy enfocando en eso ahora. También escuché que MAXX es una buena función para usar, aunque sugirió que podría ser un problema. ¡Poco confundido!

De todos modos, gracias por responder, probaré tu solución.

Hola @charliedata,

¿Qué tal el resultado después de seguir las sugerencias mencionadas en mi publicación original? ¿Podría proporcionar más detalles al respecto si no cumple con sus requisitos?

Atentamente,

@charliedata si está utilizando una consulta directa, no podré replicar. Tal vez intente importar y luego compartir el archivo pbix. ¿Qué tan grande es el conjunto de datos?

Los problemas de rendimiento pueden deberse a muchas razones, por lo que sin mirar pbix, es un poco disparar en la oscuridad, lo que odio.

Entradas relacionadas

Deja un comentario Cancelar respuesta