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í.
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ě:
Na následujícím obrázku je příklad změny trendu:
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 BYvolá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.