Elaborazione snella e scalabile per le supply chain

Joannes Vermorel

Con l’avvento del cloud computing, poco più di un decennio fa, è diventato semplice acquisire risorse di calcolo su richiesta (archiviazione, calcolo, rete) praticamente a qualsiasi scala a patto di essere disposti a pagare per esse. Tuttavia, se è semplice effettuare calcoli su larga scala sulla piattaforma di cloud computing scelta, ciò non implica che ne valga la pena in termini di costo.

Da Lokad, non addebitiamo ai nostri clienti per GB di archiviazione o per CPU all’ora. Invece, il principale fattore determinante per la nostra tariffazione, quando si opta per i nostri servizi professionali, è la complessità della sfida della supply chain da affrontare in primo luogo. Naturalmente, teniamo conto delle risorse di calcolo necessarie per servire i nostri clienti, ma in definitiva, ogni euro che spendiamo su Microsoft Azure - in termini di spesa, siamo diventati un cliente “vero” - è un euro che non possiamo spendere in R&S o nel Supply Chain Scientist che si occupa dell’account.

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

Grafi di esecuzione differenziali. Gli scienziati delle supply chain - come gli altri scienziati dei dati - di solito non scrivono centinaia di righe di codice in una volta prima di testare il loro codice sui dati. Il processo è tipicamente altamente incrementale: aggiungere alcune righe, elaborare i dati, ripetere. Queste iterazioni sono necessarie poiché i risultati ottenuti dai dati guidano spesso ciò che lo scienziato dei dati farà successivamente. Tuttavia, la maggior parte degli strumenti di data science (ad es. NumPy o R) ricalcoleranno tutto da zero ogni volta che lo script viene eseguito nuovamente. Al contrario, Envision esegue un diff sui grafi di esecuzione successivi. A differenza del diff tradizionale che trova le differenze tra i file, il nostro diff trova le differenze tra i grafi di calcolo: il diff identifica i nuovi nodi di calcolo - che devono ancora essere calcolati. Per tutti gli altri nodi, i risultati sono già stati calcolati e vengono “riciclati”. Per lo scienziato delle supply chain, il diff dei grafi di esecuzione sembra una corsa ultraveloce in cui terabyte di dati vengono elaborati in pochi secondi (suggerimento: Lokad non ha elaborato terabyte in pochi secondi, solo le poche centinaia di megabyte che differivano da uno script all’altro).

Tipi di dati orientati al dominio. La previsione probabilistica è un approccio rivoluzionario per la supply chain: consideriamo tutti i futuri possibili, invece di eleggerne uno come se fosse garantito che si verifichi. Purtroppo, l’elaborazione delle distribuzioni di probabilità richiede un’algebra delle distribuzioni che comporta calcoli non banali. Pertanto, abbiamo investito sforzi significativi per ottimizzare questa algebra al fine di eseguire operazioni su larga scala su variabili casuali a costi minimi di CPU. In particolare, teniamo conto in modo aggressivo del fatto che nella supply chain la maggior parte delle variabili casuali rappresenta probabilità in piccole quantità, di solito non più di qualche dozzina di unità². Rispetto agli approcci generici destinati, ad esempio, al calcolo scientifico, l’angolo specifico del dominio offre un aumento 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 es. Scala o Julia) offre enormi capacità per distribuire i calcoli su molti nodi. Tuttavia, ciò significa che ogni riga di codice scritta ha l’opportunità di consumare una quantità arbitrariamente grande di risorse di calcolo. È necessaria molta disciplina ingegneristica per contrastare le esigenze apparentemente sempre crescenti dell’applicazione man mano che i cambiamenti si fanno strada nell’applicazione. Al contrario, Envision adotta una posizione difensiva: il linguaggio è stato creato per scoraggiare gli scienziati delle supply chain dallo scrivere codice che sarebbe estremamente costoso da scalare. Questo spiega perché Envision non ha cicli, ad esempio, poiché è quasi impossibile offrire prestazioni prevedibili al momento della compilazione quando il linguaggio contiene cicli arbitrari.

Solo archiviazione chiave-valore. L’archiviazione di blob³ è l’approccio di archiviazione dei dati più efficiente in termini di costo offerto dal cloud, con prezzi che arrivano a circa $20 al TB al mese. Lokad opera direttamente su Blob Storage (oltre ai dischi locali per la cache), non abbiamo database relazionali o NoSQL - tranne quelli che abbiamo costruito noi stessi sopra Blob Storage. In pratica, il nostro livello di archiviazione è profondamente integrato con Envision, il linguaggio dedicato all’ottimizzazione della Catena di Fornitura Quantitativa all’interno di Lokad. Ciò ci consente di evitare strati di overhead che tradizionalmente esistono all’intersezione tra l’applicazione e il suo livello di accesso ai dati. Invece di ottimizzare al minimo l’attrito ai confini, abbiamo eliminato del tutto questi confini.

Anche se raggiungere un’elaborazione dei dati scalabile ed efficiente per la tua supply chain può sembrare una “tecnicalità” per le catene di fornitura di grandi dimensioni, il costo IT di elaborare terabyte di dati è reale. Troppo spesso il sistema è troppo costoso o troppo lento, e l’attrito finisce per consumare una buona parte dei benefici previsti generati dal sistema in primo luogo. I costi del cloud computing stanno ancora diminuendo, ma non aspettarti molto più del 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 ritardare la tua supply chain basata sui dati di un’altra decade circa.

Puoi anche guardare l’episodio di Lokad TV che abbiamo prodotto su Scalabilità Terabyte per le Catene di Fornitura.