Envision der etwas technischere Überblick - Software zur Bestandsoptimierung

Der etwas technischere Überblick von Envision












Startseite » Ressourcen » Hier

Envision ist eine anwendungsspezifische Sprache, die speziell für Lieferkettensanalysen entwickelt wurde. Die Syntax hat Ähnlichkeiten zu SQL und Python. Lokad bietet sowohl eine Web-basierte Entwicklungsumgebung, als auch eine Cloud-basierte Ausführungsumgebung. Die Eingabedaten müssen als tabellarische Dateien, entweder flache Textdateien oder Excel-Blätter, in Lokad gehostet vorhanden sein. Die Ausgabe eines Envision-Skripts ist ein Dashboard, bzw. auch mehrere tabellarische Ausgabedateien, die sich aus den Berechnungen des Skripts ergeben.

Die Entstehung eine anwendungsspezifischen Sprache

Envision ist das Ergebnis der langjährigen Erfahrung Lokads mit hunderten Einzelhändlern. Als wir 2008 Lokad gründeten war sie nicht Teil unserer Pläne. Eine neue Programmiersprache zu schaffen bedarf eines hohen Engagements, so benutzten wir zwischen 2008 und 2013 nur gängigen Programmiersprachen. Doch mit der Erfahrungen kamen wir zur Erkenntnis, dass die Entwicklung einer einzigartigen, für Lieferketten kreierte Programmiersprache uns dabei helfen würde, die maßgeschneiderten Aufträge unserer Kunden viel schneller abzuwickeln und auszuführen.

als wir 2014 unsere erste Schritte in diesem Prozess machten und erstmals Envision für manche interne Projekte nutzten, wurde uns klar, dass mit Envision ausgeführte Berechnungen die mit alternativen herkömmlichen Programmiersprachen, sogar bei erstklassigen Softwareentwicklern, systematisch übertrafen. Wir wollen nicht sagen, dass Envision besser als C#/Java/Python/SQL/etc. ist. Im Allgemeinen ist es dennoch so, dass für die äußerst spezifischen Fälle, die bei Lieferketten auftreten, diese Sprachen nicht die Spitze der Unternehmensproduktivität darstellen, auch wenn sie sonst hervorragend funktionieren.

Die Eigenschaften einer durchdachten Sprache

Seien wir Mal ehrlich: die Mehrheit der Programmiersprachen für Unternehmen sind gerade noch gut genug, dass sie als „Ramsch“ bewertet werden können. Als wir Envision entworfen haben, entschlossen wir uns, eine beeindruckende Sprache zu schaffen, die nur durch ihren nicht verhandelbaren Fokus auf Lieferketten eingeschränkt war.

Die Sprache:

  • Keine Schleifen, keine Verzweigungen (ja, das ist ein Feature)
  • Starke Typisierung
  • Funktionsaufrufe ohne Nebenwirkungen
  • Native Code-Kompilierung
  • Ultra-schnelle Ausführung mit spezialisierten Algorithmen

Die Entwicklungsumgebung:

  • Code-Färbung und Autovervollständigung des Codes
  • Schlaue Kompilierung, mit verständlichen Fehlermeldungen
  • Komplette Versionisierung von vergangenen Bearbeitungen und Ausführungen
  • Contextual browsing der Eingabedaten

Was den Programmierstil betrifft, ist Envision von der präzisen Syntax von Python inspiriert, doch auch weiter guten Ideen von anderen Programmiersprachen, wie etwa C#, ließen wir auch mit einfließen.

SQL vs. Envision

Sowohl SQL, als auch Envision besitzen eine hohe Affinität zu Daten. Doch während bei SQL der Fokus auf einem Modell von Abfrage der Transaktionsdaten, mit besonderem Augenmerk auf ACID-Eigenschaften (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) liegt, wird bei Envision nur ein Set von tabellarischen Flachdateien abgefragt. Was die meisten Herausforderungen bei der Lieferkettenoptimierung betrifft, werden keine „Echtzeitdaten“ benötigt, es reicht mit Daten bis zum Vortag. Diese Daten stammen aus der Vergangenheit und sind unveränderlich. Folglich können solche Dateien um einige Größenordnungen schneller (1), als relationale Tabellen verarbeitet werden, da keine INSERT, UPDATE oder DELETE unterstützt werden müssen, sondern nur READ.

In Envision ist es möglich, eine Tabelle mit einer Anweisung, die der SELECT-Anweisung in SQL sehr ähnlich ist, anzuzeigen.
show table "Product List" with Id, Name, Supplier
Erfahrene SQL-Entwickler werden sofort bemerken, dass bei dieser Anweisung der FROM-Teil, der gewöhnlich hinter SELECT erscheint, fehlt. Bei Lieferketten konnten wir bemerken, dass sich die Daten um Produkte drehen (oder SKUs) und dass praktisch alle historischen Daten als Ereignisse, die auch an den Produkten hängen, beschrieben werden können. Daher haben wir, anstatt überall JOINS zu schreiben und dasselbe Muster endlos zu wiederholen, in Envision natürliche JOINs eingebaut. So können Sie zum Beispiel im unteren Skript sehen, wie man eine Liste der meistverkauften Produkte auf Grundlage der historischen Umsatzdaten ohne einen ausdrücklichen JOIN erstellen kann.
LastYearQty = sum(Orders.Quantity) when date > end - 365
show table "Top Sellers" with Id, Name, LastYearQty order by LastYearQty desc
Außerdem haben wir festgestellt, dass bei Lieferketten häufig periodische zeitliche Aggregationen (nach Kalender) auftreten. Manager benötigen tägliche, wöchentliche oder monatliche Zahlen. Obwohl dies grundsätzlich nötig ist, ist es bei SQL sehr schwer, etwas so einfaches wie ein wöchentliches Liniendiagramm anzuzeigen, was in Envision mit zwei kinderleichten Zeilen geschrieben werden kann.
Week.quantity := sum(Orders.Quantity)
show linechart "Weekly quantities sold" with Week.quantity
Zuletzt verstärken die Tools um SQL ein mentales Modell von eine Abfrage nach der anderen. Wir hingegen kamen zum Entschluss, dass ein gutes Dashboard gewöhnlich zur Produktivität eine Kombination von sehr spezifischen Unternehmensindikatoren benötigt. Im Gegensatz hierzu also, bietet Envision-Skripte einen direkten Versuch, ein komplexes Dashboard sofort zu erstellen.

(1) Ja, es ist möglich, Ihre SQL-Datenbank abzustimmen, so dass sie ein Leistungsniveau erreicht, das dem System mit Flatfiles ähnelt. Doch unserer Erfahrung nach, lohnt sich die notwendige Mühe im Vergleich zu den Vorteilen, die an erster Stelle zur Einführung einer SQL-Datenbank geführt haben könnten, nicht.

Excel vs. Envision

Envision ist eine Programmiersprache, dennoch wurde sie so konzipiert, dass sie für fortgeschrittene Excel-User zugänglich ist. Wir schauen nicht auf Excel herab: diese jahrzehntealten tabellarischen Blätter sind schwer zu verbessern. Wir selbst, als Team von Datenwissenschaftlern und Entwicklern, benutzen letzten Endes auch oft Excel, z.B. um schnell die Ergebnisse einer Reihe von Experimenten zu konsolidieren.

Eines der Bereiche, in denen Excel hervorsticht, ist die Fähigkeit zur schnellen Ausführung von Berechnungen über ganze Zeilen oder Spalten, das heißt, Vektorberechnungen, mit der Funktion ausschneiden und einfügen. Vektorberechnungen sind äußerst praktisch, doch die Logik für ausschneiden und einfügen ist es nicht. Gehen wir davon aus, dass wir den Mittelwert für den Preis des Produkts im letzten Jahr, auf Grundlage vergangener Transaktionen, berechnen wollen. Dies könnte mit nur ein paar Zeilen in Envision geschrieben werden.
Orders.UnitPrice = Orders.NetAmount / Orders.Quantity
UnitPrice = mode(Orders.UnitPrice) when date > end - 365
show table "Median Price" with median(UnitPrice)
In der ersten Zeile befindet sich eine Vektorberechnung, die dem Einfügen einer neuen Spalte, namens UnitPrice, in die Tabelle Orders entspricht. In der zweiten Zeile befindet sich eine weitere Vektorberechnung, bei der der Modalwert mode (häufigste Wert) für jedes Produkt berechnet wird. Wie bei Excel, ist es auch mit Envision sehr klar, wie man Zwischenrechnungen einfügen und sie danach zusammenführen kann.

Envision legt auch ein besonderes Augenmerkt auf kompakte Dashboards, ähnlich zu den synthetischen Excel-Blättern. Jede show-Anweisung in Envision definiert ein Element, das im Dashboard angezeigt wird. Dieses Element wird so ähnlich wie ein Excel-Gitternetz ausgerichtet.
show label "Hello World" a1d1 tomato
show table "Product Lines" a2b2 royalblue with sum(1)
show table "Order Lines" c2b2 darkorange with sum(Orders.1)
Das obere Skript definiert drei Elemente, die entsprechend in A1:D1, A2:B2, und C2:D2 platziert sind, in Anlehnung an die Konvention in Excel, Buchstaben für Spalten und Nummern für Zeilen zu benutzen.

Keine Schleifen, keine Verzweigungen, und mehr

Envision bietet eine äußerst funktionale Syntax. Wir haben keine Schleifen, Verzweigungen oder Null-Werte und falls Sie sich wundern, ist Envision keine Turin-vollständige Sprache. In der Praxis werden diese Features nicht ausgelassen. Stattdessen bietet Envision eingebaute Konstrukte, um dasselbe Ergebnis, aber mit weniger Aufwand, zu erreichen. Dadurch dass solche Features in Envision nicht vorhanden sind, werden nicht nur alle Probleme, die schwer zu debuggen sind, aus den Weg geräumt, sondern auch die Produktivität enorm erhöht.

Versuchen wir das gesamte Umsatzvolumen der 10 besten Produkte über die wöchentlichen Daten dieses Jahres graphisch darzustellen und diese wöchentlichen Gesamtwerte mit denen derselben 10 Güter im letzten Jahr zu vergleichen. Dies kann man mit den wenigen nachstehenden Zeilen erreichen.
Volume = sum(Orders.Amount) when date > end - 365
Week.amt := sum(Orders.Amount) where rank(Volume) <= 10
show linechart "Top 10. This Year vs Last Year." a1f3 tomato with 
  Week.amt as "Sold this year{$}"
  Week.amt[-52] as "Sold last year{$}"
Envision ist außerdem blitzschnell. Wir haben es nicht nur geschafft, die bereichsspezifischen Algorithmen (2) zu nutzen, außerdem cachen wir (fast) jeden Berechnungsknoten unserer Envision-Skripte. Folglich werden nur die Berechnungsknoten der veränderten Graphen neu berechnet, wenn leicht modifizierte Skripte erneut ausgeführt werden. In der Praxis wollen Sie wohl kaum zu den trägen SQL-Abfragen zurück, wenn Sie einmal ausprobiert haben, wie es ist, 20GB Daten innerhalb von 5 Sekunden zu verarbeiten.

(2) Wir nutzen einen Bucketsort-Algorithmus, der oft 500mal schneller als die gängigen Quicksort-Algorithmen ist. Tatsächlich ist es möglich, trotz der theoretisch optimalen Grenze von Sortieralgorithmen bei O(n.log(n)), ein Sortieralgorithmus 500mal zu beschleunigen, wenn die Situation vorteilhaft ist (beispielsweise: Sortierung nach Datum). Bei Lieferketten sind die Situationen äußerst vorteilhaft, was dies betrifft.