Anomáliák észlelése az Azure Stream Analyticsben

A felhőben és a Azure IoT Edge is elérhető Azure Stream Analytics beépített gépi tanulási alapú anomáliadetektálási képességeket kínál, amelyekkel figyelheti a két leggyakrabban előforduló rendellenességet: az ideiglenest és az állandót. A AnomalyDetection_SpikeAndDip és AnomalyDetection_ChangePoint függvények használatával közvetlenül a Stream Analytics-feladatban végezhet rendellenességészlelést.

A gépi tanulási modellek egységesen mintavételezett idősort feltételeznek. Ha az idősor nem egységes, szúrjon be egy összesítési lépést egy ugróablakkal, mielőtt meghívja az anomáliadetektálást.

A gépi tanulási műveletek jelenleg nem támogatják a szezonalitási trendeket és a többváltozós korrelációkat.

Anomáliadetektálás gépi tanulással Azure Stream Analytics

Az alábbi videó bemutatja, hogyan lehet valós időben észlelni az anomáliát gépi tanulási függvények használatával Azure Stream Analytics.

Modell viselkedése

A modell pontossága általában javul a tolóablakban lévő több adattal. A megadott tolóablakban lévő adatok az adott időkeretre vonatkozó normál értéktartomány részeként lesznek kezelve. A modell csak a tolóablakban lévő eseményelőzményeket veszi figyelembe annak ellenőrzéséhez, hogy az aktuális esemény rendellenes-e. A tolóablak mozgása során a régi értékek ki lesznek távolítva a modell betanításából.

A függvények úgy működnek, hogy létrehoznak egy bizonyos normát az eddig látottak alapján. A kiugró értékeket a konfidenciaszinten belül a megállapított normálishoz viszonyítva azonosítjuk. Az ablakméretnek a modell normál viselkedésre való betanításához szükséges minimális eseményeken kell alapulnia, hogy a rendellenesség bekövetkezésekor felismerje azt.

A modell válaszideje az előzménymérettel együtt nő, mivel több korábbi eseményhez kell hasonlítani. A jobb teljesítmény érdekében csak a szükséges számú eseményt foglalja bele.

Az idősorok közötti rések akkor fordulhatnak elő, ha a modell nem fogad eseményeket bizonyos időpontokban. A Stream Analytics számítási logikával kezeli ezt a helyzetet. Az előzményméretet és az ugyanazon tolóablakhoz tartozó időtartamot az események várható érkezési átlagos sebességének kiszámítására használják.

Az anomália generátor használatával olyan adatokat küldhet az IoT Hub számára, amelyek különböző anomália mintákat tartalmaznak. Ezen anomáliadetektálási függvények használatával beállíthat egy Azure Stream Analytics feladatot, hogy ebből a IoT Hub olvasson, és észlelje az anomáliákat.

Kiugrás és lecsúszás

Az idősoros eseményfolyamok átmeneti rendellenességeit csúcsoknak és lecsúszásoknak nevezzük. A Machine Learning-alapú AnomalyDetection_SpikeAndDip használatával figyelheti a kiugrásokat és visszaeséseket.

Ugyanabban a tolóablakban, ha egy második kiugró érték kisebb az elsőnél, előfordulhat, hogy a kisebb kiugró érték számított pontszáma nem lesz elég jelentős a megadott megbízhatósági szinten belüli első kiugró értékhez képest. Megpróbálhatja csökkenteni a modell megbízhatósági szintjét az ilyen anomáliák észleléséhez. Ha azonban túl sok riasztást kezd kapni, használjon nagyobb megbízhatósági intervallumot.

Az alábbi példa lekérdezés egy másodpercenként egy esemény egységes bemeneti sebességét feltételezi egy 2 perces csúsztatási ablakban, amely 120 esemény előzményeit tartalmazza. A végső SELECT utasítás kinyeri és kimenetként ábrázolja a pontszámot és az anomália állapotát is 95%százalékos megbízhatósági szinttel.

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

Változási pont

Az idősoros eseménystreamek állandó anomáliái az eseményfolyam értékeinek eloszlásában bekövetkező változások, például a szintváltozások és a trendek. A Stream Analyticsben a Machine Learning-alapú AnomalyDetection_ChangePoint operátor észleli ezeket az anomáliákat.

Az állandó változások sokkal tovább tartanak, mint a kiugró értékek és a visszaesések, és katasztrofális eseményeket jelezhetnek. Az állandó változások általában szabad szemmel nem láthatók, de a AnomalyDetection_ChangePoint operátor észleli őket.

Az alábbi képen egy szintváltás látható:

Az alábbi képen egy trendváltozás látható:

Az alábbi példa lekérdezés egy másodpercenként egy esemény egységes bemeneti sebességét feltételezi egy 20 perces tolóablakban, amelynek előzménymérete 1200 esemény. A végső SELECT utasítás kinyeri és kiírja a pontszámot és az anomália státuszát 80%bizalmi szinttel.

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

Teljesítményjellemzők

Ezeknek a modelleknek a teljesítménye az előzmények méretétől, az ablak időtartamától, az eseményterheléstől és a függvényszintű particionálástól függ. Ez a szakasz ezeket a konfigurációkat ismerteti, és mintákat tartalmaz arra vonatkozóan, hogyan lehet fenntartani az 1 K, 5 K és 10 K események másodpercenkénti bevitel sebességét.

• Előzményméret – Ezek a modellek lineárisan, az előzmények méretével működnek. Minél hosszabb az előzményméret, annál tovább tart a modelleknek pontozni egy új eseményt. A modellek összehasonlítják az új eseményt az előzménypuffer minden korábbi eseményével.
• Ablak időtartama – Az ablak időtartamának azt kell tükröznie, hogy mennyi ideig tart az előzményméret által megadott számú esemény fogadása. Ha nem lenne ennyi esemény az ablakban, Azure Stream Analytics a hiányzó értékeket is imputálta volna. Ezért a processzorhasználat az előzmények méretének függvénye.
• Eseménybetöltés – Minél nagyobb az eseményterhelés, annál több munkát végeznek a modellek, ami hatással van a processzorhasználatra. A feladat horizontális felskálázásával kínosan párhuzamossá teheti azt, feltéve, hogy az üzleti logikának érdemes több bemeneti partíciót használnia.
• Függvényszintű particionálás – Az PARTITION BY anomáliadetektálási függvényhíváson belül használható függvényszintű particionálás végrehajtására. Az ilyen típusú particionálás többletterhelést okoz, mivel a feladatnak egyszerre több modell állapotát is fenn kell tartania. A függvényszintű particionálást olyan helyzetekben használjuk, mint az eszközszintű particionálás.

Kapcsolat

Az előzmények mérete, az ablak időtartama és a teljes eseménybetöltés a következő módon kapcsolódik:

windowDuration (ms-ben) = 1000 * historySize / (összes bemeneti esemény másodpercenként / Bemeneti partíciók száma)

Ha a függvényt deviceId alapján particionálja, adja hozzá a "PARTITION BY deviceId" kifejezést az anomáliadetektálási függvény hívásához.

Megfigyelések

Az alábbi táblázat egy csomópont (hat SU) átviteli sebességének megfigyeléseit mutatja be a nem particionált eset esetében:

Előzmények mérete (események)	Ablak hossza (ms)	Összes bemeneti esemény másodpercenként
60	55	2200
600	728	1,650
6000	10,910	1,100

Az alábbi táblázat a particionált eset egyetlen csomópontjának (hat SU) átviteli sebesség-megfigyeléseit mutatja be:

Előzmények mérete (események)	Ablak hossza (ms)	Összes bemeneti esemény másodpercenként	Eszközök száma
60	1,091	1,100	10
600	10,910	1,100	10
6000	218,182	<550	10
60	21,819	550	100
600	218,182	550	100
6000	2,181,819	<550	100

A Streaming At Scale adattárban Azure nem particionált konfigurációk futtatására szolgáló mintakódot talál. A kód létrehoz egy Stream Analytics-feladatot függvényszintű particionálás nélkül, amely az Event Hubsot használja bemenetként és kimenetként. A tesztalkalmazások generálják a bemeneti terhelést. Minden bemeneti esemény egy 1 KB-os JSON-dokumentum. Az események egy JSON-adatokat küldő IoT-eszközt szimulálnak (legfeljebb 1 K-s eszközök esetén). Az előzmények mérete, az ablak időtartama és az esemény teljes terhelése két bemeneti partíciótól függ.

Megjegyzés:

A pontosabb becslés érdekében szabja testre a mintákat a forgatókönyvnek megfelelően.

Szűk keresztmetszetek azonosítása

A folyamat szűk keresztmetszeteinek azonosításához használja a Metrikák panelt a Azure Stream Analytics feladatban. Tekintse át a bemeneti/kimeneti eseményeket az átviteli teljesítmény szempontjából, valamint nézze meg a "Vízjel késleltetése" vagy Felhalmozott események állapotát annak ellenőrzéséhez, hogy a feladat tartja-e a lépést a bemeneti sebességgel. Event Hubs metrikák esetén keresse meg a korlátozott kéréseket, és ennek megfelelően módosítsa a küszöbértékek mértékegységeit. Az Azure Cosmos DB metrikák esetében tekintse át a Max által felhasznált RU/s-t partíciókulcs-tartományonként az Átviteli sebesség alatt, hogy a partíciókulcs-tartományok egységesen használva legyenek. Az Azure SQL DB esetén a Log IO és a CPU figyelése ajánlott.

Bemutató videó

Következő lépések

• Introduction to Azure Stream Analytics
• Kezdjen el Azure Stream Analytics használatát
• Méretezze az Azure Stream Analytics-feladatokat
• Azure Stream Analytics lekérdezési nyelvi referencia
• Azure Stream Analytics Felügyeleti REST API hivatkozás