Für das „Internet of Things“ oder kurz IoT werden schwindelerregende Wachstumszahlen prognostiziert. Je nachdem, welcher Prognose man Glauben schenken will, werden im Jahr 2020 bis zu 26 Milliarden „Dinge“ mit dem Internet verbunden sein und komplexe Systeme bilden [1]. All diese Geräte oder Devices werden Daten erheben und zur weiteren Verarbeitung an ein zentrales System übertragen. Gerade bei Systemen, die in sehr kurzen Intervallen Daten übermitteln, oder bei einer sehr großen Anzahl an Devices, ergeben sich Anforderungen an das Backend, die mit klassischen Lösungsansätzen bzw. Architekturen nur schwer zu erfüllen sind.

Wenn es um viele Sensordaten geht, ist ein IoT-System zur Überwachung von Umweltdaten in einer Chemie- oder Industrieanlage sicher ein gutes Beispiel. Dort finden sich sehr schnell Tausende von Sensoren, die in kurzen Zeitintervallen Telemetriedaten wie z. B. die aktuelle Temperatur, Luftfeuchtigkeit, Windstärke, Luftverschmutzung etc. senden.

Um sich die anfallenden Datenmenge zu verdeutlichen, kann die in Tabelle 1 gezeigte Rechnung aufgestellt werden. In Summe ergeben sich hier ~ 86,5 Millionen Ingests pro Tag und ~ 70 MB Datenvolumen pro Stunde, die analysiert und bearbeitet werden müssen. Man kann sich vorstellen, dass klassische Ansätze, wie z. B. das Speichern der Daten in einer relationalen Datenbank mit nachgelagerter Businesslogik, welche die Daten analysiert, sehr schnell an Grenzen stoßen. Microsoft stellt mit Azure Event Hubs nun einen Cloud-Service zur Verfügung, der es sehr einfach macht, die Datenmengen, die bei einer IoT-Lösung anfallen können, entgegenzunehmen und für die weitere Verarbeitung bereitzustellen [2].

Telemetrie Ingest mit Azure Event Hubs

Event Hubs sind ein weiterer Service innerhalb des Azure­ Service Bus, stellen neben Relay, Queue, Topic/Subscription und Notifications das fünfte Familienmitglied dar und wurde für High-scale-Daten-Ingest konzipiert (Abb. 1). Ein Event Hub kann hierbei Daten von bis zu 1 MB (Megabyte!) pro Sekunde aufnehmen und für die weitere Verarbeitung speichern.

Ähnlich wie Topics kann ein so genannter „Event Publisher“, sprich der Sensor, der die Telemetriedaten erzeugt, diese an einen Event Hub übermitteln. „Event Consumer“, d. h. Komponenten, welche die Telemetriedaten verarbeiten, können diese wiederum aus dem Event Hub abrufen. Ähnlich wie bei Topics/Subscription können die Telemetriedaten von mehreren „Event Consumer“ abgerufen werden, und mehrere „Event Publisher“ können die Daten an den Event Hub senden (Abb. 2).

Abb. 1: Aufbau des Azure Service Bus

Abb. 2: Der Event Hub zwischen Publisher und Comsumer

Competing Consumer vs. Partitioned Consumer

Der Hauptunterschied zwischen Event Hubs und Topics ist, dass Event Hubs Telemetriedaten hochskalierbar, mit geringer Latenz und hoher Zuverlässigkeit entgegennehmen und für weitere Verarbeitung vorhalten können. Dies wird im Unterschied zu Topics durch einen anderen konzeptionellen Aufbau erreicht. Service Bus Topics und Service Bus Queues verwenden ein so genanntes „Competing Consumer“-Modell, in dem mehrere Consumer versuchen, von der gleichen Ressource (Subscription oder Queue) zu lesen. Dieser „Wettbewerb“ der Consumer wird vom Server koordiniert und z. B. durch Locks, Dead Letter Queues usw. verwaltet. Im weitesten Sinne kann dieses Konzept mit einem serverseitigen Cursor verglichen werden. Wie alle serverseitigen Konzepte münden diese in Komplexität und Skalierungslimits am Server. So auch bei Service Bus Queues und Topics.

Event Hubs verwenden im Gegensatz dazu ein „Partitioned Consumer“-Modell. Hierbei verwaltet der Client, welche Daten er vom Server, in diesem Fall dem Event Hub, bereits angefordert hat bzw. anfordern möchte. Dies ist im weitesten Sinne mit einem clientseitigen Cursor zu vergleichen. Da sich die Komplexität am Server dadurch verringert, kann dieser auch eine sehr viel größere Menge an Informationen bzw. Telemetrie-Ingests entgegennehmen...