Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Az Azure Stream Analyticsben az időkezelés olyan mechanizmusok készlete, amelyek meghatározzák, hogy a streamelési események hogyan vannak időbélyegzve, rendezve és feldolgozva attól függően, hogy mikor történtek és mikor érkeztek. Ez a cikk bemutatja, 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 bekövetkezik. 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 időpontig töltött be eseményeket. A vízjelek lehetővé teszik a rendszer számára az események feldolgozásának 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 az Azure 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
Az Azure Stream Analytics két lehetőséget kínál 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ő)
A(z) alkalmazási idő hozzá van rendelve, amikor az esemény létrejön, és ez az eseményhasznos adatkör 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 csomagban, amikor az időbeli logika érintett, hogy figyelembe vegye 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 (időbélyeg) a legnagyobb eseményidő, amelyet az Azure Stream Analytics eddig látott, mínusz a rendetlen események tűrésablakának 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 IoT Hubon) jön létre, nem az eseményeket feldolgozó Azure Stream Analytics virtuális gépen.
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. Amikor ezt a beállítást konfigurálja, vegye figyelembe az időbeliség és a rendezésen kívüli események tűrésének kompromisszumát az eseménystreamben.
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éshatár nélküli adatfolyam-feldolgozá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ózza az ismétléshez szükséges becsült érkezési időt a hibaelhárítás céljából történő újrajátszás során.
Ha úgy dönt, hogy az érkezési időt használja eseményidőként, 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 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 részfolyamokkal
A heurisztikus vízjelgenerálási mechanizmus – ahol az Azure Stream Analytics a legnagyobb megfigyelt időbélyeggel követi nyomon az eseményidő előrehaladását a tolerancia időszaka nélkül – jól működik a legtöbb esetben, 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 rendszernek kevés befolyása van az esemény feladóinak időzítésére. Az esemény feladói lehetnek mindenféle IoT-eszköz a területen, talán az eszköz hardverének és belső vezérlőprogramjának különböző verzióiban.
Ahelyett, hogy globális vízjelet használnál egy bemeneti partíció összes eseményéhez, az Azure Stream Analytics egy másik , alstreameknek nevezett mechanizmussal rendelkezik. A feladatban alstreameket használhat egy olyan feladat-lekérdezés 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 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.
Alstreamek használata esetén az Azure 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. Például, ha az 1. eszköz az 1. időbélyegnél van, és a 2. eszköz a 2. időbélyegnél, akkor a maximális késői érkezési tűrés a 2. időbélyeg mínusz az 1. időbélyeg. Az alapértelmezett késői érkezési tűrés beállítása 5 másodperc, ami valószínűleg túl kicsi az eltérő időbélyeggel rendelkező IoT-eszközök esetében. Kezdje 5 perccel, é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
A korai érkezési időszak egy rögzített 5 perces tűréshatár, amely meghatározza, hogy egy esemény milyen korán érkezik az esemény időpontjához képest, mielőtt az Azure Stream Analytics elveti azt. Ez az ablak 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 ideje szükséges ahhoz, hogy a rendszer ne csak az ablak közepétől dolgozza fel a teljes ablakot.
Az Azure 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étlődés, ahogy azt sok más streamelési rendszer állítja.
Az eseményrendezési időtűrések mellékhatásai
Az Azure 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ó. Az Azure Stream Analytics ezeket az időszabályzatokat használja, hogy erős garanciákat nyújtson. Ezek a beállítások azonban néha váratlan következményekkel járnak:
Véletlenül túl korai időpontban küld eseményeket.
A korai események általában nem kellene kimenetre kerüljenek. 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 eseményt, így egyik sem jelenik meg a kimenetből.
Régi események küldése az Event Hubsba feldolgozásra az Azure Stream Analytics által.
Bár a régi események elsőre ártalmatlannak tűnhetnek, a késői érkezési tolerancia alkalmazása miatt előfordulhat, hogy a régi események elvesznek. 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 jobban alkalmas közel valós idejű eseményfeldolgozási forgatókönyvekre, mint az előzményesemény-feldolgozási forgatókönyvekre. 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 kerül generálásra: a rendszer által eddig megfigyelt maximális eseményidő, mínusz a sorrenden kívüli toleranciaablak 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). Amikor magasabb, nem nulla időértéket állít be, az adatfolyam-feladat első kimenete késik a beállított időérték (vagy annál nagyobb) miatt az első kiszámított vízjel-idő miatt.
A bemenetek ritkák.
Ha egy adott partícióban nincs bemenet, a vízjel idejét úgy számítja ki a rendszer, hogy az érkezési időből kivonja a késői érkezés tolerancia ablakát. 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ésve érkező események beállítás 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, de az esemény időmezője nincs módosítva. Ezzel azonosíthatja, hogy mely eseményekhez lettek módosítva az időbélyegek. Ha a rendszer az egyik tűrés miatt módosítja 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:
| Mérőszám | Leírás |
|---|---|
| Rendelésen kívüli események | Azon események számát jelzi, amelyeket sorrenden kívül kaptak meg, és vagy elvetettek, vagy módosított időbélyeget kaptak. 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 olyan eseményeket is tartalmaz, amelyeket elvetettek, vagy az időbélyegüket módosították. Ezt a metrikát közvetlenül befolyásolja a Későn érkező események beállítás konfigurációja az Eseményrendezés lapján a feladaton az Azure Portálon. |
| Korai bemeneti események | Az események számát jelzi, amelyek korábban érkeznek a forrásból, és el lettek dobva, vagy az időbélyegük módosult, ha több mint 5 perccel korábbiak. |
| Vízjel késleltetése | A streamelési adatfeldolgozási feladat késését jelzi. További információkért lásd a következő szakaszt. |
Vízjel késleltetés részletei
Az Azure Stream Analytics úgy számítja ki a vízjel késleltetési metrikáját, hogy a feldolgozási csomópont falióra ideje mínusz az eddig látott legnagyobb vízjel. További információ: vízjel késleltetése.
Ennek a metrikaértéknek több oka lehet, hogy normál működés esetén nagyobb, mint 0.
A streamelési folyamat eredendő feldolgozási késleltetése. Ez a késleltetés általában névleges.
A sorrendi tűrésablak késést eredményezett, mert a vízjel a tűrésablak méretének csökkenésével mérséklődik.
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 más erőforrás-korlátozás is fennáll, amelyek miatt a streamelési folyamat lelassulhat. A vízjelkésleltetési mutató a következők miatt emelkedhet:
Nincs elég feldolgozási erőforrás az Azure 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 tárolók (például az Azure SQL Database, a Blob Storage vagy a Power BI) nincsenek elegendő kapacitással kiépítve, ezért korlátozottak. A lehetséges megoldások a használt kimeneti szolgáltatástól függően széles körben változnak.
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 az ablakokból generált részleges összesítéseket szeretné látni. 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 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 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 | eszköz1 |
| 12:08 | 12:08 | eszköz2 |
| 12:17 | 12:11 | device1 |
| 12:08 | 12:13 | eszköz3 |
| 12:19 | 12:16 | eszköz1 |
| 12:12 | 12:17 | eszköz3 |
| 12:17 | 12:18 | device2 |
| 12:20 | 12:19 | eszköz2 |
| 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 idő 5 perc
- 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 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 (a deviceId1 12:11-kor) nincs elvetve ebben a forgatókönyvben, és a vízjel 12:15-re emelkedik. A negyedik eseményidő 7 perccel (12:08–12:15) van módosítva.
A végső ábrán részfolyamokat használnak (a DeviceId fölött). 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.
