Eigentlich hätte ich gestern auf der buildingIoT Konferenz meinen Talk zu “IoT Analytics – Stream und Batch-Processing” gehalten. Nun ja, es sollte nicht sein. Daher habe ich meine Takeaways hier zusammengefasst.
In IoT Use Cases werden oft Daten verarbeitet. Ab einer gewissen Menge an Daten gibt es einen nicht mehr zu erfüllenden Zielkonflikt zwischen Real-Time-Anforderungen und der Genauigkeit. Dieser lässt sich durch die Lambda-Architektur auflösen und in zwei Layern getrennt erfüllen. In SaaS Plattformen, wie der CumulocityIoT, stehen dazu oft Mittel wie Complex Event Processing (CEP) Engines und REST-Schnittstellen zur Verfügung. Im Falle der CumulocityIoT Plattform läuft die Stream Verarbeitung über die CEP Engine Apama. Es gibt jedoch ein paar Dinge für eine stabile und effektive Verarbeitung zu beachten. Daher hier meine 6 Tipps zu IoT Analytics.
1. Daten komplett in-memory anstatt über Datenbanken und Schnittstellen
Bei der Verarbeitung von Daten sollten Zugriffe über HTTP Schnittstellen oder die Datenbank reduziert werden. Diese Zugriffe sind relativ zeitintensiv und blockieren die Verarbeitung. Solche Calls sollten nur bei der Initialisierung oder gelegentlich genutzt werden. Die Datenhaltung sollte besser komplett in-memory erfolgen.
2. Zu hoher Memeory Verbrauch
Es gibt einige Mechanismen, die den Speicherverbrauch nach oben treiben. Teilweise sogar exponentiell. Hier die Top 3:
- lange onWait Zeiten
- spawn-Methode, zum Klonen des Kontextes.
- Modularisierung und Verkettung von Regeln
3. Mind the Gap – Vorbereitung von Up- und Downtimes
Durch Updates, Deployments oder ungeplante Downtimes entstehen Lücken in der Verarbeitung. Diese müssen durch andere Tools im Batch Layer aufgefangen werden. Zudem kann es sein, dass durch neue Parameter oder Fehler eine Neuberechnung notwendig wird. Auch dazu sollte man Tools auf dem Batch Layer, wie Microservices, nutzen.
4. Batch Layer – Es benötigt eine Queue und Statusinformationen
Batch Layer Jobs laufen Stunden und in der Regel parallel. Durch die hohe Last wird das System vermutlich überfordert. Dadurch entstehen Lücken bzw. unvollständige Daten. Wenn dann auch noch Bugs dazu kommen, wird das Chaos perfekt. Es sollte also eine gute Job-Steuerung verwendet werden, um Queues zu verwalten und Status zu erhalten.
5. Tracebility – Wer hat hier eigentlich wann was berechnet?
Hat man nun mehrere Berechnungsalgorithmen in unterschiedlichen Versionen über die Daten geschickt, ist in Zweifelsfall nicht mehr nachzuvollziehen, wodurch die Daten berechnet wurden. Daher sollten auch Metadaten zu den berechneten Daten gespeichert werden. Das erhöht zwar den Gesamtstorage, ist aber im Endeffekt effizienter.
6. Datenformate ändern
Prinzipiell ist es gut, schnell vom Prototypen in die Realität zu kommen. In Hinsicht auf die Datenformate ist es jedoch zu empfehlen, die Skalierungsstufen mit Bedacht zu wählen. Denn die Datenformate, sofern sie nur per REST o.ä. zugänglich sind, sind nur sehr Aufwändig zu ändern. Das resultiert dann entweder in dutzenden Formaten oder in langwierigen Migrationen. Daher sollte, sobald die Skalierung über eine Erprobungsphase hinaus stattfindet, das Datenmodell gut abgehangen sein.