Elaborazione lean scalabile per supply chains

Joannes Vermorel

Con l’avvento del cloud computing, poco più di un decennio fa, è diventato semplice acquisire risorse di calcolo on-demand (storage, compute, network) praticamente a qualsiasi scala purché si sia disposti a pagarle. Tuttavia, sebbene sia semplice effettuare calcoli su larga scala sulla piattaforma di cloud computing di propria scelta, ciò non implica che l’investimento ne valga la pena.

Da Lokad, non addebitiamo ai nostri clienti un costo per GB di storage o per CPU all’ora. Invece, il fattore principale per la nostra tariffazione, quando si opta per i nostri servizi professionali, è la complessità della sfida della supply chain da affrontare. Naturalmente, includiamo nei nostri prezzi anche le risorse di calcolo necessarie per servire i nostri clienti, ma in definitiva, ogni euro che spendiamo su Microsoft Azure - per quanto riguarda la spesa, siamo diventati un cliente aziendale “vero” - è un euro che non possiamo destinare a R&S o al Supply Chain Scientist che si occupa del conto.

Pertanto, la piattaforma software di Lokad è stata progettata secondo il principio guida di essere il più lean possibile in termini di risorse di calcolo¹. La sfida non è elaborare 1TB di dati - cosa semplice - ma elaborare 1TB di dati nel modo più economico possibile. Questo ci ha portato a una serie di decisioni alquanto “insolite” nella progettazione di Lokad.

Differenza nei grafici di esecuzione. I Supply Chain Scientist - come altri data scientist - in genere non scrivono centinaia di righe di codice tutte in una volta prima di testare il loro codice sui dati. Il processo è tipicamente altamente incrementale: aggiungi qualche riga, elabori i dati, risciacqui e ripeti. Queste iterazioni sono necessarie poiché i risultati ottenuti dai dati guidano frequentemente le successive azioni del data scientist. Tuttavia, la maggior parte degli strumenti di data science (es. NumPy o R) ricalcolerà tutto da zero ogni volta che lo script viene ri-eseguito. Al contrario, Envision esegue un diff sui grafici di esecuzione successivi. A differenza del diff tradizionale che trova le differenze tra file, il nostro diff individua le differenze tra grafici di calcolo: il diff identifica i nuovi nodi di calcolo - che devono ancora essere elaborati. Per tutti gli altri nodi, i risultati sono già stati elaborati e vengono invece “riciclati”. Per il Supply Chain Scientist, effettuare il diff dei grafici di esecuzione assomiglia a una corsa ultrarapida in cui terabyte di dati vengono elaborati in pochi secondi (suggerimento: Lokad non ha elaborato terabyte in pochi secondi, ma solo le poche centinaia di megabyte che differivano da uno script all’altro).

Tipi di dati guidati dal dominio. La previsione probabilistica è un approccio rivoluzionario per supply chain: consideriamo tutti i futuri possibili, invece di eleggere un futuro come se fosse garantito. Sfortunatamente, l’elaborazione delle distribuzioni di probabilità richiede un’algebra delle distribuzioni che comporta calcoli non banali. Pertanto, abbiamo investito notevoli sforzi per ottimizzare questa algebra al fine di eseguire operazioni su larga scala su variabili casuali con costi minimi in CPU. In particolare, teniamo conto in maniera aggressiva del fatto che, in ambito supply chain, la maggior parte delle variabili casuali rappresenta probabilità in piccole quantità, tipicamente non più di qualche dozzina di unità². Rispetto agli approcci generici destinati, ad esempio, al calcolo scientifico, l’angolazione specifica del dominio offre un incremento della velocità di calcolo di due ordini di grandezza.

Scalabilità difensiva. La maggior parte dei linguaggi di programmazione destinati all’elaborazione di dati su larga scala (ad esempio Scala o Julia) offrono capacità straordinarie nel distribuire i calcoli su molti nodi. Tuttavia, questo significa che ogni riga di codice scritta ha la possibilità di consumare una quantità arbitrariamente grande di risorse di calcolo. Occorre molta disciplina ingegneristica per contrastare le esigenze apparentemente in costante aumento dell’applicazione man mano che vengono apportate modifiche. Al contrario, Envision adotta un approccio difensivo: il linguaggio è stato creato per dissuadere i Supply Chain Scientist dallo scrivere codice che sarebbe estremamente costoso da scalare. Ciò spiega perché Envision non ha loop, per esempio perché è quasi impossibile offrire prestazioni prevedibili al momento della compilazione quando il linguaggio contiene loop arbitrari.

Solo archiviazione key-value. Il Blob storage³ è l’approccio di archiviazione dati a basso costo più bare-metal offerto dal cloud, con prezzi che possono scendere fino a circa 20$ per TB al mese. Lokad opera direttamente sul Blob Storage (più dischi locali per la cache), non disponiamo di database relazionali o NoSQL - tranne quelli che abbiamo costruito noi stessi su Blob Storage. In pratica, il nostro livello di archiviazione è profondamente integrato con Envision, il linguaggio dedicato all’ottimizzazione della Quantitative Supply Chain all’interno di Lokad. Questo ci consente di evitare gli strati di overhead che tradizionalmente esistono all’intersezione tra l’applicazione e il suo livello di accesso ai dati. Invece di micro-ottimizzare l’attrito ai confini, abbiamo eliminato del tutto tali confini.

Se ottenere un’elaborazione dati lean e scalabile per la tua supply chain può sembrare una “formalità” per supply chains di notevoli dimensioni, il sovraccarico IT derivante dall’elaborazione di terabyte di dati è reale. Troppo spesso il sistema risulta troppo costoso o troppo lento, e l’attrito finisce per erodere gran parte dei benefici previsti dal sistema stesso. I costi del cloud computing sono ancora in diminuzione, ma non aspettarti molto più di un 20% all’anno, quindi lasciare che il progresso generale dell’hardware di calcolo faccia la sua magia non è davvero un’opzione, a meno che tu non sia disposto a posticipare la tua supply chain orientata ai dati di un altro decennio o giù di lì.

Puoi anche dare un’occhiata all’episodio di Lokad TV che abbiamo prodotto su Terabyte Scalability for Supply Chains.