Koncepty kontrolního bodu a přehrání v úlohách Azure Stream Analytics
Tento článek popisuje koncepty interních kontrolních bodů a přehrání ve službě Azure Stream Analytics a jejich dopad na obnovení úlohy. Při každém spuštění úlohy Stream Analytics se interně uchovávají informace o stavu. Informace o stavu se pravidelně ukládají do kontrolního bodu. V některých scénářích se informace o kontrolních bodech používají k obnovení úlohy, pokud dojde k selhání úlohy nebo upgradu. Za jiných okolností nelze kontrolní bod použít k obnovení a je nutné ho znovu přehrát.
Logika stavového dotazu v dočasných elementech
Jednou z jedinečných schopností úlohy Azure Stream Analytics je provádět stavové zpracování, jako jsou agregace s okny, časová spojení a dočasné analytické funkce. Každý z těchto operátorů uchovává informace o stavu při spuštění úlohy. Maximální velikost okna pro tyto prvky dotazu je sedm dní.
Koncept dočasného okna se zobrazuje v několika prvech dotazu Stream Analytics:
Agregace s okny (GROUP BY pro přeskakující, skákající a posuvná okna)
Dočasná spojení (JOIN s datediffem)
Dočasné analytické funkce (ISFIRST, LAST a LAG s LIMIT DURATION)
Obnovení úlohy ze selhání uzlu, včetně upgradu operačního systému
Při každém spuštění úlohy Stream Analytics se interně škáluje na více instancí, aby fungovala napříč několika pracovními uzly. Stav každého pracovního uzlu se každých několik minut zařadí do kontrolního bodu, což pomáhá systému obnovit, pokud dojde k selhání.
V některých případech může daný pracovní uzel selhat nebo může dojít k upgradu operačního systému pro tento pracovní uzel. Aby se služba Stream Analytics obnovila automaticky, získá nový uzel, který je v pořádku, a předchozí stav pracovního uzlu se obnoví z nejnovějšího dostupného kontrolního bodu. K obnovení stavu od okamžiku vytvoření kontrolního bodu je nutné k obnovení práce provést malou část přehrání. Obvykle je prodleva obnovení pouze několik minut. Pokud je pro úlohu vybrán dostatečný počet jednotek streamování, mělo by se přehrávání rychle dokončit.
U plně paralelního dotazu je doba potřebná k dohánění po selhání pracovního uzlu úměrná:
[vstupní rychlost událostí] x [délka mezery] / [počet oddílů zpracování]
Pokud někdy zaznamenáte významné zpoždění zpracování kvůli selhání uzlu a upgradu operačního systému, zvažte možnost vytvoření plně paralelního dotazu a škálováním úlohy přidělte více jednotek streamování. Další informace najdete v tématu Škálování úlohy Azure Stream Analytics za účelem zvýšení propustnosti.
Aktuální Stream Analytics nezobrazuje sestavu, když probíhá tento druh procesu obnovení.
Obnovení úlohy po upgradu služby
Microsoft příležitostně upgraduje binární soubory, ve kterých se spouští úlohy Stream Analytics ve službě Azure. V těchto časech se spuštěné úlohy uživatelů upgradují na novější verzi a úloha se automaticky restartuje.
Azure Stream Analytics používá k obnovení dat z posledního stavu kontrolního bodu kontrolní body tam, kde je to možné. Ve scénářích, kdy není možné použít interní kontrolní body, se stav dotazu streamování zcela obnoví pomocí techniky přehrání. Aby úlohy Stream Analytics mohly přehrávat úplně stejný vstup jako předtím, je důležité nastavit zásady uchovávání informací pro zdrojová data alespoň na velikost oken v dotazu. Pokud to neuděláte, může to mít za následek nesprávné nebo částečné výsledky během upgradu služby, protože zdrojová data se nemusí uchovávat dostatečně daleko, aby zahrnovala celou velikost okna.
Obecně platí, že množství potřebného přehrání je úměrné velikosti okna vynásobené průměrnou frekvencí událostí. Například pro úlohu s frekvencí vstupu 1000 událostí za sekundu se velikost okna větší než jedna hodina považuje za velkou velikost přehrávání. K inicializaci stavu může být potřeba znovu zpracovat až jednu hodinu dat, aby se mohly zobrazit úplné a správné výsledky, což může způsobit zpoždění výstupu (žádný výstup) po určitou delší dobu. Dotazy bez oken nebo jiných dočasných operátorů, jako jsou JOIN nebo LAG, by měly nulový počet opakování.
Odhad doby dohrání přehrání
Pokud chcete odhadnout délku zpoždění způsobeného upgradem služby, můžete postupovat podle tohoto postupu:
Načtěte vstupní službu Event Hubs s dostatečným objemem dat, aby pokryla největší velikost okna v dotazu a očekávanou rychlostí událostí. Časové razítko událostí by mělo být v průběhu tohoto časového období blízko času hodin na zdi, jako by se jedná o živý vstupní kanál. Pokud máte například v dotazu 3denní interval, odesílejte události do služby Event Hubs po dobu tří dnů a pokračujte v odesílání událostí.
Spusťte úlohu tak, že jako čas spuštění použijete Nyní .
Změřte čas mezi časem spuštění a vygenerovaným prvním výstupem. Doba je přibližná, o kolik zpoždění by úloha při upgradu služby nastala.
Pokud je zpoždění příliš dlouhé, zkuste úlohu rozdělit na oddíly a zvýšit počet jednotek SU, aby se zatížení rozprostřelo do více uzlů. Případně zvažte zmenšení velikosti oken v dotazu a provedení další agregace nebo jiného stavového zpracování výstupu vytvořeného úlohou Stream Analytics v podřízené jímce (například pomocí Azure SQL Database).
V případě obecných problémů se stabilitou služeb během upgradu důležitých úloh zvažte spuštění duplicitních úloh ve spárovaných oblastech Azure. Další informace najdete v tématu Záruka spolehlivosti úlohy Stream Analytics během aktualizací služby.
Obnovení úlohy ze zastavení a spuštění iniciovaného uživatelem
Pokud chcete upravit syntaxi dotazu u úlohy streamování nebo upravit vstupy a výstupy, je potřeba úlohu zastavit, aby se provedly změny a upgradovali návrh úlohy. Když uživatel v takových scénářích zastaví úlohu streamování a znovu ji spustí, je scénář obnovení podobný upgradu služby.
Data kontrolního bodu nelze použít pro restartování úlohy iniciované uživatelem. Pokud chcete odhadnout zpoždění výstupu během takového restartování, použijte stejný postup jako v předchozí části a použijte podobné zmírnění, pokud je zpoždění příliš dlouhé.
Další kroky
Další informace o spolehlivosti a škálovatelnosti najdete v těchto článcích: