DAX para calcular el stock de apertura y cierre, superar el límite de memoria

[Analitika]

Tengo una gran tabla de datos en el modelo de datos de 2000 años

¿Por qué la medida simple supera los límites de memoria? ¿Y cómo deshacerse de eso?

Apertura de Stock
CALCULAR (
SUM ( Table1[value] ),
FILTRO ( ALL ( 'Date'[Date] ), 'Date'[Date] < MIN ( 'Date'[Date] ) )
)

Cierre de stock
CALCULAR (
SUM ( Table1[value] ),
FILTRO ( ALL ( 'Date'[Date] ), 'Date'[Date] <- MAX ( 'Date'[Date] ) )
)

Carga solo si se selecciona un mes

[v-alq-msft]

Hola, @Analitika

Le sugerimos que consulte la siguiente guía para mejorar el rendimiento de Power BI optimizando DAX.

Mejore el rendimiento de Power BI optimizando DAX

Saludos

Allan

Si este post ayuda, entonces considera Aceptarlo como la solución para ayudar a los otros miembros a encontrarlo más rápidamente.

[Greg_Deckler]

@Analitika Un par de pensamientos sobre esto. En primer lugar, increíblemente difícil de solucionar problemas de RENDIMIENTO relacionado DAX sin el modelo por lo que todo lo que puedo hacer es tipo de suposición. Escribí una serie de dos partes sobre la optimización del rendimiento de DAX que podría ayudar.

• DAX de ajuste del rendimiento - Parte 1 - Comunidad de Microsoft Power BI
• DAX de ajuste del rendimiento - Parte 2 - Comunidad de Microsoft Power BI

No esté seguro de si ayudará, pero tal vez intente usar una tabla de fechas independiente para la segmentación de datos que no esté relacionada con la tabla de fechas principal. A continuación, podrá abandonar su instrucción ALL. Además, si la tabla Fecha está relacionada con la tabla de hechos, también podría intentar filtrar la tabla directamente en lugar de pasar por la tabla Fecha una vez que tenga una tabla de fechas desconectada independiente para la segmentación de datos. Mi preocupación con la declaración ALL es que parece que usted está poniendo toda su tabla de hechos en contexto y no puedo imaginar que sea óptimo. Además, definitivamente desactivaría la fecha / hora automática y la razón es que esto hace estallar el tamaño de su tabla de fechas a enormes proporciones, por lo general innecesariamente. Luego, usando ALL para traer toda tu tabla de fechas tienes que cargar este behemonth en la memoria. Deshacerse de la fecha y hora automáticas debería reducir drásticamente el tamaño de la tabla de fechas en el modelo de datos y, a continuación, puede caber en la memoria.

[Greg_Deckler]

@Analitika: tendría que comprender mejor el modelo de datos para comprender lo que está pasando. ¿Realmente necesitas el TODO ahí dentro? Con el ALL allí está reemplazando el contexto forzando la medida a cargar toda la tabla de fechas en la memoria y luego pare de nuevo hacia abajo en comparación con simplemente tomar lo que tiene en contexto y filtrarlo. ¿Qué tan grande es tu tabla de citas? ¿Has desactivado la fecha/hora automática?

[Analitika]

@Greg_Deckler

Tengo una rebanadora

se llenó con fecha/hora automática 'Fecha'[Fecha] pero cortada en rodajas para durar 3 años para reducir las fechas de segmentación (solo necesita fechas para mostrar los últimos 3 años)

pero MIN(Table1[date]) es 2000.01.01

Por lo tanto, para Opening Stock necesito sumar todo en Table1[value] desde 2000.01.01 hasta MIN(Date[Date]) seleccionado por slicer

Así que para cerrar stock necesito sumar todo en Table1[value] desde 2000.01.01 hasta MAX(Date[Date]) seleccionado por slicer

[amitchandak]

@parry2k, @Greg_Deckler, ¿cuál es la mejor manera de hacerlo de manera eficiente en el rendimiento?

[amitchandak]

@Analitika , Vea si este blog sobre el mismo tema puede ayudar

https://blog.crossjoin.co.uk/2020/01/20/visual-has-exceeded-the-available-resources-error-power-bi/

[Analitika]

cálculos DAX ineficientes pueden hacer que una consulta intente captar una gran cantidad de memoria

así que cómo escribir un cálculo eficiente para ese propósito?