Anomalieerkennung in Azure Stream Analytics

Azure Stream Analytics ist sowohl in der Cloud als auch in Azure IoT Edge verfügbar und bietet integrierte, auf Machine Learning basierende Anomalieerkennungsfunktionen, mit denen die beiden am häufigsten auftretenden Anomalien überwacht werden können: temporäre und persistente. Mit den Funktionen AnomalyDetection_SpikeAndDip und AnomalyDetection_ChangePoint können Sie die 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, können Sie vor dem Aufruf der Anomalieerkennung einen Aggregationsschritt mit einem rollierenden Fenster einfügen.

Die Machine Learning-Vorgänge unterstützen derzeit keine saisonalen Trends oder multivariaten Korrelationen.

Anomalieerkennung mithilfe von Machine Learning in Azure Stream Analytics

Im folgenden Video wird veranschaulicht, wie Sie mithilfe von Machine Learning-Funktionen in Azure Stream Analytics eine Anomalie in Echtzeit 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 der etablierten Normalverteilung 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. Es wird empfohlen, nur die erforderliche Anzahl von Ereignissen einzuschließen, um eine bessere Leistung zu erzielen.

Lücken in der Zeitreihe können darauf zurückzuführen sein, dass das Modell zu bestimmten Zeitpunkten keine Ereignisse empfängt. Diese Situation wird von Stream Analytics mithilfe von Imputationslogik behandelt. Die Verlaufsgröße sowie eine Zeitdauer für dasselbe gleitende Fenster werden verwendet, um die durchschnittliche Rate zu berechnen, mit der Ereignisse erwartet werden.

Ein hier verfügbarer Anomaliegenerator kann verwendet werden, um einen IoT Hub mit Daten mit unterschiedlichen Anomaliemustern zu füttern. Ein Azure Stream Analytics-Auftrag kann mit diesen Anomalieerkennungsfunktionen eingerichtet werden, um aus 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. Spitzen und Einbrüche können mit dem auf maschinellem Lernen basierenden Operator AnomalyDetection_SpikeAndDip überwacht werden.

Wenn im selben gleitenden Fenster eine zweite Spitze kleiner als die erste ist, ist die berechnete Punktzahl für die kleinere Spitze im Vergleich zu der Punktzahl für die erste Spitze innerhalb des angegebenen Konfidenzniveaus wahrscheinlich nicht signifikant genug. Sie können versuchen, das Konfidenzniveau des Modells zu verringern, um solche Anomalien zu erkennen. Wenn Sie jedoch zu viele Warnungen erhalten, können Sie ein höheres Konfidenzintervall verwenden.

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 werden solche Anomalien mithilfe des auf maschinellem Lernen basierenden AnomalyDetection_ChangePoint Operators erkannt.

Anhaltende Veränderungen dauern viel länger als Spitzen und Einbrüche und können auf katastrophale Ereignisse hinweisen. Anhaltende Veränderungen sind in der Regel nicht mit bloßem Auge sichtbar, können aber mit dem AnomalyDetection_ChangePoint Bediener erkannt werden.

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 Verlaufsgröße, der Fensterdauer, der Ereignislast und davon ab, ob die Partitionierung auf Funktionsebene verwendet wird. In diesem Abschnitt werden diese Konfigurationen erläutert und Beispiele für die Aufrechterhaltung von Erfassungsraten von 1 K, 5 K und 10 K Ereignissen pro Sekunde bereitgestellt.

• Verlaufsgröße : Diese Modelle funktionieren linear mit der Verlaufsgröße. Je länger die Verlaufsgröße, desto länger brauchen die Modelle, um ein neues Ereignis zu bewerten. Dies liegt daran, dass die Modelle das neue Ereignis mit jedem der vergangenen Ereignisse im Verlaufspuffer vergleichen.
• Fensterdauer - Die Fensterdauer sollte widerspiegeln, wie lange es dauert, bis so viele Ereignisse empfangen werden, wie durch die Verlaufsgröße angegeben. Ohne so viele Ereignisse im Fenster würde Azure Stream Analytics fehlende Werte imputieren. Daher ist der CPU-Verbrauch eine Funktion der Verlaufsgröße.
• Ereignislast : Je größer die Ereignislast, desto mehr Arbeit wird von den Modellen ausgeführt, was sich auf die CPU-Auslastung auswirkt. Der Auftrag kann horizontal hochskaliert werden, indem er peinlich parallel gemacht wird, vorausgesetzt, es ist sinnvoll, dass die Geschäftslogik mehr Eingabepartitionen verwendet.
• Partitionierung - auf FunktionsebeneDie Partitionierung auf Funktionsebene erfolgt mithilfe PARTITION BY des Funktionsaufrufs der Anomalieerkennung. Diese Art der Partitionierung führt zu einem Mehraufwand, da der Zustand für mehrere Modelle gleichzeitig beibehalten werden muss. Die Partitionierung auf Funktionsebene wird in Szenarien wie der Partitionierung auf Geräteebene verwendet.

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 enthält die Durchsatzbeobachtungen für einen einzelnen Knoten (sechs SU) für den nicht partitionierten Fall:

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

Beispielcode zum Ausführen der oben genannten nicht partitionierten Konfigurationen befindet sich im Streaming At Scale-Repository von Azure Samples. Der Code erstellt einen Stream Analytics-Auftrag ohne Partitionierung auf Funktionsebene, der Event Hubs als Ein- und Ausgabe verwendet. Die Eingabelast wird mit Hilfe von Testclients generiert. Jedes Eingabeereignis ist ein 1 KB großes JSON-Dokument. Ereignisse simulieren ein IoT-Gerät, das JSON-Daten sendet (für Geräte mit bis zu 1 KB). Die Verlaufsgröße, die Fensterdauer und die Gesamtlast des Ereignisses werden über zwei Eingabepartitionen hinweg variiert.

Identifizierung von Engpässen

Um Engpässe in Ihrer Pipeline zu identifizieren, verwenden Sie den Bereich Metriken in Ihrem Azure Stream Analytics-Auftrag. Überprüfen Sie Eingabe-/Ausgabeereignisse hinsichtlich des Durchsatzes sowie "Wasserzeichenverzögerung" oder Ereignisse im Rückstand, um festzustellen, ob der Auftrag mit der Eingangsrate Schritt halten kann. Suchen Sie bei Event Hubs-Metriken nach Gedrosselte Anforderungen, und passen Sie die Schwellenwerteinheiten entsprechend an. Überprüfen Sie für Azure Cosmos DB-Metriken Max. genutzte RU/Sek. pro Partitionsschlüsselbereich unter „Durchsatz“, um sicherzustellen, dass Ihre Partitionsschlüsselbereiche gleichmäßig genutzt werden. Überwachen Sie für Azure SQL-DB Protokoll-E/A und CPU.

Demovideo

Nächste Schritte

• Einführung in Azure Stream Analytics
• Erste Schritte mit Azure Stream Analytics
• Skalieren von Azure Stream Analytics-Aufträgen
• Stream Analytics Query Language Reference (in englischer Sprache)
• Referenz zur Azure Stream Analytics-Verwaltungs-REST-API