Pokračuji v seznamování se s IoT v Azure a dnes budu chtít surová data z IoT Hubu kontinuálně přechroupávat, trochu filtrovat, trochu agregovat a hlavně posílat na dlouhodobé uložení v Azure SQL DB, Azure Cosmos DB, Azure Blob Storage a také do real-time vizualizace s Power BI. Zní to složitě? Ve skutečnosti to bylo snadné.
Proč Stream Analytics
S daty z IoT bude většinou potřeba něco dělat. Proč to ale nepodniknout rovnou na vstupu? Nebo proč to naopak nenechat až po uložení do databáze?
Možná máte senzory, které posílají teplotu v jiných jednotkách (nějaký v Celsius, jiný ve Fahrenheit), jiné škále (nějaký v milionech, jiný v tisících), jiném formátu (jeden v Avro, druhý v JSON a políčko teploty označuje temparature, třetí sicé také v JSON, ale teplotu označuje temp) nebo v jiném intervalu (nějaký každých 10 vteřin, jiný každou minutu). Potřebujete tedy data upravit a je s tím nějaká práce, má to nezanedbatelnou náročnost na zpracování.
Druhý aspekt může být nutnost reagovat v reálném čase. Vždy je skvělé se důkladně zamyslet nad uloženými daty s dvacetiletou historií a spustit komplikované algoritmy, ale někdy je důležitější mít informaci rychle i za cenu, že je to samozřejmě méně přesné. Třeba potřebujeme zabránit výbuchu v přetlakovaných trubkách nebo odmítnout podezřelou platební transakci.
Třetí věc k zamyšlení je zda surová data nejsou pro naše účely nesmyslně podrobná. Možná hledáme agregované pohledy s hodinovými trendy a analytiku postavenou nad relační strukturou, ne nutnost zvlášť zkoumat každou vteřinu dat. Nebo zařízení posíla data z víc senzorů a nás zajímají zatím jen některé. Surová data je fajn si uložit co nejlevnějším způsobem třeba do Blob storage pro případ, že se do podrobností budeme chtít někdy podívat, ale do relační databáze nám stačí třeba minutové pohledy.
Všechny tři situace myslím ukazují důležitost Stream Analytics. Funkce zpracování dat nechceme dávat přímo do systému pro příjem dat, protože bychom dramaticky ovlivnili jeho škálovatelnost. IoT Hub (stejně jako Event Hub) musí být jednoduchý a neuvěřitelně škálovatelný, být schopen přijmout cokoli a fungovat jako buffer pro další zpracování; pokud by při příjmu prováděl nějaký složitější kód, data by nestíhal přijímat, timeouty by způsobovaly ztrátu dat, rozpad komunikace se zařízeními nebo dlouhé čekací doby vedoucí k větší spotřebě zařízení. Zpracování tedy chceme oddělit od příjmu. Strategie nějakým jednoduchým způsobem data pouze dostat do databáze a teprve pak je upravovat by také nebyla nejefektivnější. Docházelo by jednak ke ztrátě schopnosti reagovat co nejblíže reálnému času (místo predikce výbuchu továrny tak jak data proudí bychom čekali na jejich uložení a pak je nějakými SELECTy zkoumali) a také bychom mohli zbytečně zatěžovat cílový systém daty, která ve skutečnosti nepotřebujeme (představte si kolik výkonu relační DB bychom zbytečně spotřebovali, pokud bychom do ní uložili surová data, nad nimi teprve udělali tabulky minutových agregací a surová data pak exportovali do Blobu).
Moje první Query a odkládání do Blob storage
Začněme tím, že si vytvoříme Azure Stream Analytics.
Základem pro škálování výkonu je počet jednotek. Velmi zajímavá je v Preview možnost použít stejnou technologii mimo cloud na IoT bráně. To souvisí se strategií Intelligent Edge, kdy Microsoft nabízí Azure Machine Learning, Azure Stream Analytics nebo Azure Functions ve formě spustitelné na takových zařízeních.
Následně si přidáme vstup. Jak už padlo půjde v mém případě o Azure IoT Hub, podporovaný je i Azure Event Hub (zajímavé pro jednosměrné scénáře, třeba sběr clickstreamu a jiných událostí z vaší webové aplikace s cílem analyzovat chování uživatele v reálném čase a udržet ho na stránce co nejdéle) nebo Blob Storage.
Můj IoT DevKit z minulého dílu seriálu je připojen a posílá data. Abychom si mohli Query odladit, můžeme si v GUI nahrát vzorek dat nebo ještě lépe si ho zachytit z právě přicházejících dat.
Jazyk Stream Analytics je velmi podobný SQL. To je z mého pohledu perfektní scénář. K proudu dat se tak syntakticky mohu chovat jako k databázi včetně věcí jako WHERE, GROUP BY nebo JOIN. Nemusím se tedy učit příliš mnoho nové terminologie. Začnu tak, že si vezmu všechno ze vstupu a pošlu na výstup. Kliknu na Test, abych viděl co to udělá.
Výborně. Co kdybych pro zjednodušení chtěl ve svém Query pracovat pouze s vlhkostí?
Pojďme si teď tenhle výstup nechat ukládat do Blob storage. Přidáme tedy nový Output.
Pro mne bude nejpříjemnější vytvářet ve storage JSON soubor, ale můžete zvolit i CSV nebo Avro.
Output mám, upravím tedy své Query. Posílat budu vlhkost a teplotu a teď už do blobu.
Máme nastaveno, pojďme Stream Analytics zapnout.
Po chvilce se podívám na svou Azure Blob Storage.
A nacházím tam svoje data.
A je to. Úžasně jednoduché.
Přechroupání do Azure Cosmos DB
Cosmos DB mám strašně rád. Je to NoSQL databáze a jedním z modelů je document store, tedy to co ukládáte jsou JSON struktury a přistupovat k nim můžete buď přes SQL jazyk (Document DB API) nebo s využitím Mongo DB API. Protože databáze je velmi výkonná a skvěle škáluje, perfektně se hodí na data z IoT. Narozdíl od relačního světa se do ní nebojím nahnat surová data jak jsou a hotovo. Chtěl jsem tedy využít Stream Analytics také na přetažení dat tak jak jsou do Cosmos DB.
Moje Cosmos DB je připravena, takže si v Stream Analytics založím další Output a specifikuji svoji DB a kolekci.
Udělám si jednoduché Query (pozor, aby to šlo, musíte Stream Analytics na chvíli zastavit - ale to nevadí, dokáže navázat tam, kde přestalo) typu SELECT všechno do Cosmos DB. Všimněte si, že v jednom Stream Analytics můžete mít jako já víc dotazů, víc výstupů.
Stream Analytics jsem zapnul a za malou chvilku vidím ve své Cosmos DB telemetrická data ze senzorů.
Prostředky Document DB API si pak snadno můžu zobrazit jen čas a vlhkost.
Případně se zeptat na průměrnou vlhkost za všechna měření.
Stream Analytics můžeme tedy použít jako jednoduchý prostředek přesunu dat z IoT Hub či Event Hub do Cosmos DB. Pokud nepotřebujete dělat rozhodnutí vyloženě v reálném čase a chcete se soustředit na sílu Cosmos DB, dobrá volba. Cosmos DB dokáže i věci jako Change Feed a můžete tak informovat třeba serverless kód o tom, že jsou v Cosmos DB nová data. Něco podobného umí i Stream Analytics, takže je na vás, co vám bude dávat největší smysl. Pokud vám nejde o vyloženě real time rozhodnutí, nesnášíte jakýkoli SQL a milujete Mongo API, můžete jednoduše dát všechno na hrb Cosmos DB.
Příprava agregovaných dat pro relační svět Azure SQL DB
Pro účely zpracování v relační databázi mi bude stačit vlhkost jako průměr za minutu, nepotřebuji detaily každé dvě vteřiny. Nejprve jsem si vytvořil Azure SQL Database. Přímo v GUI portálu lze posílat T-SQL dotazy (ale stejně tak můžete využít SQL Management Studio pro Windows, SQL plug-in pro Visual Studio Code pro Windows, Linux nebo Mac nebo SqlCmd jako příkazovou řádku), takže jsem si vytvořil následující tabulku:
Přidám ji jako další output do Stream Analytics.
V mém query teď vytvoříme agregaci, tedy například průměr. Pro agregační funkce ale, jak znáte z relačních systémů, musíme mít nějaké GROUP BY. Protože chceme průměr za minutu, potřebujeme seskupit podle časových oken dlouhých jednu minutu. Pro některé situace budeme potřebovat plovoucí okno (to příště - je vhodné třeba pro detekci anomálií), pro náš případ použiji TumblingWindow, tedy seskupení po celých minutách.
Zapněme Stream Analytics a podíváme se na data v SQL. Díky nové funkci portálu tak můžeme učinit přímo z GUI Azure.
Příprava dat na vizualizaci s Power BI
Poslední co si chci vyzkoušet je příprava dat přímo do Power BI pro jejich vizualizaci. Power BI se dá samozřejmě napojit na databázi, ale pro jednoduché zobrazení v reálném čase to uděláme napřímo.
Nejprve tedy přidáme Power BI jako další Output do Stream Analytics.
Musíme Stream Analytics autorizovat, tedy přihlásit se do Power BI. Následně si vyberu workspace, jméno pro nový datový zdroj a tabulku v něm.
Použiji skoro stejné query jako v předchozím případě, jen budu chtít data agregovat do 15 vteřinových intervalů místo minuty.
Naloguji se do Power BI a zkontroluji, že vidím novou datovou sadu. Následně vytvořím nový dashboard.
Jako typ použiji zobrazení proudu dat v reálném čase.
Vyberu svůj dataset.
Na hlavní osu dám čas, na druhou vlhkost a necháme si ukázat posledních 10 minut.
Máme hotovo, uvidíme graf v reálném čase.
Roztlačit něco základního a jednoduchého v Azure je snadné, protože vezmete kostičky a propojíte je dohromady. Během pár hodin jsem měl rozjeto přechroupávání dat do Blob storage, do Cosmos DB, do Azure SQL DB i do Power BI. Pokud chcete do hloubky, prozkoumejte query jazyk Stream Analytics blíže - je velmi mocný a dostanete se o hodně dál, než v dnešní ukázce.
Přechroupávání dat mám vyzkoušeno, příště ale u Stream Analytics ještě zůstanu. Chci se podívat na reakce nad daty v reálném čase ať už to bude překročení nějakých hodnot či detekce anomálie s Machine Learningem a spouštět na základě toho akce s frontováním, Azure Functions a Azure Logic Apps. Přijďte si přečíst.