Principy zpracování času ve službě Azure Stream Analytics
V tomto článku se dozvíte, jak zvolit návrh, abyste vyřešili praktické problémy s zpracováním č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í
Abychom mohli diskuzi lépe zarámovat, nadefinujme některé základní koncepty:
Čas události: Čas, kdy došlo k původní události. Například když se auto na dálnici blíží k mýtnici.
Doba zpracování: Čas, kdy událost dosáhne systému zpracování a je pozorována. Například když senzor placené brány vidí auto a počítačový systém chvíli trvá, než data zpracuje.
Vodoznak: Značka času události, která označuje, do jakého bodu došlo k příchozímu přenosu událostí do procesoru streamování. Vodoznaky umožňují systému jasně indikovat 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 ve streamu.
Koncept vodoznaku je důležitý. Vodoznaky umožňují službě Stream Analytics určit, kdy může systém vytvořit úplné, správné a opakovatelné výsledky, které není potřeba odvolat. Zpracování lze provádět předvídatelným a opakovatelným způsobem. Pokud je například potřeba provést přepočet pro určitou podmínku zpracování chyb, vodoznaky jsou bezpečné počáteční a koncové body.
Další zdroje informací k tomuto tématu najdete v blogových příspěvcích Tylera Akidaua Streaming 101 a Streaming 102.
Volba nejlepšího času zahájení
Stream Analytics nabízí 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 se přiřadí 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 IoT Hub a vlastnosti BlobProperties.LastModified pro vstup objektu blob.
Ve výchozím nastavení se používá čas příjezdu a je nejvhodnější pro scénáře archivace dat, kdy není časová logika nutná.
Čas aplikace (označovaný také jako čas události)
Čas aplikace se přiřadí při generování události a je součástí datové části události. Pokud chcete zpracovávat události podle času aplikace, použijte klauzuli Timestamp by v dotazu SELECT. Pokud časové razítko chybí, události se zpracovávají podle času příjezdu.
Je důležité použít časové razítko v datové části, pokud je zahrnuta dočasná logika pro zohlednění zpoždění ve zdrojovém systému nebo v síti. Čas přiřazený události je k dispozici v systému SYSTEM. ČASOVÉ RAZÍTKO.
Postup času ve službě Azure Stream Analytics
Při použití času aplikace je časový průběh založen na příchozích událostech. Pro systém zpracování datových proudů je obtížné zjistit, jestli neexistují žádné události nebo jestli jsou události zpožděné. Z tohoto důvodu Azure Stream Analytics pro každý vstupní oddíl vygeneruje heuristické vodoznaky následujícími způsoby:
Pokud dojde k nějaké příchozí události, vodoznak představuje největší čas události, který Stream Analytics dosud viděl, a to po odečtení velikosti okna tolerance mimo pořadí.
Pokud není žádná příchozí událost, vodoznak je aktuální odhadovaný čas příjezdu minus interval tolerance pozdního příjezdu. Odhadovaný čas příjezdu je čas, který uplynul od posledního zobrazení vstupní události plus čas příjezdu vstupní události.
Čas příjezdu je možné odhadnout pouze proto, že skutečný čas příjezdu se generuje na vstupním zprostředkovateli událostí, jako je Event Hubs, ani na virtuálním počítači Azure Stream Analytics, který události zpracovává.
Návrh má kromě generování vodoznaků ještě dva další účely:
Systém generuje výsledky včas s příchozími událostmi nebo bez příchozích událostí.
Máte kontrolu nad tím, jak včas chcete zobrazit výsledky výstupu. V Azure Portal můžete na stránce Pořadí událostí úlohy Stream Analytics nakonfigurovat nastavení Události mimo pořadí. Při konfiguraci tohoto nastavení zvažte kompromis včasnosti s tolerancí událostí mimo pořadí ve streamu událostí.
Okno tolerance pozdního příchodu je nezbytné k zachování generování vodoznaků, a to i při absenci příchozích událostí. 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 zhuštěný. Tento problém je ještě horší použitím více oddílů ve vstupním zprostředkovateli událostí.
Systémy pro zpracování dat streamování bez okna tolerance pozdního příchodu můžou mít zpoždění výstupu, když jsou vstupy zhuštěné a používají 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 je odvozený z času příjezdu a času aplikace. Oba jsou trvalé ve zprostředkovateli událostí, a proto se dají opakovat. Při odhadu času příjezdu v případě nepřítomnosti událostí Azure Stream Analytics zapisuje odhadovaný čas příjezdu, aby se během přehrávání opakovalo obnovení kvůli selhání.
Pokud se rozhodnete jako čas události použít čas příjezdu , nemusíte konfigurovat odolnost proti nedoobjednávce a pozdnímu příjezdu. Vzhledem k tomu, že se u zprostředkovatele vstupních událostí zaručeně prodlužuje čas příjezdu , Azure Stream Analytics jednoduše ignoruje konfigurace.
Události pozdního příchodu
Podle definice okna tolerance pozdního příchodu porovnává Azure Stream Analytics pro každou příchozí událost č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.
Po vygenerování vodoznaků 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 buď zahodí , nebo upravila čas události na hodnotu meze.
V rámci úpravy je system.Timestamp události nastaveno na novou hodnotu, ale samotné pole času události se nezmění. Tato úprava je jedinou situací, kdy se časové razítko System.Timestamp události může lišit od hodnoty v poli čas události a může způsobit vygenerování neočekávaných výsledků.
Zpracování časových variací pomocí podstreamů
Popsaný heuristický mechanismus generování vodoznaků 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 hodinami odesílatelů událostí. Odesílateli událostí můžou být nejrůznější zařízení v terénu, třeba na 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. 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. Pokud chcete 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 řešení velkých nerovnoměrných distribuce hodin nebo zpoždění sítě mezi odesílateli událostí.
Podstreamy jsou jedinečné řešení poskytované službou Azure Stream Analytics a jiné systémy zpracování streamovaných dat je nenabízí.
Když používáte podstreamy, Stream Analytics použije u příchozích událostí okno tolerance pozdního příchodu. Tolerance pozdního příchodu určuje maximální množství, o 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 v časovém razítku 2, je tolerance nejpozději dojezdu časová razítka 2 minus časové razítko 1. Výchozí nastavení je 5 sekund a je pravděpodobně příliš malé pro zařízení s odlišnými časovými razítky. Doporučujeme začít s 5 minutami a provádět úpravy podle vzoru nerovnoměrné distribuce hodin zařízení.
Události s dřívějším příchodem
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 pevně nastaveno na 5 minut a slouží k jinému účelu než při pozdním příjezdu.
Vzhledem k tomu, že Azure Stream Analytics zaručuje úplné výsledky, můžete jako první čas výstupu úlohy zadat pouze čas zahájení úlohy , nikoli čas vstupu. Čas spuštění úlohy se vyžaduje, aby se celé okno zpracovalo, a to nejen ze středu okna.
Stream Analytics odvozuje čas zahájení ze specifikace dotazu. Vzhledem k tomu, že zprostředkovatel vstupních událostí je indexován pouze podle času 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 od tohoto bodu ve vstupním zprostředkovateli událostí. S limitem časného příchodu je překlad jednoduchý: čas zahájení události minus 5 minut před příchodem. Tento výpočet také znamená, že systém zahodí všechny události, které mají čas události o 5 minut dříve, než je čas příjezdu. Metrika počátečních vstupních událostí se při zahození událostí zvýší.
Tento koncept se používá k zajištění opakovatelného zpracování bez ohledu na to, odkud začnete výstup. Bez takového mechanismu by nebylo možné zaručit opakovatelnost, jak tvrdí mnoho jiných systémů streamování.
Vedlejší účinky časových tolerancí řazení událostí
Úlohy Stream Analytics mají několik možností řazení událostí . V Azure Portal je možné nakonfigurovat dvě: nastavení Události mimo pořadí (tolerance mimo pořadí) a nastavení Události, které dorazí pozdě (tolerance pozdního příchodu). Tolerance předčasného příchodu je pevná a nelze ji upravit. Tyto časové zásady používá Stream Analytics k poskytování silných záruk. Tato nastavení ale mají v některých případech neočekávané důsledky:
Náhodné odesílání událostí, které jsou příliš brzy
Časné události by se neměly vypouštět normálně. Je možné, že se do výstupu odesílají časné události, pokud hodiny odesílatele běží příliš rychle. Všechny události, které přicházejí předčasně, se zahodí, takže z výstupu neuvidíte žádnou 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 mohou na první pohled zdát neškodné, kvůli použití tolerance pozdního příletu mohou být staré události 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 azure Stream Analytics v současné době vhodnější pro scénáře zpracování událostí téměř v reálném čase než pro scénáře zpracování historických událostí. V některých případech můžete toto chování obejít nastavením události, které přicházejí pozdě na nejvyšší možnou hodnotu (20 dní).
Zdá se, že výstupy jsou zpožděné.
První vodoznak se vygeneruje v vypočítaný čas: maximální doba, po které systém doposud zaznamenal událost, 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ž nastavíte vyšší nenulovou časovou hodnotu, první výstup úlohy streamování se zpozdí o tuto hodnotu času (nebo vyšší) kvůli prvnímu vypočítanému času meze.
Vstupy jsou zhuštěné.
Pokud v daném oddílu není žádný vstup, čas meze se vypočítá jako čas příjezdu minus interval tolerance pozdního příchodu. V důsledku toho, pokud jsou vstupní události málo časté a zhuštěné, může být výstup o danou dobu zpožděn. Výchozí hodnota Události, které přijdou pozdě , je 5 sekund. Měli byste očekávat, že například při odesílání vstupních událostí po jednom dochází k určitému zpoždění. Zpoždění se můžou zhoršovat, když nastavíte možnost Události, které dorazí pozdě , na velkou hodnotu.
Hodnota System.Timestamp se liší od času v poli Čas události.
Jak je popsáno výše, systém upravuje čas události podle tolerance mimo pořadí nebo o intervaly tolerance pozdního příchodu. Hodnota System.Timestamp události se upraví, ale ne pole čas události . Dá se použít k určení událostí, pro které se časová razítka upravila. Pokud systém změnil časové razítko kvůli některé z tolerancí, obvykle jsou stejné.
Metriky k pozorování
Prostřednictvím metrik úlohy Azure Stream Analytics můžete sledovat řadu efektů časové tolerance pořadí událostí. Relevantní jsou následující metriky:
| Metric | Popis |
|---|---|
| Události mimo pořadí | Určuje počet událostí přijatých mimo pořadí, které byly buď vyřazeny, nebo byly přiřazeny upravené časové razítko. Tato metrika je přímo ovlivněna konfigurací nastavení Událostí mimo pořadí na stránce Řazení událostí u úlohy v Azure Portal. |
| Pozdní vstupní události | Určuje počet událostí přicházejících pozdě ze zdroje. Tato metrika zahrnuje události, které byly vyřazeny nebo u kterých došlo k úpravě jejich časového razítka. Tato metrika je přímo ovlivněna konfigurací nastavení Události, které přijdou pozdě na stránce Pořadí událostí úlohy v Azure Portal. |
| Počáteční vstupní události | Označuje počet událostí přicházejících dříve ze zdroje, které byly buď vyřazeny, nebo bylo 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 počítá jako hodinový čas na zdi uzlu zpracování minus největší vodoznak, který dosud viděl. Další informace najdete v blogovém příspěvku zpoždění vodoznaku.
Může existovat několik důvodů, proč je tato hodnota metriky při normálním provozu větší než 0:
Vlastní zpoždění zpracování kanálu streamování Za normálních okolností je toto zpoždění nominální.
V okně tolerance mimo pořadí došlo ke zpoždění, protože vodoznak je zmenšen velikostí okna tolerance.
V okně pozdního příchodu došlo ke zpoždění, protože vodoznak je zmenšen o velikost okna tolerance.
Nerovnoměrná distribuce hodin uzlu zpracování, který metriku generuje.
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ů:
Ve 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í dostatečná propustnost, takže jsou omezeni. Možná řešení najdete v tématu Automatické vertikální navýšení kapacity Azure Event Hubs jednotek propustnosti.
Výstupní jímky nejsou zřízené s dostatečnou kapacitou, takže se omezují. Možná řešení se výrazně liší v závislosti na typu používané výstupní služby.
Frekvence výstupních událostí
Azure Stream Analytics používá průběh vodoznaku jako jediný trigger pro vytváření výstupních událostí. Vzhledem k tomu, že vodoznak je odvozen ze vstupních dat, je opakovatelný během neúspěšného obnovení a také při opětovném zpracování iniciované uživatelem. Při použití agregací v oknech vytváří služba 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ě v Azure Stream Analytics nepodporují.
V jiných řešeních streamování je možné v závislosti na externích okolnostech materializovat výstupní události v různých aktivačních bodech. V některých řešeních je možné, že výstupní události pro dané časové období by mohly být generovány vícekrát. Se zpřesněním vstupních hodnot budou agregované výsledky přesnější. Události by se mohly 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ě, systém může použít odhadovanou hodnotu. Později se stejné zařízení dostane do režimu online v síti. Do vstupního streamu by pak mohla být zahrnuta skutečná data události. Výstup je výsledkem zpracování daného časového intervalu a výsledkem je 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 v grafu níže. Všimněte si, že čas události a čas příjezdu se liší, někdy odpovídá 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á okna příjezdu do 5 minut
- Zpoždění příjezdu je 5 minut
- Okno změny pořadí je 2 minuty
Obrázek vodoznaku procházejícího těmito událostmi:
Procesy, které jsou znázorněny na předchozím obrázku:
První událost (device1) a druhá událost (device2) mají zarovnané časy a zpracovávají se bez úprav. Vodoznak pokračuje u každé události.
Když se zpracuje třetí událost (device1), čas příjezdu (12:11) předchází času události (12:17). Událost dorazila o 6 minut dříve, takže se událost zahodí kvůli toleranci příjezdu o 5 minut dříve.
Vodoznak nepostupuje v tomto případě dřívější události.
Čtvrtá událost (device3) a pátá událost (device1) mají zarovnané časy a zpracovávají se bez úpravy. Vodoznak pokračuje u každé události.
Když se zpracuje šestá událost (device3), čas příjezdu (12:17) a čas události (12:12) jsou pod úrovní meze. Čas události se upraví na hladinu vodní hladiny (12:17).
Když se zpracuje dvanáctá událost (device3), čas příjezdu (12:27) je 6 minut před časem události (12:21). Použijí se zásady pozdního přijetí. Čas události se upraví (12:22), který je nad vodoznakem (12:21), takže se žádné další úpravy neuplatní.
Druhá ilustrace 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říchodu. Odlehlé události, které přijdou dříve, vodoznak výrazně zvýší. Všimněte si, že třetí událost (id zařízení1 v čase 12:11) se v tomto scénáři nezahodí a vodoznak se zvýší na hodnotu 12:15. Čtvrtý čas události se upraví dopředu o 7 minut (12:08 až 12:15).
Na posledním obrázku se používají podstreamy (OVER the DeviceId). Sleduje se více vodoznaků, jeden na datový proud. Vzhledem k tomu, že se jejich časy upraví, je méně.
