Anomalieerkennung in Azure Stream Analytics

Azure Stream Analytics in der Cloud und Azure IoT Edge verfügbar ist, bietet integrierte Machine Learning-basierte Anomalieerkennungsfunktionen, mit denen Sie die beiden am häufigsten auftretenden Anomalien überwachen können: temporär und persistent. Mithilfe der funktionen AnomalyDetection_SpikeAndDip und AnomalyDetection_ChangePoint können Sie Anomalieerkennung direkt in Ihrem Stream Analytics-Auftrag durchführen.

Die Modelle des maschinellen Lernens gehen von einer einheitlich abgetasteten Zeitreihe aus. Wenn die Zeitreihe nicht einheitlich ist, fügen Sie vor dem Aufrufen der Anomalieerkennung einen Aggregationsschritt mit einem Sturzfenster ein.

Die Machine Learning-Vorgänge unterstützen derzeit keine Saisonalitätstrends oder multivariate Korrelationen.

Anomalieerkennung mithilfe von maschinellem Lernen in Azure Stream Analytics

Das folgende Video zeigt, wie Sie eine Anomalie in Echtzeit mithilfe von Maschinellen Lernfunktionen in Azure Stream Analytics erkennen.

Modellverhalten

Im Allgemeinen verbessert sich die Genauigkeit des Modells, je mehr Daten im gleitenden Fenster angezeigt werden. Die Daten im angegebenen gleitenden Fenster werden als Teil des normalen Wertebereichs für diesen Zeitraum behandelt. Das Modell berücksichtigt nur den Ereignisverlauf über das gleitende Fenster, um zu überprüfen, ob das aktuelle Ereignis anomal ist. Wenn sich das gleitende Fenster bewegt, werden alte Werte aus dem Training des Modells entfernt.

Die Funktionen funktionieren, indem sie eine bestimmte Normalität auf der Grundlage dessen etablieren, was sie bisher gesehen haben. Ausreißer werden durch einen Vergleich mit dem etablierten Normalbereich innerhalb des Konfidenzniveaus identifiziert. Die Fenstergröße sollte auf den minimalen Ereignissen basieren, die erforderlich sind, um das Modell für normales Verhalten zu trainieren, damit eine Anomalie erkannt werden kann, wenn sie auftritt.

Die Reaktionszeit des Modells nimmt mit der Größe des Verlaufs zu, da es mit einer höheren Anzahl vergangener Ereignisse verglichen werden muss. Um eine bessere Leistung zu erzielen, schließen Sie nur die erforderliche Anzahl von Ereignissen ein.

Lücken in der Zeitreihe können auftreten, wenn das Modell keine Ereignisse zu bestimmten Zeitpunkten empfängt. Stream Analytics behandelt diese Situation mithilfe der Berechnungslogik. Die Verlaufshistorie und eine festgelegte Zeitdauer für dasselbe Gleitfenster werden verwendet, um die durchschnittliche Eingangsrate der erwarteten Ereignisse zu berechnen.

Sie können einen Anomalie-Generator verwenden, um einen IoT Hub mit Daten zu versorgen, die unterschiedliche Anomaliemuster enthalten. Sie können einen Azure Stream Analytics Job einrichten, indem Sie diese Anomalieerkennungsfunktionen verwenden, um von diesem IoT-Hub zu lesen und Anomalien zu erkennen.

Spike und Dip

Temporäre Anomalien in einem Zeitreihenereignisstrom werden als Spitzen und Einbrüche bezeichnet. Sie können Spitzen und Dips überwachen, indem Sie den Machine Learning basierten Operator AnomalyDetection_SpikeAndDip verwenden.

Wenn im gleichen Gleitfenster eine zweite Spitze kleiner ist als die erste, könnte der bewertete Wert für die kleinere Spitze möglicherweise nicht signifikant genug sein im Vergleich zum Ergebnis für die erste Spitze innerhalb der angegebenen Vertrauensstufe. Sie können versuchen, das Konfidenzniveau des Modells zu verringern, um solche Anomalien zu erkennen. Wenn Sie jedoch zu viele Warnungen erhalten, verwenden Sie ein höheres Konfidenzintervall.

Bei der folgenden Beispielabfrage wird von einer einheitlichen Eingaberate von einem Ereignis pro Sekunde in einem gleitenden Fenster von 2 Minuten mit einem Verlauf von 120 Ereignissen ausgegangen. Die abschließende SELECT-Anweisung extrahiert und gibt die Punktzahl und den Anomaliestatus mit einem Konfidenzniveau von 95%aus.

WITH AnomalyDetectionStep AS
(
    SELECT
        EVENTENQUEUEDUTCTIME AS time,
        CAST(temperature AS float) AS temp,
        AnomalyDetection_SpikeAndDip(CAST(temperature AS float), 95, 120, 'spikesanddips')
            OVER(LIMIT DURATION(second, 120)) AS SpikeAndDipScores
    FROM input
)
SELECT
    time,
    temp,
    CAST(GetRecordPropertyValue(SpikeAndDipScores, 'Score') AS float) AS
    SpikeAndDipScore,
    CAST(GetRecordPropertyValue(SpikeAndDipScores, 'IsAnomaly') AS bigint) AS
    IsSpikeAndDipAnomaly
INTO output
FROM AnomalyDetectionStep

Punkt ändern

Persistente Anomalien in einem Zeitreihenereignisstrom sind Änderungen in der Verteilung von Werten im Ereignisstrom, z. B. Pegeländerungen und Trends. In Stream Analytics erkennt der Machine Learning basierende AnomalyDetection_ChangePointOperator diese Anomalien.

Anhaltende Veränderungen dauern viel länger als Spitzen und Einbrüche und können auf katastrophale Ereignisse hinweisen. Dauerhafte Änderungen sind in der Regel nicht für das bloße Auge sichtbar, aber der AnomalyDetection_ChangePoint Operator kann sie erkennen.

Die folgende Abbildung ist ein Beispiel für eine Ebenenänderung:

Die folgende Abbildung ist ein Beispiel für eine Trendänderung:

Die folgende Beispielabfrage geht von einer einheitlichen Eingaberate von einem Ereignis pro Sekunde in einem 20-minütigen gleitenden Fenster mit einer Verlaufsgröße von 1.200 Ereignissen aus. Die abschließende SELECT-Anweisung extrahiert und gibt die Punktzahl und den Anomaliestatus mit einem Konfidenzniveau von 80%aus.

WITH AnomalyDetectionStep AS
(
    SELECT
        EVENTENQUEUEDUTCTIME AS time,
        CAST(temperature AS float) AS temp,
        AnomalyDetection_ChangePoint(CAST(temperature AS float), 80, 1200) 
        OVER(LIMIT DURATION(minute, 20)) AS ChangePointScores
    FROM input
)
SELECT
    time,
    temp,
    CAST(GetRecordPropertyValue(ChangePointScores, 'Score') AS float) AS
    ChangePointScore,
    CAST(GetRecordPropertyValue(ChangePointScores, 'IsAnomaly') AS bigint) AS
    IsChangePointAnomaly
INTO output
FROM AnomalyDetectionStep

Leistungsmerkmale

Die Leistung dieser Modelle hängt von der Verlaufshistorie, der Fensterdauer, der Ereignislast und davon ab, ob die Partitionierung auf Funktionsebene verwendet wird. In diesem Abschnitt werden diese Konfigurationen erläutert und Beispiele dafür bereitgestellt, wie man Aufnahmeraten von 1 K, 5 K und 10 K Events pro Sekunde aufrechterhält.

• Verlaufsgröße – Diese Modelle werden linear mit Verlaufsgröße ausgeführt. Je länger die Verlaufsgröße, desto länger brauchen die Modelle, um ein neues Ereignis zu bewerten. Die Modelle vergleichen das neue Ereignis mit jedem der vorherigen Ereignisse im Verlaufsspeicher.
• Fensterdauer – Die Fensterdauer sollte angeben, wie lange es dauert, bis so viele Ereignisse empfangen werden, wie durch die Verlaufsgröße angegeben. Ohne diese Anzahl von Ereignissen im Fenster würden Azure Stream Analytics fehlende Werte inputieren. Daher ist der CPU-Verbrauch eine Funktion der Historiengröße.
• Ereignislast – Je größer die Ereignislast ist, desto mehr Arbeit führen die Modelle aus, was sich auf den CPU-Verbrauch auswirkt. Sie können den Auftrag verkleinern, indem Sie ihn peinlich parallel gestalten, vorausgesetzt, es ist sinnvoll, dass geschäftslogik mehr Eingabepartitionen verwendet.
• Partitionierung auf Funktionsebene : Verwenden Sie PARTITION BY innerhalb des Anomalieerkennungsfunktionsaufrufs zum Ausführen der Partitionierung auf Funktionsebene. Diese Art der Partitionierung fügt einen Mehraufwand hinzu, da die Aufgabe den Zustand für mehrere Modelle gleichzeitig beibehalten muss. Verwenden Sie die Partitionierung auf Funktionsebene in Szenarien wie der Partitionierung auf Geräteebene.

Beziehung

Die Verlaufsgröße, die Fensterdauer und die Gesamtlast des Ereignisses stehen in folgenden Beziehungen:

windowDuration (in ms) = 1000 * historySize / (Gesamtzahl der Eingabeereignisse pro Sekunde / Anzahl der Eingabepartitionen)

Wenn Sie die Funktion nach deviceId partitionieren, fügen Sie dem Funktionsaufruf der Anomalieerkennung "PARTITION BY deviceId" hinzu.

Beobachtungen

Die folgende Tabelle zeigt die Durchsatzbeobachtungen für einen einzelnen Knoten (sechs SU) für den nicht partitionierten Fall:

Die folgende Tabelle zeigt die Durchsatzbeobachtungen für einen einzelnen Knoten (sechs SU) für den partitionierten Fall:

Sie finden Beispielcode zum Ausführen der nicht partitionierten Konfigurationen im Streaming At Scale Repo von Azure Samples. Der Code erstellt einen Stream Analytics-Auftrag ohne Partitionierung auf Funktionsebene, der Event Hubs als Eingabe und Ausgabe verwendet. Die Testclients generieren die Eingabelast. Jedes Eingabeereignis ist ein 1 KB JSON-Dokument. Die Ereignisse simulieren ein IoT-Gerät, das JSON-Daten sendet (für bis zu 1 K-Geräte). Die Verlaufsgröße, die Fensterdauer und die Gesamtlast der Ereignisse verändern sich über zwei Eingabepartitionen.

Identifizierung von Engpässen

Verwenden Sie zum Identifizieren von Engpässen in Ihrer Pipeline den Bereich "Metriken" in Ihrem Azure Stream Analytics Auftrag. Überprüfen Sie Eingabe-/Ausgabeereignisse für den Durchsatz und Wasserzeichenverzögerung oder ausstehende Ereignisse, um festzustellen, ob der Auftrag mit der Eingaberate mithält. Suchen Sie bei Event Hubs-Metriken nach gedrosselten Anforderungen , und passen Sie die Schwellenwerteinheiten entsprechend an. Überprüfen Sie für Azure Cosmos DB-Metriken Maximal verbrauchte RU/s pro Partitionsschlüsselbereich unter "Durchsatz", um sicherzustellen, dass die Partitionsschlüsselbereiche einheitlich genutzt werden. Überwachen Sie für Azure SQL DB Log IO und CPU.

Demovideo

Nächste Schritte

• Introduction to Azure Stream Analytics
• Get started using Azure Stream Analytics
• Scale-Azure Stream Analytics Aufträge
• Azure Stream Analytics Query Language Reference
• Referenz zur Verwaltung der Azure Stream Analytics REST-API