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.

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 Memory Verbrauch

Es gibt einige Mechanismen, die den Speicherverbrauch teilweise sogar exponentiell nach oben treiben. Hier die Top 3:

1. Lange onWait Zeiten
2. spawn-Methode zum Klonen des Kontextes
3. 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 wie Microservices auf dem Batch Layer nutzen.

4. Batch Layer – Es benötigt eine Queue und Statusinformationen

Batch Layer Jobs laufen stundenlang 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 im 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 mit sehr hohem Aufwand zu ändern. Das resultiert dann entweder in dutzenden Formaten oder in langwierigen Migrationen. Daher sollte das Datenmodell gut abgehangen sein, sobald die Skalierung über eine Erprobungsphase hinaus stattfindet.

Weitere interessante Seiten zum Thema:

• In nur 2 Tagen zur Visualisierung Ihrer Use Cases mit der Cumulocity Widget Entwicklung
• Ihr kostenloser Cumulocity IoT Demozugang durch unsere Partnerschaft mit der Software AG