Sdílet prostřednictvím


Detekce anomálií ve službě Azure Stream Analytics

Azure Stream Analytics je k dispozici v cloudu i v Azure IoT Edge a nabízí integrované funkce detekce anomálií založených na strojovém učení, které je možné použít k monitorování dvou nejčastěji se vyskytujících anomálií: dočasných a trvalých. Pomocí funkcí AnomalyDetection_SpikeAndDip a AnomalyDetection_ChangePoint můžete provádět detekci anomálií přímo v úloze Stream Analytics.

Modely strojového učení předpokládají jednotně vzorkovanou časovou řadu. Pokud časová řada není jednotná, můžete před voláním detekce anomálií vložit krok agregace s přeskakujícím oknem.

Operace strojového učení v současné době nepodporují trendy sezónnosti ani korelace s více variatemi.

Detekce anomálií na základě strojového učení v prostředí Azure Stream Analytics

Následující video ukazuje, jak detekovat anomálie v reálném čase pomocí funkcí strojového učení ve službě Azure Stream Analytics.

Chování modelu

Obecně platí, že přesnost modelu se zlepšuje s více daty v posuvném okně. Data v zadaném posuvném okně se považují za součást svého normálního rozsahu hodnot pro daný časový rámec. Model považuje historii událostí pouze za posuvné okno a zkontroluje, jestli je aktuální událost neobvyklá. Při pohybu posuvného okna se staré hodnoty vyřadí z trénování modelu.

Funkce fungují vytvořením určitého normálního stavu na základě toho, co dosud viděli. Odlehlé hodnoty jsou identifikovány porovnáním se zavedeným normálním stavem v rámci úrovně spolehlivosti. Velikost okna by měla být založena na minimálních událostech potřebných k trénování modelu pro normální chování, aby při výskytu anomálií bylo možné ho rozpoznat.

Doba odezvy modelu se zvyšuje s velikostí historie, protože musí porovnat s vyšším počtem minulých událostí. Doporučujeme zahrnout pouze potřebný počet událostí pro lepší výkon.

Mezery v časové řadě můžou být výsledkem toho, že model nepřijímá události v určitých časových bodech. Tuto situaci zpracovává Stream Analytics pomocí logiky imputace. Velikost historie a doba trvání pro stejné posuvné okno se používá k výpočtu průměrné míry, s jakou mají události dorazit.

Generátor anomálií, který je zde k dispozici, se dá použít k podávání Iot Hubu s daty s různými vzory anomálií. Pomocí těchto funkcí detekce anomálií je možné nastavit úlohu Azure Stream Analytics pro čtení z této služby Iot Hub a detekci anomálií.

Špička a pokles

Dočasné anomálie v datovém proudu událostí časové řady se označují jako špičky a poklesy. Špičky a poklesy je možné monitorovat pomocí operátoru založeného na AnomalyDetection_SpikeAndDip počítače Učení.

Example of spike and dip anomaly

Pokud je ve stejném posuvném okně menší než první špička, vypočítané skóre pro menší špičku pravděpodobně není dostatečně významné v porovnání s skóre pro první špičku v zadané úrovni spolehlivosti. Pokud chcete zjistit takové anomálie, můžete zkusit snížit úroveň spolehlivosti modelu. Pokud ale začnete dostávat příliš mnoho upozornění, můžete použít vyšší interval spolehlivosti.

Následující příklad dotazu předpokládá jednotnou vstupní rychlost jedné události za sekundu v 2minutovém posuvném okně s historií 120 událostí. Konečný příkaz SELECT extrahuje a vypíše skóre a stav anomálií s úrovní spolehlivosti 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

Bod změny

Trvalé anomálie v datovém proudu událostí časové řady jsou změny v distribuci hodnot v datovém proudu událostí, jako jsou změny na úrovni a trendy. V Stream Analytics se takové anomálie detekují pomocí operátoru Učení založeného na AnomalyDetection_ChangePoint počítače.

Trvalé změny trvají mnohem déle než špičky a poklesy a mohly by značit katastrofické události. Trvalé změny nejsou obvykle viditelné pro nahý oko, ale je možné je zjistit pomocí operátoru AnomalyDetection_ChangePoint .

Následující obrázek je příkladem změny úrovně:

Example of level change anomaly

Na následujícím obrázku je příklad změny trendu:

Example of trend change anomaly

Následující příklad dotazu předpokládá jednotnou vstupní rychlost jedné události za sekundu v 20minutovém posuvném okně s velikostí historie 1 200 událostí. Konečný příkaz SELECT extrahuje a vypíše skóre a stav anomálií s úrovní spolehlivosti 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

Charakteristiky výkonu

Výkon těchtomodelůch Tato část popisuje tyto konfigurace a poskytuje ukázky pro udržení míry příjmu 1 K, 5 K a 10 tisíc událostí za sekundu.

  • Velikost historie – Tyto modely fungují lineárně s velikostí historie. Čím delší je velikost historie, tím déle modely zabírají skóre nové události. Je to proto, že modely porovnávají novou událost s každou z minulých událostí v vyrovnávací paměti historie.
  • Doba trvání okna – Doba trvání okna by měla odrážet dobu trvání příjmu tolik událostí, kolik určuje velikost historie. Bez toho, aby v okně bylo mnoho událostí, by služba Azure Stream Analytics imputovala chybějící hodnoty. Proto je spotřeba procesoru funkcí velikosti historie.
  • Zatížení událostí – čím větší je zatížení událostí, tím více práce provádí modely, což má vliv na spotřebu procesoru. Úlohu je možné škálovat tak, že ji ztrapníte paralelně, za předpokladu, že má smysl pro obchodní logiku používat více vstupních oddílů.
  • Dělení - na úrovni funkce se provádí pomocí PARTITION BY volání funkce detekce anomálií. Tento typ dělení přidává režii, protože je potřeba udržovat stav pro více modelů najednou. Dělení na úrovni funkce se používá ve scénářích, jako je dělení na úrovni zařízení.

Vztah

Velikost historie, doba trvání okna a celkové zatížení událostí souvisejí následujícím způsobem:

windowDuration (in ms) = 1000 * historySize / (celkový počet vstupních událostí za sekundu / Počet vstupních oddílů)

Při dělení funkce podle id zařízení přidejte "PARTITION BY deviceId" do volání funkce detekce anomálií.

Postřehy

Následující tabulka obsahuje pozorování propustnosti jednoho uzlu (šest jednotek SU) pro případ, který není součástí:

Velikost historie (události) Doba trvání okna (ms) Celkový počet vstupních událostí za sekundu
60 55 2 200
600 728 1,650
6 000 10,910 1 100

Následující tabulka obsahuje pozorování propustnosti jednoho uzlu (šest jednotek SU) pro dělený případ:

Velikost historie (události) Doba trvání okna (ms) Celkový počet vstupních událostí za sekundu Počet zařízení
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

Vzorový kód pro spuštění výše nedílených konfigurací se nachází v úložišti Stream At Scale ukázek Azure. Kód vytvoří úlohu stream Analytics bez dělení na úrovni funkce, která jako vstup a výstup používá službu Event Hubs. Vstupní zatížení se generuje pomocí testovacích klientů. Každá vstupní událost je dokument JSON 1 kB. Události simulují zařízení IoT odesílající data JSON (pro až 1 K zařízení). Velikost historie, doba trvání okna a celkové zatížení událostí se liší ve dvou vstupních oddílech.

Poznámka:

Pokud chcete přesnější odhad, přizpůsobte si vzorky tak, aby vyhovovaly vašemu scénáři.

Identifikace kritických bodů

K identifikaci kritických bodů v kanálu můžete použít podokno Metriky v úloze Azure Stream Analytics. Zkontrolujte vstupní a výstupní události pro propustnost a zpoždění vodoznaku nebo nevyřízených událostí a zjistěte, jestli úloha udržuje krok se vstupní rychlostí. V případě metrik služby Event Hubs vyhledejte omezené požadavky a odpovídajícím způsobem upravte prahové jednotky. V případě metrik Služby Azure Cosmos DB zkontrolujte maximální spotřebované RU/s na rozsah klíčů oddílu v části Propustnost a ujistěte se, že se rozsahy klíčů oddílů rovnoměrně spotřebovávají. V případě Azure SQL DB monitorujte vstupně-výstupní operace protokolů a procesor.

Ukázkové video

Další kroky