Poznámka
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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í pomocí strojového učení ve službě 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 posuzuje historii událostí pouze v rámci posuvného okna, aby zjistil, zda je aktuální událost neobvyklá. Při pohybu posuvného okna se staré hodnoty vyřadí z trénování modelu.
Funkce pracují vytvořením určitého standardu na základě toho, co bylo dosud zaznamenáno. Odlehlé hodnoty jsou identifikovány porovnáním se zavedenou normou v rámci intervalu 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 časové období pro stejné posuvné okno se používá k výpočtu průměrné rychlosti, s jakou se očekává, že události přijdou.
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. Výkyvy a poklesy je možné monitorovat pomocí operátoru založeného na strojovém učení, AnomalyDetection_SpikeAndDip.
Pokud je ve stejném posuvném okně druhá špička menší než první, vypočítané skóre pro menší špičku pravděpodobně není dostatečně významné v porovnání se skóre první špičky 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. Ve službě Stream Analytics se takové anomálie detekují pomocí operátoru AnomalyDetection_ChangePoint založeného na strojovém učení.
Trvalé změny trvají mnohem déle než špičky a poklesy a mohly by značit katastrofické události. Trvalé změny obvykle nejsou 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ěchto modelů závisí na velikosti historie, délce okna, zatížení událostí a na tom, zda je použito dělení na úrovni funkcí. Tato část popisuje tyto konfigurace a poskytuje ukázky pro udržení rychlosti příjmu 1 tisíc, 5 tisíc a 10 tisíc událostí za sekundu.
- Velikost historie – Tyto modely fungují lineárně s velikostí historie. Čím delší je délka historie, tím déle trvá modelům vyhodnotit novou událost. 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é rozšířit tím, že ji učiníte triviálně paralelní, za předpokladu, že má smysl pro logiku podnikání používat více oddílů vstupních dat.
- Dělení na úrovni funkce je prováděno prostřednictvím volání funkce pro detekci anomálií. Tento typ rozdělení přidává náklad, protože je nutné 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 (v 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 měření propustnosti jednoho uzlu (šest jednotek SU) pro případ bez dělení.
| 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álostmi se liší přes dvě vstupní oddíly.
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 úzkých míst v datovém řetězci použijte podokno Metriky v úloze Azure Stream Analytics. Zkontrolujte vstupní a výstupní události pro propustnost a zpoždění vodoznaku nebo nevyřízené události, abyste zjistili, jestli úloha udržuje krok s rychlostí vstupu. 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ílů v sekci Propustnost a ujistěte se, že jsou rozsahy klíčů oddílů rovnoměrně spotřebovávány. V případě Azure SQL DB monitorujte vstupně-výstupní operace protokolů a procesor.