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.
Háttéridővel kapcsolatos fogalmak
A vitafórum jobb keretbe helyezése érdekében határozzunk meg néhány háttérfogalmat:
Esemény időpontja: Az eredeti esemény bekövetkezésének időpontja. Ha például egy autópályán mozgó autó közelít egy fizetős standhoz.
Feldolgozási idő: Az az idő, amikor az esemény eléri a feldolgozórendszert, és megfigyeli. 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 pillanatot vesz igénybe az adatok feldolgozásához.
Vízjel: Eseményidő-jelölő, amely jelzi, hogy a streamfeldolgozóba mely pontok eseményei kerültek be. A vízjelek lehetővé teszik, hogy a rendszer egyértelműen jelezze az események betöltésének előrehaladását. A streamek természetéből adódóan a bejövő eseményadatok soha nem fejeződnek be, így a vízjelek jelzik a folyamat előrehaladását a stream egy bizonyos pontjára.
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étel újraszámlálását kell elvégezni, a vízjelek biztonságos kezdő és záró pontok.
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 és az alkalmazásidőt.
Érkezés időpontja
Az érkezési idő a bemeneti forráshoz lesz rendelve, amikor az esemény eléri a forrást. Az érkezési idő eléréséhez használja az Event Hubs-bemenet EventEnqueuedUtcTime tulajdonságát, a IoT Hub bemenethez tartozó IoTHub.EnqueuedTime tulajdonságot, a blobbemenethez pedig a BlobProperties.LastModified tulajdonságot.
Az érkezési időt alapértelmezés szerint a rendszer használja, és olyan adatarchiválási forgatókönyvekhez ajánlott, ahol nincs szükség időbeli logikára.
Alkalmazás ideje (más néven eseményidő)
Az alkalmazásidőt az esemény létrehozásakor rendeli hozzá a rendszer, amely 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ő szerint záradékát. Ha az időbélyegző hiányzik, az események feldolgozása érkezési idő szerint történik.
Fontos, hogy időbélyeget használjon a hasznos adatban, ha a temporális logika a forrásrendszer vagy a hálózat késéseit veszi figyelembe. Az eseményhez rendelt idő a SYSTEM-ben érhető el . IDŐBÉLYEG.
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 megállapítani, 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ények esetén a vízjel a Stream Analytics által eddig tapasztalt legnagyobb eseményidő, amely nem tartalmazza a rendelésen kívüli tűrésablak méretét.
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 megtekintésekor 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ényközvetítő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 generálá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.
Szabályozhatja, hogy milyen időben szeretné megtekinteni a kimeneti eredményeket. A Azure Portal 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, vegye figyelembe az idősorok kompromisszumot az eseménystreamben a sorrenden kívüli események tűrésével.
A késői érkezési tűrésablak szükséges a vízjelek generálásához, még a 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 súlyosbítja a több partíció használata a bemeneti eseményközvetítőben.
A késési tűréshatár nélküli streamelési adatfeldolgozó rendszerek késhetnek a kimenetekben, 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 rendszerek fontos tulajdonsága.
A vízjel az érkezési időből és a jelentkezés idejéből származik. Mindkettő megmarad az eseményközvetítőben, és így ismételhető. Ha események hiányában becsült érkezési időt ad meg, az Azure Stream Analytics naplókban naplóz a hibahelyreállítás visszajátszása során az ismétlődés becsült érkezési idejét.
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ényközvetítőben, az Azure Stream Analytics egyszerűen figyelmen kívül hagyja a konfigurációkat.
Későn érkező események
A késői érkezési tolerancia időszakának definíciója szerint az Azure Stream Analytics minden bejövő eseményhez összehasonlítja az eseményidőt az érkezési idővel. Ha az esemény ideje kívül esik a tűréshatáron, konfigurálhatja a rendszert úgy, hogy eldobja az eseményt, vagy módosítsa az esemény időtartományát úgy, hogy a tűréshatáron belül legyen.
A vízjelek létrehozása után a szolgáltatás a vízjelnél rövidebb 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 módosí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őeltérés kezelése alstreamekkel
A leírt heurisztikus vízjel-létrehozási mechanizmus a legtöbb esetben jól működik, amikor az idő többnyire szinkronizálódik a különböző eseményküldők között. A való életben azonban, különösen sok IoT-forgatókönyvben, a rendszer kevés vezérléssel rendelkezik az esemény küldőinek óráján. Az esemény küldői lehetnek mindenféle eszköz a mezőben, például a hardver és a szoftver különböző verzióiban.
Ahelyett, hogy globális vízjelet használ egy bemeneti partíció összes eseményéhez, a Stream Analytics egy másik, alstreameknek nevezett mechanizmussal rendelkezik. A feladatban alstreameket használhat egy olyan feladat lekérdezésének megírásával, amely a TIMESTAMP BY záradékot és az OVER kulcsszót használja. Az alstream kijelöléséhez adjon meg egy kulcsoszlopnevet az OVER kulcsszó után, például egy deviceid, hogy a rendszer időszabályzatokat alkalmazzon az adott oszlopra. Minden alstream saját, független vízjelet kap. Ez a mechanizmus akkor hasznos, ha lehetővé teszi a kimenet időben történő létrehozását, amikor nagy óraeltérésekkel vagy hálózati késésekkel foglalkozik az esemény küldő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 tolerancia határozza meg azt a maximális mennyiséget, amellyel a különböző alstreamek megkülönböztethetők egymástól. Ha például az 1. eszköz az 1. időbélyegnél, a 2. eszköz pedig a 2. időbélyegnél van, akkor a legfeljebb késői érkezési tűrés az Időbélyeg 2 mínusz Az 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 kezdjen 5 perccel, és végezze el a beállításokat az eszköz óraeltérési mintájának megfelelően.
Korai érkezési események
Előfordulhat, hogy észrevett egy másik, korai érkezési ablaknak nevezett fogalmat, amely a késői érkezési tolerancia ablak ellentéteként néz ki. Ez az ablak 5 percen belül ki van javítva, é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, csak a feladat első kimeneti időpontjaként adhatja meg a feladat kezdési időpontját , 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őt. 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ényközvetítőben. A korai érkezési időkorláttal a fordítás egyszerű: az esemény kezdő időpontja mínusz az 5 perces korai érkezési idő. Ez a számítás azt is jelenti, hogy a rendszer elvet minden olyan eseményt, amely az érkezési időnél 5 perccel korábbi eseményidőnek minősül. A korai bemeneti események metrika az események elvetésekor növekszik.
Ezzel a koncepcióval biztosíthatja, hogy a feldolgozás megismételhető legyen, függetlenül attól, hogy honnan kezdi a kimenetet. Ilyen mechanizmus nélkül nem lehetne garantálni az ismételhetőséget, ahogy azt számos 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ó a Azure Portal: a Rendelésen kívüli események beállítás (rendelésen kívüli tolerancia) és a Késő érkezési tűrésű események beállításban. 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 erős garanciák biztosításához. 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 a szokásos módon 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ő eseményt, így egyik sem jelenik meg a kimenetből.
Régi események küldése az Event Hubsba, amelyeket az Azure Stream Analytics feldolgoz.
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 jelenleg az Azure Stream Analytics alkalmasabb a közel valós idejű eseményfeldolgozási forgatókönyvekhez a korábbi eseményfeldolgozási forgatókönyvek helyett. A késői időben érkező eseményeket a lehető legnagyobb értékre (20 nap) á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. A rendelésen kívüli tűrés alapértelmezés szerint nulla (00 perc és 00 másodperc) értékre van konfigurálva. Ha magasabb, nem nulla időértékre állítja be, a streamelési feladat első kimenetét a kiszámított első vízjelidő miatt az adott idő (vagy nagyobb) késlelteti.
A bemenetek ritkák.
Ha egy adott partíción 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. A bemeneti események egyenkénti küldésekor várhatóan némi késés jelenik meg, például. A késések rosszabbodhatnak, ha nagy értékre állítja a későn érkező eseményeket .
A System.Timestamp érték eltér az esemény idő mezőjében megadott időtől.
A korábban leírtak szerint 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ésablakok alapján állítja be. Az esemény System.Timestamp értéke módosul, az esemény időmezője azonban nem. Ezzel megállapítható, hogy mely eseményekhez igazodtak az időbélyegek. Ha a rendszer az egyik tűrés miatt módosította az időbélyeget, általában megegyeznek.
Megfigyelendő metrikák
Az Eseményrendezés időtűrési hatásait az Azure Stream Analytics feladatmetrikáiban figyelheti 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, amelyek elvetve vagy módosított időbélyeget kaptak. Ezt a metrikát közvetlenül befolyásolja a Azure Portal feladat Event ordering (Eseményrendezés) lapján található Rendelésen kívüli események beállítás konfigurálása. |
| Késői bemeneti események | A forrásból későn érkező események számát jelzi. Ez a metrika azokat az eseményeket tartalmazza, amelyeket elvetett vagy módosítottak az időbélyegük alapján. Ezt a metrikát közvetlenül befolyásolja a Azure Portal feladat Event ordering (Eseményrendezés) lapján későn érkező események konfigurációja. |
| Korai beviteli események | Azt jelzi, hogy a forrásból korábban érkező események száma vagy el lett távolítva, 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ája a feldolgozási csomópont falióra-idejeként van kiszámítva, mínusz az eddigi legnagyobb vízjel. További információt a vízjel késleltetéséről szóló blogbejegyzésben talál.
Ennek a metrikaértéknek több oka lehet, hogy normál művelet esetén 0-nál nagyobb:
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, mert 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, mert a vízjelet a tűrésablak mérete csökkenti.
A metrikát létrehozó feldolgozási csomópont óraeltérése.
Számos más erőforrás-korlátozás is fennáll, amelyek miatt a streamelési folyamat lelassulhat. A vízjel késleltetési metrikája 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 lásd: Streamelési egységek ismertetése és módosítása.
Nincs elég átviteli sebesség a bemeneti eseményközvetítőkben, ezért szabályozva vannak. A lehetséges megoldásokért lásd: Azure Event Hubs átviteli egységek automatikus felskálázása.
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 előállítá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 részleges összesítéseket szeretnének látni az ablakokból. A részleges összesítések 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 valósulhatnak meg. 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 módosítható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 a 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 időpontja és az érkezési idő eltérő, néha egyező és néha nem.
| Esemény időpontja | Érkezés időpontja | DeviceId |
|---|---|---|
| 12:07 | 12:07 | device1 |
| 12:08 | 12:08 | device2 |
| 12:17 | 12:11 | device1 |
| 12:08 | 12:13 | device3 |
| 12:19 | 12:16 | device1 |
| 12:12 | 12:17 | device3 |
| 12:17 | 12:18 | device2 |
| 12:20 | 12:19 | device2 |
| 12:16 | 12:21 | device3 |
| 12:23 | 12:22 | device2 |
| 12:22 | 12:24 | device2 |
| 12:21 | 12:27 | device3 |
Ebben az ábrán a következő tűréseket használjuk:
- A korai érkezési ablakok 5 percek
- A 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ó fontosabb folyamatok:
Az első esemény (device1) é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, így 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énynél.
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 (device3) 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 igazodik (12:17).
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ő érkezési szabályzatot. Az eseményidőt módosítja (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 ábrá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-ös értékre van emelve. A negyedik eseményidő 7 perccel (12:08 és 12:15 között) van módosítva.
A végső á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 időpontjai ennek megfelelően módosulnak.
