Procesamiento escalable y lean para cadenas de suministro

Joannes Vermorel

Con la llegada de la computación en la nube, hace poco más de una década, se ha vuelto sencillo adquirir recursos informáticos bajo demanda (almacenamiento, cálculo, red) prácticamente a cualquier escala, siempre y cuando uno esté dispuesto a pagar por ello. Sin embargo, aunque es sencillo realizar cálculos a gran escala en la plataforma de computación en la nube de su elección, 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 cambio, el factor principal para nuestra fijación de precios, al optar por nuestros servicios profesionales, es la complejidad del desafío de la cadena de suministro que se abordará en primer lugar. Naturalmente, tenemos en cuenta los recursos informáticos que necesitamos para atender a nuestros clientes en nuestros precios, pero en última instancia, cada euro que gastamos en Microsoft Azure, en términos de gastos, nos convertimos en un cliente empresarial “verdadero”, es un euro que no podemos gastar en I+D o en el Supply Chain Scientist que se encarga de la cuenta.

Por lo tanto, 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 desafío 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 una serie de decisiones algo “inusuales” al diseñar Lokad.

Gráficos de ejecución de diferencias. Los científicos de la cadena de suministro, al igual que otros científicos de datos, típicamente no escriben cientos de líneas de código de una vez antes de probar su código con los datos. El proceso suele ser altamente incremental: agregar algunas líneas, procesar los datos, repetir. Estas iteraciones son necesarias ya que los resultados obtenidos de los datos frecuentemente guían lo que el científico de datos hará a continuación. Sin embargo, la mayoría de las herramientas de ciencia de datos (por ejemplo, NumPy o R) vuelven a calcular todo desde cero cada vez que se vuelve a ejecutar el script. En cambio, Envision realiza una diferencia sobre gráficos de ejecución sucesivos. A diferencia de la diferencia tradicional que encuentra diferencias entre archivos, nuestra diferencia encuentra diferencias entre gráficos de cálculo: la diferencia identifica los nuevos nodos de cálculo, que aún deben calcularse. Para todos los demás nodos, los resultados ya se han calculado y se “reciclan”. Para el científico de la cadena de suministro, la diferenciación de los gráficos de ejecución parece una ejecución ultrarrápida donde se procesan terabytes de datos en segundos (pista: Lokad no procesó terabytes en segundos, solo los pocos cientos de megabytes que diferían de un script a otro).

Tipos de datos impulsados por el dominio. El pronóstico probabilístico es un enfoque revolucionario para la cadena de suministro: consideremos todos los futuros posibles en lugar de elegir un futuro como si estuviera garantizado que sucederá. Desafortunadamente, el procesamiento de distribuciones de probabilidad requiere un álgebra de distribuciones que implica cálculos no triviales. Por lo tanto, hemos invertido esfuerzos significativos para optimizar esta álgebra y realizar operaciones a gran escala sobre variables aleatorias con un costo mínimo de CPU. En particular, estamos teniendo en cuenta de manera agresiva el hecho de que en la cadena de suministro, 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 enfoques genéricos destinados, por ejemplo, a la computación científica, el enfoque específico del dominio proporciona una aceleración de dos órdenes de magnitud en el cálculo.

Escalabilidad defensiva. La mayoría de los lenguajes de programación destinados al procesamiento de datos a gran escala (por ejemplo, Scala o Julia) ofrecen capacidades tremendas para distribuir cálculos en muchos nodos. Sin embargo, esto significa que cada línea de código escrita tiene la oportunidad de consumir una cantidad arbitrariamente grande de recursos informáticos. Se requiere mucha disciplina de ingeniería para contrarrestar las necesidades aparentemente cada vez mayores de la aplicación a medida que los cambios se abren camino en la aplicación. En cambio, Envision adopta una postura defensiva: el lenguaje ha sido diseñado para alejar a los científicos de la cadena de suministro 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 clave-valor. El almacenamiento de blobs³ es el enfoque de almacenamiento de datos más eficiente en términos de costo ofrecido en la nube, con precios que pueden llegar a ser tan bajos como $20 por TB por mes aproximadamente. Lokad opera directamente sobre Blob Storage (además de discos locales para la caché), no tenemos bases de datos relacionales ni NoSQL, excepto las 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 la Supply Chain Cuantitativa dentro de Lokad. Esto nos permite evitar 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 escalable y eficiente para su cadena de suministro puede parecer una “cuestión técnica” para cadenas de suministro de gran tamaño, los costos de TI de procesar terabytes de datos son reales. Con demasiada frecuencia, el sistema es demasiado caro o demasiado lento, y la fricción termina consumiendo una gran parte de los beneficios previstos generados por el sistema en primer lugar. Los costos de la computación en la nube siguen disminuyendo, pero no espere más del 20% por año, por lo que dejar que el progreso general del hardware informático haga su magia ya no es realmente una opción a menos que esté dispuesto a retrasar su cadena de suministro basada en datos por otra década o más.

También puedes ver el episodio de Lokad TV que produjimos sobre Escalabilidad de terabytes para cadenas de suministro.