Lösungsmuster in Azure Stream Analytics

Wie viele andere Dienste in Azure wird Stream Analytics am besten mit anderen Diensten verwendet, um eine größere End-to-End-Lösung zu erstellen. Dieser Artikel beschreibt einfache Azure Stream Analytics-Lösungen und verschiedene Architekturmuster. Sie können auf Basis dieser Muster komplexere Lösungen entwickeln. Die in diesem Artikel beschriebenen Muster können in einer Vielzahl von Szenarien verwendet werden. Beispiele für Muster für bestimmte Szenarien finden Sie unter Azure-Lösungsarchitekturen.

Erstellen eines Stream Analytics-Auftrags zur Förderung von Dashboarding in Echtzeit

Mithilfe von Azure Stream Analytics können Sie schnell Echtzeitdashboards und Warnungen erstellen. Eine einfache Lösung erfasst Ereignisse von Event Hubs oder IoT Hub und speist das Power BI-Dashboard mit einem Streamingdataset. Weitere Informationen finden Sie in dem ausführlichen Tutorial Analysieren von betrügerischen Anrufdaten mit Stream Analytics und Visualisieren der Ergebnisse in einem Power BI-Dashboard.

Diagram that shows events from Event Hubs and IoT Hubs flowing through Stream Analytics and to the Power BI dashboard.

Sie können diese Lösung mit dem Azure-Portal in nur wenigen Minuten erstellen. Sie müssen nicht viel programmieren. Stattdessen können Sie die Geschäftslogik in der SQL-Sprache ausdrücken.

Dieses Lösungsmuster bietet das geringste Maß an Latenz zwischen der Ereignisquelle und dem Power BI-Dashboard in einem Browser. Azure Stream Analytics ist der einzige Azure-Dienst mit dieser integrierten Funktion.

Verwenden von SQL für das Dashboard

Das Power BI-Dashboard bietet niedrige Latenz, aber Sie können es nicht verwenden, um umfassende Power BI-Berichte zu erstellen. Einem gängigen Muster für die Berichterstellung folgend sollten Sie Ihre Daten zuerst in eine SQL-Datenbank ausgeben. Verwenden Sie dann den SQL-Connector von Power BI für die SQL-Abfrage der aktuellen Daten.

Diagram that shows SQL Database as an intermediate store between Stream Analytics and Power BI dashboard.

Die Verwendung der SQL-Datenbank bietet Ihnen zwar mehr Flexibilität, allerdings auf Kosten einer etwas höheren Latenz. Diese Lösung ist optimal für Aufträge, bei denen die Latenzanforderungen über einer Sekunde liegen. Wenn Sie diese Methode verwenden, können Sie die Funktionen von Power BI in vollem Umfang einsetzen, um Daten gezielter für Berichte zu analysieren und auszuwerten, und viel mehr Visualisierungsoptionen nutzen. Sie erhalten auch die Flexibilität der Verwendung anderer Dashboardlösungen, wie z.B. Tableau.

SQL ist kein Datenspeicher mit hohem Durchsatz. Der maximale Durchsatz von Azure Stream Analytics auf eine SQL-Datenbank liegt derzeit bei etwa 24 MB/s. Wenn die Ereignisquellen in der Lösung Daten mit höherer Rate produzieren, müssen Sie die Ausgaberate an SQL mit der Verarbeitungslogik in Stream Analytics reduzieren. Sie können Techniken wie z.B. Filtern, Aggregat im Fenstermodus, Musterabgleich mit temporalen Verknüpfungen und Analysefunktionen verwenden. Sie können mit Techniken, die in Azure Stream Analytics-Ausgabe an Azure SQL-Datenbank beschrieben werden, die Ausgaberate an SQL weiter optimieren.

Integrieren von Echtzeiteinblicken in Ihre Anwendung mit Ereignisnachrichten

Die zweithäufigste Verwendung von Stream Analytics ist das Generieren von Echtzeitwarnungen. Bei diesem Lösungsmuster kann Geschäftslogik in Stream Analytics zum Erkennen von temporalen und räumlichen Mustern oder Anomalien und anschließendem Generieren von Warnsignalen verwendet werden. Hier können Sie im Gegensatz zur Dashboardlösung, wo Stream Analytics Power BI als bevorzugten Endpunkt verwendet, andere Zwischendatensenken verwenden. Zu diesen Senken zählen Event Hubs, Service Bus und Azure Functions. Als Entwickler der Anwendung müssen Sie entscheiden, welche Datensenke am besten für Ihr Szenario geeignet sind.

Sie müssen die Downstreamereignis-Verarbeitungslogik zum Generieren von Warnungen in Ihrem vorhandenen Geschäftsworkflow implementieren. Da Sie benutzerdefinierte Logik in Azure Functions implementieren können, stellt diese Lösung die schnellste Möglichkeit dar, diese Integration durchzuführen. Ein Tutorial zur Verwendung von Azure Functions als Ausgabe für einen Stream Analytics-Auftrag finden Sie unter Ausführen von Azure Functions in Azure Stream Analytics-Aufträgen. Azure Functions unterstützt auch verschiedene Arten von Benachrichtigungen einschließlich Text und E-Mail. Sie können auch Logic Apps für eine solche Integration verwenden, mit Event Hubs zwischen Stream Analytics und Logic Apps.

Diagram that shows Event Hubs and IoT Hubs as data sources and Event Hubs, Service Bus, or Functions as destinations for an Azure Stream Analytics job.

Der Azure Event Hubs-Dienst bietet andererseits den flexibelsten Integrationspunkt. Viele andere Dienste wie Azure Data Explorer and Time Series Insights können Ereignisse von Event Hubs verarbeiten. Es können direkt Verbindungen von Diensten mit der Event Hubs-Senke von Azure Stream Analytics hergestellt werden, um die Lösung fertigzustellen. Event Hubs ist auch der Nachrichtenbroker mit dem höchsten Durchsatz, der für solche Integrationsszenarien in Azure verfügbar ist.

Dynamische Anwendungen und Websites

Sie können mithilfe von Azure Stream Analytics und Azure SignalR Service benutzerdefinierte Visualisierungen in Echtzeit erstellen, z.B. Dashboard- oder Kartenvisualisierung. Wenn Sie SignalR verwenden, können Webclients aktualisiert und dynamische Inhalte in Echtzeit angezeigt werden.

Diagram that shows a Web app using SignalR service as a destination.

Integrieren von Echtzeiteinblicken in Ihre Anwendung mit Datenspeichern

Die meisten Webdienste und Webanwendungen verwenden heute ein Anforderung/Antwort-Muster für die Darstellungsschicht. Das Anforderung/Antwort-Muster ist einfach zu erstellen und kann mithilfe eines zustandslosen Front-Ends und skalierbaren Speichern wie Azure Cosmos DB einfach mit schnellen Antwortzeiten skaliert werden.

Hohe Datenvolumen führen in einem CRUD-basierten System häufig zu Leistungsengpässen. Das Ereignissourcing-Lösungsmuster wird verwendet, um Leistungsengpässe zu beheben. Das Extrahieren von temporalen Mustern und Einblicken aus einem herkömmlichen Datenspeicher ist auch schwierig und ineffizient. Moderne, von einem umfangreichen Datenvolumen gesteuerte Anwendungen übernehmen häufig eine datenflussbasierte Architektur. Azure Stream Analytics ist als Computeengine für bewegte Daten zentrales A und O in dieser Architektur.

Diagram that shows a real-time application as a destination for a Stream Analytics job.

Bei diesem Lösungsmuster werden Ereignisse von Azure Stream Analytics verarbeitet und in Datenspeichern aggregiert. Die Anwendungsschicht interagiert über das herkömmliche Anforderung/Antwort-Muster mit Datenspeichern. Aufgrund der Fähigkeit von Stream Analytics zum Verarbeiten einer großen Anzahl von Ereignissen in Echtzeit ist die Anwendung hoch skalierbar, ohne dass die Datenspeicherschicht übermäßig groß angelegt werden muss. Die Datenspeicherschicht ist im Wesentlichen eine materialisierte Sicht in das System. In Azure Stream Analytics-Ausgabe an Azure Cosmos DB wird beschrieben, wie Azure Cosmos DB als Stream Analytics-Ausgabe verwendet wird.

In realen Anwendungen, in denen die Verarbeitungslogik komplex ist und bestimmte Teile der Logik unabhängig voneinander aktualisiert werden müssen, können mehrere Stream Analytics-Aufträge mit Event Hubs als Zwischenereignisbroker zusammengestellt werden.

Diagram that shows Event Hubs as an intermediary and a real-time application as a destination for a Stream Analytics job.

Dieses Muster verbessert Resilienz und Verwaltbarkeit des Systems. Auch wenn Stream Analytics eine exakte einmalige Verarbeitung garantiert, besteht eine geringe Wahrscheinlichkeit, dass doppelte Ereignisse in den zwischengeschalteten Event Hubs eingehen. Für den nachgelagerten Stream Analytics-Auftrag ist wichtig, Ereignisse mit Logikschlüsseln in einem Rückblickfenster zu deduplizieren. Weitere Informationen zur Ereignisübermittlung finden Sie in der Referenz zu Garantien zur Ereignisbereitstellung.

Verwenden von Verweisdaten für die Anwendungsanpassung

Das Verweisdatenfeature von Azure Stream Analytics wurde speziell für die Anpassung von z.B. Warnungsschwellenwert, Verarbeitungsregeln und Geofences durch Endbenutzer entworfen. Die Anwendungsschicht kann Parameteränderungen annehmen und in einer SQL-Datenbank speichern. Der Stream Analytics-Auftrag fragt in regelmäßigen Abständen Änderungen von der Datenbank ab und ermöglicht den Zugriff auf die Anpassungsparameter über eine Verweisdatenverknüpfung. Weitere Informationen zum Verwenden von Verweisdaten für die Anwendungsanpassung finden Sie unter Verwenden von Verweisdaten aus einer SQL-Datenbank für einen Azure Stream Analytics-Auftrag (Vorschauversion) und JOIN-Anweisung für Verweisdaten.

Dieses Muster kann auch verwendet werden, um eine Regelengine dort zu implementieren, wo die Schwellenwerte der Regeln aus den Verweisdaten definiert werden. Weitere Informationen zu Regeln finden Sie unter Verarbeiten von konfigurierbaren schwellenwertbasierten Regeln in Azure Stream Analytics.

Diagram that shows a Stream Analytics job and the destination application using reference data.

Hinzufügen von Machine Learning zu Ihren Einblicken in Echtzeit

Das integrierte Modell zur Anomalieerkennung von Azure Stream Analytics ist eine komfortable Möglichkeit, Machine Learning in Ihre Echtzeitanwendung einzuführen. Informationen zu einem umfassenderen Bereich der Machine Learning-Anforderungen finden Sie unter Durchführen von Standpunktanalysen mit Azure Stream Analytics und Azure Machine Learning.

Erfahrene Benutzer, die Onlinetraining und -bewertung in dieselbe Stream Analytics-Pipeline integrieren möchten, sollten sich dieses Beispiel ansehen, wo dies mit linearer Regression durchgeführt wird.

Diagram that shows an Azure Stream Analytics job using an ML scoring model.

Data Warehousing in Echtzeit

Ein weiteres häufiges Muster ist das Data Warehousing in Echtzeit, auch als Streaming-Data Warehouse bezeichnet. Zusätzlich zu Ereignissen, die von Ihrer Anwendung bei Event Hubs und IoT Hub eintreffen, kann Azure Stream Analytics auf IoT Edge verwendet werden, um Anforderungen an Datenbereinigung, Reduzierung der Datenmenge sowie Datenspeicher und Weiterleitung zu erfüllen. Auf IoT Edge ausgeführt kann Stream Analytics Bandbreiteneinschränkungen und Verbindungsprobleme im System ordnungsgemäß behandeln. Stream Analytics kann beim Schreiben in Azure Synapse Analytics Durchsatzraten von bis zu 200 MB/s unterstützen.

Diagram that shows real-time data warehouse a destination for a Stream Analytics job.

Archivieren von Echtzeitdaten für die Analyse

Die meisten Data Science- und Analyseaktivitäten werden immer noch offline durchgeführt. Sie können Daten über Azure Data Lake Store Gen2-Ausgabe und Parquet-Ausgabeformate in Azure Stream Analytics archivieren. Diese Funktion vermeidet die Probleme der direkten Datenübertragung in Azure Data Lake Analytics, Azure Databricks und Azure HDInsight. Azure Stream Analytics wird in dieser Lösung als ETL-Modul zum Extrahieren, Transformieren und Laden in nahezu Echtzeit eingesetzt. Sie können in Data Lake archivierte Daten mit verschiedenen Computeengines untersuchen.

Diagram that shows archiving of real-time data from a Stream Analytics job.

Verwenden von Verweisdaten zur Anreicherung

Datenanreicherung ist oft eine Anforderung für ETL-Engines. Azure Stream Analytics unterstützt die Datenanreicherung mit Verweisdaten aus SQL-Datenbank und Azure Blob Storage. Die Datenanreicherung ist sowohl für in Azure Data Lake als auch Azure Synapse Analytics landende Daten möglich.

Diagram that shows the usage of reference data to enrich streaming data and then use it offline analytics.

Operationalisieren von Einblicken aus archivierten Daten

Wenn Sie das Offlineanalysemuster mit dem Nahezu-in-Echtzeit-Anwendungsmuster kombinieren, können Sie eine Feedbackschleife erstellen. Die Feedbackschleife ermöglicht der Anwendung die automatische Anpassung an sich ändernde Muster in den Daten. Diese Rückmeldungsschleife kann so einfach sein wie das Ändern des Schwellenwerts für die Warnung oder so komplex wie das erneute Trainieren von Machine Learning-Modellen. Dieselbe Lösungsarchitektur kann gleichermaßen auf in der Cloud und auf IoT Edge ausgeführte ASA-Aufträge angewendet werden.

Diagram that shows both cold path and hot path in a Stream Analytics solution.

Überwachung von ASA-Aufträgen

Ein Azure Stream Analytics-Auftrag kann rund um die Uhr zur kontinuierlichen Verarbeitung eingehender Ereignisse in Echtzeit ausgeführt werden. Die Betriebszeitgarantie ist für die Integrität der gesamten Anwendung entscheidend. Obwohl Stream Analytics als einziger Streaminganalysedienst in der Branche eine Verfügbarkeit von 99,9 % garantiert, kommt es dennoch zu einem gewissen Grad an Ausfallzeiten. Im Laufe der Jahre wurden bei Stream Analytics Metriken, Protokolle und Auftragsstatus eingeführt, die die Integrität der Aufträge widerspiegeln. Sie werden alle in der Benutzeroberfläche des Diensts Azure Monitor angezeigt und können nach der OMS exportiert werden. Weitere Informationen finden Sie unter Überwachen des Stream Analytics-Auftrags mit Azure-Portal.

Diagram that shows monitoring of Stream Analytics jobs.

Zwei Hauptkriterien sind zu überwachen:

  • Status „Fehler“ des Auftrags

    Zuallererst müssen Sie sicherstellen, dass der Auftrag ausgeführt wird. Wenn der Auftrag sich nicht im Ausführungsstatus befindet, werden keine neuen Metriken oder Protokolle generiert. Aufträge können sich aus unterschiedlichen Gründen in einem fehlerhaften Zustand befinden, einschließlich einer hohen SU-Auslastung (d. h. unzureichend Ressourcen).

  • Wasserzeichenverzögerungs-Metriken

    Diese Metrik reflektiert, wie weit Ihre Verarbeitungspipeline in Gesamtbetrachtungszeit (Sekunden) zurückliegt. Die Verzögerung ist zum Teil mit ihrer Verarbeitungslogik verbunden. Daher ist die Überwachung der zunehmenden Trends viel wichtiger als die Überwachung des absoluten Werts. Der Verzögerung im stabilen Zustand sollten Sie mit dem Anwendungsentwurf begegnen, nicht mit Überwachung oder Warnungen.

Bei einem Ausfall sollten Sie zuerst in Aktivitätsprotokollen und Diagnoseprotokollen nach Fehlern suchen.

Erstellen robuster und unternehmenskritischer Anwendungen

Unabhängig von der SLA-Garantie von Azure Stream Analytics und der Sorgfalt, mit der Sie die End-to-End-Anwendung ausführen, können Ausfälle auftreten. Wenn Ihre Anwendung unternehmenskritisch ist, müssen Sie auf Ausfälle vorbereitet sein, um ordnungsgemäß wiederherstellen zu können.

Bei Warnungsanwendungen ist es am wichtigsten, die nächste Warnung zu erkennen. Sie können festlegen, dass der Auftrag bei der Wiederherstellung ab dem aktuellen Zeitpunkt neu gestartet wird, wobei frühere Warnmeldungen ignoriert werden. Die Auftragsstartzeit-Semantik liegt beim ersten Ausgabezeitpunkt, nicht dem ersten Eingabezeitpunkt. Die Eingabe wird um einen entsprechenden Zeitraum zurückgespult, um sicherzustellen, dass die erste Ausgabe zum angegebenen Zeitpunkt vollständig und korrekt ist. Sie erhalten keine teilweisen Aggregate und lösen als Ergebnis unerwartet Warnungen aus.

Außerdem können Sie festlegen, dass die Ausgabe ab einem bestimmten Zeitpunkt in der Vergangenheit beginnt. Dank der Aufbewahrungsrichtlinien für Event Hubs und IoT Hub steht eine ausreichende Datenmenge zur Verarbeitung von einem Punkt in der Vergangenheit aus zur Verfügung. Die Frage ist nur, wie schnell Sie zum aktuellen Zeitpunkt aufholen und ob Sie rechtzeitig beginnen können, neue Warnungen zu generieren. Daten verlieren im Laufe der Zeit schnell an Wert, daher ist es wichtig, schnell zum aktuellen Zeitpunkt aufzuholen. Es gibt zwei Möglichkeiten, schnell aufzuholen:

  • Stellen Sie während des Aufholens weitere Ressourcen (SU) bereit.
  • Starten Sie ab dem aktuellen Zeitpunkt neu.

Ab dem aktuellen Zeitpunkt neu zu starten ist einfach, allerdings mit dem Nachteil verbunden, dass eine Lücke während der Verarbeitung hinterlassen wird. Ein derartiger Neustart mag für Warnungsszenarien in Ordnung sein, kann aber für Dashboardszenarien problematisch sein und kommt für Archivierungs- und Data Warehousing-Szenarien nicht infrage.

Die Bereitstellung weiterer Ressourcen kann den Prozess beschleunigen, aber die Auswirkungen eines plötzlichen Anstiegs der Verarbeitungsrate sind komplex.

  • Prüfen Sie, ob Ihr Auftrag für eine größere Anzahl von SUs skalierbar ist. Nicht alle Abfragen sind skalierbar. Sie müssen sicherstellen, dass Ihre Abfrage parallelisiert ist.

  • Stellen Sie sicher, dass genügend Partitionen in den vorgelagerten Event Hubs- oder IoT Hub-Instanzen vorhanden sind, sodass Sie weitere Durchsatzeinheiten (Throughput Units, TUs) zum Skalieren des Eingabedurchsatzes hinzufügen können. Beachten Sie, dass jede Event Hubs-TU eine maximale Ausgaberate von 2MB/s hat.

  • Vergewissern Sie sich, dass Sie genügend Ressourcen in den Ausgabesenken (d. h. SQL Database, Azure Cosmos DB) bereitgestellt haben, damit diese den plötzlichen Anstieg der Ausgabe nicht drosseln, was manchmal dazu führen kann, dass das System blockiert.

Das Wichtigste ist, die Änderung der Verarbeitungsrate vorwegzunehmen, diese Szenarien vor dem Start der Produktion zu testen und bereit zu sein, die Verarbeitung während der Wiederherstellungszeit ordnungsgemäß zu skalieren.

Im extremen Szenario, dass alle eingehenden Ereignisse verzögert sind, ist es möglich, dass alle verzögerten Ereignisse gelöscht werden, wenn Sie ein spätes Ankunftsfenster für Ihren Auftrag angewendet haben. Das Löschen der Ereignisse mag anfangs rätselhaft erscheinen, doch Stream Analytics erwartet als Echtzeitverarbeitungsmodul, dass eingehende Ereignisse nahe an der Systemuhrzeit liegen. Sie muss Ereignisse löschen, die diese Einschränkungen verletzen.

Lambda-Architekturen oder Abgleichsprozess

Glücklicherweise kann das vorherige Datenarchivierungsmuster verwendet werden, um diese verspäteten Ereignisse ordnungsgemäß zu verarbeiten. Dahinter steht der Gedanke, dass der Archivierungsauftrag eingehende Ereignisse zur Eingangszeit verarbeitet und Ereignisse in Azure Blob Storage oder Azure Data Lake Store mit ihrer Ereigniszeit im richtigen Zeitbucket archiviert. Ganz gleich, wie spät ein Ereignis eingeht, es wird nie gelöscht. Es gelangt immer in den richtigen Zeitbucket. Während der Wiederherstellung können die archivierten Ereignisse erneut verarbeitet und die Ergebnisse mit dem Speicher Ihrer Wahl abgeglichen werden. Dies ähnelt der Art, in der Lambda-Muster implementiert werden.

ASA backfill

Der Abgleich muss mit einem Offline-Batchverarbeitungssystem erfolgen, dessen Programmiermodell sich wahrscheinlich von dem von Azure Stream Analytics unterscheidet. Dies bedeutet, dass Sie die gesamte Verarbeitungslogik erneut implementieren müssen.

Für den Abgleich ist es immer noch wichtig, zumindest vorübergehend mehr Ressourcen für die Ausgabesenken bereitzustellen, um einen höheren Durchsatz zu verarbeiten, als die Verarbeitung im stabilen Zustand erfordert.

Szenarien Nur ab jetzt neu starten Vom letzten Stoppzeitpunkt aus neu starten Ab jetzt neu starten + Abgleich mit archivierten Ereignissen
Dashboarding Erstellt Lücke OK für kurzen Ausfall Verwendung für langen Ausfall
Warnungen Akzeptabel OK für kurzen Ausfall Nicht erforderlich
Ereignissourcing-App Akzeptabel OK für kurzen Ausfall Verwendung für langen Ausfall
Data Warehousing Datenverlust Akzeptabel Nicht erforderlich
Offlineanalyse Datenverlust Akzeptabel Nicht erforderlich

Zusammenfügen des Gesamtbilds

Es ist nicht schwierig, sich vorzustellen, dass alle zuvor genannten Lösungsmuster in einem komplexen End-to-End-System kombiniert werden können. Das kombinierte System kann Dashboards, Warnungen, Ereignissourcinganwendungen, Data Warehousing und Offlineanalysefunktionen enthalten.

Entscheidend ist, dass Sie Ihr System in kombinierbaren Mustern entwerfen, damit jedes Subsystem unabhängig erstellt, getestet, aktualisiert und wiederhergestellt werden kann.

Nächste Schritte

Sie haben jetzt verschiedene Lösungsmustern mit Azure Stream Analytics kennengelernt. Nun können Sie tiefer einsteigen und Ihren ersten Stream Analytics-Auftrag erstellen: