Az Azure Stream Analytics időkezelésének ismertetése
Ebből a cikkből megtudhatja, hogyan hozhat tervezési döntéseket az Azure Stream Analytics-feladatok gyakorlati időkezelési problémáinak megoldásához. Az időkezelési tervezési döntések szorosan kapcsolódnak az eseményrendezési tényezőkhöz.
A háttéridő fogalmai
A vita jobb keretéhez definiáljunk néhány háttérfogalmat:
Esemény időpontja: Az az időpont, amikor az eredeti esemény történt. Ha például egy autópályán mozgó autó egy fizetős standhoz közelít.
Feldolgozási idő: Az az idő, amikor az esemény eléri a feldolgozó rendszert, és megfigyelik. Ha például egy fizetős stand érzékelője látja az autót, és a számítógépes rendszer néhány percet vesz igénybe az adatok feldolgozásához.
Vízjel: Eseményidő-jelölő, amely jelzi, hogy a streamfeldolgozó milyen pont eseményeket iktatott be. A vízjelek lehetővé teszik a rendszer számára az események betöltésének egyértelmű előrehaladását. A streamek természetéből adódóan a bejövő eseményadatok soha nem szűnnek meg, ezért a vízjelek a stream egy bizonyos pontjára jelzik az előrehaladást.
A vízjel fogalma fontos. A vízjelek lehetővé teszik a Stream Analytics számára annak meghatározását, hogy a rendszer mikor hozhat létre teljes, helyes és megismételhető eredményeket, amelyeket nem kell visszavonni. A feldolgozás kiszámítható és megismételhető módon végezhető el. Ha például egy hibakezelési feltételhez újra kell számolni, a vízjelek biztonságos kezdő- és végpontok.
A témával kapcsolatos további forrásokért lásd Tyler Akidau blogbejegyzéseit : Streaming 101 and Streaming 102.
Válassza ki a legjobb kezdési időpontot
A Stream Analytics két lehetőséget kínál a felhasználóknak az eseményidő kiválasztásához: az érkezési idő és az alkalmazás ideje.
Érkezési idő
Az érkezési idő a bemeneti forráshoz lesz rendelve, amikor az esemény eléri a forrást. Az érkezési időt az Event Hubs-bemenet EventEnqueuedUtcTime tulajdonságával, az IoT Hub-bemenet IoTHub.EnqueuedTime tulajdonságával és a blobbemenet BlobProperties.LastModified tulajdonságával érheti el.
Az érkezési időt alapértelmezés szerint a rendszer használja, és olyan adatarchiválási forgatókönyvekhez használható, ahol nincs szükség időbeli logikára.
Alkalmazás ideje (más néven eseményidő)
Az alkalmazásidő az esemény létrehozásakor lesz hozzárendelve, és az az esemény hasznos adatainak része. Az események alkalmazásidő szerinti feldolgozásához használja a SELECT lekérdezés Időbélyegzője záradékot . Ha az időbélyeg nem jelenik meg, az események feldolgozása az érkezési idő szerint történik.
Fontos, hogy időbélyeget használjon a hasznos adatokban, ha az időbeli logika figyelembe veszi a forrásrendszerben vagy a hálózatban bekövetkező késéseket. Az eseményhez rendelt idő a SYSTEM-ben érhető el. IDŐBÉLYEGZŐ.
Az idő előrehaladása az Azure Stream Analyticsben
Az alkalmazásidő használatakor az idő előrehaladása a bejövő eseményeken alapul. A streamfeldolgozó rendszer nehezen tudja, hogy nincsenek-e események, vagy ha az események késnek. Ezért az Azure Stream Analytics heurisztikus vízjeleket hoz létre az egyes bemeneti partíciókhoz a következő módokon:
Bejövő esemény esetén a vízjel a Stream Analytics eddigi legnagyobb eseményideje, mínusz a rendelésen kívüli tűrésablak mérete.
Ha nincs bejövő esemény, a vízjel az aktuális becsült érkezési idő mínusz a késői érkezési tolerancia időszaka. A becsült érkezési idő az az idő, amely a bemeneti esemény legutóbbi megjelenésétől eltelt, valamint a bemeneti esemény érkezési ideje.
Az érkezési idő csak azért becsülhető meg, mert a valós érkezési idő a bemeneti eseményszervezőn, például az Event Hubson vagy az eseményeket feldolgozó Azure Stream Analytics virtuális gépen jön létre.
A kialakítás a vízjelek előállításán kívül két további célt is szolgál:
A rendszer időben hozza létre az eredményeket bejövő eseményekkel vagy anélkül.
Ön szabályozhatja, hogy a kimeneti eredmények milyen időben jelenjenek meg. Az Azure Portalon a Stream Analytics-feladat Eseményrendezés lapján konfigurálhatja a Rendelésen kívüli események beállítást. Ha ezt a beállítást konfigurálja, fontolja meg az ütemtervek kompromisszumot az eseménystreamben a rendezésen kívüli események tűrésével.
A késői érkezési tűrés időszak szükséges a vízjelek létrehozásához, még bejövő események hiányában is. Időnként előfordulhat, hogy nem érkeznek bejövő események, például amikor egy eseménybemeneti stream ritkán fordul elő. Ezt a problémát tovább súlyosbítja, hogy több partíciót használnak a bemeneti eseményszervezőben.
A késői érkezési tűrésablak nélküli streamelési adatfeldolgozási rendszerek késéssel járhatnak, ha a bemenetek ritkák, és több partíciót használnak.
A rendszer viselkedésének ismételhetőnek kell lennie. Az ismételhetőség a streamelési adatfeldolgozási rendszer fontos tulajdonsága.
A vízjel az érkezési időből és a jelentkezési időből származik. Mindkettő megmarad az eseményszervezőben, így megismételhető. Ha az érkezési időt események hiányában becsülik meg, az Azure Stream Analytics naplókban naplózja az ismétlés becsült érkezési idejét a sikertelen helyreállítás visszajátszása során.
Ha úgy dönt, hogy az érkezési időt használja eseményidőként, ott nem kell konfigurálnia a rendelésen kívüli tűrést és a késői érkezési tűrést. Mivel az érkezési idő garantáltan növekszik a bemeneti eseményszervezőben, az Azure Stream Analytics egyszerűen figyelmen kívül hagyja a konfigurációkat.
Késői érkezési események
A késői érkezési tűrés időszak definíciója szerint az Azure Stream Analytics minden bejövő eseményhez összehasonlítja az esemény időpontját az érkezési idővel. Ha az esemény ideje kívül esik a tűrésablakon, beállíthatja, hogy a rendszer elvetje az eseményt, vagy módosítsa az esemény időtartományát a tűréshatáron belülre.
A vízjelek létrehozása után a szolgáltatás a vízjelnél alacsonyabb eseményidővel rendelkező eseményeket fogadhat. Beállíthatja, hogy a szolgáltatás elvetje ezeket az eseményeket, vagy módosítsa az esemény idejét a vízjel értékére.
A módosítás részeként az esemény System.Timestamp értéke az új érték, de maga az esemény időmezője nem változik. Ez a beállítás az egyetlen olyan helyzet, amikor egy esemény System.Timestamp értéke eltérhet az esemény idő mezőjében szereplő értéktől, és váratlan eredményeket eredményezhet.
Időváltozás kezelése alstreamekkel
A leírt heurisztikus vízjelgenerálási mechanizmus az esetek többségében jól működik, amikor az idő többnyire szinkronizálva van a különböző esemény feladói között. A valós életben azonban, különösen sok IoT-forgatókönyv esetében, a rendszer kevés vezérléssel rendelkezik az esemény feladóinak óráján. Az esemény küldői lehetnek mindenféle eszköz a területen, talán különböző hardver- és szoftververziókon.
Ahelyett, hogy globális vízjelet használnál egy bemeneti partíció összes eseményéhez, a Stream Analytics egy másik, alstreameknek nevezett mechanizmussal rendelkezik. A feladatban lévő alstreameket a TIMESTAMP BY záradékot és a OVER kulcsszót használó feladat-lekérdezés megírásával használhatja. Az alstream kijelöléséhez adjon meg egy kulcsoszlopnevet a OVER kulcsszó után, például egy deviceid, hogy a rendszer időszabályzatokat alkalmazzon az adott oszlopra. Minden alstream saját önálló vízjelet kap. Ez a mechanizmus akkor hasznos, ha időben generálja a kimenetet, amikor nagy óraeltéréseket vagy hálózati késéseket kezel az esemény feladói között.
Az alstreamek az Azure Stream Analytics által biztosított egyedi megoldások, amelyeket más streamelési adatfeldolgozási rendszerek nem kínálnak.
Ha alstreameket használ, a Stream Analytics a késői érkezési tűrésablakot alkalmazza a bejövő eseményekre. A késői érkezési tűrés határozza meg azt a maximális mennyiséget, amellyel a különböző alstreamek egymástól eltérhetnek. Ha például az 1. eszköz az Időbélyeg 1, a 2. eszköz pedig a Timestamp 2-nél van, a legfeljebb késői érkezési tűrés az Időbélyeg 2 mínusz Időbélyeg 1. Az alapértelmezett beállítás 5 másodperc, és valószínűleg túl kicsi az eltérő időbélyeggel rendelkező eszközök esetében. Javasoljuk, hogy 5 perccel kezdjen, és végezze el a beállításokat az eszköz óraátállítási mintájának megfelelően.
Korai érkezési események
Lehet, hogy észrevette egy másik fogalom, az úgynevezett korai érkezési ablak, amely úgy néz ki, mint az ellentéte késői érkezési tűrésablak. Ez az ablak 5 perc alatt van rögzítve, és más célt szolgál, mint a késői érkezési tűrésablak.
Mivel az Azure Stream Analytics garantálja a teljes eredményeket, a feladat kezdési idejét csak a feladat első kimeneti időpontjaként adhatja meg, a bemeneti időt nem. A feladat kezdési időpontjára azért van szükség, hogy a teljes ablak ne csak az ablak közepéről legyen feldolgozva.
A Stream Analytics a lekérdezés specifikációjából származtatja a kezdési időpontot. Mivel azonban a bemeneti eseményközvetítőt csak az érkezési idő indexeli, a rendszernek le kell fordítania a kezdő esemény időpontját az érkezési időre. A rendszer ettől a ponttól kezdve megkezdheti az események feldolgozását a bemeneti eseményszervezőben. A korai érkezési időkorláttal a fordítás egyszerű: a kezdő esemény időpontja mínusz az 5 perces korai érkezési idő. Ez a számítás azt is jelenti, hogy a rendszer az összes olyan eseményt elveti, amelynek eseményideje 5 perccel korábbi, mint az érkezési idő. A korai bemeneti események metrikája az események elvetésekor növekszik.
Ez a koncepció biztosítja, hogy a feldolgozás megismételhető legyen, függetlenül attól, hogy honnan kezdi a kimenetet. Ilyen mechanizmus nélkül nem garantálható az ismételhetőség, ahogy azt sok más streamelési rendszer állítja.
Az eseményrendezési időtűrések mellékhatásai
A Stream Analytics-feladatok számos eseményrendezési lehetőséggel rendelkeznek. Kettő konfigurálható az Azure Portalon: a Rendelésen kívüli események beállítás (rendelésen kívüli tolerancia) és a késedelmesen érkező események (késői érkezési tűrés). A korai érkezési tűrés rögzített, és nem módosítható. A Stream Analytics ezeket az időszabályzatokat használja az erős garanciák biztosítására. Ezek a beállítások azonban néha váratlan következményekkel járnak:
Véletlenül túl korai eseményeket küld.
A korai eseményeket nem szabad normálisan kimenetelni. Előfordulhat, hogy a rendszer korai eseményeket küld a kimenetbe, ha a feladó órája túl gyorsan fut. A rendszer elveti az összes korai érkezési eseményt, így egyik sem jelenik meg a kimenetből.
Régi események küldése az Event Hubsba az Azure Stream Analytics által feldolgozandó feldolgozáshoz.
Bár a régi események elsőre ártalmatlannak tűnhetnek, a késői érkezési tolerancia alkalmazása miatt a régi események elvethetők. Ha az események túl régiek, a System.Timestamp érték módosul az eseménybetöltés során. Ennek a viselkedésnek köszönhetően az Azure Stream Analytics jelenleg inkább közel valós idejű eseményfeldolgozási forgatókönyvekhez alkalmas, nem pedig előzményesemény-feldolgozási forgatókönyvekhez. A késői időben érkező eseményeket a lehető legnagyobb értékre (20 napra) állíthatja be, hogy bizonyos esetekben megkerülje ezt a viselkedést.
Úgy tűnik, hogy a kimenetek késnek.
Az első vízjel a számított időpontban jön létre: a rendszer által eddig megfigyelt maximális eseményidő , mínusz a rendelésen kívüli tűrésablak mérete. Alapértelmezés szerint a rendelésen kívüli tűrés nullára van konfigurálva (00 perc és 00 másodperc). Ha magasabb, nem nulla időértékre állítja, a streamelési feladat első kimenete az első kiszámított vízjel-idő miatt az idő (vagy nagyobb) értékkel késik.
A bemenetek ritkák.
Ha egy adott partícióban nincs bemenet, a rendszer úgy számítja ki a vízjel idejét, hogy az érkezési idő mínusz a késői érkezési tűrésablak. Ennek eredményeképpen, ha a bemeneti események ritkán és ritkán jelennek meg, a kimenet ennyi idővel késleltethető. Az alapértelmezett késői érték 5 másodperc. Előfordulhat például, hogy a bemeneti események küldésekor némi késés várható. A késések rosszabbodhatnak, ha nagy értékre állítja a késői ablakba érkező eseményeket.
A System.Timestamp értéke eltér az esemény idő mezőjében megadott időtől .
A korábban leírtaknak megfelelően a rendszer az eseményidőt a rendelésen kívüli tűréshatár vagy a késői érkezési tűréshatár alapján állítja be. Az esemény System.Timestamp értéke módosul, az esemény időmezője azonban nem. Ezzel azonosítható, hogy az időbélyegek mely eseményekhez igazodtak. Ha a rendszer az egyik tűrés miatt módosította az időbélyeget, általában megegyeznek.
Megfigyelendő metrikák
Az Azure Stream Analytics-feladatmetrikákon keresztül számos eseményrendezési időtűrési effektus figyelhető meg. A következő metrikák relevánsak:
| Metrika | Leírás |
|---|---|
| Rendelésen kívüli események | A sorrenden kívül fogadott események számát jelzi, amelyeket elvetett vagy módosított időbélyeget kapott. Ezt a metrikát közvetlenül befolyásolja a rendelésen kívüli események beállítása az Azure Portal eseményrendelési oldalán. |
| Késői bemeneti események | A forrásból későn érkező események számát jelzi. Ez a metrika tartalmazza azokat az eseményeket, amelyeket elvetett vagy módosítottak az időbélyegükkel. Ezt a metrikát közvetlenül befolyásolja az Azure Portalon a feladat Eseményrendezés lapján későn érkező események konfigurációja. |
| Korai bemeneti események | Azt jelzi, hogy a forrásból korábban érkező események száma vagy elvetett, vagy az időbélyegük módosult, ha 5 perccel korábbiak. |
| Vízjel késleltetése | A streamelési adatfeldolgozási feladat késését jelzi. További információt a következő szakaszban talál. |
Vízjel késleltetésének részletei
A vízjel késleltetési metrikáját a feldolgozási csomópont fali óraidejeként számítjuk ki, az eddigi legnagyobb vízjel nélkül. További információkért tekintse meg a vízjel késleltetéséről szóló blogbejegyzést.
Ennek a metrikaértéknek több oka lehet, mint 0 normál művelet esetén:
A streamelési folyamat eredendő feldolgozási késleltetése. Ez a késleltetés általában névleges.
A rendelésen kívüli tűrésablak késést vezetett be, mivel a vízjel a tűrésablak méretével csökken.
A késői érkezési időszak késést vezetett be, mivel a vízjel a tűrésablak méretével csökken.
A metrikát létrehozó feldolgozási csomópont órajele.
Számos egyéb erőforrás-korlátozás is fennáll, amelyek miatt a streamelési folyamat lelassulhat. A vízjel késleltetési metrika a következő miatt emelkedhet:
Nincs elég feldolgozási erőforrás a Stream Analyticsben a bemeneti események mennyiségének kezeléséhez. Az erőforrások vertikális felskálázásához tekintse meg a streamelési egységek értelmezését és módosítását.
Nincs elég átviteli sebesség a bemeneti eseményközvetítőkben, ezért szabályozva vannak. A lehetséges megoldásokért tekintse meg az Azure Event Hubs átviteli sebességegységeinek automatikus skálázását.
A kimeneti fogadók nincsenek elegendő kapacitással kiépítve, ezért szabályozva vannak. A lehetséges megoldások széles körben eltérnek a használt kimeneti szolgáltatás ízétől függően.
Kimeneti esemény gyakorisága
Az Azure Stream Analytics a vízjelek előrehaladását használja egyetlen eseményindítóként a kimeneti események létrehozásához. Mivel a vízjel bemeneti adatokból származik, a hiba helyreállítása és a felhasználó által kezdeményezett újrafeldolgozás során is megismételhető. Ablakos összesítések használatakor a szolgáltatás csak az ablakok végén állít elő kimeneteket. Bizonyos esetekben előfordulhat, hogy a felhasználók szeretnének részleges összesítéseket látni az ablakokból. A részleges aggregátumok jelenleg nem támogatottak az Azure Stream Analyticsben.
Más streamelési megoldásokban a kimeneti események a külső körülményektől függően különböző eseményindító pontokon is megvalósulhatnak. Egyes megoldásokban előfordulhat, hogy egy adott időablak kimeneti eseményei többször is létrehozhatók. A bemeneti értékek finomításával az összesített eredmények pontosabbá válnak. Az események először spekulálhatók, és idővel átdolgozhatók. Ha például egy adott eszköz offline állapotban van a hálózatról, a rendszer becsült értéket használhat. Később ugyanez az eszköz online állapotba kerül a hálózaton. Ezután a tényleges eseményadatok belefoglalhatók a bemeneti adatfolyamba. Az adott időablak feldolgozásából származó kimenet pontosabb kimenetet eredményez.
Illusztrált példa vízjelekre
Az alábbi képek bemutatják, hogyan haladnak a vízjelek különböző körülmények között.
Ez a táblázat az alábbi diagramon ábrázolt példaadatokat mutatja be. Figyelje meg, hogy az esemény ideje és az érkezési idő változó, néha egyező, néha nem.
| Esemény időpontja | Érkezési idő | DeviceId |
|---|---|---|
| 12:07 | 12:07 | device1 |
| 12:08 | 12:08 | device2 |
| 12:17 | 12:11 | device1 |
| 12:08 | 12:13 | eszköz3 |
| 12:19 | 12:16 | device1 |
| 12:12 | 12:17 | eszköz3 |
| 12:17 | 12:18 | device2 |
| 12:20 | 12:19 | device2 |
| 12:16 | 12:21 | eszköz3 |
| 12:23 | 12:22 | device2 |
| 12:22 | 12:24 | device2 |
| 12:21 | 12:27 | eszköz3 |
Ebben az ábrán a következő tűréseket használjuk:
- A korai érkezési ablakok 5 percek
- Késői érkezési idő 5 perc
- Az átrendezés ablaka 2 perc
Az alábbi eseményeken végighaladó vízjel illusztrációja:
Az előző ábrán látható jelentős folyamatok:
Az első esemény (eszköz1) és a második esemény (device2) igazodik az időpontokhoz, és módosítás nélkül lesz feldolgozva. A vízjel minden eseményen előrehalad.
A harmadik esemény (eszköz1) feldolgozásakor az érkezési idő (12:11) megelőzi az esemény időpontját (12:17). Az esemény 6 perccel korábban érkezett meg, ezért az 5 perces korai érkezési tolerancia miatt az esemény el lesz ejtve.
A vízjel nem halad előre ebben az esetben egy korai esemény esetén.
A negyedik esemény (device3) és az ötödik esemény (device1) igazodik az időpontokhoz, és módosítás nélkül lesz feldolgozva. A vízjel minden eseményen előrehalad.
A hatodik esemény (eszköz3) feldolgozásakor az érkezési idő (12:17) és az esemény időpontja (12:12) a vízjel szintje alatt van. Az eseményidő a vízjel szintjéhez (12:17) van igazítva.
A tizenkettedik esemény (device3) feldolgozásakor az érkezési idő (12:27) 6 perccel az esemény előtt van (12:21). A rendszer alkalmazza a késői érkezési szabályzatot. Az esemény időbeállítása (12:22), amely a vízjel felett van (12:21), így a program nem alkalmaz további módosítást.
A vízjel korai érkezési szabályzat nélkül történő előrehaladásának második illusztrációja:
Ebben a példában nem alkalmazunk korai érkezési szabályzatot. A korán érkező kiugró események jelentősen megnövelik a vízjelet. Figyelje meg, hogy a harmadik esemény (12:11 időpontban a deviceId1) nincs elvetve ebben a forgatókönyvben, és a vízjel 12:15-ösre van emelve. A negyedik eseményidő 7 perccel (12:08–12:15) van módosítva.
Az utolsó ábrán az alstreamek lesznek használatban (a DeviceId-en keresztül). A rendszer több vízjelet követ nyomon, streamenként egyet. Kevesebb olyan esemény van, amelynek az ideje ennek megfelelően módosul.
