Aufbau einer IoT-Datenpipeline mit Azure Event Hubs und Azure Functions

10.000 Geräte direkt mit einer Datenbank zu verbinden, ist keine Pipeline – es ist ein Engpass. Eine produktive IoT-Datenpipeline muss Millionen von Nachrichten pro Tag verarbeiten, Ausfälle ohne Datenverlust überstehen und Echtzeit- sowie historische Abfragen gleichzeitig bedienen.

Pipeline-Architektur

Stufe 1: Ingest   -> Azure IoT Hub (MQTT/HTTPS)
Stufe 2: Routing  -> Nachrichten-Routing zu Endpunkten nach Typ
Stufe 3: Verarbeitung -> Azure Functions (Event-Hubs-Trigger)
Stufe 4: Bereitstellung -> Time Series Insights + Cosmos DB

Azure Functions — Event-Hub-Trigger

app.eventHub("processTelemetry", {
    connection: "EventHubsConn",
    eventHubName: "telemetry",
    cardinality: "many",
    handler: async (events, context) => {
        for (const e of events) {
            await tsi.write(e.deviceId, e.timestamp, e.readings);
            await cosmos.upsert({id: e.deviceId, lastSeen: e.timestamp});
        }
    }
});

Partitionierungsstrategie für Event Hubs

Event Hubs nutzt Partitionen, um Durchsatz zu erreichen – jede Partition ist ein eigenständiger, geordneter Datenstrom. Consumer-Gruppen lesen parallel aus den Partitionen, mehr Partitionen bedeuten also mehr parallele Verarbeitung. Ein häufiger Fehler ist Unter-Partitionierung: Man startet mit 4 Partitionen und stellt fest, dass die Azure Functions nicht skalieren können, um 100.000 Nachrichten pro Sekunde zu verarbeiten, wenn ein Firmware-Bug dazu führt, dass alle Geräte gleichzeitig Fehler-Events senden.

Die Partitionsanzahl kann nach der Erstellung nicht mehr geändert werden. Dimensionieren Sie für das 2- bis 5-Fache Ihres erwarteten Spitzendurchsatzes. Verwenden Sie die Geräte-ID als Partitionsschlüssel – so wird sichergestellt, dass alle Nachrichten eines einzelnen Geräts innerhalb einer Partition geordnet sind, was die Zeitreihen-Rekonstruktion und das Zustandsmanagement in Ihren Functions vereinfacht.

Umgang mit Reconnection-Stürmen von Geräten

Wenn ein Cloud-Ausfall endet, versuchen alle Geräte gleichzeitig, sich wieder zu verbinden. Bei 10.000 Geräten entsteht ein Thundering Herd: Millionen gepufferter Nachrichten treffen innerhalb von Sekunden auf Event Hubs. Ihre verarbeitenden Functions müssen dies souverän bewältigen – implementieren Sie exponentielles Backoff mit Jitter in der Geräte-Firmware und konfigurieren Sie Event Hubs mit ausreichenden Throughput Units und Aufbewahrung, um den Ansturm abzufangen.

int backoff_ms = BASE_BACKOFF_MS;
while (!connected) {
    int jitter = random(0, backoff_ms / 2);
    vTaskDelay(pdMS_TO_TICKS(backoff_ms + jitter));
    backoff_ms = MIN(backoff_ms * 2, MAX_BACKOFF_MS);
    connected = mqtt_connect();
}

Cold-Path- vs. Hot-Path-Architektur

IoT-Datenpipelines haben typischerweise zwei Pfade: den Hot Path für die Echtzeitverarbeitung (Dashboards, Alarme, Anomalieerkennung) und den Cold Path für historische Speicherung und Batch-Analysen. Der Hot Path priorisiert Latenz – Azure Functions verarbeiten Event-Hub-Events und pushen sie über SignalR an Live-Dashboards. Der Cold Path priorisiert Vollständigkeit – alle Rohnachrichten werden im Parquet-Format in Azure Blob Storage geschrieben, für spätere Analysen mit Azure Synapse oder Databricks.

Beide Pfade von Tag eins an zu entwerfen, vermeidet das häufige Problem, Rohdaten zu verwerfen, die sich später als wertvoll erweisen. Speicher ist günstig; die Rekonstruktion historischer Sensordaten, die nie gespeichert wurden, ist unmöglich. Unsere Standard-Pipeline schreibt alle Roh-Gerätenachrichten in den Cold Storage und eine verarbeitete Teilmenge in die Warm-Tier – die Rohdaten können Sie jederzeit erneut verarbeiten, aber Sie können sie nicht wieder herbeizaubern, wenn sie verloren sind.