Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Zpracování času ve službě Azure Stream Analytics je sada mechanismů, které určují, jak se události streamování časově značkují, seřazují a zpracovávají na základě jejich výskytu oproti jejich příchodu. Tento článek vysvětluje, jak provádět návrhová rozhodnutí k ř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í.
Časové koncepty na pozadí
Abychom mohli diskuzi lépe zarámovat, pojďme definovat některé základní koncepty:
Čas události: Čas, kdy dojde k původní události. Například když se auto na dálnici blíží k mýtné bráně.
Doba zpracování: Čas, kdy událost dosáhne systému zpracování a je pozorována. Například, když senzor mýtné brány vidí auto a počítačovému systému chvíli trvá zpracovat data.
Vodoznak: Časová značka události, která ukazuje, do jakého bodu byl streamovací procesor schopen zpracovat události. Časové značky umožňují systému naznačit jasný postup při přijímání 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í službě Azure 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. Například pokud je nutné provést rekalkulaci kvůli zvládání chybových podmínek, 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
Azure Stream Analytics nabízí dvě možnosti pro výběr času události: čas přijetí a čas aplikace.
Čas příjezdu
Čas příjezdu je přiřazen ke vstupnímu zdroji ve chvíli, 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 klauzuli Timestamp by 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, když je zapojena časová logika, aby se zohlednilo 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. Je pro systém zpracování datových proudů obtížné zjistit, zda nedošlo k žádným událostem nebo zda 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ž se objeví nějaká příchozí událost, vodoznak představuje největší čas události, který služba Azure Stream Analytics dosud zaznamenala, mínus velikost okna tolerance pro události 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 součet času, který uplynul od okamžiku, kdy byla naposledy zaznamenána událost vstupu, a času příjezdu dané vstupní události.
Čas příjezdu se dá odhadnout jenom proto, že se vygeneruje čas skutečného příjezdu na vstupním zprostředkovateli událostí (jako je Event Hubs nebo IoT Hub), ne na virtuálním počítači Azure Stream Analytics, který události zpracovává.
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álostí 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 mohly být vodoznaky generovány nepřetržitě, dokonce i při 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 jsou persistováni ve zprostředkovateli událostí, a lze je tak opakovat. Když se v nepřítomnosti událostí odhaduje doba příjezdu, Azure Stream Analytics zaznamenává tuto odhadovanou dobu příjezdu pro opakovatelnost během opakovaného přehrání při obnově po selhání.
Pokud se rozhodnete použít čas příjezdu jako čas události, nemusíte konfigurovat toleranci mimo pořadí a toleranci pozdního příjezdu. Vzhledem k tomu, že je zaručeno, že doba příjezdu se ve zprostředkovateli vstupních událostí zvyšuje, Azure Stream Analytics ignoruje konfigurace.
Události přicházející pozdě
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 byly tyto události zahozena, nebo upravit čas události na hodnotu vodotisku.
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, ve kterém Azure Stream Analytics sleduje průběh času události pomocí největšího pozorovaného časového razítka minus interval tolerance, funguje dobře ve většině případů, kdy je čas většinou synchronizován mezi různými odesílateli událostí. V reálném životě, zejména v mnoha scénářích IoT, má však systém malou kontrolu nad časovým nastavením odesílatelů událostí. Odesílatelé událostí můžou být v terénu nejrůznější zařízení IoT, možná v různých verzích hardwaru a firmwaru zařízení.
Místo použití globálního vodoznaku pro všechny události ve vstupním oddílu má Azure Stream Analytics jiný mechanismus nazývaný dílčí streamy. V úloze můžete použí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ý pro včasné generování výstupu v případě velkých časových zkreslení nebo zpoždění sítě mezi odesílateli událostí.
Když používáte podstreamy, Azure 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í tolerance pozdního příjezdu je 5 sekund, což je pro zařízení IoT s rozdílovými časovými razítky pravděpodobně příliš malé. Začněte s 5 minutami a proveďte úpravy podle vzoru časového posunu hodin zařízení.
Události s předčasným příchodem
Počáteční okno příjezdu je pevná 5minutová tolerance, která určuje, jak brzy může událost dorazit vzhledem k času události, než ji Azure Stream Analytics zahodí. Toto okno 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 je nutný, aby systém zpracovává úplné okno, a ne pouze od středu okna.
Azure Stream Analytics odvozuje počáteční čas ze specifikace dotazu. Vzhledem k tomu, že vstupní zprostředkovatel událostí je indexován pouze podle času příjezdu, musí systém převést 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 příjezdového okna je překlad jednoduchý: počáteční čas události minus 5 minutové okno příjezdu. 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 zvýší, když jsou události vyřazeny.
Tento koncept zajišťuje, ž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 Azure Stream Analytics mají několik možností řazení událostí . Na portálu Azure lze nakonfigurovat dvě nastavení: nastavení událostí mimo pořadí (tolerance pro události mimo pořadí) a nastavení událostí, které přicházejí pozdě (tolerance pozdního příchodu). Tolerance předčasného příjezdu je pevná a nelze ji upravit. Azure Stream Analytics tyto časové zásady používá k zajištění silných záruk. Tato nastavení ale někdy mají neočekávané důsledky:
Neúmyslné odesílání událostí, které jsou příliš brzy.
Počáteční události by normálně neměly být výstupem. Pokud hodiny odesílatele běží příliš rychle, mohou být počáteční události odesílány do výstupu. Všechny předčasně přicházející události se zahodí, takže se žádná z nich nezobrazí ve výstupu.
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é, kvůli použití tolerance pozdního příjezdu může dojít k vyřazení starých událostí. Pokud jsou události příliš staré, hodnota System.Timestamp se během příjmu událostí změní. Kvůli tomuto chování je Azure Stream Analytics vhodnější pro scénáře zpracování událostí téměř v reálném čase než pro historické scénáře 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 až dosud zaznamenal, minus velikost okna tolerance pro zpracování mimo pořadí. Ve výchozím nastavení je tolerance chybného pořadí nakonfigurovaná na nulu (00 minut a 00 sekund). Když ji nastavíte na hodnotu času větší než nula, první výstup streamovací úlohy se zpozdí o tuto hodnotu času (nebo vyšší) kvůli časové známce prvního vodoznaku, která je vypočítaná.
Vstupy jsou omezené.
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 pro události, které přicházejí pozdě je 5 sekund. Očekávejte určité zpoždění, když například odesíláte vstupní události jednotlivě. Zpoždění se mohou zhoršit, 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 tolerančního okna neuspořádanosti nebo pozdního příjezdu. Hodnota System.Timestamp události se upraví, ale pole času události se neupraví. Můžete to použít k identifikaci událostí, u kterých byla časová razítka upravena. Pokud systém změní č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 pořadí | Určuje počet událostí přijatých mimo pořadí, které byly buď vyřazeny, nebo dostaly upravené časové razítko. Tato metrika je přímo ovlivněna konfigurací nastavení Události mimo pořadí na stránce Pořadí událostí úlohy na Azure Portalu. |
| 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 kterým byla upravena časová razítka. Tato metrika je přímo ovlivněna konfigurací událostí, které přicházejí pozdě na stránce pořadí událostí v Azure Portálu. |
| Události počátečního vstupu | Označuje počet událostí časně příchozích ze zdroje, které byly buď vyřazeny, nebo měly upravené časové razítko, pokud přicházejí o více než 5 minut dříve. |
| Zpoždění vodoznaku | Označuje zpoždění úlohy zpracování streamovaných dat. Další informace najdete v následující části. |
Podrobnosti o zpoždění vodoznaku
Azure Stream Analytics vypočítá metriku zpoždění vodoznaku jako hodinový čas uzlu zpracování minus největší vodoznak, který zatím viděl. Další informace najdete v části 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í interval příjezdu způsobil zpoždění, protože vodoznak je zmenšen o velikost intervalu tolerance.
Časový posun uzlu zpracování generujícího metriku.
Existuje několik 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 Azure Stream Analytics není dostatek prostředků pro zpracování objemu vstupních událostí. Pokud chcete navýšit kapacitu prostředků, přečtěte si Vysvětlení a úprava streamovacích jednotek.
Vstupní zprostředkovatelé událostí nemají dostatečnou propustnost, takže jsou omezováni. 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 (například Azure SQL Database, Blob Storage nebo Power BI) nejsou zřízené s dostatečnou kapacitou, takže jsou omezené. Možná řešení se značně liší v závislosti na používané výstupní službě.
Frekvence výstupních událostí
Azure Stream Analytics používá průběh vodoznaku jako jediný spouštěč k vytváření výstupních událostí. Vzhledem k tomu, že vodoznak je odvozen ze vstupních dat, je opakovatelný během obnovy po selhání a také při opětovném zpracování iniciovaném uživatelem. Při použití okenních agregací služba generuje výstupy pouze na konci oken. V některých případech můžete chtít zobrazit částečné agregace vygenerované z oken. V Azure Stream Analytics se v současné době nepodporují částečné agregace.
V jiných řešeních streamování je možné výstupní události materializovat 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é vygenerovat výstupní události pro dané časové období 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ýsledky zpracování tohoto časového okna vedou k přesnějšímu výstupu.
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 | zařízení1 |
| 12:08 | 12:08 | device2 |
| 12:17 | 12:11 | device1 |
| 12:08 | 12:13 | zařízení3 |
| 12:19 | 12:16 | zařízení1 |
| 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 | zařízení2 |
| 12:22 | 12:24 | zařízení2 |
| 12:21 | 12:27 | zařízení3 |
Na tomto obrázku se používají následující tolerance:
- Počáteční okno příjezdu je 5 minut
- Pozdní příchozí okno je 5 minut
- Okno pro nové objednávky trvá 2 minuty
Zobrazení, jak vodoznak postupuje těmito událostmi:
Významné procesy znázorněné na předchozím obrázku:
První událost (device1) a druhá událost (zařízení2) mají zarovnané časy a zpracovávají se bez úprav. Vodoznak pokračuje během každé události.
Když se zpracovává třetí událost (device1), čas přijetí (12:11) předchází času události (12:17). Událost přišla o 6 minut dříve, takže je z důvodu tolerance 5minutového předčasného příchodu vyřazena.
Vodoznak v tomto případě časné události nepostupuje.
Čtvrtá událost (device3) a pátá událost (device1) mají zarovnanou dobu a zpracovávají se bez úpravy. Vodoznak postupuje při každé události.
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 je upraven na úroveň vodní hladiny (12:17).
Při zpracování dvanácté události (device3) je čas příjezdu (12:27) o 6 minut dříve než čas 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á ilustrace postupujícího vodoznaku bez politiky 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ýší prahovou hodnotu. 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 zvýší na 12:15. Čas čtvrté události je posunut o 7 minut dopředu (z 12:08 na 12:15) v důsledku toho.
Na posledním obrázku se použijí podstreamy (OVER DeviceId). Sleduje se více vodoznaků, každý pro jeden datový tok. V důsledku toho dochází k menšímu počtu událostí s upravenými časy.
