Vzory řešení služby Azure Stream Analytics
Stejně jako mnoho dalších služeb v Azure se Služba Stream Analytics nejlépe používá s dalšími službami k vytvoření většího uceleného řešení. Tento článek popisuje jednoduchá řešení Azure Stream Analytics a různé vzory architektury. Na těchto vzorech můžete stavět a vyvíjet složitější řešení. Vzory popsané v tomto článku lze použít v nejrůznějších scénářích. Příklady vzorů specifických pro scénáře jsou k dispozici v architekturách řešení Azure.
Vytvoření úlohy Stream Analytics pro výkon řídicího panelu v reálném čase
Pomocí Azure Stream Analytics můžete rychle vytvářet řídicí panely a upozornění v reálném čase. Jednoduché řešení ingestuje události ze služby Event Hubs nebo IoT Hub a podává řídicí panel Power BI streamovací sadou dat. Další informace najdete v podrobném kurzu Analýza podvodných dat volání pomocí Stream Analytics a vizualizace výsledků na řídicím panelu Power BI.
Toto řešení můžete vytvořit během několika minut pomocí webu Azure Portal. Nemusíte provádět rozsáhlé kódování. Místo toho můžete k vyjádření obchodní logiky použít jazyk SQL.
Tento model řešení nabízí nejnižší latenci ze zdroje událostí do řídicího panelu Power BI v prohlížeči. Azure Stream Analytics je jediná služba Azure s touto integrovanou funkcí.
Použití SQL pro řídicí panel
Řídicí panel Power BI nabízí nízkou latenci, ale nemůžete ho použít k vytváření plnohodnotných sestav Power BI. Běžným vzorem generování sestav je nejprve výstup dat do služby SQL Database. Potom použijte konektor SQL Power BI k dotazování SQL na nejnovější data.
Když používáte SLUŽBU SQL Database, získáte větší flexibilitu, ale na úkor mírně vyšší latence. Toto řešení je optimální pro úlohy s požadavky na latenci větší než jednu sekundu. Při použití této metody můžete maximalizovat možnosti Power BI k dalšímu řezu a dice dat pro sestavy a mnohem více možností vizualizace. Získáte také flexibilitu při používání jiných řešení řídicího panelu, jako je Tableau.
SQL není úložiště dat s vysokou propustností. Maximální propustnost služby SQL Database ze služby Azure Stream Analytics je v současné době přibližně 24 MB/s. Pokud zdroje událostí ve vašem řešení vytvářejí data vyšší rychlostí, musíte použít logiku zpracování ve službě Stream Analytics, abyste snížili výstupní rychlost do SQL. Můžete použít techniky, jako je filtrování, agregace s okny, porovnávání vzorů s časovými spojeními a analytické funkce. Výstupní rychlost pro SQL můžete optimalizovat pomocí technik popsaných ve výstupu Azure Stream Analytics do služby Azure SQL Database.
Začlenění přehledů v reálném čase do aplikace pomocí zasílání zpráv událostí
Druhým nejoblíbenějším využitím Stream Analytics je generování výstrah v reálném čase. V tomto vzoru řešení je možné obchodní logiku ve službě Stream Analytics použít k detekci dočasných a prostorových vzorů nebo anomálií a následnému generování výstrah. Na rozdíl od řešení řídicího panelu, ve kterém Stream Analytics používá Power BI jako upřednostňovaný koncový bod, ale můžete použít jiné zprostředkující datové jímky. Mezi tyto jímky patří Event Hubs, Service Bus a Azure Functions. Jako tvůrce aplikací musíte rozhodnout, která jímka dat bude pro váš scénář nejvhodnější.
K vygenerování výstrah ve stávajícím obchodním pracovním postupu je potřeba implementovat logiku příjemce podřízených událostí. Vzhledem k tomu, že ve službě Azure Functions můžete implementovat vlastní logiku, je služba Azure Functions nejrychlejším způsobem, jak tuto integraci provést. Kurz použití funkce Azure Functions jako výstupu úlohy Stream Analytics najdete v tématu Spouštění funkcí Azure Functions z úloh Azure Stream Analytics. Azure Functions také podporuje různé typy oznámení, včetně textu a e-mailu. Logic Apps můžete také použít pro takovou integraci se službou Event Hubs mezi Stream Analytics a Logic Apps.
Služba Azure Event Hubs na druhé straně nabízí nejflexibilnější integrační bod. Mnoho dalších služeb, jako je Azure Data Explorer a Time Series, Přehledy můžou využívat události ze služby Event Hubs. Služby je možné připojit přímo k jímce služby Event Hubs z Azure Stream Analytics a dokončit řešení. Služba Event Hubs je také zprostředkovatel zasílání zpráv s nejvyšší propustností dostupný v Azure pro takové scénáře integrace.
Dynamické aplikace a weby
Pomocí Azure Stream Analytics a služby Azure SignalR můžete vytvářet vlastní vizualizace v reálném čase, jako je řídicí panel nebo vizualizace map. Když používáte SignalR, můžou být webové klienty aktualizovány a zobrazovat dynamický obsah v reálném čase.
Začlenění přehledů v reálném čase do aplikace prostřednictvím úložišť dat
Většina webových služeb a webových aplikací dnes používá vzor požadavků a odpovědí k poskytování prezentační vrstvy. Model požadavků a odpovědí je jednoduchý k sestavení a dá se snadno škálovat s nízkou dobou odezvy pomocí bezstavového front-endu a škálovatelných úložišť, jako je Azure Cosmos DB.
Velký objem dat často vytváří kritické body výkonu v systému založeném na CRUD. Model řešení event sourcing se používá k řešení kritických bodů výkonu. Dočasné vzory a přehledy jsou také obtížné a neefektivní pro extrakci z tradičního úložiště dat. Moderní aplikace řízené velkým objemem dat často přijímají architekturu založenou na toku dat. Azure Stream Analytics jako výpočetní modul pro data v pohybu je v této architektuře linchpin.
V tomto modelu řešení se události zpracovávají a agregují do úložišť dat službou Azure Stream Analytics. Aplikační vrstva komunikuje s úložišti dat pomocí tradičního vzoru požadavků a odpovědí. Vzhledem k tomu, že Stream Analytics dokáže zpracovávat velký počet událostí v reálném čase, je aplikace vysoce škálovatelná, aniž by bylo nutné hromadně navýšit vrstvu úložiště dat. Vrstva úložiště dat je v podstatě materializované zobrazení v systému. Výstup Azure Stream Analytics do služby Azure Cosmos DB popisuje, jak se služba Azure Cosmos DB používá jako výstup Stream Analytics.
V reálných aplikacích, kde je logika zpracování složitá a je potřeba nezávisle upgradovat určité části logiky, lze několik úloh Stream Analytics sestavit společně se službou Event Hubs jako zprostředkující zprostředkovatel událostí.
Tento model zlepšuje odolnost a možnosti správy systému. Přestože ale Stream Analytics zaručuje přesně jedno zpracování, existuje malá šance, že se duplicitní události dostanou do zprostředkující služby Event Hubs. Je důležité, aby podřízená úloha Stream Analytics odstrašovala události pomocí klíčů logiky v okně zpětného vyhledávání. Další informace o doručení událostí naleznete v tématu Záruky doručení událostí .
Použití referenčních dat pro přizpůsobení aplikace
Funkce referenčních dat Azure Stream Analytics je navržená speciálně pro přizpůsobení koncových uživatelů, jako jsou prahová hodnota pro upozorňování, pravidla zpracování a geografické zóny. Aplikační vrstva může přijímat změny parametrů a ukládat je do služby SQL Database. Úloha Stream Analytics se pravidelně dotazuje na změny z databáze a zpřístupňuje parametry přizpůsobení prostřednictvím připojení referenčních dat. Další informace o tom, jak používat referenční data pro přizpůsobení aplikace, naleznete v tématu Referenční data SQL a připojení referenčních dat.
Tento vzor lze také použít k implementaci stroje pravidel, kde jsou prahové hodnoty pravidel definovány z referenčních dat. Další informace opravidlech
Přidání Učení počítače do přehledů v reálném čase
Integrovaný model detekce anomálií v Azure Stream Analytics představuje pohodlný způsob, jak do aplikace v reálném čase zavést strojové Učení. Širší škálu potřeb Učení počítačů najdete v tématu Integrace Azure Stream Analytics se službou Azure Machine Učení.
Pokročilí uživatelé, kteří chtějí začlenit online trénování a bodování do stejného kanálu Stream Analytics, najdete v tomto příkladu s lineární regresí.
Datové sklady v reálném čase
Dalším běžným vzorem je datové sklady v reálném čase, označované také jako streamovaný datový sklad. Kromě událostí přicházejících do event Hubs a IoT Hubu z vaší aplikace je možné použít Azure Stream Analytics běžící na IoT Edge k plnění požadavků na čištění dat, redukci dat a ukládání dat a předávání. Stream Analytics běžící na IoT Edge může řádně zvládnout omezení šířky pásma a problémy s připojením v systému. Stream Analytics může při zápisu do Azure Synapse Analytics podporovat propustnost až 200 MB/s.
Archivace dat v reálném čase pro analýzy
Většina aktivit datových věd a analýz stále probíhá offline. Data v Azure Stream Analytics můžete archivovat prostřednictvím výstupních formátů Azure Data Lake Store Gen2 a Parquet. Tato funkce odebere třecí plochy pro přímé podávání dat do Azure Data Lake Analytics, Azure Databricks a Azure HDInsight. Azure Stream Analytics se v tomto řešení používá jako modul ETL (Extract-Transform-Load) téměř v reálném čase. Archivovaná data v Data Lake můžete prozkoumat pomocí různých výpočetních modulů.
Použitíreferenčníchch
Rozšiřování dat je často požadavkem pro moduly ETL. Azure Stream Analytics podporuje rozšiřování dat s referenčními daty z SQL Database i azure Blob Storage. Rozšiřování dat je možné provést pro cíl dat v Azure Data Lake i Azure Synapse Analytics.
Zprovoznění přehledů z archivovaných dat
Pokud zkombinujete model offline analýz se vzorem aplikace téměř v reálném čase, můžete vytvořit smyčku zpětné vazby. Smyčka zpětné vazby umožňuje aplikaci automaticky upravit změny vzorů v datech. Tato smyčka zpětné vazby může být stejně jednoduchá jako změna prahové hodnoty pro upozorňování nebo stejně složitá jako opětovné natrénování modelů Učení stroje. Stejnou architekturu řešení je možné použít pro úlohy ASA běžící v cloudu i ioT Edge.
Monitorování úloh ASA
Úlohu Azure Stream Analytics je možné spustit 24/7 pro průběžné zpracování příchozích událostí v reálném čase. Její záruka dostupnosti je zásadní pro stav celkové aplikace. I když je Stream Analytics jedinou službou streamovací analýzy v oboru, která nabízí záruku dostupnosti 99,9 %, stále máte určitou úroveň výpadku. V průběhu let služba Stream Analytics zavedla metriky, protokoly a stavy úloh, které odrážejí stav úloh. Všechny se zobrazí prostřednictvím služby Azure Monitor a je možné je dále exportovat do OMS. Další informace najdete v tématu Monitorování úlohy Stream Analytics pomocí webu Azure Portal.
Monitorování je potřeba provést dvěma klíčovými věcmi:
-
Nejprve je potřeba se ujistit, že je úloha spuštěná. Bez úlohy ve spuštěném stavu se negenerují žádné nové metriky ani protokoly. Úlohy se můžou změnit na stav selhání z různých důvodů, včetně vysoké úrovně využití SU (to znamená nedostatku prostředků).
-
Tato metrika odráží, jak daleko je kanál zpracování ve nástěnné době (v sekundách). Některé zpoždění jsou přičítány k vlastní logice zpracování. Díky tomu je monitorování rostoucího trendu mnohem důležitější než monitorování absolutní hodnoty. Zpoždění stabilního stavu by mělo být řešeno návrhem aplikace, nikoli monitorováním nebo upozorněními.
Při selhání jsou protokoly aktivit a diagnostické protokoly nejvhodnějším místem, kde začít hledat chyby.
Vytváření odolných a důležitých aplikací
Bez ohledu na záruku SMLOUVY SLA služby Azure Stream Analytics a způsobu, jakým pečlivě spouštíte kompletní aplikaci, dochází k výpadkům. Pokud je vaše aplikace důležitá, musíte být připraveni na výpadky, abyste mohli řádně obnovit.
Pro upozorňování aplikací je nejdůležitější zjistit další výstrahu. Při obnovování můžete úlohu restartovat z aktuálního času a ignorovat předchozí výstrahy. Sémantika času spuštění úlohy je první čas výstupu, nikoli prvním vstupem. Vstup se znovu vrátí zpět, aby se zajistilo, že první výstup v zadaném čase bude dokončený a správný. V důsledku toho nebudete dostávat částečné agregace a neočekávaně aktivovat upozornění.
Můžete také zvolit spuštění výstupu z nějakého časového limitu v minulosti. Zásady uchovávání informací služby Event Hubs i IoT Hub obsahují přiměřené množství dat, která umožňují zpracování z minulosti. Kompromisem je, jak rychle můžete dohnat aktuální čas a začít generovat včasné nové výstrahy. Data rychle ztratí svou hodnotu v průběhu času, takže je důležité rychle dohnat aktuální čas. Existují dva způsoby, jak rychle dohnat:
- Zřizování dalších prostředků (SU) při zachytávání
- Restartujte se z aktuálního času.
Restartování z aktuálního času je jednoduché, protože kompromis při zpracování opouští mezeru. Restartování tímto způsobem může být v pořádku pro scénáře upozorňování, ale může být problematické pro scénáře řídicího panelu a je to neskladná položka pro scénáře archivace a datových skladů.
Zřizování dalších prostředků může proces urychlit, ale dopad nárůstu rychlosti zpracování je složitý.
Otestujte, že je vaše úloha škálovatelná na větší počet jednotek SU. Ne všechny dotazy jsou škálovatelné. Musíte se ujistit, že je dotaz paralelizovaný.
Ujistěte se, že v upstreamové službě Event Hubs nebo IoT Hubu existuje dostatek oddílů, které můžete přidat další jednotky propustnosti (TU) pro škálování vstupní propustnosti. Mějte na paměti, že každý počet členů tu služby Event Hubs je maximálně ve výstupní rychlosti 2 MB/s.
Ujistěte se, že jste ve výstupních jímkách (tj. VE službě SQL Database, Azure Cosmos DB) zřídili dostatek prostředků, takže nezpůsobí omezování nárůstu ve výstupu, což může někdy způsobit, že se systém zamkne.
Nejdůležitější je předvídat změnu rychlosti zpracování, otestovat tyto scénáře před přechodem do produkčního prostředí a připravit se na správné škálování zpracování během doby obnovení selhání.
V extrémním scénáři, kdy jsou všechny příchozí události zpožděné, je možné, že se všechny zpožděné události zahodí, pokud jste u své úlohy použili pozdní příchozí okno. Vyřazení událostí může vypadat jako záhadné chování na začátku; Vzhledem k tomu, že Stream Analytics je modul pro zpracování v reálném čase, očekává, že příchozí události budou blízko hodinového času. Musí vypustit události, které porušují tato omezení.
Architektury lambda nebo proces obnovení
Předchozí vzor archivace dat se naštěstí dá použít ke zpracování těchto pozdních událostí elegantně. Myšlenka spočívá v tom, že archivační úloha zpracovává příchozí události v čase příjezdu a archivuje události do správného časového intervalu ve službě Azure Blob nebo Azure Data Lake Store s časem události. Nezáleží na tom, jak pozdě událost přijde, nikdy se neodhodí. Vždy se dostane do správného časového intervalu. Během obnovení je možné znovu zpracovat archivované události a obnovit výsledky do zvoleného úložiště. Podobá se tomu, jak se implementují vzory lambda.
Proces zálohování musí být proveden pomocí offline systému dávkového zpracování, který má pravděpodobně jiný programovací model než Azure Stream Analytics. To znamená, že musíte znovu vytvořit celou logiku zpracování.
Pro obnovení je stále důležité alespoň dočasně zřídit pro výstupní jímky více prostředků, aby zvládly vyšší propustnost než potřeby zpracování stabilního stavu.
| Scénáře | Restartovat pouze odteď | Restartování z posledního zastaveného času | Restartovat odteď + backfill s archivovanými událostmi |
|---|---|---|---|
| Řídicí panely | Vytvoří mezeru. | OK pro krátký výpadek | Použití pro dlouhý výpadek |
| Upozorňování | Přijatelné | OK pro krátký výpadek | Není nutné |
| Aplikace Event Sourcing | Přijatelné | OK pro krátký výpadek | Použití pro dlouhý výpadek |
| Datové sklady | Ztráta dat | Přijatelné | Není nutné |
| Offline analýzy | Ztráta dat | Přijatelné | Není nutné |
Spojení všech součástí dohromady
Není těžké si představit, že všechny vzory řešení uvedené dříve je možné kombinovat v komplexním komplexním komplexním systému. Kombinovaný systém může zahrnovat řídicí panely, upozorňování, aplikaci event sourcing, datové sklady a možnosti offline analýz.
Klíčem je navrhnout systém v kompozibilních vzorech, takže je možné každý subsystém sestavit, otestovat, upgradovat a obnovit nezávisle.
Další kroky
Nyní jste viděli různé vzory řešení pomocí Azure Stream Analytics. V dalším kroku se můžete do tématu ponořit hlouběji a vytvořit si svoji první úlohu Stream Analytics: