Streaming von Echtzeit-Daten in Azure Synapse Analytics

IoT in Azure

Auch Microsoft hat es verstanden: Das Internet der Dinge ist der Hit! Mehr und mehr Organisationen schaffen sich kleine Geräte an, verbinden diese mehr oder weniger direkt mit dem Internet, und messen und erfassen damit alle möglichen Informationen, die das Gerät dann mehr oder weniger in Echtzeit in die Cloud sendet. So ein kleines Helferlein ist in allen aktuellen Stromzählern eingebaut, fährt mit Lieferfahrzeugen durch die Gegend und meldet die Position, und sitzt an so mancher Fertigungsmaschine dran und passt etwa auf Temperatur und Vibrationen auf.

Der ideale Ort, um diese Datenmengen dann zu sammeln, zu speichern und langfristig zu analysieren (womöglich gleich mit Künstlicher Intelligenz oder Machine Learning) ist natürlich ein enorm flexibler Big Data Cluster, der spielend mit den Datenmengen klar kommt und dann auch noch alle Auswertungen unterstützt, und da fällt einem in der Microsoft-Welt derzeit gleich Azure Synapse Analytics ein. (NOCH besser dafür geeignet wäre natürlich der Azure Data Explorer, früher bekannt als Kusto, aber um den soll es heute einmal nicht gehen).

Azure Synapse Analytics und IoT-Daten

Synapse Analytics wird von Microsoft derzeit intensiv beworben, als eine Plattform, die alle Funktionen, die man im Bereich Data + AI benötigt, gleich beinhaltet, so dass man für jede neue Daten-Herausforderung nicht wieder gleich ein neues Daten-Silo aufbauen muss. Was heißt das für Streaming-Daten in Echtzeit? Dazu hat mich eine Folie aus dem aktuell von Microsoft kostenlos angebotenen Workshop “Analytics in a Day” neugierig gemacht:

Azure Event Hub oder Azure IoT Hub?

Die Folie oben sieht ja sehr verlockend aus! Den Azure Event Hub oder den Azure IoT Hub sollte eigentlich jeder kennen, der mit Event-Daten im Azure-Umfeld arbeitet, denn sie sind quasi “eierlegende Wollmilchsäue”, die eigentlich in keiner IoT-Anwendung fehlen. Kleine Warnung dabei: der IoT Hub ist sehr viel einfacher zu bedienen und zu verwenden, und er enthält auch eine Riesenmenge von Features, die der Event Hub nicht hat. Beliebtestes Beispiel: der IoT Hub kann auch Meldungen zurück zum Gerät senden und nicht nur empfangen! Dafür aber ist er ein ganzes Ende teurer; irgendwie auch logisch. Aus unserer Erfahrung versuchen Kunden daher immer, so weit wie möglich mit dem Event Hub auszukommen, um Geld zu sparen, oder sie beschränken sich auf 8.000 Nachrichten am Tag, die maximal 0,5 KB groß sind: dann kann man nämlich den “Free”-Tarif für den IoT Hub nutzen (das geht leider nur einmal in jeder Azure Subscription). Aber macht ja nichts, ob Event Hub oder IoT Hub, denn beide können offenbar in Synapse hinein ihre Streaming-Daten “abladen”, wie es die Grafik oben zeigt. Für unser kleines Beispiel nutzen wir den IoT Hub!

Es geht nicht ohne: Stream Analytics

Aus der Grafik am Anfang geht es nicht so eindeutig hervor, aber wenn man sich etwas mit den IoT-Werkzeugen in Azure auskennt, ahnt man schon: jetzt benötigt man einen Stream Analytics Job! Stream Analytics ist eine von der Funktion her sehr mächtige Komponente in Azure, die das “Complex Event Processing” beherrscht. Das bedeutet, dass man eine Unmenge an Daten in sie hinein-streamen kann, und sie kann diese verarbeiten, während sie “durchfließen”, und dann Filter darauf realisieren, ID-Felder durch sprechende Namen ersetzen etc. pp, und dann wieder an eine Unmenge von verschiedenen “Outputs” weiterreichen. Das wirklich tolle an Stream Analytics ist aber, dass es die “Verarbeitung” der Streamingdaten mit der guten, alten Abfragesprache SQL durchführt, so dass diejenigen, die diese Sprache mal erlernt haben, so schöne Dinge wiederfinden wie SELECT, GROUP BY, HAVING, WHERE und vieles mehr.

Die Hauptfunktion von Stream Analytics ist aber auf jeden Fall die Aggregation, also das Bilden eines Aggregatwerts über den Datenstrom, der dort hindurchfließt. Simples Beispiel: “lies die Daten mit, die von einem Gerät alle zwei Sekunden kommen, filtere mit irgendeiner Bedingung auf gültige Datensätze und schreib dann einmal in der Minute den maximalen Wert, den minimalen Wert und einen Durchschnitt in ein “Output” weg”. In der Grafik oben kann man einen extrem einfachen Stream Analytics Job beim Laufen zusehen, der aber nichts aggregiert, sondern die Events fast 1:1 wieder herausschickt. Immerhin filtert er, d.h. er sendet nur die Sätze weiter, wo die das Feld Temperatur höher ist als der Wert 27. Das sieht man auch sehr schön an der “Monitoring”-Grafik links unter dem SQL-Statement: etwa die Hälfte aller “Input Events” genügen der Bedingung nicht, und werden daher kein “Output Event”.

Sehr wichtig, obwohl nur im Hintergrund: die Blob Storage

Wenn man diese Streaming-Daten nun in seinen Azure Synapse “dedicated SQL Pool” leiten will, dann gibt es dafür eine sehr wichtige Vorbedingung, die aber auch ohne Synapse total sinnvoll ist, nämlich: eine Ausgabe in eine Azure Blob Storage. Dort werden die Daten im Prinzip einfach nur genauso abgelegt, wie sie hineingekommen sind; jedenfalls dann, wenn man im SQL-Statement in der Stream Analytics Query nichts damit anstellt. Das sieht dann so aus, wie man es im letzten Screenshot schon erahnen konnte:

				
					SELECT *
INTO   blobstorageoutput
FROM   iothubinput
HAVING temperature > 27  
				
			

..und wie sehen dann die Daten in der Blob Storage aus? Das kann man im Azure-Portal sehr schon betrachten:

Da eine Blob Storage ja so gut wie nichts kostet, spricht eigentlich wenig dagegen, dauerhaft alle diese Daten hier zu speichern, denn dann kann man auch Monate später noch in die historischen Daten zurückgehen und sie nach Auffälligkeiten durchsuchen und so weiter. Allerdings wäre das eben bedeutend einfacher und viel schneller, wenn wir die Daten gleich in einer Datenbanktabelle in Azure Synapse Analytics hätten, und das geht nur, wenn man auch einen solchen “Blob Storage Output” eingerichtet hat!

Und jetzt das Ganze in den Datenbankserver, bitte: Synapse als Ziel

Als letzten und entscheidenden Schritt müssen wir jetzt diesem “Input”, der in Stream Analytics hineinströmt, einen zweiten Output neben der Blob Storage hinzufügen, der eben auf den dezidierten SQL Pool unseres Synapse-Servers zeigt. Das geht relativ einfach:

Hier sieht man einmal, welche möglichen Outputs es Anfang 2021 gibt, und wer zum Beispiel die Daten einfach in Echtzeit visuell betrachten möchte, der nimmt einfach einen Power BI-Output, wie wir schon mehrfach beschrieben haben. Aber wir wollen nach Synapse! Hier wird noch darauf hingewiesen, dass das Produkt mal “SQL DW” hieß, zu Recht, denn in diesem Teil hat sich da nicht besonders viel verändert. Das sind die genauen Einstellungen, die man benötigt:

Achtung, bitte genau einhalten, denn hier kann einiges schiefgehen; so versteht dieser Output zum Beispiel bei den Ziel-Tabellen keinen Schema-Namen davor, und man muss unbedingt sicherstellen, dass der verwendete Nutzer auch vollen Zugriff auf die Tabelle hat. Wichtig ist auch, dass die Spaltennamen und Datentypen der Tabelle genau zu dem passen, was Euer IoT-Gerät so sendet! Das ist gar nicht so einfach, aber man kann vieles wirklich schon in Stream Analytics konvertieren, nämlich in der zweiten SQL-Abfrage im “Query”-Feld des Jobs. Das heißt, dass man danach, um sowohl die Blob Storage also auch die Synapse-Datenbank zu füllen, zwei SELECT-Statements hintereinander hat, was etwa so aussehen kann:

				
					SELECT TRY_CAST([messageId] AS BIGINT) AS messageid
	  ,TRY_CAST([deviceId] AS NVARCHAR(max)) AS deviceid
	  ,TRY_CAST(temperature AS FLOAT) AS temperature
	  ,TRY_CAST([humidity] AS FLOAT) AS humidity
	  ,TRY_CAST([EventProcessedUtcTime] AS DATETIME) AS eventprocessedutctime
	  ,TRY_CAST([PartitionId] AS BIGINT) AS partitionid
	  ,TRY_CAST([EventEnqueuedUtcTime] AS DATETIME) AS eventenqueuedutctime
INTO   synapseoutput
FROM   IoTHubInput
HAVING Temperature > 27

SELECT *
INTO   blobstorageoutput
FROM   IoTHubInput
HAVING Temperature > 27
				
			

Dabei ist das TRY_CAST ziemlich wichtig, denn dass die Datentypen auch in die Zielspalten passen, sollte man am besten schon in Stream Analytics klarstellen! Und wenn das dann alles erfolgreich war, dann laufen die Daten direkt in Echtzeit in Synapse ein, und zwar – wie Microsoft versichert – mit Durchsatzraten von bis zu 200 MB/s, 750 GB in der Stunde! Hier zum Beweis eine Abfrage auf die Zieltabelle im Azure Synapse Studio, die auch die Möglichkeiten zur grafischen Anzeige dort nutzt, bescheiden wie sie sind:

Fazit

Man sieht mal wieder, dass die ganzen Cloud-IoT-Tools von Microsoft größtenteils sehr gut miteinander kombinierbar sind, so dass man relativ einfach Lösungen “zusammenstecken” kann. Wenn man allerdings auf die Betriebskosten dieser Architekturen dann schaut, dann geht in vielen Fällen das Basteln wieder los, denn je mehr Komfort man beim Bau der Lösung genießt, desto mehr saugt sie uns auch die Kreditkarte leer…