Avvikelseidentifiering i Azure Stream Analytics

Azure Stream Analytics är tillgängligt i både molnet och Azure IoT Edge och erbjuder inbyggda funktioner för maskininlärningsbaserad avvikelseidentifiering som kan användas för att övervaka de två vanligaste avvikelserna: tillfälliga och beständiga. Med funktionerna AnomalyDetection_SpikeAndDip och AnomalyDetection_ChangePoint kan du utföra avvikelseidentifiering direkt i Stream Analytics-jobbet.

Maskininlärningsmodellerna förutsätter en enhetligt samplad tidsserie. Om tidsserien inte är enhetlig kan du infoga ett aggregeringssteg med ett rullande fönster innan du anropar avvikelseidentifiering.

Maskininlärningsåtgärderna stöder inte säsongstrender eller korrelationer med flera variater just nu.

Avvikelseidentifiering med hjälp av maskininlärning i Azure Stream Analytics

Följande video visar hur du identifierar en avvikelse i realtid med hjälp av maskininlärningsfunktioner i Azure Stream Analytics.

Modellbeteende

I allmänhet förbättras modellens noggrannhet med mer data i skjutfönstret. Data i det angivna skjutfönstret behandlas som en del av dess normala värdeintervall för den tidsramen. Modellen tar endast hänsyn till händelsehistorik över skjutfönstret för att kontrollera om den aktuella händelsen är avvikande. När skjutfönstret flyttas avlägsnas gamla värden från modellens träning.

Funktionerna fungerar genom att upprätta ett visst normalläge baserat på vad de har sett hittills. Avvikande värden identifieras genom att jämföras med det etablerade normala inom konfidensnivån. Fönsterstorleken bör baseras på de minsta händelser som krävs för att träna modellen för normalt beteende så att den kan identifiera den när en avvikelse inträffar.

Modellens svarstid ökar med historikstorleken eftersom den måste jämföras med ett högre antal tidigare händelser. Vi rekommenderar att du bara inkluderar det nödvändiga antalet händelser för bättre prestanda.

Luckor i tidsserierna kan bero på att modellen inte tar emot händelser vid vissa tidpunkter. Den här situationen hanteras av Stream Analytics med hjälp av imputationslogik. Historikstorleken, samt en tidslängd, för samma skjutfönster används för att beräkna den genomsnittliga hastighet som händelser förväntas anlända till.

En avvikelsegenerator som är tillgänglig här kan användas för att mata en Iot Hub med data med olika avvikelsemönster. Ett Azure Stream Analytics-jobb kan konfigureras med dessa funktioner för avvikelseidentifiering för att läsa från denna Iot Hub och identifiera avvikelser.

Topp och dopp

Tillfälliga avvikelser i en tidsseriehändelseström kallas toppar och dalar. Toppar och dips kan övervakas med hjälp av den Maskininlärningsbaserade operatorn AnomalyDetection_SpikeAndDip.

I samma skjutfönster, om en andra topp är mindre än den första, är den beräknade poängen för den mindre toppen förmodligen inte tillräckligt betydande jämfört med poängen för den första topp inom den angivna konfidensnivån. Du kan försöka minska modellens konfidensnivå för att identifiera sådana avvikelser. Men om du börjar få för många aviseringar kan du använda ett högre konfidensintervall.

Följande exempelfråga förutsätter en enhetlig indatafrekvens på en händelse per sekund i ett skjutfönster på 2 minuter med en historik på 120 händelser. Den slutliga SELECT-instruktionen extraherar och matar ut poäng- och avvikelsestatusen med en konfidensnivå på 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

Ändringspunkt

Beständiga avvikelser i en tidsseriehändelseström är ändringar i fördelningen av värden i händelseströmmen, till exempel nivåändringar och trender. I Stream Analytics identifieras sådana avvikelser med hjälp av den Machine Learning-baserade AnomalyDetection_ChangePoint-operatorn .

Beständiga ändringar varar mycket längre än toppar och dalar och kan tyda på katastrofala händelser. Beständiga ändringar är vanligtvis inte synliga för blotta ögat, men kan identifieras med operatorn AnomalyDetection_ChangePoint .

Följande bild är ett exempel på en nivåändring:

Följande bild är ett exempel på en trendförändring:

Följande exempelfråga förutsätter en enhetlig indatafrekvens på en händelse per sekund i ett skjutfönster på 20 minuter med en historikstorlek på 1 200 händelser. Den slutliga SELECT-instruktionen extraherar och matar ut poäng- och avvikelsestatusen med en konfidensnivå på 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

Prestandaegenskaper

Prestandan för dessa modeller beror på historikens storlek, fönstervaraktighet, händelsebelastning och om partitionering på funktionsnivå används. Det här avsnittet beskriver dessa konfigurationer och innehåller exempel på hur du upprätthåller inmatningshastigheter på 1 K, 5 K och 10 000 händelser per sekund.

• Historikstorlek – Dessa modeller fungerar linjärt med historikstorlek. Desto längre historikstorlek, desto längre tid tar det för modellerna att poängsätta en ny händelse. Det beror på att modellerna jämför den nya händelsen med var och en av de tidigare händelserna i historikbufferten.
• Fönstervaraktighet – Varaktigheten för fönstret bör återspegla hur lång tid det tar att ta emot så många händelser som anges av historikstorleken. Utan så många händelser i fönstret skulle Azure Stream Analytics imputera saknade värden. Cpu-förbrukningen är därför en funktion av historikstorleken.
• Händelsebelastning – Ju större händelsebelastning, desto mer arbete utförs av modellerna, vilket påverkar CPU-förbrukningen. Jobbet kan skalas ut genom att göra det pinsamt parallellt, förutsatt att det är meningsfullt för affärslogik att använda fler indatapartitioner.
• Partitionering på funktionsnivå Partitionering - av funktionsnivå görs med hjälp PARTITION BY av funktionsanropet för avvikelseidentifiering. Den här typen av partitionering lägger till ett omkostnader eftersom tillståndet måste underhållas för flera modeller samtidigt. Partitionering på funktionsnivå används i scenarier som partitionering på enhetsnivå.

Relation

Historikstorleken, fönstervaraktigheten och den totala händelsebelastningen är relaterade på följande sätt:

windowDuration (i ms) = 1 000 * historySize/ (totalt antal indata per sekund/antal indatapartitioner)

När du partitionerar funktionen efter deviceId lägger du till "PARTITION BY deviceId" i funktionsanropet för avvikelseidentifiering.

Observationer

Följande tabell innehåller dataflödesobservationer för en enskild nod (sex SU) för det icke-partitionerade fallet:

Historikstorlek (händelser)	Varaktighet för fönster (ms)	Totalt antal indatahändelser per sekund
60	55	2 200
600	728	1,650
6 000	10,910	1 100

Följande tabell innehåller dataflödesobservationer för en enskild nod (sex SU) för det partitionerade fallet:

Historikstorlek (händelser)	Varaktighet för fönster (ms)	Totalt antal indatahändelser per sekund	Antal enheter
60	1,091	1 100	10
600	10,910	1 100	10
6 000	218,182	<550	10
60	21,819	550	100
600	218,182	550	100
6 000	2,181,819	<550	100

Exempelkoden för att köra de icke-partitionerade konfigurationerna ovan finns i lagringsplatsen För direktuppspelning i skala för Azure-exempel. Koden skapar ett stream analytics-jobb utan partitionering på funktionsnivå, som använder Event Hubs som indata och utdata. Indatabelastningen genereras med testklienter. Varje indatahändelse är ett json-dokument på 1 KB. Händelser simulerar en IoT-enhet som skickar JSON-data (för upp till 1 K enheter). Historikstorleken, fönstervaraktigheten och den totala händelsebelastningen varierar mellan två indatapartitioner.

Kommentar

Om du vill ha en mer exakt uppskattning kan du anpassa exemplen så att de passar ditt scenario.

Identifiera flaskhalsar

Om du vill identifiera flaskhalsar i pipelinen använder du fönstret Mått i ditt Azure Stream Analytics-jobb. Granska Indata-/utdatahändelser för dataflöde och "Vattenstämpelfördröjning" eller Efterloggade händelser för att se om jobbet håller jämna steg med indatahastigheten. För Event Hubs-mått letar du efter begränsade begäranden och justerar tröskelvärdesenheterna i enlighet med detta. För Azure Cosmos DB-mått läser du Max förbrukade RU/s per partitionsnyckelintervall under Dataflöde för att säkerställa att partitionsnyckelintervallen används på ett enhetligt sätt. För Azure SQL DB övervakar du Logg-I/O och CPU.

Demonstrationsvideo

Nästa steg

• Introduktion till Azure Stream Analytics
• Komma igång med Azure Stream Analytics
• Skala Azure Stream Analytics-jobb
• Referens för Azure Stream Analytics-frågespråket
• Referens för Azure Stream Analytics Management REST API