IoT-Daten flexibel verarbeiten und verteilen

IoT-Daten müssen heute nicht mehr ausschließlich an IoT Hub oder den Blob Storage gesendet werden. Mit Data Flows lassen sich Datenströme gezielt auf der Edge aufbereiten, filtern oder aggregieren und anschließend an verschiedene Zielsysteme wie Event Hub, Azure Data Explorer oder Microsoft Fabric weiterleiten.

Dieser Beitrag schließt inhaltlich an die Informationen aus dem Artikel „IoT neu eingebunden“ an. 

IoT-Daten neu gedacht: Von starren Pfaden zu flexiblen Datenflüssen

Die Integration und Verarbeitung von IoT-Daten ist ein zentrales Element moderner Cloud-Architekturen. In vielen Projekten zeigt sich jedoch, dass der Weg von der Edge bis zur Analyse in der Cloud oft durch technische Einschränkungen, starre Datenflüsse und komplexe Konfigurationen geprägt ist. Daten in Azure IoT werden out-of-the-box nur an vordefinierte Ziele wie Azure IoT Hub oder Azure Storage Account gesendet, was die Weiterverarbeitung und Integration in andere Systeme erschwert.

Mit Azure IoT Operations und den dort verfügbaren Data Flows steht nun ein flexiblerer Ansatz zur Verfügung. Datenquellen lassen sich direkt aus der Cloud heraus konfigurieren, mit Transformationen wie Aggregation oder Filterung anreichern und an unterschiedliche Zielsysteme weiterleiten. Dabei sind nicht nur klassische Azure-Dienste wie Event Hub oder Data Explorer möglich, sondern auch offene Schnittstellen wie MQTT-Broker oder Apache Kafka.

Im weiteren Verlauf dieses Artikels wird gezeigt, wie sich diese neuen Möglichkeiten in der Praxis nutzen lassen. Zunächst werfen wir einen Blick auf bestehende Datenflüsse in Azure IoT und deren Grenzen. Anschließend stellen wir das Konzept der Data Flows vor und zeigen, wie Microsoft Fabric als Zielsystem für Echtzeit- und Analyseanwendungen eingebunden werden kann.

Was heute in Azure IoT möglich ist

Azure IoT bietet eine Vielzahl an Diensten, um Daten von Geräten zu erfassen, zu verarbeiten und weiterzuleiten. Der klassische Einstiegspunkt ist der IoT Hub, der als zentrales Gateway für eingehende Telemetrie dient. Von dort aus lassen sich Daten über integrierte Routen an Dienste wie Azure Stream Analytics, Azure Functions, Azure Service Bus oder Azure Storage Account weitergeben. Diese Architektur ist gut dokumentiert und in vielen Projekten etabliert.

In der Praxis zeigt sich jedoch, dass diese Struktur schnell an ihre Grenzen stößt, wenn Anforderungen über einfache Datenweiterleitung hinausgehen. Die Konfiguration ist oft technisch anspruchsvoll und verteilt sich auf mehrere Dienste, die jeweils separat verwaltet werden müssen. Transformationen wie das Filtern, Aggregieren oder Umwandeln von Datenformaten erfordern zusätzliche Komponenten wie eigene Stream Analytics Jobs oder benutzerdefinierte Funktionen und Module.

Ein weiteres Problem ist die eingeschränkte Auswahl an Zielsystemen. In vielen Fällen ist der Datenfluss auf Azure-interne Dienste beschränkt. Wer Daten an externe Systeme wie Kafka, MQTT Broker außerhalb von Azure oder moderne Analyseplattformen senden möchte, muss eigene Integrationen entwickeln. Auch die Wiederverwendbarkeit solcher Datenflüsse ist begrenzt, da sie meist individuell aufgebaut und nicht deklarativ beschrieben sind. Dazu kommt das Thema Kosten. Alle Nachrichten, die an Azure Services weitergeleitet werden sollen, müssen trotzdem über den IoT Hub. Dadurch werden Nachrichten im Zweifel doppelt abgerechnet: Einmal im IoT Hub und einmal im Ingress des Service, an den weitergeleitet wird.

Wer IoT Edge nutzt, kann über den Edge Hub nur an den IoT Hub senden. Dabei ist keine Skalierbarkeit gegeben. Bei vielen Nachrichten, die auf der Edge verarbeitet und weitergeleitet werden müssen, kommt man irgendwann an ein Limit, was man nur bedingt mit vertikaler Skalierung lösen kann.

Diese Herausforderungen zeigen, dass klassische IoT-Datenarchitekturen in Azure zwar leistungsfähig sind, aber wenig Flexibilität bieten. Sie erfordern tiefes technisches Wissen, sind schwer zu skalieren und lassen sich nur mit erheblichem Aufwand an neue Anforderungen anpassen. Genau an diesem Punkt setzen Data Flows in Azure IoT Operations an. Sie bieten einen modularen und deklarativen Ansatz für moderne Datenintegration.

Von der Quelle bis zum Ziel: Daten intelligent weiterleiten mit Data Flows

Data Flows in Azure IoT Operations bestehen aus drei klar definierten Bestandteilen: Source, Transforms und Data Flow Endpoint. Diese Struktur ermöglicht es, Datenflüsse modular aufzubauen und gezielt an unterschiedliche Anforderungen anzupassen (siehe Bild 1).

Source beschreibt die Datenquelle, aus der ein Flow gespeist wird. Als Source kann der integrierte MQTT Broker dienen, bei dem beliebige Topics abonniert werden können. Alternativ kann auch ein Asset als Quelle verwendet werden. In diesem Fall ist die Zuordnung der Daten bereits über die Schema Registry definiert. Das bedeutet, dass im Asset und im zugehörigen Asset Endpoint festgelegt ist, welche Daten über welches MQTT Topic gesendet werden. Dadurch muss man die konkreten Topics nicht kennen, sondern kann sich auf die semantische Beschreibung des Assets verlassen. Das vereinfacht die Konfiguration erheblich. Zusätzlich besteht die Möglichkeit, Kafka-Nachrichten als Source zu verwenden. Diese werden nicht über das Webportal, sondern über direkte Konfiguration eingebunden.

Transforms ermöglichen die Verarbeitung der eingehenden Daten innerhalb des Flows. Hier können Funktionen wie Filtern, Aggregieren oder Umbenennen von Feldern angewendet werden. Diese Schritte lassen sich deklarativ definieren und erinnern in ihrer Funktion an bekannte Konzepte aus Azure Stream Analytics. Die Transformationen sind vollständig in die Plattform integriert und benötigen keine zusätzlichen Dienste.

Data Flow Endpoint bezeichnet das Ziel, an das die verarbeiteten Daten gesendet werden. Hier bietet Azure IoT Operations deutlich mehr Flexibilität als frühere Ansätze. Neben klassischen Azure-Diensten wie Event Grid als MQTT-Broker, Event Hub, Azure Data Explorer oder Azure Data Lake Storage können auch externe Systeme angebunden werden. Dazu zählen beispielsweise MQTT-Broker oder auch Kafka-Cluster, die nicht zwangsläufig in Azure gehostet sein müssen, oder aber auch auf der Edge betrieben werden. Auch Microsoft Fabric kann als Zielsystem verwendet werden, entweder über OneLake für analytische Zwecke oder über Real-Time Intelligence für Echtzeitanalyse. Die Authentifizierung und Autorisierung erfolgt hierbei über Azure Identities statt über Account Keys oder ähnliches.

Ein weiterer Vorteil ergibt sich bei der Nutzung des MQTT-Brokers als Source. In diesen Fällen werden Nachrichten, die in die Cloud geschickt werden sollen, im Broker zwischengespeichert, wenn keine Verbindung besteht. Dieses Verhalten ist vergleichbar mit dem bekannten Offline-Puffermechanismus des Edge Hub. Dadurch wird sichergestellt, dass keine Daten verloren gehen, wenn die Verbindung zur Cloud temporär unterbrochen ist.

Ein weiterer Vorteil liegt in der Wiederverwendbarkeit und Versionierung. Da Data Flows deklarativ beschrieben werden, lassen sie sich in Git-Repositories verwalten und über GitOps automatisiert ausrollen. In Kubernetes-Umgebungen können so Änderungen nachvollziehbar dokumentiert und konsistent über mehrere Cluster hinweg ausgerollt werden.

Auch das Monitoring ist integraler Bestandteil der Plattform. Über OpenTelemetry lassen sich Metriken und Logs aus den Data Flows erfassen und in bestehende Observability-Stacks integrieren. In Kombination mit Kubernetes-Monitoring lassen sich so Performance, Fehlerzustände und Durchsatz transparent überwachen.

Data Flows unterstützen sowohl strukturierte als auch semistrukturierte Daten. Die Schema Registry, die zwischen Edge und Cloud synchronisiert wird, stellt sicher, dass die Struktur der Daten bekannt ist und validiert werden kann. In der Cloud kann so nachvollzogen werden, welche Formate von der Edge erwartet werden. Das erleichtert die Weiterverarbeitung und reduziert Fehler durch inkonsistente Datenstrukturen.

Data Flows sind darüber hinaus skalierbar. Bei einer hohen Anzahl an eingehenden Nachrichten können sie horizontal über mehrere Pods oder sogar über mehrere Nodes hinweg betrieben werden, abhängig vom jeweiligen Kubernetes-Setup. Im Vergleich zu IoT Edge, wo Module in der Regel nur einmal pro Gerät laufen, ist damit eine deutlich höhere Datenverarbeitung möglich. Das macht Data Flows besonders geeignet für Szenarien mit hohem Datenvolumen und verteilten Architekturen.

Microsoft Fabric als Zielsystem für IoT-Daten

Microsoft Fabric erweitert die Möglichkeiten zur Verarbeitung und Analyse von Daten in Azure deutlich. Die Plattform vereint verschiedene Daten- und Analysefunktionen unter einer einheitlichen Oberfläche und bietet zwei zentrale Wege, um IoT-Daten zu integrieren: über OneLake für analytische Workloads und über Real-Time Intelligence für die Verarbeitung von Echtzeitdaten.

OneLake ist die zentrale Speicherkomponente von Microsoft Fabric. Hier können strukturierte und semistrukturierte Daten abgelegt und für Analysezwecke aufbereitet werden. Daten, die über Data Flows in OneLake geschrieben werden, stehen sofort für weitere Verarbeitungsschritte zur Verfügung. Sie lassen sich in Notebooks analysieren, in Power BI visualisieren oder in Data Warehouses integrieren. Dieser Pfad eignet sich besonders für Szenarien, in denen historische Daten gesammelt, angereichert und langfristig ausgewertet werden sollen.

Der zweite Weg führt über Real-Time Intelligence. Dieser Dienst ist darauf ausgelegt, eingehende Datenströme in Echtzeit zu verarbeiten. Hier können Regeln definiert werden, um auf bestimmte Muster oder Ereignisse sofort zu reagieren. Gleichzeitig lassen sich die verarbeiteten Daten an weitere Ziele innerhalb von Fabric weiterleiten. Ein typisches Beispiel ist die Übergabe an ein Event House, also eine Data-Explorer-Instanz innerhalb von Fabric. Dort können die Daten dauerhaft gespeichert, abgefragt und für weiterführende Analysen genutzt werden. Auch die klassische Variante über den Event Hub ist möglich, wobei ein Fabric Data Flow beispielsweise das Weiterleiten der Daten in das Event House übernimmt.

Ein wesentlicher Vorteil von Fabric liegt im einheitlichen Datenmodell, das über alle Komponenten hinweg konsistent bleibt. Das erleichtert die Integration von Daten aus unterschiedlichen Quellen und ermöglicht eine durchgängige semantische Beschreibung. Besonders in IoT-Szenarien, in denen Daten aus vielen verschiedenen Geräten und Formaten zusammengeführt werden, sorgt das für mehr Übersicht und weniger Integrationsaufwand.

Darüber hinaus ist Fabric vollständig in Microsoft Purview integriert. Damit stehen Funktionen für Datenschutz, Zugriffskontrolle und Datenklassifikation auch für IoT-Daten zur Verfügung. Sensible oder geschäftskritische Informationen lassen sich gezielt schützen und verwalten, ohne dass zusätzliche Governance-Werkzeuge erforderlich sind.

Im Vergleich zu bisherigen Lösungen wie Azure Stream Analytics oder Azure Data Lake Storage (ADLS) bietet Microsoft Fabric eine engere Verzahnung der Komponenten. Daten müssen nicht mehr zwischen verschiedenen Diensten verschoben werden, sondern bleiben innerhalb einer konsistenten Plattform. Das vereinfacht nicht nur die Architektur, sondern reduziert auch die Komplexität bei Betrieb und Wartung.

Durch die Kombination aus OneLake und Real-Time Intelligence lassen sich sowohl klassische Analyseanforderungen als auch Echtzeitszenarien abbilden. In Verbindung mit Data Flows entsteht so eine durchgängige Datenpipeline von der Edge bis zur Auswertung, die sich flexibel an unterschiedliche Anforderungen anpassen lässt.

Fazit

Die Verarbeitung und Integration von IoT-Daten in Azure war lange durch feste Strukturen und eingeschränkte Zielsysteme geprägt. Mit Data Flows in Azure IoT Operations steht nun ein flexibler und skalierbarer Ansatz zur Verfügung, der sich direkt aus der Cloud heraus konfigurieren lässt. Datenquellen wie MQTT Topics, Assets oder Kafka lassen sich einfach anbinden, Transformationen deklarativ definieren und Zielsysteme gezielt auswählen.

Im Vergleich zu klassischen Architekturen mit IoT Hub, Stream Analytics und Blob Storage bieten Data Flows eine deutlich höhere Flexibilität und Wiederverwendbarkeit. Durch die Möglichkeit zur horizontalen Skalierung über Kubernetes lassen sich auch große Datenmengen zuverlässig verarbeiten.

Mit Microsoft Fabric steht zudem eine moderne Plattform zur Verfügung, die sowohl Echtzeitverarbeitung über Real-Time Intelligence als auch langfristige Analyse über OneLake unterstützt. Die enge Integration innerhalb der Fabric-Umgebung reduziert Komplexität und schafft neue Möglichkeiten für die Auswertung und Visualisierung von IoT-Daten.

Wer bestehende Datenarchitekturen modernisieren oder neue Projekte aufbauen möchte, findet in der Kombination aus Data Flows und Microsoft Fabric eine leistungsfähige Grundlage für skalierbare, Cloud-native Datenpipelines.