Überblick über den Use Case

Zunächst möchten wir Dir einen kurzen Überblick über den Use Case geben. Unser Anwendungsfall heißt CoffAI und der Name ist Programm, denn wir haben unsere Leidenschaft zur Artificial Intelligence (AI) mit dem vermutlich meist genutzten Gegenstand in jedem IT Büro, der Kaffeemaschine, kombiniert.

Die Kaffeemaschine von esentri produziert täglich nicht nur hervorragenden Kaffee, sondern ist zusätzlich mit einem Vibrationssensor ausgestattet, der alle Vibrationen und Umgebungsdaten wie Temperatur und Feuchtigkeit misst.

Anhand von diesen Daten können wir nicht nur die Produktauswahl des jeweiligen Kaffees bestimmen, sondern auch zusätzlich eine Statistik führen. Die Historie geht dabei inzwischen bereits mehr als 18 Monate zurück, in der wir jeden einzelnen Kaffee der 9000 Kaffeeobservationen vorhergesagt und aufgezeichnet haben.

Ein besonderes Highlight ist dabei immer, die Vibrationsdaten des gerade erzeugten Kaffees live mitzuverfolgen. Doch wie macht man die gerade erzeugten Daten am besten für eine Echtzeitanzeige verfügbar?

Dieser Frage werden wir im anschließenden Absatz auf den Grund gehen.

2 Fälle, um ein Problem zu lösen

Die Daten des Vibrationssensors durchlaufen einen AWS Kinesis-Stream, um anschließend durch eine Lambdafunktion klassifiziert in eine DynamoDB Datenbank geschrieben zu werden. Zusätzlich werden die Rohdaten direkt von dem Sensor in eine DynamoDB Datenbank geschrieben. Den Vorgang hierzu kannst Du auf dem Beitrag im Detail nachverfolgen.

Nun gibt es zwei Möglichkeiten auf diese Daten zuzugreifen, entweder wir nutzen die Daten aus der Datenbank (Fall 1) oder wir greifen direkt auf den Kinesis-Stream (Fall 2) zu. Die Frage, die uns dabei umgetrieben hat, war vor allem:

Wie viel reaktiver ist denn eigentlich ein direkter Zugriff auf den Datenstream im Vergleich zum Zugriff auf die mit dem Datenstream gefüllte Datenbank? Lohnt sich der direkte Zugriff auf den Datenstream oder reden wir hier von Millisekunden?

Um diese Frage zu beantworten, haben wir beide Fälle implementiert und stellen Dir nun die Ergebnisse hierzu vor.

Die beiden Architekturen im Vergleich

Fall 1: Architektur mit Datenbankabfrage

Die erste Herausforderung, die wir in Fall 1 zu bewältigen haben, ist, die Live-Anzeige erst dann zu starten, wenn neue Daten in die Datenbank geschrieben werden. Dies führt aber zu einer unnötig hohen Abfragerate auf der DynamoDB und verursacht durch die kontinuierlichen Abfragen dabei sogar noch zusätzliche Kosten.

Ein weiterer Aspekt, der in diese Herausforderung noch eingeht, ist die Frage, welchen Datenpunkt das Dashboard zuletzt angezeigt hatte und welche Datenpunkte sind nun neu dazugekommen.

Ein weiteres Problem, das die Datenbankabfrage zur Folge hat, ist die Latenz, die zwischen dem Kinesis-Stream und der DynamoDB entsteht, da die Daten erst in eine DynamoDB geschrieben werden müssen und anschließend erst eine Abfrage durchgeführt werden kann.

Fall 2: Architektur mit direkter Streamabfrage

Fall 2 dagegen ist eine native Anwendungsmöglichkeit des Kinesis-Streams. Denn wir können mit Python in Form eines Kinesis-Consumers direkt auf diesen zugreifen. Dabei fangen wir die Daten direkt ab und bringen diese nach einer Transformation durch eine Pythonfunktion sofort auf die Live-Anzeige.

Das bedeutet, die Daten stehen dem Live-Dashboard in der Sekunde zur Verfügung, in der sie in den Stream geschrieben wurden. Ein weiterer Vorteil, der durch den Kinesis-Stream möglich wird, ist die Funktion alle neuen Daten seit der letzten Abfrage abzurufen, weshalb wir nie einen Datenpunkt verlieren und immer bei dem letzten bereits verarbeiteten Input starten können.

Das Ergebnis dieser zwei Methoden ist in der nachfolgenden Live-Aufnahme im Vergleich zu sehen, wobei wir auf der unteren Hälfte Fall 1 und auf der oberen Hälfte Fall 2 abbilden.

Das Video hat die Vorteile des zweiten Falles eindeutig untermauert, so startete die Live-Aufzeichnung der Vibrationsdaten deutlich früher und hat bereits die ersten Daten dargestellt, bevor die Anzeige aus dem anderen Ansatz überhaupt gestartet ist.

Der zweite Vorteil ist, dass die anfänglichen Daten auch komplett zur Verfügung stehen, so ist in dem Video klar zu erkennen, dass die ersten Datenpunkte von dem DynamoDB-Dashboard gar nicht mehr angezeigt wurden, da diese Daten zu lange gebraucht haben, um noch relevant zu sein.

Der letzte Punkt ist in dem Video nicht zu erkennen: die Kostenkomponente.

Für den ersten Fall verursachen wir dauerhaft Kosten, unabhängig davon, ob Daten vorhanden sind oder nicht. Dies geschieht allein auf dem Grundsatz, dass wir die DynamoDB kontinuierlich nach neuen Daten abfragen, auch wenn keine verfügbar sind.

Im Gegensatz hierzu verursacht der zweite Fall nur dann Kosten, wenn auch tatsächlich Daten zur Verfügung stehen, da der Kinesis-Stream durch einen Consumer überwacht wird, der bei neuen Daten in dem Stream das Signal gibt, die Live-Anzeige zu starten und die Daten zu verarbeiten. Das bedeutet, bereits der erste Datenpunkt geht in die Live-Anzeige mit ein und wir haben hierbei keinen Informationsverlust.

Fazit: Das braucht es für eine Echtzeit-Architektur

Die Verwendung des Kinesis-Streams als Datengrundlage für die Live-Anzeige ist nicht nur aus unternehmerischer Sicht sinnvoll, sondern bietet auch einen signifikanten Mehrwert in der Anwendung. Insgesamt konnte mit diesem Ansatz die Reaktivität der Live-Anzeige optimiert werden und damit auch das Nutzererlebnis deutlich gesteigert werden.

Für den Nutzer ist die Veränderung dahingehend optimiert worden, dass er direkt nach der Auswahl des gewünschten Kaffees bereits das Real-time-Dashboard mitverfolgen kann und keine ein- bis zweisekündige Verzögerung erfahren hat.

Für viele Use Cases ist es essenziell Daten tatsächlich in Echtzeit zu verwenden und darstellen.
Daher ist unsere Empfehlung ganz klar: Nutze für Real-time-Anzeigen, wenn möglich immer die Rohdaten direkt aus dem Stream, um eine geringere Latenz zu ermöglichen und somit sofort alle Daten verfügbar zu machen.

Real-time Analytics & die Anwendung in Unternehmen

In diesem Use Case haben wir 2 Architekturen gegenübergestellt, um zu überprüfen, wie viel Echtzeit wirklich möglich ist. Das Thema Real-time Analytics gewinnt für Unternehmen zunehmend an Bedeutung. Tagtäglich müssen Entscheidungen getroffen werden und benötigen verlässliche Daten, die oftmals eben auch in Echtzeit vorliegen müssen.

In einem unserer weiteren Artikel haben wir uns angeschaut, warum Unternehmen Real-time Analytics benötigen und wie die zugehörige Architektur aussehen kann. Hier findest du den Artikel.

Nimm gerne Kontakt zu uns auf!

Dieser Use Case zeigt, welche Möglichkeiten sich für eine Architektur im Kontext von Echtzeitdaten eignen. Der zweite Fall ist nicht nur performanter, sondern ist auch unter ökonomischen Gesichtspunkten wertvoller.

Wenn Du Fragen hast, melde Dich gerne bei mir. Ich stehe Dir gerne zur Verfügung.

Simon Kneller, Senior Consultant, Industrial Analytics & IoT

Simon Kneller
Lead Industrial Analytics & IoT