greg_deckler
Introducción
OK, es oficial, tamaño lo hace importa cuando se trata de DAX. Seamos claros, estamos hablando de DAX aquí. Después de todo, este es un sitio de blog de la comunidad de Power BI. Sigamos siendo profesionales. Este tema del tamaño y el rendimiento (todavía sobre DAX) surgió en una conversación bastante graciosa sobre la creación de mi envío más reciente a la Galería de medidas rápidas, Cumplimiento de pedidos. Sin embargo, si nada más, me hizo pensar si el hecho de que el tamaño y el rendimiento realmente importan Realmente importa en cada situación. No creo que lo haga, pero siéntete libre de estar en desacuerdo.
Fondo
Así que esta pregunta se hizo en los foros. Dado un conjunto de líneas de pedido de ventas por producto y cantidad, dígame qué ubicaciones/contenedores en mi inventario que almacenan esos productos se deben usar para cumplir con esos pedidos. Ah, y cumpla primero con los pedidos de las ubicaciones/contenedores de inventario más grandes. Y luego, más tarde, esto se transformó en una situación FIFO/LIFO, cumplir primero con los pedidos de venta más tempranos o más recientes, aún abasteciéndose de las ubicaciones/contenedores más grandes.
La solución
Bien, resolvamos esto con una medida DAX. Flexible, dinámico, si en el futuro sus almacenes en Louisana son arrasados por un huracán y necesita volver a calcular su abastecimiento sobre la marcha, las medidas son buenas para ese tipo de cosas.
Bueno, el primer problema a superar es cumplir con los pedidos utilizando primero las ubicaciones/contenedores más grandes. Puaj. El orden de clasificación en DAX no está garantizado para casi nada. No es que tengamos acceso a EVALUAR y ORDENAR POR en Power BI Desktop. Pero hay una excepción. De todas las cosas, CONCATENATEX. Ni siquiera TOPN garantiza el orden de clasificación en DAX, pero CONCATENATEX, por alguna razón misteriosa, puede hacerlo. OK, muy entusiasta, pero ahora tengo una cadena de texto. Ugh, ahora tengo que convertirlo en una tabla indexada. Oh, afortunadamente, The Mytical DAX Index se puede usar para lograr esta hazaña siempre que cuando esté CONCATENATEX use un carácter de barra vertical ( | ). Swell, las cosas se están moviendo muy bien.
Pero, y aquí es donde empezamos a tener problemas de tamaño y rendimiento, ahora tengo que realizar un bucle «while». En DAX. Muy bien, tenemos una solución para eso, el DAX «While» Loop. Excepto que no es particularmente eficiente como un ciclo while real. Básicamente, para cada pedido de ventas, necesito hacer un cálculo en cada ubicación/contenedor que contiene el producto en particular. Luego tengo que encontrar mi punto de «ruptura» y devolver el cálculo correcto desde allí. Detalles. Sin embargo, esto presenta un problema de escala.
En mi escenario de prueba de 50 000 líneas de pedido abiertas y 50 almacenes, eso significa que tengo que hacer 50 000 * 50 cálculos o 250 000 cálculos totales como mínimo y luego cálculos adicionales además de eso. Llegamos fácilmente al medio millón o un millón de cálculos en este punto. De todos modos, en mi diminuta Surface, devolver las 50 000 líneas de pedidos de ventas lleva alrededor de un minuto. Eso es mucho tiempo para esperar a que se muestre una imagen para estar seguro. Ahora, un solo pedido de ventas que consta de 5000 filas toma un par de segundos. Un producto individual que puede aparecer en 10 o más pedidos de venta, sub-segundo. Considerándolo todo, me siento bastante bien acerca de las cosas y luego…
Interrumpido
Así que de la nada empiezo a ser interrumpido como «tu código es basura», «nunca escalará a millones de registros» y así sucesivamente. Ni siquiera el tipo «bueno» de abucheos como «su código es basura y así es como puede mejorarlo». Sólo usted sabe, «basura». Está bien y es un poco divertido porque estoy pensando para mí mismo, «¿A quién le importa si no puede escalar a millones de pedidos de ventas y miles de millones de ubicaciones/contenedores?» Quiero decir, es DAX después de todo. Ni siquiera tenemos bucles while adecuados. Y no es que el mundo se vaya a acabar se convierte en un código DAX complejo. Entonces, sí, 1 millón por 1,000, eso es como, ¡eso es un montón de cálculos! Pero, solo porque no puede escalar, ¿eso hace que la solución sea inútil? No necesariamente.
Ahora bien, no soy el tipo de persona que arroja estadísticas. Porque, ya sabes, mentiras, ** bleep ** mentiras y estadísticas. Además, en mi experiencia, las personas que citan estadísticas son como personas que constantemente te dicen cuán inteligentes son. Las personas más inteligentes que he conocido nunca me han dicho lo inteligentes que son. Solo digo. Pero, tenga en cuenta que hay estadísticas sobre el tamaño de las empresas en los Estados Unidos. El 99,9% de esas empresas tienen menos de 500 empleados. Del 0,1% restante, alrededor de 2/3 de ellos tienen menos de 1000 empleados.
Entonces, comencé a pensar para mí mismo. ¿Cuáles son las probabilidades de que el 99,9% de las empresas en los Estados Unidos puedan usar mi medida de Cumplimiento de pedidos de basura? Estoy pensando, bastante alto. Estoy seguro de que hay negocios por ahí con menos de 500 empleados que tienen millones de órdenes de venta abiertas y miles de almacenes, pero estoy dispuesto a apostar que es un pequeño porcentaje de la población.
De todos modos, al final del día, una empresa con millones de pedidos de venta abiertos y miles de ubicaciones de almacén o contenedores no podrá usar mi medida de Cumplimiento de Oder de basura. ¿Qué me importa? No. Es mejor que una empresa de ese tamaño obtenga esa información de algo como Dynamics 365 porque ese es el tipo de cosas para las que los sistemas de planificación de recursos empresariales (ERP) fueron creados específicamente para hacer. Entonces, tomaré el 99.9% de las empresas que pueden usar mi código basura y lo anotaré como una victoria. El otro 0,1% puede utilizar sus sistemas ERP.
Conclusión
Alguien me dijo una vez que largo sin ancho no es nada. Espera… ¿eso se aplica aquí? Hmm… tal vez eso fue pronunciado en un contexto diferente. ¡Maldita sea! ¡Arruiné otra conclusión!
4
