00:00:06 Desafíos en el procesamiento de datos de la cadena de suministro y la escalabilidad de terabytes de Lokad.
00:00:38 Mejoras en la capacidad de procesamiento de Lokad durante el último año.
00:01:33 Explicación de la plataforma de Lokad y su lenguaje de programación Envision.
00:03:55 Comparación de Envision con otros lenguajes de programación como Python.
00:06:27 Ideas clave y avances que llevaron a las mejoras de Lokad.
00:08:00 Almacenamiento tabular vs. columnar en bases de datos y sus eficiencias.
00:10:36 Desafíos y costos asociados con el procesamiento de grandes cantidades de datos.
00:12:04 El impacto del procesamiento de terabytes en los científicos de la cadena de suministro y la eficiencia laboral.
00:14:10 Beneficios reales de un procesamiento más rápido y el manejo de conjuntos de datos más grandes.
00:15:30 Importancia de eliminar casos extremos y el peligro de procesos largos en iniciativas cuantitativas de la cadena de suministro.
00:17:43 Importancia de un enfoque iterativo para lidiar con contingencias del mundo real.
00:20:47 Desafíos e implicaciones del procesamiento de datos a gran escala en la optimización de la cadena de suministro.
00:21:10 El impacto de la escalabilidad de terabytes en la perspectiva de Lokad y el futuro de la optimización de la cadena de suministro.
00:24:41 Reflexiones finales y posibles vías para mejorar la optimización de la cadena de suministro.
Resumen
Kieran Chandler entrevista a Joannes Vermorel, fundador de Lokad, sobre la optimización de la cadena de suministro y el manejo de grandes conjuntos de datos. Lokad ha aumentado su capacidad de procesamiento en 20 veces desde 2017, utilizando su lenguaje específico del dominio, Envision, para el procesamiento de datos a gran escala. Envision simplifica la computación distribuida en el contexto de la cadena de suministro en comparación con los lenguajes de programación genéricos. Los avances de Lokad han reducido los tiempos de procesamiento de datos de horas a minutos, lo que permite a los científicos de la cadena de suministro trabajar de manera más eficiente. Vermorel enfatiza la importancia de la agilidad y la optimización iterativa para el éxito de las iniciativas de la cadena de suministro. La escalabilidad de terabytes de Lokad permite un enfoque más integral para la optimización y planea mejorar la expresividad en los scripts de Envision para abordar mejor las situaciones de la cadena de suministro del mundo real.
Resumen Extendido
En esta entrevista, Kieran Chandler, el presentador, discute con Joannes Vermorel, el fundador de Lokad, una empresa de software especializada en la optimización de la cadena de suministro. Hablan sobre los desafíos de manejar grandes cantidades de datos en la industria de la cadena de suministro y los desarrollos de Lokad en escalabilidad de terabytes.
Joannes menciona que 2018 ha sido un año de escalabilidad para Lokad, con la empresa aumentando su capacidad de procesamiento en un factor de 20 en comparación con el año anterior. Esta mejora ha permitido a Lokad manejar conjuntos de datos de varios terabytes con relativa facilidad, considerando el estado actual de la tecnología.
La empresa ha logrado esto desarrollando la plataforma Solocat, que está diseñada para la optimización de la supply chain quantitativa. La plataforma utiliza el lenguaje de scripting específico del dominio de Lokad llamado Envision. Envision está diseñado para abordar las necesidades específicas de los problemas de la cadena de suministro y facilitar el procesamiento de datos a gran escala.
Antes de 2018, un solo script de Envision solo podía ejecutarse en una sola máquina, aunque la plataforma podía contener varios terabytes de datos. La empresa había implementado cierto nivel de escalabilidad distribuyendo los cálculos de machine learning en varias máquinas. Sin embargo, tareas como la clasificación de datos aún estaban limitadas a una sola máquina grande.
En 2018, Lokad implementó una arquitectura completamente actualizada para la lógica de ejecución en el backend de los scripts de Envision. La nueva arquitectura permite la paralelización automática en múltiples CPUs e incluso en flotas enteras de máquinas. Como resultado, tareas como la clasificación de datos ahora se pueden realizar mucho más rápido utilizando la potencia de procesamiento de docenas de máquinas.
Al comparar Envision con lenguajes de programación genéricos como Python, Java, C++ y C#, Joannes explica que Envision es un lenguaje específico del dominio diseñado para manejar problemas de la cadena de suministro. Si bien los lenguajes de programación genéricos ofrecen la capacidad de hacer casi cualquier cosa, a menudo requieren configuraciones más complejas y una comprensión más profunda de bibliotecas y marcos específicos para lograr la computación distribuida.
En cambio, Envision simplifica estas complejidades técnicas, facilitando el manejo de la computación distribuida y el procesamiento de datos a gran escala en el contexto de la optimización de la cadena de suministro. Este enfoque especializado permite a Lokad mejorar la escalabilidad y manejar terabytes de datos de manera más efectiva que el uso de lenguajes de programación genéricos.
Discuten el software de la empresa, Envision, sus beneficios y cómo los avances recientes han mejorado la analítica de la cadena de suministro.
Envision es un lenguaje de scripting diseñado específicamente para problemas de la cadena de suministro, lo que lo hace más fácil y eficiente de usar que otros lenguajes de programación de propósito general. Sacrifica cierta expresividad por simplicidad, pero dado que se enfoca en un tipo específico de problema, este compromiso es aceptable. Vermorel compara la facilidad de uso de Envision con la escritura de hojas de cálculo avanzadas de Excel con promedios, clasificaciones y búsquedas sofisticadas.
Hace un año, Lokad ya había implementado un enfoque columnar para el almacenamiento de datos en análisis de big data, que es más adecuado para análisis por lotes que para procesamiento en tiempo real. Este enfoque almacena los datos por columna, en lugar de por fila, lo que permite un procesamiento más eficiente de operaciones que solo afectan a algunas columnas. Sin embargo, la desventaja es que agregar nuevas filas requiere trabajar con cada columna individual, lo que lo hace menos eficiente para el procesamiento en tiempo real.
Al discutir los costos asociados con el procesamiento de grandes cantidades de datos, Vermorel enfatiza que el recurso más costoso es el supply chain scientist (o data scientist), ya que son escasos, requieren conocimientos específicos y necesitan una amplia capacitación. Como resultado, Lokad tiene como objetivo optimizar el uso del tiempo de estos científicos reduciendo el tiempo dedicado al procesamiento de datos.
Anteriormente, el procesamiento de terabytes de datos llevaba horas, pero los avances recientes han reducido ese tiempo a minutos. Esto permite que los científicos de la cadena de suministro se centren en sus tareas y pasen rápidamente a la siguiente etapa, en lugar de esperar resultados. Sin embargo, también significa que tienen menos oportunidades para descansar.
El avance en el procesamiento de conjuntos de datos más grandes y más rápidos tiene varios beneficios en el mundo real. Permite a las empresas analizar y optimizar sus cadenas de suministro de manera más eficiente y efectiva, mejorando en última instancia sus operaciones generales.
Abordan los desafíos de lograr la optimización, la importancia de la agilidad y el enfoque iterativo necesario para manejar contingencias del mundo real.
Vermorel identifica el principal peligro en la implementación de una iniciativa de supply chain quantitativa como el tiempo que lleva perfeccionar el sistema, ya que es crucial manejar todos los casos límite para evitar la intervención manual. Cuanto más tiempo lleve, es más probable que el proyecto enfrente faltantes de stock, como actualizaciones de TI o ERP, o transformaciones comerciales drásticas, que pueden volver obsoleto el trabajo anterior.
Para tener éxito, las iniciativas de optimización de la cadena de suministro deben ponerse en producción rápidamente, lo que requiere agilidad. Vermorel explica que aunque pueda parecer mucho lograrlo en unos meses, llevar demasiado tiempo arriesga el fracaso del proyecto. Él enfatiza el enfoque iterativo para la optimización, que es necesario debido a la naturaleza impredecible de las cadenas de suministro y las contingencias del mundo real que pueden desviar las recetas numéricas.
La optimización iterativa es esencial para manejar el flujo interminable de sorpresas que vienen con la gestión de la cadena de suministro. Vermorel explica que las cadenas de suministro son complejas, involucran múltiples mercados, países, proveedores y líneas de productos. Es imposible idear y enumerar todos los posibles desafíos técnicos de antemano, por lo que la agilidad es crucial al solucionar recetas numéricas.
Luego, Kieran pregunta a Vermorel sobre el impacto de la escalabilidad de terabytes en Lokad y su perspectiva futura. Vermorel afirma que la empresa ha logrado mejoras tremendas en el procesamiento de escalabilidad, lo que abre nuevas oportunidades para la optimización de la cadena de suministro. Aclara que la escalabilidad no se trata solo de lidiar con empresas más grandes, sino también de lograr una optimización a nivel de red.
Vermorel destaca que la verdadera optimización requiere considerar toda la red como una sola entidad, en lugar de optimizar cada tienda o proveedor de forma aislada. La escalabilidad de terabytes permite a Lokad abordar la optimización de manera más holística, lo que a su vez ayuda a evitar que los problemas se desplacen por la cadena de suministro.
En el futuro, Lokad planea utilizar sus avances en escalabilidad para mejorar la expresividad, permitiendo formas más fluidas y directas de reflejar situaciones complejas del mundo real en sus scripts de Envision. Esto facilitará el desarrollo de recetas numéricas que aborden eficazmente situaciones reales de la cadena de suministro.
La entrevista concluye con Vermorel enfatizando la importancia de la agilidad, la optimización iterativa y los enfoques holísticos para la gestión de la cadena de suministro.
Transcripción completa
Kieran Chandler: Hoy en Lokad TV, vamos a entender la gran cantidad de datos que se gestionan dentro de una cadena de suministro y también discutir cómo Lokad ha desarrollado la escalabilidad de terabytes para hacer frente a eso. Entonces, Joannes, hoy vamos a hablar un poco sobre la investigación y el desarrollo realizado en Lokad durante el último año. ¿En qué has estado trabajando en 2018?
Joannes Vermorel: 2018 ha sido el año de la escalabilidad para nosotros. Hemos estado trabajando casi continuamente durante un año en aumentar la escalabilidad. En comparación con la misma fecha de enero pasado, hemos aumentado nuestra capacidad de procesamiento en un factor de 20, lo que nos permite procesar conjuntos de datos de varios terabytes relativamente con facilidad. No existe tal cosa como el procesamiento fácil de terabytes considerando la tecnología tal como está hoy, pero aún se puede hacer relativamente sencillo.
Kieran Chandler: Un factor de 20 suena como una mejora increíblemente grande. ¿Qué tipo de pasos tuviste que tomar para lograr esta mejora?
Joannes Vermorel: Lokad es una plataforma diseñada para la optimización de la cadena de suministro. Técnicamente, se accede a través de scripts escritos en nuestro propio lenguaje de scripting casero llamado Envision. Este lenguaje está diseñado no solo para abordar específicamente las necesidades de la optimización de la cadena de suministro, sino también para facilitar el procesamiento a gran escala. Hasta el año pasado, una sola cuenta de uno de nuestros clientes podía contener varios terabytes de datos, pero un solo script o fragmento de código se ejecutaría en una sola máquina. Ya habíamos implementado la escalabilidad, por lo que la idea de que se puede distribuir el cálculo en muchas máquinas para componentes específicos como el aprendizaje automático. Sin embargo, en términos generales, cuando solo estabas ordenando los datos, esto ocurría en una sola máquina grande. En 2018, implementamos una arquitectura completamente actualizada para la lógica de ejecución en segundo plano de los scripts de Envision. Hoy en día, tienes paralelización automática no solo en múltiples procesadores y CPUs, sino también en una flota de máquinas. Esto significa que un solo script que realiza una operación simple, como ordenar los datos por fecha, producto, tienda o precio, puede ocurrir en una flota de docenas de máquinas, lo que lo hace mucho más rápido.
Kieran Chandler: Hablemos un poco sobre Envision. ¿Cómo funciona Envision para hacer estas mejoras y mejorar la escalabilidad en comparación con trabajar con otros lenguajes de programación como Python o algo así?
Joannes Vermorel: Envision es un lenguaje de programación específico del dominio, mientras que Python, Java, C++ y C# son lenguajes de programación genéricos. Con un lenguaje de programación genérico, obtienes la capacidad de hacer prácticamente cualquier cosa, pero el precio que tienes que pagar es que hay clases de tecnicismos que surgen en el entorno de programación. Por ejemplo, puedes hacer cómputo distribuido con Python, pero debes escribir tu código de una manera que aproveche bibliotecas y marcos específicos para que esos cálculos ocurran en una flota de máquinas. Además, tendrás que configurar un clúster de máquinas tú mismo para que pueda ejecutar esta lógica distribuida. Si tienes varios programas concurrentes que se ejecutan en el mismo clúster porque tienes diferentes scripts o diferentes usuarios, se vuelve más complejo. Diferentes necesidades… Bueno, necesitamos tener toda la infraestructura en su lugar para compartir los recursos, ya sabes, el ancho de banda, los discos, las CPUs y demás. Y todo eso es precisamente lo que Envision hace de manera completamente integrada para ti. Entonces, lo que pierdes es que pierdes mucha expresividad, lo cual está bien porque, nuevamente, Envision puede sobrevivir. No está roto, a pesar de haber perdido mucha expresividad, porque estamos especializados en un tipo específico de problema, que son básicamente problemas de cadena de suministro. Entonces no tratamos de resolver todos los problemas. No tratamos de escribir un motor para jugar ajedrez o hacer modelado 3D. Está muy orientado hacia tipos específicos de problemas.
Kieran Chandler: Ok, entonces lo que estás diciendo es que es mucho más sencillo usar Envision en lugar de otro tipo de lenguaje de programación?
Joannes Vermorel: Exactamente. Quiero decir, escribir un script que procese tablas que contengan miles de millones de líneas para realizar el tipo de análisis que esperarías en un contexto de supply chain, como estimar el costo y el impacto de los faltantes de stock en una gran red durante los últimos tres años, es algo que podrías hacer con solo una docena de líneas de código. Pero un código que es fácil de escribir. Cuando digo fácil de escribir, quiero decir que nunca es tan fácil escribir código, pero no es más difícil que, digamos, escribir una hoja de cálculo avanzada de Excel que haga promedios sofisticados, clasificaciones sofisticadas y búsquedas sofisticadas en los datos.
Kieran Chandler: Ok, ¿y cuáles fueron algunas de las ideas clave y avances que llevaron a estas mejoras?
Joannes Vermorel: Solo para entender desde dónde partíamos, hace un año, Lokad ya tenía muchos ingredientes de big data en su lugar. Uno de ellos es tener un enfoque columnar para el almacenamiento de datos. En resumen, las bases de datos SQL tradicionales adoptan un almacenamiento tabular. Esto significa que cuando tienes una tabla, estás almacenando líneas de datos, y si tienes una línea, se colocan juntas, y esa es tu unidad. Básicamente, eso hace que las bases de datos tabulares sean muy eficientes para realizar pequeñas actualizaciones o lectura/escritura línea por línea.
En contraste, en las últimas décadas, cuando se quiere hacer un análisis de datos a gran escala, se ha desarrollado un enfoque columnar. Básicamente, cuando tienes una tabla, digamos que tienes una tabla con 20 columnas, vas a almacenar los datos empaquetados por columna. Entonces, ¿qué significa eso? Significa que cuando realizas una operación, como por ejemplo, “Tengo el precio por unidad y tengo la cantidad. Digamos que tienes una tabla que representa el historial de ventas. Ahora quieres saber el monto total de ventas, ¿qué necesitas hacer? Necesitas multiplicar el precio por la cantidad y hacer la suma de todo eso en la tabla”. Bueno, resulta que tu tabla puede tener 20 columnas, pero la operación que acabo de describir solo está tocando dos columnas. Entonces, si tienes un almacenamiento columnar, la principal ventaja es que cada operación que toca solo unas pocas columnas, esas pocas columnas se procesarán y el resto se puede ignorar. Si tienes un formato tabular, bueno, las otras columnas siguen estando completamente en medio y no puedes saltártelas realmente.
Pero la desventaja podría ser que si estás agregando líneas adicionales, si estás trabajando en tiempo real, si tienes un enfoque columnar, si estás agregando una línea, tendrías que trabajar con cada columna individualmente.
Kieran Chandler: Entonces, cuando agregas una línea, tienes que tocar 20 columnas, lo que lo hace relativamente ineficiente. El almacenamiento columnar es más adecuado para análisis por lotes, no exactamente en tiempo real, pero más para el tipo de análisis que te interesa en el supply chain. Se puede actualizar cada minuto, pero no cada milisegundo. Hablemos un poco sobre los costos asociados con la potencia de procesamiento y el trabajo con grandes cantidades de datos. ¿Cómo ha afectado la implementación de la escalabilidad de terabytes a los costos de trabajar con datos?
Joannes Vermorel: En realidad, bastante. Los recursos más costosos cuando intentas optimizar un supply chain a gran escala son los Supply Chain Scientists. Estas personas no son gratuitas y es un desafío encontrar y capacitar a individuos con el talento adecuado. El recurso escaso no son las CPUs, los discos o el ancho de banda, que se pueden construir de manera económica desde tu plataforma de computación en la nube favorita, sino las personas talentosas con las que tienes que trabajar en el problema.
Cuando entras en el ámbito del procesamiento de terabytes, todo es lento. Procesar un terabyte de datos puede llevar bastante tiempo, especialmente si estás realizando cálculos no triviales que involucran cálculos probabilísticos con variables aleatorias. Esto podría llevar horas, pero ahora está tomando minutos. Para los Supply Chain Scientists, esto significa que pueden mantenerse enfocados en la tarea, obtener los resultados y pasar a la siguiente cosa en lugar de quedarse esperando los resultados. Entonces, si algo, es una mala noticia para nuestros Supply Chain Scientists porque tienen menos descansos para tomar café.
Kieran Chandler: ¿Qué significa este avance para el mundo real? Obviamente, podemos trabajar con conjuntos de datos mucho más grandes y trabajar con ellos mucho más rápido, pero ¿hay algún otro beneficio que estemos viendo?
Joannes Vermorel: Sí, uno de los peligros clave, o causas fundamentales del fracaso de las iniciativas de Supply Chain Quantitativa, es el tiempo que lleva hacerlo bien, hacerlo funcionar y pulirlo por completo para que no haya casos marginales persistentes. Con la capacidad de procesar conjuntos de datos más grandes de manera más rápida, ahora podemos abordar estos problemas de manera más eficiente, lo que en última instancia conduce a mejores decisiones de supply chain.
Kieran Chandler: Tus sistemas son buenos, pero todavía hay una persona que sigue siendo completamente manual. Esto requiere mucha mano de obra para revisar manualmente todos los casos marginales que no se manejan correctamente. Esto de alguna manera va en contra del propósito de tener automatización avanzada de aprendizaje automático para la optimización. El peligro es que el proceso para eliminar todos los casos marginales, para realmente afinar la receta numérica de toma de decisiones, puede llevar demasiado tiempo.
Joannes Vermorel: Sí, y ese retraso es letal porque en algún momento, las personas pierden la fe en el éxito de la iniciativa. Si eres lento, es probable que la tecnología de la información se vea interrumpida en el medio. Por ejemplo, si tu proyecto lleva dos años, hay una probabilidad de uno de cada tres de que haya una actualización del ERP en el medio. Comienzas a optimizar el supply chain y luego hay un cambio masivo dentro de la idea de la empresa. Gran parte de lo que has hecho se desmorona simplemente porque todos los sistemas están siendo cambiados.
Cuanto más esperas, más cosas pueden interrumpir tu proyecto. El propio negocio puede sufrir una transformación dramática que hace que tu trabajo anterior sea obsoleto a la luz de los nuevos cambios empresariales. Hay muchas fuerzas impulsoras que ejercen presión para que el producto se ponga en producción rápidamente. Si no puedes tener éxito en unos pocos meses, es probable que tu iniciativa fracase. Ahí es donde se requiere absolutamente la agilidad.
Puede sonar como mucho, un par de meses, pero cuando tocas terabytes de datos y lleva horas obtener un resultado, estás ajustando tus recetas numéricas una o dos veces al día como máximo. Las cosas comienzan a volverse muy lentas.
Kieran Chandler: Entonces, lo que estás mencionando es una especie de enfoque iterativo para optimizar el supply chain. ¿Por qué hay un enfoque tan iterativo? ¿Por qué no puedes simplemente presionar un botón, usar deep learning para aprender y obtener un buen pronóstico y buenos resultados?
Joannes Vermorel: La realidad tiene una forma de interponerse en tu camino. El supply chain se trata realmente de lidiar con contingencias del mundo real. Hay tantos casos particulares que surgen de la propia realidad. Por ejemplo, comienzas a calcular una cantidad ideal para pedir, digamos 80 unidades. Es la mejor cantidad para pedir, pero los palets solo vienen en cero unidades o 100 unidades porque se empacan sobre un palet. 80 no es una opción, ¿entonces qué haces?
Hay docenas de situaciones como esta. Puedes pensar que el valor de tu inventario decae gradualmente con el tiempo, pero no es así. ¿Por qué? Porque hay una vida útil con una fecha específica. Cuando alcanzas el límite de vida útil, el valor de tu inventario cae de algo a cero o incluso negativo porque ahora tienes que pagar para deshacerte de este stock sin valor.
La realidad es que las cadenas de suministro son complejas. Si estamos hablando de empresas que operan en muchos mercados, múltiples países, con muchos proveedores, potencialmente docenas de líneas de productos, hay muchas complicaciones. Es ilusorio creer que puedes simplemente sentarte en una habitación y hacer una lluvia de ideas con el equipo sobre todos los desafíos técnicos que surgirán más adelante con las iniciativas. No puedes simplemente decir… Siéntate con tu equipo de supply chain y di, hagamos una lista de todas las pequeñas cosas que desviarán la receta numérica que genera las decisiones de supply chain optimizadas. La realidad, como siempre, tiene una forma de sorprenderte porque descubrirás cosas extrañas como un cierto país que tiene un impuesto extraño sobre algo, por ejemplo. Volviendo a tu pregunta inicial sobre el enfoque iterativo, la única forma de lidiar con esta interminable corriente de sorpresas es ser extremadamente ágil en la corrección de tu receta numérica cuando te enfrentas a algo inesperado.
Kieran Chandler: Ahora centrémonos en la escalabilidad de terabytes y empecemos a unir las cosas. ¿Cómo cambia esto las perspectivas de Lokad y qué significa para el futuro?
Joannes Vermorel: Hemos logrado mejoras tremendas en términos de procesamiento escalable. Este desarrollo abre muchos cambios que antes nos eran inaccesibles. No se trata solo de lidiar con empresas más grandes, hay muchas formas de hacer trampa, por ejemplo. Considera una gran red minorista. Si tu enfoque para optimizar una red minorista a gran escala es procesar cada mercado de forma aislada, y si tienes, digamos, 200 mercados, solo necesitarías 200 máquinas, una por mercado, y escalaría. Pero este método no te dará la mejora de supply chain que estás buscando porque no estás optimizando a nivel de red. Estás optimizando localmente cada tienda de forma aislada, ignorando por completo lo que está sucediendo en el resto de la red.
Kieran Chandler: ¿Entonces estas 200 máquinas no se comunicarían entre sí?
Joannes Vermorel: Exactamente. Si tienes silos independientes, es muy fácil escalar tu procesamiento. Pero el desafío es cuando empiezas a pensar en tu red como una entidad donde todo está conectado. En realidad, puedes enviar inventario y materiales a través de la red de casi cualquier manera que desees. Aunque hay muchas formas que no son rentables y no tienen sentido, es posible. Y algunas de estas formas sutiles podrían ser muy buenas ideas y rentables. Necesitas un sistema que pueda procesar todo de una vez, de manera monolítica. ¿Qué significa eso para el futuro? Significa que se abren toneladas de oportunidades para una mejor optimización holística. La maldición de la optimización de la cadena de suministro es que no resuelves los problemas; solo los desplazas. Puedes mirar un área y optimizarla, pero todo lo que estás haciendo es mover el problema hacia abajo en la línea o de vuelta al proveedor. Otra oportunidad es que ahora que hemos ganado significativamente en escalabilidad, probablemente intentaremos volver a la expresividad. Básicamente, nuestro objetivo es expresar situaciones complejas que ocurren en el mundo real de manera más directa y fluida en esos scripts de Envision. De esta manera, es más fácil ofrecer recetas numéricas que se ajusten bien a situaciones del mundo real.
Kieran Chandler: Eso suena genial. Tendremos que terminar aquí, pero gracias por tu tiempo hoy. Eso es todo por esta semana. Muchas gracias por vernos y nos vemos la próxima vez. Hasta luego.
