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

Článek
07/17/2024

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

Koncepty času na pozadí

Abychom mohli diskuzi lépe zarámovat, pojďme definovat některé základní koncepty:

Č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í: Čas, kdy událost dosáhne systému zpracování a je pozorována. Například když senzor placené linky vidí 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 příjmu událostí. Podle povahy datových proudů se příchozí data událostí nikdy nezastaví, takže vodoznaky označují průběh do určitého bodu v datovém 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 třeba například provést přepočet pro určitý stav 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 Streaming 101 a Streaming 102.

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

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

Čas příjezdu

Čas příjezdu se přiřadí ke vstupnímu 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 služby IoT Hub a vlastnosti BlobProperties.LastModified pro vstup objektu blob.

Čas příjezdu se používá ve výchozím nastavení a je nejvhodnější pro scénáře archivace dat, kdy není nutná dočasná logika.

Čas aplikace (také s názvem Čas události)

Čas aplikace se přiřadí, když se událost vygeneruje, a je součástí datové části události. Chcete-li zpracovat události 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.

Jak čas postupuje 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:

Když dojde k nějaké příchozí události, vodoznak je největší čas, kdy Stream Analytics dosud viděl minus velikost okna tolerance mimo pořadí.
Pokud nedojde k žádné příchozí události, 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í události vstupu a čas příjezdu vstupní události.

Čas příjezdu lze odhadnout pouze proto, že se na vstupním zprostředkovateli událostí, jako je Event Hubs, nebo na virtuálním počítači Azure Stream Analytics, který události zpracovává, vygeneruje skutečný čas příjezdu.

Návrh slouží ke dvěma dalším účelům než generování vodoznaků:

Systém generuje výsledky včas s příchozími událostmi nebo bez.

Máte kontrolu nad tím, jak včas chcete zobrazit výsledky výstupu. Na webu Azure Portal můžete na stránce Řazení událostí úlohy Stream Analytics nakonfigurovat nastavení události Mimo pořadí. Když toto nastavení nakonfigurujete, zvažte kompromis s včasností s tolerancí událostí mimo pořadí ve streamu událostí.

Okno tolerance pozdního příjezdu je nezbytné k tomu, aby se vygenerovaly vodoznaky, a to i v případě nepřítomnosti příchozích událostí. Někdy může docházet k období, kdy nedochází k žádným příchozím událostem, 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ředkovateli událostí.

Systémy zpracování streamovaných dat bez okna tolerance pozdního příjezdu můžou mít zpoždění výstupů, když jsou vstupy zhuštěné a používá se více oddílů.
Chování systému musí být opakovatelné. Opakovatelnost je důležitou vlastností systému zpracování streamovaných dat.

Vodoznak se odvozuje od času příjezdu a času aplikace. Oba se uchovávají ve zprostředkovateli událostí, a proto se dají opakovat. Když se odhaduje doba příjezdu v nepřítomnosti událostí, azure Stream Analytics deníkuje odhadovanou dobu doručení pro opakovatelnost během opakovaného přehrání pro obnovení selhání.

Pokud se rozhodnete použít čas příjezdu jako čas události, nemusíte konfigurovat toleranci mimo objednávku a toleranci pozdního příjezdu. Vzhledem k tomu, že je zaručeno, že doba příjezdu se zvyšuje ve vstupním zprostředkovateli událostí, Azure Stream Analytics jednoduše ignoruje konfigurace.

Pozdní příchozí události

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

Po vygenerování vodoznaků může služba potenciálně přijímat události s nižším časem události, než je vodoznak. Službu můžete nakonfigurovat tak, aby tyto události zahodí nebo upravila čas události na hodnotu meze.

V rámci ú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 časové razítko události může lišit od hodnoty v poli času události a může způsobit vygenerování neočekávaných výsledků.

Zpracování časové variace s dílčími streamy

Heuristický mechanismus generování vodoznaku popsaný ve většině případů funguje dobře, 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, ale systém má malou kontrolu nad hodinami odesílatelů událostí. Odesílatelé událostí můžou být nejrůznější zařízení v terénu, možná v různých verzích hardwaru a softwaru.

Místo použití vodoznaku, který je globální pro všechny události ve vstupním oddílu, má Stream Analytics jiný mechanismus označovaný jako podstreamy. V úloze můžete využít podstreamy napsáním dotazu ú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á svůj vlastní nezávislý vodoznak. Tento mechanismus je užitečný k tomu, aby bylo možné včas vygenerovat výstup při zpracování velkých zpoždění hodin nebo zpoždění sítě mezi odesílateli událostí.

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

Pokud 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, o kterou 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 v časovém razítku 2, maximální tolerance pozdního příjezdu je časové razítko 2 minus časové razítko 1. Výchozí nastavení je 5 sekund a pro zařízení s rozdílovými časovými razítky je pravděpodobně příliš malá. Doporučujeme, abyste začali s 5 minutami a provedli úpravy podle vzoru nerovnoměrné distribuce hodin zařízení.

Časné příchody událostí

Možná jste si všimli jiného konceptu označovaného jako okno předčasného příjezdu, které vypadá jako opak okna tolerance pozdního příjezdu. Toto okno je opraveno 5 minut a slouží k jinému účelu než okno 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 pouze čas spuštění úlohy, nikoli vstupní čas. Čas spuštění úlohy se vyžaduje, aby se celé okno zpracovalo, ne jenom uprostřed okna.

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ředkovateli událostí. S počátečním limitem vstupního okna je překlad jednoduchý: počáteční čas události minus 5minutový počáteční příchozí okno. Tento výpočet také znamená, že systém zahodí všechny události, které jsou považovány za události o 5 minut dříve než čas příjezdu. Metrika počátečních vstupních událostí se při vyřazení událostí zvýší.

Tento koncept se používá k zajištění, že zpracování bude opakovatelné bez ohledu na to, odkud začnete vytvářet výstupy. 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 tolerance času řazení událostí

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

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

Počáteční události by se neměly normálně vysílat. Pokud ale hodiny odesílatele běží příliš rychle, je možné, že se do výstupu odesílají počáteční události. Všechny včas přicházející události se zahodí, takže z výstupu se nezobrazí žádná z nich.
Odesílání starých událostí do služby Event Hubs ke zpracování službou Azure Stream Analytics

I když se staré události můžou zpočátku zdát neškodné, protože se používá 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í. V některých případech můžete nastavit události, které přicházejí pozdě na nejvyšší možnou hodnotu (20 dní), aby se toto chování v některých případech obešlo.
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 hodnotu času, první výstup úlohy streamování se zpozdí podle této hodnoty času (nebo vyšší) kvůli prvnímu vypočítanému času vodoznaku.
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álosti, 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šovat, když nastavíte události, které přicházejí pozdě , na velkou hodnotu.
Hodnota system.Timestamp se liší od času v poli času události.

Jak jsme popsali dříve, systém upraví čas události podle tolerance mimo objednávku nebo oken tolerance pozdního příjezdu. Hodnota System.Timestamp události se upraví, ale ne pole času události. To se dá použít k identifikaci událostí upravených časových razítek. Pokud systém změnil časové razítko kvůli jedné z tolerancí, obvykle jsou stejné.

Metriky, které se mají sledovat

Pomocí metrik úloh Azure Stream Analytics můžete sledovat řadu efektů časového tolerance pořadí událostí. Relevantní jsou následující metriky:

Metrický	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 je přímo ovlivněna konfigurací nastavení Události mimo pořadí na stránce Pořadí událostí úlohy na webu Azure Portal.
Události pozdního vstupu	Urč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ěná konfigurací událostí, které přicházejí pozdě na stránce pořadí událostí na stránce pořadí událostí na webu 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ů:

Zpoždění zpracování kanálu streamování. Obvykle je toto zpoždění nominální.
Mimoobjednávné okno tolerance zavedlo zpoždění, protože vodoznak se zmenší o velikost okna tolerance.
Pozdní okno příjezdu zavedlo zpoždění, protože vodoznak se zmenší o velikost okna tolerance.
Nerovnoměrná distribuce hodin uzlu zpracování, který generuje 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ů:

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 téma Vysvětlení a úprava jednotek streamování.
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 jednotek propustnosti služby Azure Event Hubs.
Výstupní jímky nejsou zřízeny s dostatečnou kapacitou, takže jsou omezené. Možná řešení se značně liší v závislosti na typu používané výstupní služby.

Frekvence výstupních událostí

Azure Stream Analytics používá jako jediný trigger průběh vodoznaku 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 generuje výstupy pouze na konci oken. V některých případech můžou uživatelé chtít zobrazit částečné agregace generované 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í můžou 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 výstupní události pro daný časový interval se dají vygenerovat několikrát. S upřesněním vstupních hodnot se agregované výsledky stanou přesnějšími. Události lze nejprve spekulovat a v průběhu času je možné 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í daného č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 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	zařízení3
12:19	12:16	device1
12:12	12:17	zařízení3
12:17	12:18	device2
12:20	12:19	device2
12:16	12:21	zařízení3
12:23	12:22	device2
12:22	12:24	device2
12:21	12:27	zařízení3

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

Časná příjezdová okna je 5 minut
Pozdní příchozí okno je 5 minut
Změna pořadí okna je 2 minuty

Obrázek vodoznaku procházejícího těmito událostmi:

Popisné procesy znázorněné na předchozím obrázku:
1. První událost (device1) a druhá událost (zařízení2) mají zarovnané časy a zpracovávají se bez úprav. Vodoznak postupuje u každé události.
2. Při zpracování třetí události (device1) předchází čas přijetí (12:11) času události (12:17). Událost přišla o 6 minut dříve, takže událost se z důvodu tolerance 5minutového příjezdu přeruší.
  
  Vodoznak v tomto případě nepostupuje.
3. Čtvrtá událost (device3) a pátá událost (device1) mají zarovnanou dobu a zpracovávají se bez úpravy. Vodoznak postupuje u každé události.
4. Při zpracování šesté události (device3) je čas příletu (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 (device3) je čas příjezdu (12:27) o 6 minut před časem události (12:21). Použijí se zásady 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.
Druhý obrázek vodoznaku, který postupuje bez zásad předčasného příjezdu:

V tomto příkladu se nepoužijí žádné zásady předčasného příjezdu. Odlehlé události, které přicházejí dříve, výrazně zvýší 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.
Na posledním obrázku se použijí podstreamy (OVER DeviceId). Více vodoznaků se sleduje, jeden na datový proud. V důsledku toho dochází k menšímu počtu událostí, které se v důsledku toho upraví.