Vysvětlení zpracování času ve službě Azure Stream Analytics

V tomto článku se dozvíte, jak se rozhodnout pro návrh řešení praktických problémů při zpracování času v úlohách Azure Stream Analytics. Rozhodnutí o návrhu zpracování času úzce souvisí s faktory řazení událostí.

Koncepty času na pozadí

Pokud chcete lépe zarámovat diskuzi, pojďme definovat některé koncepty pozadí:

  • Čas události: Čas, kdy došlo k původní události. Například když se pohyblivý vůz na dálnici blíží k placené kabině.

  • Doba zpracování: Doba, kdy událost dosáhne systému zpracování a je pozorována. Například když senzor placené kabiny uvidí auto a počítačový systém chvíli trvá zpracování dat.

  • Vodoznak: Značka času události, která označuje, do jakého bodu byly události příchozího přenosu dat do procesoru streamování. Vodoznaky umožňují systému označit jasný průběh ingestování událostí. Podle povahy datových proudů se příchozí data událostí nikdy nezastavují, takže vodoznaky označují průběh k určitému bodu datového proudu.

    Koncept vodoznaku je důležitý. Vodoznaky umožňují Stream Analytics určit, kdy může systém vytvářet úplné, správné a opakovatelné výsledky, které není potřeba odvolat. Zpracování lze provést předvídatelným a opakovatelným způsobem. Pokud je například potřeba provést přepočítání pro určitou podmínku zpracování chyb, vodoznaky jsou bezpečné počáteční a koncové body.

Další zdroje informací o tomto tématu najdete v blogových příspěvcích Tyler Akidau streamování 101 a Streamování 102.

Volba nejlepšího počátečního času

Stream Analytics poskytuje uživatelům dvě možnosti pro výběr času události: čas příjezdu a čas aplikace.

Čas příjezdu

Čas příjezdu je přiřazen na vstupním zdroji, když událost dosáhne zdroje. K času příjezdu můžete přistupovat pomocí vlastnosti EventEnqueuedUtcTime pro vstup služby Event Hubs, vlastnosti IoTHub.EnqueuedTime pro vstup IoT Hub a vlastnost BlobProperties.LastModified pro vstup objektu blob.

Čas příjezdu se používá ve výchozím nastavení a nejlépe se používá pro scénáře archivace dat, kde není nutná časová logika.

Čas aplikace (také pojmenovaný čas události)

Čas aplikace se přiřadí, když se událost vygeneruje a je součástí datové části události. K zpracování událostí podle času aplikace použijte časové razítko podle klauzule v dotazu SELECT. Pokud časové razítko chybí, události se zpracovávají časem příjezdu.

Je důležité použít časové razítko v datové části, pokud je časová logika zapojena do účtu zpoždění ve zdrojovém systému nebo v síti. Čas přiřazený k události je k dispozici v systému SYSTEM. ČASOVÉ RAZÍTKO.

Průběh času ve službě Azure Stream Analytics

Při použití času aplikace je průběh času založený na příchozích událostech. Systém zpracování datových proudů je obtížné zjistit, jestli nedošlo k žádným událostem nebo jestli jsou události zpožděné. Z tohoto důvodu Azure Stream Analytics vygeneruje heuristické vodoznaky následujícími způsoby pro každý vstupní oddíl:

  • Pokud dojde k nějaké příchozí události, vodoznak je největší čas události Stream Analytics, který zatím viděl minus velikost okna tolerance mimo pořadí.

  • Pokud neexistuje žádná příchozí událost, vodoznak je aktuální odhadovaný čas příjezdu minus okno tolerance pozdního příjezdu. Odhadovaný čas příjezdu je čas, který uplynul od posledního výskytu vstupní události a času příjezdu vstupní události.

    Čas příjezdu lze odhadnout pouze proto, že se vygeneruje čas skutečného příjezdu na vstupním zprostředkovatele událostí, jako je Event Hubs, ani na virtuálním počítači Azure Stream Analytics zpracovávající události.

Návrh nabízí dva další účely než generování vodoznaků:

  1. Systém vygeneruje včas nebo bez příchozích událostí výsledky.

    Máte kontrolu nad tím, jak včas chcete zobrazit výsledky výstupu. V Azure Portal můžete na stránce Řazení událostí úlohy Stream Analytics nakonfigurovat nastavení událostí mimo pořadí. Když toto nastavení nakonfigurujete, zvažte kompromis časového limitu s odolností proti událostem mimo pořadí ve streamu událostí.

    Okno tolerance pozdního příjezdu je nezbytné pro zachování generování vodoznaků, a to i v případě, že nejsou příchozí události. Někdy může dojít k období, kdy nepřicházejí žádné příchozí události, například když je vstupní datový proud události řídký. Tento problém se zhoršuje použitím více oddílů ve vstupním zprostředkovatele událostí.

    Streamování systémů zpracování dat bez okna tolerance pozdního příjezdu může mít zpoždění výstupů, když jsou vstupy řídké a používají se více oddílů.

  2. Chování systému musí být opakovatelné. Opakovatelnost je důležitou vlastností systému zpracování streamovaných dat.

    Vodoznak je odvozen od času příjezdu a času aplikace. Obě jsou zachovány v zprostředkovateli událostí, a proto je to opakovatelné. Když se odhaduje doba příjezdu v nepřítomnosti událostí, azure Stream Analytics zapisuje odhadovanou dobu příjezdu pro opakovatelnost během opakovaného přehrávání pro zotavení po selhání.

Pokud se rozhodnete použít čas příjezdu jako čas události, nemusíte konfigurovat odolnost proti výpadku objednávky a toleranci pozdního příjezdu. Vzhledem k tomu, že doba příjezdu se zaručuje zvýšení vstupního zprostředkovatele událostí, Azure Stream Analytics jednoduše ignoruje konfigurace.

Pozdní příchozí události

Podle definice okna tolerance pozdního příjezdu porovnává Azure Stream Analytics čas události s časem příjezdu. Pokud je čas události mimo okno tolerance, můžete systém nakonfigurovat tak, aby událost zahodil nebo upravil čas události tak, aby byl v rámci tolerance.

Jakmile se vygenerují vodoznaky, může služba potenciálně přijímat události s časem události nižším než vodoznak. Službu můžete nakonfigurovat tak, aby tyto události zahodí nebo upravila čas události na hodnotu vodoznaku.

Jako součást úpravy je časové razítko události nastaveno na novou hodnotu, ale samotné pole času události se nezmění. Tato úprava je jediná situace, kdy se systémové razítko události může lišit od hodnoty v poli času události a může způsobit neočekávané výsledky.

Zpracování časových variací s podstreamy

Heuristický mechanismus generování vodoznaku popsaný ve většině případů, kdy se čas většinou synchronizuje mezi různými odesílateli událostí. V reálném životě, zejména v mnoha scénářích IoT, má systém malou kontrolu nad hodinami u odesílatelů událostí. Odesílatelé událostí můžou být v terénu nejrůznější zařízení, třeba na různých verzích hardwaru a softwaru.

Místo použití vodoznaku globálního pro všechny události ve vstupním oddílu má Stream Analytics jiný mechanismus označovaný jako podstreamy. Podstreamy ve své úloze můžete využít tak, že napíšete dotaz úlohy, který používá klauzuli TIMESTAMP BY a klíčové slovo OVER. Chcete-li určit podstream, zadejte název klíčového sloupce za klíčové slovo OVER , například deviceid, aby systém použil zásady času podle tohoto sloupce. Každý podstream získá vlastní nezávislý vodoznak. Tento mechanismus je užitečný k tomu, aby bylo možné včas vygenerovat výstup, při práci s velkými zpožděními hodin nebo zpoždění sítě mezi odesílateli událostí.

Podstreamy představují jedinečné řešení poskytované službou Azure Stream Analytics a nejsou nabízeny jinými systémy pro zpracování dat streamování.

Když používáte podstreamy, Stream Analytics použije okno tolerance pozdního příjezdu na příchozí události. Tolerance pozdního příjezdu rozhoduje o maximální výši, podle které mohou být různé podstreamy vzájemně odděleny. Pokud je například zařízení 1 v časovém razítku 1 a zařízení 2 je ve formátu Timestamp 2, je maximální tolerance pozdního příjezdu časové razítko 2 minus časové razítko 1. Výchozí nastavení je 5 sekund a je pravděpodobné, že je pro zařízení s rozdílnými časovými razítky příliš malá. Doporučujeme začít s 5 minutami a provádět úpravy podle vzoru nerovnoměrné distribuce hodin zařízení.

Včasné příchody událostí

Možná jste si všimli jiného konceptu označovaného jako počáteční okno příjezdu, které vypadá jako opačné okno tolerance pozdního příjezdu. Toto okno je opraveno 5 minut a slouží k jinému účelu od okna tolerance pozdního příjezdu.

Vzhledem k tomu, že Azure Stream Analytics zaručuje úplné výsledky, můžete jako první výstupní čas úlohy zadat jenom počáteční čas úlohy , nikoli čas vstupu. Čas zahájení úlohy se vyžaduje, aby se celé okno zpracovávaly, nejen zprostředkující okno.

Stream Analytics odvozuje počáteční čas ze specifikace dotazu. Vzhledem k tomu, že vstupní zprostředkovatel událostí je indexován pouze časem příjezdu, musí systém přeložit počáteční čas události na čas příjezdu. Systém může začít zpracovávat události z tohoto bodu ve vstupním zprostředkovatele událostí. S počátečním limitem příchozího okna je překlad jednoduchý: počáteční čas události minus 5minutové počáteční okno příjezdu. Tento výpočet také znamená, že systém zahodí všechny události, které jsou vidět jako události 5 minut starší než čas příjezdu. Metrika počátečních vstupních událostí se zvýší při vyřazení událostí.

Tento koncept slouží k zajištění, že zpracování bude opakovatelné bez ohledu na to, odkud začnete výstupovat. Bez takového mechanismu by nebylo možné zaručit opakovatelnost, protože mnoho dalších systémů streamování tvrdí, že to dělají.

Vedlejší účinky časových tolerancí událostí

Úlohy Stream Analytics mají několik možností řazení událostí . Dvě je možné nakonfigurovat v Azure Portal: nastavení událostí mimo pořadí (tolerance mimo pořadí) a události, které přicházejí pozdě (tolerance pozdního příjezdu). Časná tolerance příjezdu je pevná a nelze ji upravit. Tyto časové zásady používají Stream Analytics k zajištění silných záruk. Tato nastavení ale někdy mají neočekávaný dopad:

  1. Náhodné odesílání událostí, které jsou příliš rané.

    Počáteční události by neměly být normálně výstupovány. Je možné, že se do výstupu odesílají časné události, pokud ale hodiny odesílatele běží příliš rychle. Všechny včasné příchozí události se zahodí, takže se z výstupu nezobrazí žádná z nich.

  2. Odesílání starých událostí do služby Event Hubs ke zpracování službou Azure Stream Analytics

    I když staré události mohou být zpočátku neškodné, protože aplikace tolerance pozdního příjezdu, staré události mohou být vyřazeny. Pokud jsou události příliš staré, hodnota System.Timestamp se během příjmu událostí změní. Vzhledem k tomuto chování je v současné době Azure Stream Analytics vhodnější pro scénáře zpracování událostí téměř v reálném čase místo historických scénářů zpracování událostí. Události, které přijdou pozdě, můžete nastavit na největší možnou hodnotu (20 dní), aby se toto chování v některých případech obešlo.

  3. Zdá se, že výstupy jsou zpožděné.

    První vodoznak se vygeneruje v počítaném čase: maximální čas události , který systém zatím zaznamenal, minus velikost okna tolerance mimo pořadí. Ve výchozím nastavení je tolerance mimo pořadí nakonfigurovaná na nulu (00 minut a 00 sekund). Když ji nastavíte na vyšší, nenulovou časovou hodnotu, první výstup úlohy streamování se zpozdí podle této hodnoty času (nebo vyšší) kvůli prvnímu vypočítanému času vodoznaku.

  4. Vstupy jsou řídké.

    Pokud v daném oddílu není žádný vstup, vypočítá se čas meze jako čas příjezdu minus okno tolerance pozdního příjezdu. Pokud jsou vstupní události občasné a řídké, může být výstup zpožděn o tuto dobu. Výchozí hodnota Událostí, které přicházejí pozdě , je 5 sekund. Při odesílání vstupních událostí byste měli očekávat určité zpoždění, například. Zpoždění se můžou zhoršit, když nastavíte události, které přicházejí pozdě , na velkou hodnotu.

  5. Hodnota system.Timestamp se liší od času v poli času události .

    Jak jsme popsali dříve, systém upraví čas události podle odolnosti proti výpadku objednávky nebo oknech tolerance pozdních příletů. Hodnota system.Timestamp události se upraví, ale ne pole času události . Dá se použít k identifikaci událostí upravených časových razítek. Pokud systém změnil časové razítko kvůli jedné z tolerance, obvykle jsou stejné.

Metriky, které se mají sledovat

Prostřednictvím metrik úloh Azure Stream Analytics můžete sledovat řadu efektů tolerance času řazení událostí. Relevantní jsou následující metriky:

Metric Popis
Události mimo objednávku Označuje počet událostí přijatých mimo pořadí, které byly buď vyřazeny, nebo dány upraveným časovým razítkem. Tato metrika má přímý vliv na konfiguraci nastavení události Mimo pořadí na stránce Řazení událostí v úloze v Azure Portal.
Události pozdního vstupu Označuje počet událostí přicházejících pozdě ze zdroje. Tato metrika zahrnuje události, které byly vyřazeny nebo byly upraveny časové razítko. Tato metrika je přímo ovlivněna konfigurací událostí, které přicházejí pozdě nastavení na stránce Řazení událostí na úloze v Azure Portal.
Události počátečního vstupu Označuje počet událostí přicházejících brzy ze zdroje, které byly buď vyřazeny, nebo je jejich časové razítko upraveno, pokud jsou starší než 5 minut.
Zpoždění vodoznaku Označuje zpoždění úlohy zpracování streamovaných dat. Další informace najdete v následující části.

Podrobnosti zpoždění vodoznaku

Metrika zpoždění vodoznaku se vypočítá jako hodinová doba zpracování uzlu zpracování minus největší vodoznak, který dosud viděl. Další informace najdete v blogovém příspěvku o zpoždění vodoznaku.

Tato hodnota metriky je v normálním provozu větší než 0 z několika důvodů:

  1. Inherentní zpoždění zpracování kanálu streamování Obvykle je toto zpoždění nominální.

  2. Mimoobjednávné okno tolerance se zavedlo zpoždění, protože vodoznak se zmenší o velikost okna tolerance.

  3. Okno pozdního příjezdu zavedlo zpoždění, protože vodoznak se zmenší o velikost okna tolerance.

  4. Nerovnoměrná distribuce hodin uzlu zpracování generující metriku

Existuje řada dalších omezení prostředků, která můžou způsobit zpomalení kanálu streamování. Metrika zpoždění vodoznaku se může zvýšit z následujících důvodů:

  1. V Stream Analytics není dostatek prostředků pro zpracování objemu vstupních událostí. Pokud chcete vertikálně navýšit kapacitu prostředků, přečtěte si článek Vysvětlení a úprava jednotek streamování.

  2. V rámci zprostředkovatelů vstupních událostí není dostatek propustnosti, takže jsou omezené. Možná řešení najdete v tématu Automatické vertikální navýšení kapacity Azure Event Hubs jednotek propustnosti.

  3. Výstupní jímky nejsou zřízeny s dostatečnou kapacitou, takže jsou omezené. Možná řešení se v závislosti na používané výstupní službě značně liší.

Frekvence výstupních událostí

Azure Stream Analytics používá průběh vodoznaku jako jediný trigger k vytváření výstupních událostí. Vzhledem k tomu, že vodoznak je odvozen ze vstupních dat, je opakovatelný během obnovení selhání a také při opětovném zpracování iniciované uživatelem. Při použití agregací s okny služba vytváří výstupy pouze na konci oken. V některých případech můžou uživatelé chtít zobrazit částečné agregace vygenerované z oken. Částečné agregace se v současné době ve službě Azure Stream Analytics nepodporují.

V jiných řešeních streamování mohou být výstupní události materializovány v různých aktivačních bodech v závislosti na externích okolnostech. V některých řešeních je možné, že se výstupní události pro dané časové období můžou vygenerovat několikrát. Při upřesnění vstupních hodnot budou agregované výsledky přesnější. Události se můžou nejprve spekulovat a v průběhu času je revidovat. Pokud je například určité zařízení offline ze sítě, může systém použít odhadovanou hodnotu. Později se stejné zařízení dostane do sítě online. Skutečná data událostí pak mohou být zahrnuta do vstupního datového proudu. Výstupem je zpracování tohoto časového intervalu přesnější výstup.

Ilustrovaný příklad vodoznaků

Následující obrázky znázorňují průběh vodoznaků za různých okolností.

Tato tabulka ukazuje ukázková data, která jsou znázorněna níže. Všimněte si, že čas události a čas příjezdu se někdy liší, někdy odpovídající a někdy ne.

Čas události Čas příjezdu 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

Na tomto obrázku se používají následující tolerance:

  • Časná příjezdová okna jsou 5 minut
  • Pozdní příjezdové okno je 5 minut
  • Změna pořadí okna je 2 minuty
  1. Obrázek vodoznaku procházejícího těmito událostmi:

    Obrázek vodoznaku Azure Stream Analytics

    Důležité procesy znázorněné na předchozím obrázku:

    1. První událost (zařízení1) a druhá událost (zařízení2) mají zarovnané časy a zpracovávají se bez úprav. Vodoznak probíhá u každé události.

    2. Při zpracování třetí události (zařízení1) předchází čas příjezdu (12:11) času události (12:17). Událost dorazila o 6 minut dříve, takže událost se vyřadí z důvodu tolerance 5minutového příjezdu.

      Vodoznak v tomto případě počáteční události nepostupuje.

    3. Čtvrtá událost (zařízení3) a pátá událost (zařízení1) mají zarovnané časy a zpracovávají se bez úpravy. Vodoznak probíhá u každé události.

    4. Při zpracování šesté události (zařízení3) je čas příjezdu (12:17) a čas události (12:12) pod úrovní meze. Čas události se upraví na úroveň vodoznaku (12:17).

    5. Při zpracování dvanácté události (zařízení3) je čas příjezdu (12:27) před časem události 6 minut (12:21). Použije se zásada pozdního příjezdu. Čas události se upraví (12:22), který je nad vodoznakem (12:21), takže se nepoužije žádná další úprava.

  2. Druhý obrázek vodoznaku, který probíhá bez zásad předčasného příjezdu:

    Obrázek vodoznaku pro Azure Stream Analytics bez počátečních zásad

    V tomto příkladu se nepoužijí žádné zásady předčasného příjezdu. Odlehlé události, které přicházejí brzy, výrazně zvyšují vodoznak. Všimněte si, že třetí událost (deviceId1 v okamžiku 12:11) se v tomto scénáři nezahodí a vodoznak se vyvolá na 12:15. Čtvrtý čas události se upraví dopředu 7 minut (12:08 až 12:15) jako výsledek.

  3. Na posledním obrázku se použijí podstreamy (OVER DeviceId). Sleduje se více vodoznaků, jeden na datový proud. V důsledku toho dochází k menšímu počtu událostí, které se v důsledku toho upraví.

    Obrázek vodoznaku v podstreamech Azure Stream Analytics

Další kroky