Vor zwei Monaten haben wir ein großes neues Feature für Lokad eingeführt: unsere erste Echtzeit-Datenexploration. Dieses Feature trägt den Codenamen Dashboard-Slicing und erforderte eine vollständige Überarbeitung des Low-Level-Datenverarbeitungs-Backends, das Envision antreibt. Mit Dashboard-Slices wird jedes Dashboard zu einem vollständigen Wörterbuch von Dashboard-Ansichten, die in Echtzeit mit einer Suchleiste erkundet werden können.

Zum Beispiel ist es jetzt möglich, durch Slicing eines Dashboards, das als Produktinspektor gedacht ist und alle Informationen über ein Produkt zusammenführt - einschließlich probabilistischer Nachfrage- und Durchlaufzeit-Prognosen - in Echtzeit von einem Produkt zum nächsten zu wechseln.

Envision-Dashboard mit Slices

Derzeit unterstützt Lokad bis zu 200.000 Slices (auch Dashboard-Ansichten genannt), die für ein einzelnes Dashboard erstellt werden können. Diese Slices können in Echtzeit über den Selektor angezeigt werden, der über eine Echtzeitsuchfunktion verfügt, um die Exploration der Daten zu erleichtern. Im Gegensatz zu Business Intelligence (BI)-Tools können diese Slices hochkomplexe Berechnungen enthalten, nicht nur Slice-and-Dice über einen OLAP-Würfel.

Suchfeld für Slices im Envision-Dashboard

Wenn es um Datenverarbeitung und Berichterstattung geht, gibt es in der Regel zwei Lager: Online-Verarbeitung und Stapelverarbeitung. Bei der Online-Verarbeitung wird ein Datenfeed verwendet, und es wird in der Regel erwartet, dass alles, was vom System angezeigt wird, immer aktuell ist: Das System hinkt der Realität nicht mehr als ein paar Minuten, manchmal sogar nur ein paar Sekunden, hinterher. OLAP-Würfel und die meisten als Business Intelligence bezeichneten Tools fallen in diese Kategorie. Während Echtzeit-1 Analysen sehr wünschenswert sind, nicht nur aus geschäftlicher Sicht (aktuelle Daten sind besser als veraltete Daten), sondern auch aus Sicht des Endbenutzers (Performance ist ein Feature), sind sie auch mit strengen Einschränkungen verbunden. Einfach ausgedrückt, es ist äußerst schwierig, intelligente Analysen in Echtzeit zu liefern2. Als Ergebnis kommen alle Online-Analyse-Systeme mit schweren Einschränkungen hinsichtlich der Art von Analysen, die vom System durchgeführt werden können.

Auf der anderen Seite wird die Stapelverarbeitung in der Regel in regelmäßigen Abständen (z.B. täglich) ausgeführt, während alle historischen Daten (oder ein großer Teil davon) eingegeben werden. Die Aktualität der Ergebnisse ist durch die Zeitplanfrequenz begrenzt: Eine tägliche Stapelverarbeitung liefert immer Ergebnisse, die die Situation von gestern widerspiegeln, nicht die Situation von heute. Da alle Daten von Anfang an verfügbar sind, eignet sich die Stapelverarbeitung ideal für die Durchführung aller Arten von Berechnungsoptimierungen, die die gesamte Rechenleistung des Prozesses erheblich steigern können. Als Ergebnis ist es durch die Stapelverarbeitung möglich, ganze Klassen von komplexen Berechnungen auszuführen, die bei der Betrachtung der Online-Verarbeitung außer Reichweite bleiben. Auch aus IT-Sicht ist die Stapelverarbeitung sowohl bei der Implementierung als auch beim Betrieb 3 in der Regel viel einfacher. Der Hauptnachteil der Stapelverarbeitung ist die Verzögerung, die durch die stapelverarbeitete Natur des Prozesses entsteht.

Als Softwareplattform gehört Lokad definitiv zum Lager der Stapelverarbeitung. Während die Optimierung der Quantitativen Lieferkette ein hohes Maß an Reaktionsfähigkeit erfordert, gibt es viele Entscheidungen, die keine sofortige Reaktionsfähigkeit erfordern. Zum Beispiel die Entscheidung, ob ein zusätzliches Palettenprodukt hergestellt werden soll oder ob es an der Zeit ist, den Preis zu senken, um einen Bestand zu liquidieren. Bei diesen Entscheidungen geht es in erster Linie darum, die bestmögliche Entscheidung zu treffen, und wenn sich diese Entscheidung durch eine zusätzliche Rechenstunde messbar verbessern lässt, ist es nahezu garantiert, dass diese eine zusätzliche Rechenstunde eine gute Investition sein wird 4.

Daher ist Envision aus einer Stapelverarbeitungsperspektive konzipiert. Wir haben einige Tricks auf Lager, um Envision auch bei Terabyte an Daten sehr schnell zu machen. Aber in diesem Maßstab geht es darum, Ergebnisse innerhalb von Minuten zu erhalten, nicht unter einer Sekunde. Tatsächlich ist es aufgrund des hochgradig verteilten Charakters des Envision-Berechnungsmodells eine Herausforderung für Lokad, die Ausführung eines beliebigen Envision-Skripts in weniger als 5 Sekunden abzuschließen, selbst wenn nur wenige Megabyte an Daten beteiligt sind. Je verteilter ein System ist, desto mehr interne Trägheit gibt es, um alle Teile zu synchronisieren. Mehr Skalierbarkeit ist der Feind von geringerer Latenz.

Vor einigen Jahren haben wir das Konzept der Eingabeformulare in Envision eingeführt: eine Funktion, mit der Sie ein konfigurierbares Formular auf dem Dashboard hinzufügen können, das als Eingabe von dem Envision-Skript zugänglich wird. Durch diese Funktion war es zum Beispiel einfach, ein Dashboard als Produktinspektor zu gestalten, das alle relevanten Informationen zu den angegebenen Produkten anzeigt. Leider musste das Envision-Skript erneut ausgeführt werden, um das Dashboard mit dem neu eingegebenen Formularwert abzustimmen, was zu Sekunden Verzögerung führte, um die aktualisierten Ergebnisse zu erhalten; eine Dauer, die für die Datenexploration inakzeptabel lang war.

Die Dashboard-Schnitte (schauen Sie sich unsere technische Dokumentation an) stellen unseren Versuch dar, das Beste aus beiden Welten zu vereinen: Online- und Stapelverarbeitung. Der Trick besteht darin, dass Lokad jetzt in Stapelverarbeitung eine große Anzahl von Schnitten berechnen kann (jeder Schnitt kann ein Produkt, einen Standort, ein Szenario oder eine Kombination all dieser Dinge widerspiegeln) und es Ihnen ermöglicht, von einem Schnitt zum anderen in Echtzeit zu wechseln, was möglich ist, weil alles vorberechnet wurde. Natürlich ist die Vorberechnung einer großen Anzahl von Schnitten rechnerisch aufwändiger, aber nicht so sehr, wie man vielleicht denkt. Es ist in der Regel kostengünstiger für Lokad, 10.000 Schnitte auf einmal zu berechnen, anstatt 100 unabhängige Durchläufe durchzuführen, wobei jeder Durchlauf einem einzelnen Schnitt gewidmet ist.

Durch die Schnitte erhält Lokad Business-Intelligence-mit-Steroid-Fähigkeiten: Es ist nicht nur möglich, viele verschiedene Ansichten (z.B. Produkte, Standorte, Zeiträume) in Echtzeit zu erkunden, sondern auch ohne die üblichen Einschränkungen von Online-Verarbeitungsarchitekturen.


  1. In einem verteilten System gibt es keine “Echtzeit”. Die Lichtgeschwindigkeit selbst setzt harte Grenzen für den Grad der Synchronisation eines Systems, das sich über mehrere Kontinente erstreckt. Daher ist dieser Begriff etwas missbräuchlich. Wenn die Gesamtlatenz jedoch unter einer Sekunde liegt, ist es in der Regel akzeptabel, eine Datenverarbeitungsanwendung als “Echtzeit” zu bezeichnen. ↩︎

  2. Selbst fortschrittliche Echtzeit-Datenverarbeitungssysteme wie diejenigen, die für autonomes Fahren verwendet werden, vermeiden sorgfältig jeglichen Lernvorgang bei der Echtzeitverarbeitung. Alle maschinellen Lernmodelle werden vorberechnet und statisch verwendet. ↩︎

  3. Die typische Implementierung eines Stapelprozesses besteht darin, Flachdateien zu verschieben, was eine grundlegende Funktion ist, die von nahezu jedem System heutzutage unterstützt wird. Aus betrieblicher Sicht löst in der Regel eine einfache Wiederholungsrichtlinie das Problem, wenn ein Komponente des Stapelprozesses vorübergehend nicht verfügbar ist. Im Gegensatz dazu verhalten sich Online-Systeme schlecht, wenn eine Komponente ausfällt. ↩︎

  4. Zum aktuellen Zeitpunkt kostet eine Stunde Rechenzeit auf einer modernen CPU in der Regel weniger als 0,02 US-Dollar, wenn man die Pay-as-you-go-Option der dominierenden Cloud-Computing-Plattformen verwendet. Daher macht es Sinn, diese eine Stunde Rechenzeit zu investieren, solange der Nutzen, der durch eine einzige bessere Entscheidung in der Lieferkette generiert wird, deutlich mehr als 0,02 US-Dollar wert ist. ↩︎