Avvikelseidentifiering i Azure Stream AnalyticsAnomaly detection in Azure Stream Analytics

Tillgängliga i både i molnet och Azure IoT Edge, Azure Stream Analytics erbjuder inbyggda baserat avvikelseidentifiering funktioner som kan användas för att övervaka två oftast förekommande avvikelser för maskininlärning: temporär och permanent.Available in both the cloud and Azure IoT Edge, Azure Stream Analytics offers built-in machine learning based anomaly detection capabilities that can be used to monitor the two most commonly occurring anomalies: temporary and persistent. Med den AnomalyDetection_SpikeAndDip och AnomalyDetection_ChangePoint funktion, kan du utföra avvikelseidentifiering direkt i ditt Stream Analytics-jobb.With the AnomalyDetection_SpikeAndDip and AnomalyDetection_ChangePoint functions, you can perform anomaly detection directly in your Stream Analytics job.

Machine learning-modeller förutsätter en enhetligt provade tidsserie.The machine learning models assume a uniformly sampled time series. Om tidsserien inte uniform, kan du infoga ett aggregering steg med ett rullande fönster innan du anropar avvikelseidentifiering.If the time series is not uniform, you may insert an aggregation step with a tumbling window prior to calling anomaly detection.

Machine learning-åtgärder stöder inte säsongsberoende trender eller flera variate korrelationer just nu.The machine learning operations do not support seasonality trends or multi-variate correlations at this time.

Beteendet för enhetsmodellenModel behavior

I allmänhet förbättrar modellens Precision med mer data i Hoppande fönster.Generally, the model's accuracy improves with more data in the sliding window. Data i den angivna skjutfönster behandlas som en del av dess normala värdeintervall för den aktuella tidsperioden.The data in the specified sliding window is treated as part of its normal range of values for that time frame. Modellen endast tar hänsyn till Händelsehistorik över Hoppande fönster för att kontrollera om den aktuella händelsen är avvikande.The model only considers event history over the sliding window to check if the current event is anomalous. När fönstret glidande flyttas avlägsnas gamla värden från den modellen.As the sliding window moves, old values are evicted from the model’s training.

Funktionerna fungerar genom att upprätta en vissa normal baserat på vad de har sett hittills.The functions operate by establishing a certain normal based on what they have seen so far. Extremvärden identifieras genom att jämföra mot den etablerade standarden inom konfidensnivån.Outliers are identified by comparing against the established normal, within the confidence level. Fönstrets storlek ska baseras på de lägsta händelser som krävs för att träna modellen för normala beteende så att när ett fel inträffar får det skulle kunna identifiera den.The window size should be based on the minimum events required to train the model for normal behavior so that when an anomaly occurs, it would be able to recognize it.

Modellens svarstiden ökar med historikstorlek eftersom den måste jämföra med ett högre antal senaste händelser.The model's response time increases with history size because it needs to compare against a higher number of past events. Vi rekommenderar att bara inkludera nödvändigt antal händelser för bättre prestanda.It is recommended to only include the necessary number of events for better performance.

Luckor i tidsserien kan vara ett resultat av modellen inte ta emot händelser vid vissa tidpunkter i tid.Gaps in the time series can be a result of the model not receiving events at certain points in time. Den här situationen hanteras av Stream Analytics med hjälp av uppräkning logik.This situation is handled by Stream Analytics using imputation logic. Historikstorlek, samt en varaktighet för samma skjutfönster används för att beräkna Genomsnittshastigheten då förväntas händelser tas emot.The history size, as well as a time duration, for the same sliding window is used to calculate the average rate at which events are expected to arrive.

En tillgänglig avvikelseidentifiering generator här kan användas för att mata in en Iot-hubb med data med olika avvikelseidentifiering mönster.An anomaly generator available here can be used to feed an Iot Hub with data with different anomaly patterns. ASA-jobb kan konfigureras med dessa funktioner för identifiering av avvikelser att läsa från den här Iot-hubben och identifiera avvikelser.An ASA job can be set up with these anomaly detection functions to read from this Iot Hub and detect anomalies.

Topp- och dipSpike and dip

Tillfällig avvikelser i en time series händelseströmmen är känt som toppar och dalar.Temporary anomalies in a time series event stream are known as spikes and dips. Toppar och dalar kan övervakas med operatorn Maskininlärningsbaserade AnomalyDetection_SpikeAndDip.Spikes and dips can be monitored using the Machine Learning based operator, AnomalyDetection_SpikeAndDip.

Exempel på topp- och dip-avvikelseidentifiering

I samma skjutfönster, om en andra topp är mindre än den första som är den beräknade poängen för mindre topp förmodligen inte betydande tillräckligt jämfört med poäng för den första topp inom konfidensnivån har angetts.In the same sliding window, if a second spike is smaller than the first one, the computed score for the smaller spike is probably not significant enough compared to the score for the first spike within the confidence level specified. Du kan försök minska modellens konfidensnivån för att identifiera sådana avvikelser.You can try decreasing the model's confidence level to detect such anomalies. Om du börjar få för många aviseringar, kan du använda ett högre konfidensintervall.However, if you start to get too many alerts, you can use a higher confidence interval.

Följande exempelfråga förutsätter en enhetlig inkommande sats för en händelse per sekund i en glidande femminutersperiod i 2 med en historik över händelser på 120.The following example query assumes a uniform input rate of one event per second in a 2-minute sliding window with a history of 120 events. Sista SELECT-instruktionen extraherar och visar blobens poäng och avvikelseidentifiering status med en konfidensnivå på 95%.The final SELECT statement extracts and outputs the score and anomaly status with a confidence level of 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

Ändra återställningspunktChange point

Beständiga avvikelser i en time series händelseströmmen är ändringar i distributionen av värden i händelseströmmen, som ändras och trender.Persistent anomalies in a time series event stream are changes in the distribution of values in the event stream, like level changes and trends. I Stream Analytics sådana avvikelserna identifieras med hjälp av den Maskininlärningsbaserade AnomalyDetection_ChangePoint operator.In Stream Analytics, such anomalies are detected using the Machine Learning based AnomalyDetection_ChangePoint operator.

Permanenta ändringar räcker mycket längre än toppar och dalar och kan tyda på kritiska händelser.Persistent changes last much longer than spikes and dips and could indicate catastrophic event(s). Permanenta ändringar visas inte vanligtvis för blotta ögat, men kan identifieras med den AnomalyDetection_ChangePoint operator.Persistent changes are not usually visible to the naked eye, but can be detected with the AnomalyDetection_ChangePoint operator.

Följande bild är ett exempel på en nivå ändring:The following image is an example of a level change:

Exempel på nivåändring avvikelseidentifiering

Följande bild är ett exempel på en trend ändring:The following image is an example of a trend change:

Exempel på trend ändra avvikelseidentifiering

Följande exempelfråga förutsätter en enhetlig inkommande sats för en händelse per sekund i ett skjutfönster på 20 minuter med en historikstorlek på 1200-händelser.The following example query assumes a uniform input rate of one event per second in a 20-minute sliding window with a history size of 1200 events. Sista SELECT-instruktionen extraherar och visar blobens poäng och avvikelseidentifiering status med en konfidensnivå på 80%.The final SELECT statement extracts and outputs the score and anomaly status with a confidence level of 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

PrestandaegenskaperPerformance characteristics

Prestanda för dessa modeller beror på tidigare storlek, fönstervaraktigheten, händelsebelastningen, och om funktionen på partitionering används.The performance of these models depends on the history size, window duration, event load, and whether function level partitioning is used. Det här avsnittet beskriver de här konfigurationerna och innehåller exempel att kunna fortsätta arbeta enligt datainmatningsfrekvensen 1K, 5K och 10K händelser per sekund.This section discusses these configurations and provides samples for how to sustain ingestion rates of 1K, 5K and 10K events per second.

  • Historikstorlek -dessa modeller utföra linjärt med historikstorlek.History size - These models perform linearly with history size. Historikstorlek, desto längre tid tar ju längre modellerna kan bedöma de en ny händelse.The longer the history size, the longer the models take to score a new event. Det beror på att modellerna jämför den nya händelsen till var och en av tidigare händelser i bufferten historik.This is because the models compare the new event with each of the past events in the history buffer.
  • Fönstervaraktighetenfönstervaraktigheten bör återspegla hur lång tid det tar att ta emot så många händelser som den anges av den tidigare storleken.Window duration - The Window duration should reflect how long it takes to receive as many events as specified by the history size. Azure Stream Analytics skulle utan så många händelser i fönstret sedan imputera värden som saknas.Without that many events in the window, Azure Stream Analytics would impute missing values. CPU-förbrukning är därför en funktion av samma historikstorlek som.Hence, CPU consumption is a function of the history size.
  • Händelsebelastningen – ju större den händelsebelastningen, desto mer arbete som utförs av modeller, vilket påverkar CPU-förbrukning.Event load - The greater the event load, the more work that is performed by the models, which impacts CPU consumption. Jobbet kan skaländras ut genom att göra det embarrassingly parallel, förutsatt att det passar för affärslogik för att använda mer inkommande partitioner.The job can be scaled out by making it embarrassingly parallel, assuming it makes sense for business logic to use more input partitions.
  • Funktionen på partitionering - funktion på partitionering görs med hjälp av PARTITION BY i funktionsanropet för identifiering av avvikelser.Function level partitioning - Function level partitioning is done by using PARTITION BY within the anomaly detection function call. Den här typen av partitionering lägger till en belastning som tillstånd måste underhållas för flera modeller på samma gång.This type of partitioning adds an overhead, as state needs to be maintained for multiple models at the same time. Funktionen på partitionering används i scenarier som enheten på partitionering.Function level partitioning is used in scenarios like device level partitioning.

RelationRelationship

Historikstorlek, fönstervaraktigheten och totala händelsebelastningen relaterade på följande sätt:The history size, window duration, and total event load are related in the following way:

windowDuration (i ms) = 1000 * historySize / (totalt antal indata händelser Per sekund / antalet partitioner för indata)windowDuration (in ms) = 1000 * historySize / (Total Input Events Per Sec / Input Partition Count)

Lägg till ”PARTITION av deviceId” till funktionsanropet avvikelseidentifiering identifiering när partitionering funktionen av deviceId.When partitioning the function by deviceId, add “PARTITION BY deviceId” to the anomaly detection function call.

ObservationerObservations

Följande tabell innehåller dataflöde observationer för en enskild nod (6 SU) för icke-partitionerad:The following table includes the throughput observations for a single node (6 SU) for the non-partitioned case:

Historikstorlek (händelser)History size (events) Fönstret varaktighet (ms)Window duration (ms) Totalt antal inkommande händelser per sekundTotal input events per sec
6060 5555 2,2002,200
600600 728728 1,6501,650
6,0006,000 10,91010,910 1,1001,100

Följande tabell innehåller dataflöde observationer för en enskild nod (6 SU) för det partitionerade ärendet:The following table includes the throughput observations for a single node (6 SU) for the partitioned case:

Historikstorlek (händelser)History size (events) Fönstret varaktighet (ms)Window duration (ms) Totalt antal inkommande händelser per sekundTotal input events per sec EnhetsantalDevice count
6060 1,0911,091 1,1001,100 1010
600600 10,91010,910 1,1001,100 1010
6,0006,000 218,182218,182 <550<550 1010
6060 21,81921,819 550550 100100
600600 218,182218,182 550550 100100
6,0006,000 2,181,8192,181,819 <550<550 100100

Exempelkod för att köra de icke-partitionerad konfigurationerna som angetts ovan finns i den direktuppspelning i skala lagringsplatsen av Azure-exempel.Sample code to run the non-partitioned configurations above is located in the Streaming At Scale repo of Azure Samples. Koden skapar ett stream analytics-jobb med ingen funktion på partitionering, som använder Event Hub som indata och utdata.The code creates a stream analytics job with no function level partitioning, which uses Event Hub as input and output. Den inkommande belastningen genereras med hjälp av testklienter.The input load is generated using test clients. Varje händelse är ett json-dokument på 1KB.Each input event is a 1KB json document. Händelser simulera en IoT-enhet som skickar JSON-data (för upp till 1 K-enheter).Events simulate an IoT device sending JSON data (for up to 1K devices). Historikstorlek, fönstervaraktigheten och totala händelsebelastningen varieras under 2 inkommande partitioner.The history size, window duration, and total event load are varied over 2 input partitions.

Anteckning

Anpassa exemplen för att passa ditt scenario för en mer tillförlitlig uppskattning.For a more accurate estimate, customize the samples to fit your scenario.

Identifiera flaskhalsarIdentifying bottlenecks

Använda fönstret mått i Azure Stream Analytics-jobb för att identifiera flaskhalsar i din pipeline.Use the Metrics pane in your Azure Stream Analytics job to identify bottlenecks in your pipeline. Granska indata/utdata-händelser för dataflöde och ”vattenstämpel fördröjning” eller eftersläpande händelser att se om jobbet är att hålla igång med indata.Review Input/Output Events for throughput and "Watermark Delay" or Backlogged Events to see if the job is keeping up with the input rate. För Event Hub-mått, leta efter begränsade begäranden och justera tröskelvärdet enheter därefter.For Event Hub metrics, look for Throttled Requests and adjust the Threshold Units accordingly. Cosmos DB-mått, granska Max konsumerade RU/s per partitionsnyckelintervall under dataflöde för att se till att partitionen nyckelintervall används ett enhetligt sätt.For Cosmos DB metrics, review Max consumed RU/s per partition key range under Throughput to ensure your partition key ranges are uniformly consumed. Azure SQL DB, övervaka logg-IO och CPU.For Azure SQL DB, monitor Log IO and CPU.

Avvikelseidentifiering med machine learning i Azure Stream AnalyticsAnomaly detection using machine learning in Azure Stream Analytics

Följande videoklipp visar hur du kan identifiera avvikelser i realtid med machine learning-funktioner i Azure Stream Analytics.The following video demonstrates how to detect an anomaly in real time using machine learning functions in Azure Stream Analytics.

Nästa stegNext steps