Procesamiento lean y escalable para supply chains

Joannes Vermorel

Con la llegada de computación en la nube, hace poco más de una década, se ha vuelto sencillo adquirir recursos informáticos bajo demanda (almacenamiento, computación, red) prácticamente a cualquier escala si uno está dispuesto a pagar por ello. Sin embargo, aunque es sencillo realizar cálculos a gran escala a través de la plataforma de computación en la nube de tu elección, ello no implica que valga la pena el costo.

En Lokad, no cobramos a nuestros clientes por GB de almacenamiento o por CPU por hora. En su lugar, el factor principal para nuestra tarificación, al optar por nuestros servicios profesionales, es la complejidad del reto de supply chain que se debe abordar en primer lugar. Naturalmente, incluimos en nuestros precios los recursos informáticos necesarios para atender a nuestros clientes, pero en última instancia, cada euro que gastamos en Microsoft Azure - en términos de gasto, nos convertimos en un cliente empresarial “true” - es un euro que no podemos invertir en I+D ni en el Supply Chain Scientist que se encarga de la cuenta.

Así, la plataforma de software de Lokad ha sido diseñada bajo el principio rector de que debemos ser lo más lean posible en términos de recursos informáticos¹. El reto no es procesar 1TB de datos - lo cual es fácil - sino procesar 1TB de datos de la manera más económica posible. Esto nos llevó a tomar una serie de decisiones algo “inusuales” al diseñar Lokad.

Comparación de grafos de ejecución. Los Supply Chain Scientists - al igual que otros data scientists - típicamente no escriben cientos de líneas de código de una sola vez antes de probar su código contra los datos. El proceso es normalmente muy incremental: se añaden unas pocas líneas, se procesan los datos y se repite. Estas iteraciones son necesarias ya que los resultados obtenidos de los datos guían frecuentemente lo que el data scientist hará a continuación. Sin embargo, la mayoría de las herramientas de data science (eg. NumPy o R) vuelven a calcular todo desde cero cada vez que se reejecuta el script. En contraste, Envision realiza un diff sobre grafos de ejecución sucesivos. A diferencia del diff tradicional, que encuentra diferencias entre archivos, nuestro diff identifica las diferencias entre grafos de cómputo: detecta los nuevos nodos de cómputo –que aún deben ser calculados–. Para todos los demás nodos, los resultados ya se han computado y se “reciclan”. Para el Supply Chain Scientist, comparar los grafos de ejecución se asemeja a una corrida ultrarrápida en la que terabytes de datos son procesados en segundos (pista: Lokad no procesó terabytes en segundos, sino solo los pocos cientos de megabytes que diferían de un script a otro).

Datatypes impulsados por el dominio. Probabilistic forecasting es un enfoque revolucionario para supply chain: consideremos todos los futuros posibles, en lugar de elegir uno como si estuviera garantizado. Desafortunadamente, procesar distribuciones de probabilidad requiere un álgebra de distribuciones que implica cálculos no triviales. Por ello, hemos invertido esfuerzos significativos para optimizar este álgebra y realizar operaciones a gran escala sobre variables aleatorias con costos mínimos de CPU. En particular, estamos considerando de manera agresiva el hecho de que en supply chain la mayoría de las variables aleatorias representan probabilidades en pequeñas cantidades, típicamente no más de unas pocas docenas de unidades². En comparación con los enfoques genéricos destinados, digamos, a la computación científica, el enfoque específico de dominio ofrece dos órdenes de magnitud de aceleración en el cómputo.

Escalabilidad defensiva. La mayoría de los lenguajes de programación destinados al procesamiento de datos a gran escala (ej. Scala o Julia) ofrecen capacidades tremendamente potentes para distribuir cálculos en muchos nodos. Sin embargo, esto significa que cada línea de código escrita tiene la posibilidad de consumir una cantidad arbitrariamente grande de recursos informáticos. Se requiere mucha disciplina de ingeniería para contrarrestar las aparentemente crecientes demandas de la aplicación a medida que se introducen cambios. En contraste, Envision adopta una postura defensiva: el lenguaje ha sido diseñado para disuadir a los Supply Chain Scientists de escribir código que sería tremendamente costoso de escalar. Esto explica por qué Envision no tiene bucles, por ejemplo, ya que es casi imposible ofrecer un rendimiento predecible en tiempo de compilación cuando el lenguaje contiene bucles arbitrarios.

Solo almacenamiento key-value. Blob storage³ es el enfoque de almacenamiento de datos más rentable a nivel bare-metal ofrecido en la nube, con precios que pueden bajar hasta unos $20 por TB al mes aproximadamente. Lokad opera directamente sobre Blob Storage (además de discos locales para caché); no contamos con bases de datos relacionales ni NoSQL – salvo aquellas que hemos construido nosotros mismos sobre Blob Storage. En la práctica, nuestra capa de almacenamiento está profundamente integrada con Envision, el lenguaje dedicado a la optimización de Supply Chain Quantitativa en Lokad. Esto nos permite evitar las capas de sobrecarga que tradicionalmente existen en la intersección entre la aplicación y su capa de acceso a datos. En lugar de microoptimizar la fricción en los límites, hemos eliminado esos límites por completo.

Si bien lograr un procesamiento de datos lean y escalable para tu supply chain puede parecer una “minuciosidad” para supply chains de gran tamaño, la sobrecarga informática de procesar terabytes de datos es real. Con demasiada frecuencia, el sistema resulta ser demasiado costoso o demasiado lento, y la fricción termina por consumir buena parte de los beneficios previstos del sistema. Los costos de computación en la nube aún están disminuyendo, pero no esperes mucho más que un 20% anual, por lo que dejar que el avance general del hardware informático haga su magia ya no es realmente una opción, a menos que estés dispuesto a retrasar tu supply chain impulsada por datos por otra década aproximadamente.

También puedes ver el episodio de Lokad TV que produjimos sobre Terabyte Scalability for Supply Chains.