Rilevamento anomalie in Azure Stream Analytics

Disponibile sia nel cloud che nel Azure IoT Edge, Azure Stream Analytics offre funzionalità predefinite di rilevamento anomalie basate su Machine Learning che è possibile usare per monitorare le due anomalie più comuni: temporanee e persistenti. Usando le funzioni AnomalyDetection_SpikeAndDip e AnomalyDetection_ChangePoint , è possibile eseguire il rilevamento anomalie direttamente nel processo di Analisi di flusso.

I modelli di Machine Learning presuppongono una serie temporale campionata in modo uniforme. Se la serie temporale non è uniforme, inserire un passaggio di aggregazione con una finestra a cascata prima di chiamare il rilevamento anomalie.

Le operazioni di Machine Learning non supportano attualmente tendenze di stagionalità o correlazioni multivariate.

Rilevamento anomalie con Machine Learning in Azure Stream Analytics

Il video seguente illustra come rilevare un'anomalia in tempo reale usando le funzioni di Machine Learning in Azure Stream Analytics.

Comportamento del modello

In genere, l'accuratezza del modello migliora con più dati nella finestra scorrevole. I dati nella finestra temporale scorrevole specificata vengono considerati come parte dell'intervallo normale di valori per tale intervallo di tempo. Il modello considera solo la cronologia degli eventi nella finestra temporale scorrevole per verificare se l'evento corrente è anomalo. Man mano che la finestra temporale scorrevole scorre, i vecchi valori vengono rimossi dal training del modello.

Le funzioni operano stabilendo una certa normalità in base a ciò che hanno visto finora. I valori anomali vengono identificati confrontandoli con la norma stabilita, all'interno del livello di fiducia. Le dimensioni della finestra devono essere basate sugli eventi minimi necessari per eseguire il training del modello per il comportamento normale in modo che, quando si verifica un'anomalia, sia in grado di riconoscerlo.

Il tempo di risposta del modello aumenta con le dimensioni della cronologia perché deve essere confrontato con un numero maggiore di eventi precedenti. Per prestazioni migliori, includere solo il numero necessario di eventi.

Le lacune nella serie temporale possono verificarsi quando il modello non riceve eventi in determinati momenti. Analisi di flusso gestisce questa situazione usando la logica di imputazione. Le dimensioni della cronologia e una durata per la stessa finestra temporale scorrevole vengono usate per calcolare la frequenza media con cui si prevede che arrivino gli eventi.

È possibile usare un generatore anomaly per inserire un IoT Hub con dati che contengono modelli di anomalie diversi. È possibile configurare un processo Azure Stream Analytics usando queste funzioni di rilevamento delle anomalie per leggere da questo IoT Hub e rilevare le anomalie.

Picchi e flessioni

Le anomalie temporanee in un flusso di eventi delle serie temporali sono note come picchi e dips. È possibile monitorare picchi e flessioni usando l'operatore basato su Machine Learning, AnomalyDetection_SpikeAndDip.

Nella stessa finestra temporale scorrevole, se un secondo picco è inferiore al primo, il punteggio calcolato per il picco più piccolo potrebbe non essere sufficientemente significativo rispetto al punteggio per il primo picco all'interno del livello di attendibilità specificato. È possibile provare a ridurre il livello di attendibilità del modello per rilevare tali anomalie. Tuttavia, se si inizia a ottenere troppi avvisi, usare un intervallo di confidenza più elevato.

La query di esempio seguente presuppone una frequenza di input uniforme di un evento al secondo in una finestra temporale scorrevole di 2 minuti con una cronologia di 120 eventi. L'istruzione SELECT finale estrae e restituisce il punteggio e lo stato dell'anomalia con un livello di attendibilità del 95%.

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

Punto di modifica

Le anomalie persistenti in un flusso di eventi di una serie temporale sono modifiche nella distribuzione dei valori nel flusso di eventi, ad esempio modifiche al livello e tendenze. In Analisi di flusso l'operatore Machine Learning basato su AnomalyDetection_ChangePoint rileva queste anomalie.

Le modifiche persistenti durano molto più a lungo dei picchi e delle immersioni e potrebbero indicare eventi irreversibili. Le modifiche persistenti non sono in genere visibili all'occhio nudo, ma l'operatore AnomalyDetection_ChangePoint può rilevarli.

L'immagine seguente è un esempio di modifica del livello:

L'immagine seguente è un esempio di modifica della tendenza:

La query di esempio seguente presuppone una frequenza di input uniforme di un evento al secondo in una finestra temporale scorrevole di 20 minuti con dimensioni della cronologia di 1.200 eventi. L'istruzione SELECT finale estrae e restituisce il punteggio e lo stato delle anomalie con un livello di attendibilità pari a 80%.

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

Caratteristiche delle prestazioni

Le prestazioni di questi modelli dipendono dalle dimensioni della cronologia, dalla durata della finestra, dal caricamento degli eventi e dall'uso del partizionamento a livello di funzione. In questa sezione vengono discusse queste configurazioni e forniti esempi su come mantenere i tassi di ingestione di 1 K, 5 K e 10 K eventi al secondo.

• Dimensioni cronologia : questi modelli vengono eseguiti in modo lineare con le dimensioni della cronologia. Più lunga è la dimensione della cronologia, più i modelli impiegano per assegnare un punteggio a un nuovo evento. I modelli confrontano il nuovo evento con ognuno degli eventi precedenti nel buffer della cronologia.
• Durata finestra : la durata della finestra deve riflettere il tempo necessario per ricevere tutti gli eventi specificati dalle dimensioni della cronologia. Senza un numero sufficiente di eventi nella finestra, Azure Stream Analytics attribuirà valori mancanti. Di conseguenza, il consumo della CPU è una funzione della dimensione della cronologia.
• Caricamento eventi : maggiore è il carico degli eventi, maggiore è il lavoro eseguito dai modelli, che influisce sull'utilizzo della CPU. È possibile aumentare il carico di lavoro rendendolo facilmente parallelizzabile, presupponendo che sia opportuno utilizzare più partizioni di input per la logica aziendale.
• Partizionamento a livello di funzione: usare PARTITION BY nella chiamata di funzione di rilevamento anomalie per eseguire il partizionamento a livello di funzione. Questo tipo di partizionamento comporta un sovraccarico, perché il processo deve mantenere lo stato per più modelli contemporaneamente. Usare il partizionamento a livello di funzione in scenari come il partizionamento a livello di dispositivo.

Relazione

Le dimensioni della cronologia, la durata della finestra e il carico totale degli eventi sono correlati nel modo seguente:

windowDuration (in ms) = 1000 * historySize / (numero totale di eventi di input al secondo / Numero di partizioni di input)

Quando si partiziona la funzione in base a deviceId, aggiungere "PARTITION BY deviceId" alla chiamata di funzione di rilevamento anomalie.

Osservazioni

La tabella seguente illustra le misurazioni della velocità effettiva per un singolo nodo (sei SU) per il caso non partizionato.

La tabella seguente illustra le osservazioni sul throughput per un singolo nodo (sei SU) per il caso partizionato.

È possibile trovare il codice di esempio per eseguire le configurazioni non partizionate nel repository Streaming At Scale degli esempi di Azure. Il codice crea un processo di Analisi di flusso senza partizionamento a livello di funzione, che usa Hub eventi come input e output. I client di test generano il carico di input. Ogni evento di input è un documento JSON di 1 KB. Gli eventi simulano un dispositivo IoT che invia dati JSON (per un massimo di 1 K dispositivi). Le dimensioni della cronologia, la durata della finestra e il carico totale degli eventi variano in due partizioni di input.

Individuazione dei colli di bottiglia

Per identificare i colli di bottiglia nella pipeline, usare il riquadro Metriche nel processo di Azure Stream Analytics. Esaminare Eventi di input/output per il throughput e il "Watermark Delay" o Eventi in coda per verificare se il processo mantiene il passo con la frequenza di input. Per le metriche di Hub eventi, cercare Richieste limitate e regolare le unità di soglia di conseguenza. Per le metriche di Azure Cosmos DB, esaminare Max consumato RU/s per intervallo di chiavi di partizione sotto Throughput per garantire che gli intervalli di chiavi di partizione vengano consumati in modo uniforme. Per Azure SQL DB, monitorare Log IO e CPU.

Video dimostrativo

Passaggi successivi

• Introduzione a Azure Stream Analytics
• Introduzione all'uso di Azure Stream Analytics
• Ridimensionare i processi di Azure Stream Analytics
• Azure Stream Analytics Informazioni di riferimento sul linguaggio di query
• Informazioni di riferimento sulle API REST di gestione Azure Stream Analytics