00:00:06 Desafíos del procesamiento de datos de supply chain 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 scripting 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 supply chain scientists y la eficiencia del trabajo.
00:14:10 Beneficios en el mundo real de un procesamiento más rápido y el manejo de conjuntos de datos más grandes.
00:15:30 Importancia de eliminar casos límite y el peligro de procesos largos en iniciativas de Supply Chain Quantitativa.
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 supply chain.
00:21:10 El impacto de la escalabilidad de terabytes en la perspectiva de Lokad y el futuro de la optimización de supply chain.
00:24:41 Reflexiones finales y posibles vías para mejorar la optimización de supply chain.
Resumen
Kieran Chandler entrevista a Joannes Vermorel, fundador de Lokad, sobre supply chain optimization y el manejo de conjuntos de datos vastos. Lokad ha aumentado su capacidad de procesamiento en 20 veces desde 2017, utilizando su lenguaje específico de dominio, Envision, para el procesamiento de datos a gran escala. Envision simplifica la computación distribuida en el contexto de supply chain 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, permitiendo que los supply chain scientists trabajen de manera más eficiente. Vermorel destaca la importancia de la agilidad y la optimización iterativa para el éxito de las iniciativas de optimización de supply chain. La escalabilidad de terabytes de Lokad permite un enfoque más holístico de la optimización y planea mejorar la expresividad en los scripts de Envision para abordar de mejor manera las situaciones reales de supply chain.
Resumen Ampliado
En esta entrevista, Kieran Chandler, el presentador, conversa con Joannes Vermorel, fundador de Lokad, una compañía de software que se especializa en optimización de supply chain. Hablan sobre los desafíos de manejar enormes cantidades de datos en la industria de supply chain y los desarrollos en escalabilidad de terabytes de Lokad.
Joannes menciona que 2018 ha sido un año de escalabilidad para Lokad, ya que la compañía ha incrementado su capacidad de procesamiento por un factor de 20 en comparación con el año anterior. Esta mejora ha permitido que Lokad maneje conjuntos de datos de múltiples terabytes con relativa facilidad, considerando el estado actual de la tecnología.
La compañía ha logrado esto desarrollando la plataforma Solocat, que está diseñada para la optimización de Supply Chain Quantitativa. La plataforma utiliza el lenguaje de scripting específico de dominio de Lokad, llamado Envision. Envision está diseñado para atender las necesidades específicas de los problemas de supply chain 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, a pesar de que la plataforma podía alojar varios terabytes de datos. La compañía ya había implementado cierto nivel de escalabilidad distribuyendo cálculos de machine learning en múltiples máquinas. Sin embargo, tareas como ordenar los datos aún se realizaban en una sola máquina de gran tamaño.
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 a través de múltiples CPU e incluso flotas enteras de máquinas. Como resultado, tareas como el ordenamiento de datos ahora pueden realizarse mucho más rápido aprovechando la capacidad 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 para el dominio hecho a la medida para abordar problemas de supply chain. Mientras que los lenguajes de programación genéricos ofrecen la capacidad de hacer casi cualquier cosa, a menudo requieren configuraciones más complejas y un entendimiento más profundo de librerías y frameworks específicos para lograr la computación distribuida.
Envision, por otro lado, simplifica estas tecnicidades, facilitando el manejo de la computación distribuida y el procesamiento de datos a gran escala en el contexto de la optimización de supply chain. Este enfoque especializado permite a Lokad mejorar la escalabilidad y manejar terabytes de datos de manera más efectiva que utilizando lenguajes de programación genéricos.
Discuten el software de la compañía, Envision, sus beneficios, y cómo los avances recientes han mejorado el análisis de supply chain.
Envision es un lenguaje de scripting específicamente diseñado para problemas de supply chain, lo que lo hace más fácil y eficiente de utilizar que otros lenguajes de programación de propósito general. Sacrifica algo de expresividad a cambio de simplicidad, pero dado que se centra en un tipo específico de problema, esta compensación es aceptable. Vermorel compara la facilidad de usar Envision con la de escribir hojas avanzadas de Excel con promedios elaborados, ordenamientos y búsquedas sofisticadas.
Hace un año, Lokad ya había implementado un enfoque columnar para el almacenamiento de datos en analítica de big data, que es más adecuado para análisis por lotes en lugar de procesamiento en tiempo real. Este enfoque almacena los datos por columna, en lugar de por fila, permitiendo un procesamiento más eficiente de operaciones que solo afectan a unas pocas columnas. Sin embargo, el inconveniente es que agregar nuevas filas requiere trabajar con cada columna, 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 formación extensa. Como resultado, Lokad busca optimizar el uso del tiempo de estos científicos reduciendo el tiempo dedicado al procesamiento de datos.
Anteriormente, el procesamiento de terabytes de datos tomaba horas, pero los avances recientes han reducido ese tiempo a minutos. Esto permite que los supply chain scientists se mantengan enfocados en sus tareas y pasen al siguiente paso más rápidamente, en lugar de esperar los resultados. Sin embargo, también significa que tienen menos oportunidades para tomar descansos.
El avance en el procesamiento más rápido de conjuntos de datos más grandes tiene varios beneficios en el mundo real. Permite a las empresas analizar y optimizar sus supply chains 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 las contingencias del mundo real.
Vermorel identifica que el peligro principal al implementar una iniciativa de Supply Chain Quantitativa es el tiempo que se tarda en perfeccionar el sistema, ya que es crucial manejar todos los casos límite para evitar intervenciones manuales. Cuanto más tiempo tome, más probable es que el proyecto enfrente disruptions, como actualizaciones de IT o ERP, o transformaciones empresariales dramáticas, que pueden dejar obsoleto el trabajo previo.
Para tener éxito, las iniciativas de optimización de supply chain deben ponerse en producción rápidamente, lo que requiere agilidad. Vermorel explica que, aunque pueda parecer mucho lograrlo en unos pocos meses, demorarse demasiado arriesga el fracaso del proyecto. Enfatiza el enfoque iterativo en la optimización, que es necesario debido a la naturaleza impredecible de las supply chains y las contingencias del mundo real que pueden descarrilar numerical recipes.
La optimización iterativa es esencial para manejar la interminable serie de sorpresas que conlleva la gestión de supply chain. Vermorel explica que las supply chains son complejas, involucrando múltiples mercados, países, proveedores y líneas de producto. Es imposible idear y enumerar todos los desafíos técnicos potenciales de antemano, por lo que la agilidad es crucial al ajustar numerical recipes.
Luego, Kieran pregunta a Vermorel sobre el impacto de la escalabilidad de terabytes en Lokad y sus perspectivas futuras. Vermorel afirma que la compañía ha realizado mejoras tremendas en el procesamiento escalable, lo que abre nuevas oportunidades para la optimización de supply chain. Aclara que la escalabilidad no se trata solo de manejar 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 entidad única, 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 a lo largo de la supply chain.
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 numerical recipes que aborden de manera efectiva las situaciones reales de supply chain.
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 supply chain.
Transcripción Completa
Kieran Chandler: Hoy en Lokad TV, vamos a comprender la increíble escala de datos que se gestionan dentro de una supply chain y también discutir cómo Lokad ha desarrollado la escalabilidad de terabytes para hacer frente a ello. 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 de manera continua durante un año en aumentar la escalabilidad. En comparación con la misma fecha del pasado enero, hemos incrementado nuestra capacidad de procesamiento básicamente por un factor de 20, lo que nos sitúa bien dentro del rango para procesar conjuntos de datos de múltiples terabytes con relativa facilidad. No existe algo así como el procesamiento fácil de terabytes considerando la tecnología tal como está hoy, pero aún así se puede hacer de manera relativamente sencilla.
Kieran Chandler: Un factor de 20 suena como una mejora increíblemente grande. ¿Qué tipo de medidas tuvisteis que tomar para alcanzar esta mejora?
Joannes Vermorel: Lokad es una plataforma diseñada para la optimización de supply chain. Técnicamente, se accede a ella 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 supply chain, 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 ejecutaba en una sola máquina. Ya habíamos implementado la expansión a escala, de modo que la idea de distribuir el cálculo en muchas máquinas para componentes específicos, como machine learning, ya estaba en marcha. Sin embargo, en términos generales, cuando simplemente se ordenaban los datos, esto ocurría en una única máquina grande. En 2018, implementamos una arquitectura completamente actualizada para la lógica de ejecución en el backend de los scripts de Envision. Hoy en día, se cuenta con paralelización automática no solo a través de múltiples procesadores y CPUs, sino también de 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 ejecutarse en una flota de docenas de máquinas, haciéndolo mucho más rápido.
Kieran Chandler: Hablemos un poco sobre Envision. ¿Cómo funciona Envision para lograr estas mejoras y aumentar la escalabilidad en comparación con trabajar con otros lenguajes de programación como Python o algo similar?
Joannes Vermorel: Envision es un lenguaje de programación específico para el dominio, mientras que Python, Java, C++, y C# son lenguajes de programación genéricos. Con un lenguaje genérico, se tiene la capacidad de hacer casi cualquier cosa, pero el precio a pagar es que surgen clases de tecnicismos en el ambiente de programación. Por ejemplo, se puede hacer computación distribuida con Python, pero hay que escribir el código de manera que aproveche librerías y frameworks específicos para que esos cálculos se realicen en una flota de máquinas. Además, tendrás que configurar tú mismo un clúster de máquinas para que pueda ejecutar esta lógica distribuida. Si tienes varios programas concurrentes que se ejecutan en el mismo clúster porque hay diferentes scripts o usuarios, se vuelve más complejo. Diferentes necesidades… Bueno, necesitamos tener toda la infraestructura en su lugar para compartir los recursos, ya sea el ancho de banda, los discos, los CPUs, etc. Y todo eso es precisamente lo que Envision hace de una manera completamente integrada para ti. Entonces, lo que se pierde es que se pierde mucha expresividad, lo cual está bien porque, de nuevo, 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 supply chain. No intentamos resolver cada problema. No tratamos de escribir un motor para jugar ajedrez o hacer modelado 3D. Está muy orientado hacia tipos específicos de problemas.
Kieran Chandler: Bien, entonces lo que dices 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 contienen varios miles de millones de líneas para realizar el tipo de analítica que esperarías en un supply chain, como por ejemplo, estimar el costo y el impacto de faltante de stock a través de una gran red en los últimos tres años, es algo que podrías hacer con literalmente una docena de líneas de código. Pero código que es fácil de escribir. Cuando digo fácil de escribir, me refiero a que nunca es tan fácil escribir código, pero no es más difícil que, digamos, escribir una hoja de Excel avanzada que haga promedios sofisticados, ordenamientos sofisticados y búsquedas sofisticadas sobre los datos.
Kieran Chandler: Bien, ¿y cuáles fueron algunas de las ideas clave y los descubrimientos que condujeron a estas mejoras?
Joannes Vermorel: Solo para entender de dónde partíamos, hace un año, Lokad ya contaba con 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 mantiene junta, y esa es tu unidad. Básicamente, eso hace que las bases de datos tabulares sean muy eficientes para realizar pequeñas actualizaciones o lecturas/escrituras línea por línea.
En contraste, en las últimas décadas, cada vez que deseas hacer un análisis de datos, lo que se ha desarrollado es un enfoque columnar. Básicamente, cuando tienes una tabla, digamos que tienes una tabla con 20 columnas, vas a almacenar los datos agrupados por columna. ¿Qué significa esto? Significa que cuando realizas una operación, como por ejemplo, “Tengo el precio por unidad y tengo la cantidad. Supongamos que tienes una tabla que representa el historial de ventas. Ahora quieres saber el monto total de las ventas, entonces, ¿qué necesitas hacer? Necesitas multiplicar el precio por la cantidad y sumar todo eso a lo largo de la tabla.” Resulta que tu tabla puede tener 20 columnas, pero la operación que acabo de describir sólo involucra dos columnas. Así que, si tienes un almacenamiento columnar, la principal ventaja es que cada operación que toca sólo unas pocas columnas, esas pocas columnas serán procesadas y el resto podrá ser simplemente ignorado. Si tienes un formato tabular, bueno, las otras columnas siguen presentes, y no puedes simplemente omitirlas.
Pero la desventaja podría ser que si estás agregando líneas adicionales, si trabajas en tiempo real, con un enfoque columnar, al agregar una línea, tendrías que trabajar con cada una de las columnas.
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, sino más bien para el tipo de analítica que te interesa para supply chain. Puede refrescarse cada minuto, pero no cada milisegundo. Hablemos un poco sobre los costos asociados con la potencia de procesamiento y el manejo de grandes volúmenes de datos. ¿Cómo ha afectado la implementación de 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 baratas, y es un desafío encontrar y capacitar a individuos con el talento adecuado. El recurso escaso no son las CPUs, discos o ancho de banda, los cuales se pueden construir de forma económica en tu plataforma favorita de computación en la nube, sino más bien las personas talentosas que tienes para trabajar en el problema.
Cuando entras en el ámbito del procesamiento de terabytes, todo es lento. Procesar un terabyte de datos puede tomar bastante tiempo, especialmente si estás realizando cálculos no triviales que involucran cálculos probabilísticos con variables aleatorias. Esto podría tomar horas, pero ahora toma minutos. Para los Supply Chain Scientists, esto significa que pueden centrarse en la tarea, obtener los resultados y pasar a lo siguiente en lugar de quedarse esperando los resultados. Así que, si acaso, son malas noticias para nuestros Supply Chain Scientists, porque terminan teniendo menos pausas para el café.
Kieran Chandler: ¿Qué significa este avance para el mundo real? Obviamente, somos capaces de trabajar con conjuntos de datos mucho más grandes y hacerlo mucho más rápido, ¿pero hay otros beneficios que estamos viendo?
Joannes Vermorel: Sí, uno de los peligros clave, o las causas raíz del fracaso de las iniciativas de Supply Chain Quantitativa, es el tiempo que lleva hacerlo bien, lograr que funcione y pulirlo completamente para que no queden casos límite sin atender. Con la capacidad de procesar conjuntos de datos más grandes más rápido, ahora podemos abordar estos problemas de manera más eficiente, lo que finalmente conduce a mejores decisiones de supply chain.
Kieran Chandler: Tus sistemas son buenos, pero aún queda una persona que permanece completamente manual. Esto requiere mucha mano de obra para revisar manualmente todos los casos límite que no se manejan adecuadamente. Esto, de alguna manera, derrota el propósito de tener automatización avanzada de machine learning para la optimización. El peligro es que el proceso para eliminar todos los casos límite, para realmente afinar la receta numérica de toma de decisiones, puede tomar demasiado tiempo.
Joannes Vermorel: Sí, y esa demora es letal, porque en algún momento la gente pierde la fe en el éxito de la iniciativa. Si eres lento, es probable que el área de IT se vea interrumpida en el proceso. Por ejemplo, si tu proyecto toma dos años, hay una probabilidad de uno en tres de que ocurra una actualización de ERP a mitad del camino. Comienzas a optimizar supply chain, y luego se produce un cambio masivo en la dirección de la empresa. Gran parte de lo que has hecho se desmorona simplemente porque se están cambiando todos los sistemas.
Cuanto más esperas, más cosas pueden interrumpir tu proyecto. El propio negocio puede sufrir transformaciones dramáticas que hacen obsoletos tus trabajos anteriores a la luz de los nuevos cambios empresariales. Hay muchas fuerzas impulsoras que presionan para sacar el producto a producción rápidamente. Si no puedes tener éxito en unos pocos meses, es probable que tu iniciativa fracase. Ahí es donde la agilidad es absolutamente necesaria.
Puede parecer mucho, un par de meses, pero cuando manejas terabytes de datos y te toma horas obtener un resultado, esencialmente 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 allí es una especie de enfoque iterativo para optimizar supply chain. ¿Por qué existe tal enfoque iterativo? ¿Por qué no puedes simplemente presionar un botón, usar deep learning para aprender y obtener un buen forecast y buenos resultados?
Joannes Vermorel: La realidad tiene una manera de estorbarte. Supply chain se trata realmente de lidiar con contingencias del mundo real. Hay tantos casos límite que simplemente emergen del mismo tejido de la realidad. Por ejemplo, comienzas a calcular una cantidad ideal para ordenar, digamos 80 unidades. Es la mejor cantidad a ordenar, pero los palets solo vienen en 0 unidades o 100 unidades, porque se empaquetan en un palet. 80 no es una opción, entonces, ¿qué haces?
Hay docenas de situaciones como esta. Podrías pensar que el valor de tu inventario se degrada 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 la vida útil, el valor del inventario baja de algo a cero o incluso a negativo, ya que ahora tienes que pagar para disponer de este stock sin valor.
La realidad es que los supply chain son complejos. Si hablamos de empresas que operan en muchos mercados, múltiples países, con muchos proveedores, potencialmente docenas de líneas de producto, hay muchas complicaciones. Es un pensamiento ilusorio creer que puedes simplemente sentarte en una sala y hacer una lluvia de ideas con el equipo sobre todos los desafíos técnicos que surgirán a lo largo de las iniciativas. No puedes simplemente decir… Siéntate con tu equipo de supply chain y di, enumeremos todas las pequeñas cosas que descarrilarán la receta numérica que genera las decisiones optimizadas de supply chain. La realidad, como siempre, tiene una forma de sorprenderte, porque vas a descubrir cosas extrañas, como, por ejemplo, que cierto país tenga un impuesto peculiar sobre algo. Volviendo a tu pregunta inicial sobre el enfoque iterativo, la única manera de hacer frente a este flujo incesante de sorpresas es ser extremadamente ágil al ajustar tu receta numérica cuando enfrentas algo inesperado.
Kieran Chandler: Ahora enfoquémonos en la escalabilidad de terabytes y empecemos a unir las cosas. ¿Cómo cambia esto la perspectiva de Lokad y qué significa para el futuro?
Joannes Vermorel: Hemos realizado mejoras tremendas en términos de procesamiento a escala. Este desarrollo abre muchas posibilidades que anteriormente nos eran inaccesibles. No se trata solo de lidiar con empresas más grandes, sino que hay muchas formas de hacer trampa, por ejemplo. Considera una gran red de retail. Si tu enfoque para optimizar una red de retail 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 eso escalara. Pero este método no proporcionará la mejora de supply chain que buscas, porque no estás optimizando a nivel de red. Estás optimizando localmente cada tienda de forma aislada, ignorando completamente lo que sucede 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 comienzas a pensar en tu red como una entidad en la que todo está conectado. De hecho, puedes enviar inventario y materiales a través de la red de prácticamente 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 ideas muy buenas y rentables. Necesitas un sistema que pueda procesarlo todo a la vez, de forma monolítica. ¿Qué significa esto para el futuro? Significa que abre toneladas de avenidas para una optimización mejor y holística. La maldición de la optimización de supply chain es que no resuelves los problemas; simplemente los desplazas. Puedes mirar una área y optimizarla, pero lo único que haces es mover el problema hacia abajo en la cadena o de vuelta al proveedor. Otra avenida es que, ahora que hemos ganado significativamente en escalabilidad, probablemente intentaremos volver a la expresividad. Básicamente, nuestro objetivo es expresar las situaciones complejas que ocurren en el mundo real de manera más directa y fluida en esos scripts de Envision. De este modo, es más fácil entregar recetas numéricas que se ajusten adecuadamente para abordar situaciones del mundo real.
Kieran Chandler: Suena genial. Vamos a tener que concluir por aquí, pero gracias por tu tiempo hoy. Eso es todo por esta semana. Muchas gracias por mirar, y nos veremos de nuevo la próxima vez. Adiós por ahora.
