Schlanke skalierbare Verarbeitung für supply chains

Joannes Vermorel

Mit dem Aufkommen von Cloud Computing, vor etwas mehr als einem Jahrzehnt, ist es ganz einfach geworden, Rechenressourcen on-demand (Speicher, Compute, Netzwerk) in nahezu jedem Umfang zu beziehen solange man bereit ist, dafür zu zahlen. Yet, while it is straightforward to perform large scale calculations over the cloud computing platform of your choice, it does not imply that it will be worth the cost.

Bei Lokad berechnen wir unseren Kunden nicht pro GB Speicher oder pro CPU pro Stunde. Stattdessen ist der primäre Treiber für unsere Preisgestaltung, wenn man sich für unsere professionellen Dienstleistungen entscheidet, die Komplexität der supply chain-Herausforderung, die es in erster Linie zu bewältigen gilt. Natürlich beziehen wir in unsere Preise die Rechenressourcen ein, die wir benötigen, um unseren Kunden zu dienen, aber letztlich ist jeder Euro, den wir für Microsoft Azure ausgeben – und damit zu einem „wahren“ Unternehmenskunden geworden sind – ein Euro, den wir nicht in F&E oder in den Supply Chain Scientist reinvestieren können.

Daher wurde die Lokad-Softwareplattform unter dem Leitsatz entworfen, dass wir in Sachen Rechenressourcen so schlank wie möglich agieren sollten¹. Die Herausforderung besteht nicht darin, 1TB Daten zu verarbeiten – was einfach wäre – sondern darin, 1TB Daten so kostengünstig wie möglich zu verarbeiten. Dies führte uns zu einer Reihe etwas „ungewöhnlicher“ Entscheidungen bei der Gestaltung von Lokad.

Diff-Ausführungsgraphen. Supply Chain Scientists – wie andere Datenwissenschaftler – schreiben typischerweise nicht hunderte Zeilen Code auf einmal, bevor sie ihren Code an den Daten testen. Der Prozess verläuft in der Regel sehr schrittweise: ein paar Zeilen hinzufügen, die Daten verarbeiten, dann wiederholen. Diese Iterationen sind notwendig, da die aus den Daten gewonnenen Ergebnisse häufig den nächsten Schritt des Datenwissenschaftlers bestimmen. Dennoch berechnen die meisten Data-Science-Tools (z. B. NumPy oder R) bei jeder Neuausführung des Skripts alles von Grund auf neu. Im Gegensatz dazu führt Envision einen diff über aufeinanderfolgende Ausführungsgraphen durch. Anders als der traditionelle diff, der Unterschiede zwischen Dateien findet, sucht unser diff nach Unterschieden zwischen Berechnungsgraphen: Er identifiziert die neuen Rechenknoten, die noch berechnet werden müssen. Für alle anderen Knoten wurden die Ergebnisse bereits ermittelt und werden stattdessen „recycelt“. Für den Supply Chain Scientist sieht das Diffing der Ausführungsgraphen aus wie ein ultraschneller Durchlauf, bei dem Terabytes an Daten in Sekunden verarbeitet werden (Hinweis: Lokad hat nicht Terabytes in Sekunden verarbeitet, sondern nur die wenigen Hundert Megabytes, die sich von einem Skript zum nächsten unterschieden).

Domänenspezifische Datentypen. Probabilistic forecasting ist ein bahnbrechender Ansatz für supply chain: Betrachten wir alle möglichen Zukünfte, anstatt eine Zukunft auszuwählen, als wäre ihr Eintreten garantiert. Leider erfordert die Verarbeitung von Wahrscheinlichkeitsverteilungen eine Algebra der Verteilungen, die nicht triviale Berechnungen mit sich bringt. Deshalb haben wir erhebliche Anstrengungen unternommen, diese Algebra so zu optimieren, dass groß angelegte Operationen über Zufallsvariablen bei minimalen CPU-Kosten durchgeführt werden können. Insbesondere berücksichtigen wir aggressiv die Tatsache, dass in supply chain die meisten Zufallsvariablen Wahrscheinlichkeiten in geringen Mengen repräsentieren – typischerweise nicht mehr als einige Dutzend Einheiten². Im Vergleich zu generischen Ansätzen, die beispielsweise für wissenschaftliches Rechnen gedacht sind, bietet der domänenspezifische Ansatz einen um zwei Größenordnungen höheren Rechengeschwindigkeitsschub.

Defensive Skalierbarkeit. Die meisten Programmiersprachen, die für groß angelegte Datenverarbeitung vorgesehen sind (z. B. Scala oder Julia), bieten enorme Möglichkeiten, Berechnungen auf viele Knoten zu verteilen. Allerdings bedeutet das, dass jede Codezeile potenziell eine beliebig hohe Menge an Rechenressourcen verbrauchen kann. Es erfordert viel ingenieurtechnische Disziplin, den scheinbar immer weiter wachsenden Anforderungen der Anwendung entgegenzuwirken, während Änderungen in die Anwendung einfließen. Im Gegensatz dazu verfolgt Envision eine defensive Strategie: Die Sprache wurde so gestaltet, dass sie Supply Chain Scientists davon abhält, Code zu schreiben, dessen Skalierung enorm kostspielig wäre. Dies erklärt, warum Envision keine Schleifen enthält, da es nahezu unmöglich ist, zur Kompilierzeit eine vorhersagbare Leistung zu garantieren, wenn die Sprache willkürliche Schleifen enthält.

Nur Key-Value-Speicherung. Blob Storage³ ist der kosteneffizienteste Ansatz zur Datenspeicherung im Bare-Metal-Bereich, der in der Cloud angeboten wird, mit Preisen von etwa 20 $ pro TB und Monat. Lokad arbeitet direkt mit Blob Storage (zuzüglich lokaler Festplatten für den Cache); wir verwenden weder relationale Datenbanken noch NoSQL – abgesehen von denen, die wir selbst auf Blob Storage aufgebaut haben. In der Praxis ist unsere Speicherschicht tief integriert mit Envision, der Sprache, die der Optimierung der die Quantitative Supply Chain innerhalb von Lokad gewidmet ist. Dadurch entfallen die sonst üblichen Overhead-Schichten, die traditionell an der Schnittstelle zwischen Anwendung und Datenzugriffsschicht existieren. Anstatt die Reibungsverluste an den Grenzen zu mikrooptimieren, haben wir diese Grenzen vollständig entfernt.

Obwohl es für umfangreiche supply chains wie eine „technische Kleinigkeit“ erscheinen mag, ist der IT-Overhead, der mit der Verarbeitung von Terabytes an Daten einhergeht, real. Viel zu oft ist das System entweder zu teuer oder zu langsam, und die Reibungsverluste fressen einen erheblichen Teil der ursprünglich beabsichtigten Vorteile des Systems auf. Die Kosten für Cloud Computing sinken zwar weiter, aber man sollte nicht mit mehr als 20% pro Jahr rechnen – sodass es wirklich keine Option mehr ist, den generellen Fortschritt der Hardware ihre Magie entfalten zu lassen, es sei denn, man ist bereit, seine datengetriebene supply chain um ein weiteres Jahrzehnt zu verzögern.

Sie können sich auch die Lokad TV-Episode anschauen, die wir zu Terabyte-Skalierbarkeit für Supply Chains produziert haben.