Azure Stream Analytics-lösningsmönster
Precis som många andra tjänster i Azure används Stream Analytics bäst med andra tjänster för att skapa en större lösning från slutpunkt till slutpunkt. I den här artikeln beskrivs enkla Azure Stream Analytics-lösningar och olika arkitekturmönster. Du kan bygga vidare på dessa mönster för att utveckla mer komplexa lösningar. De mönster som beskrivs i den här artikeln kan användas i en mängd olika scenarier. Exempel på scenariospecifika mönster finns i Azure-lösningsarkitekturer.
Skapa ett Stream Analytics-jobb för att skapa instrumentpaneler i realtid
Med Azure Stream Analytics kan du snabbt skapa instrumentpaneler och aviseringar i realtid. En enkel lösning matar in händelser från Event Hubs eller IoT Hub och matar in Power BI-instrumentpanelen med en strömmande datauppsättning. Mer information finns i den detaljerade självstudien Analysera bedrägliga samtalsdata med Stream Analytics och visualisera resultat på Power BI-instrumentpanelen.
Du kan skapa den här lösningen på bara några minuter med hjälp av Azure-portalen. Du behöver inte koda i stor utsträckning. I stället kan du använda SQL-språk för att uttrycka affärslogik.
Det här lösningsmönstret erbjuder den lägsta svarstiden från händelsekällan till Power BI-instrumentpanelen i en webbläsare. Azure Stream Analytics är den enda Azure-tjänsten med den här inbyggda funktionen.
Använda SQL för instrumentpanel
Power BI-instrumentpanelen har låg svarstid, men du kan inte använda den för att skapa fullständiga Power BI-rapporter. Ett vanligt rapporteringsmönster är att mata ut dina data till SQL Database först. Använd sedan Power BI:s SQL-anslutningsprogram för att fråga SQL om de senaste data.
När du använder SQL Database ger det dig mer flexibilitet men på bekostnad av en något högre svarstid. Den här lösningen är optimal för jobb med svarstidskrav som är större än en sekund. När du använder den här metoden kan du maximera Power BI-funktionerna för att ytterligare dela ut och tärna data för rapporter och mycket fler visualiseringsalternativ. Du får också flexibiliteten att använda andra instrumentpanelslösningar, till exempel Tableau.
SQL är inte ett datalager med högt dataflöde. Det maximala dataflödet till SQL Database från Azure Stream Analytics är för närvarande cirka 24 MB/s. Om händelsekällorna i din lösning genererar data med en högre hastighet måste du använda bearbetningslogik i Stream Analytics för att minska utdatahastigheten till SQL. Du kan använda tekniker som filtrering, fönsteraggregeringar, mönstermatchning med temporala kopplingar och analysfunktioner. Du kan optimera utdatahastigheten till SQL med hjälp av tekniker som beskrivs i Azure Stream Analytics-utdata till Azure SQL Database.
Införliva insikter i realtid i ditt program med händelsemeddelanden
Den näst populäraste användningen av Stream Analytics är att generera realtidsaviseringar. I det här lösningsmönstret kan affärslogik i Stream Analytics användas för att identifiera temporala och rumsliga mönster eller avvikelser och sedan generera aviseringssignaler. Men till skillnad från instrumentpanelslösningen där Stream Analytics använder Power BI som en önskad slutpunkt kan du använda andra mellanliggande datamottagare. Dessa mottagare är Event Hubs, Service Bus och Azure Functions. Som programbyggare måste du bestämma vilken datamottagare som fungerar bäst för ditt scenario.
Du måste implementera konsumentlogik för underordnade händelser för att generera aviseringar i ditt befintliga affärsarbetsflöde. Eftersom du kan implementera anpassad logik i Azure Functions är Azure Functions det snabbaste sättet att utföra den här integreringen. En självstudiekurs om hur du använder Azure Function som utdata för ett Stream Analytics-jobb finns i Köra Azure Functions från Azure Stream Analytics-jobb. Azure Functions har också stöd för olika typer av meddelanden, inklusive text och e-post. Du kan också använda Logic Apps för sådan integrering med Event Hubs mellan Stream Analytics och Logic Apps.
Azure Event Hubs-tjänsten erbjuder däremot den mest flexibla integrationspunkten. Många andra tjänster, till exempel Azure Data Explorer och Time Series Insights, kan använda händelser från Event Hubs. Tjänster kan anslutas direkt till Event Hubs-mottagaren från Azure Stream Analytics för att slutföra lösningen. Event Hubs är också den högsta meddelandekö för dataflöde som är tillgänglig i Azure för sådana integreringsscenarier.
Dynamiska program och webbplatser
Du kan skapa anpassade realtidsvisualiseringar, till exempel instrumentpanel eller kartvisualisering, med hjälp av Azure Stream Analytics och Azure SignalR Service. När du använder SignalR kan webbklienter uppdateras och visa dynamiskt innehåll i realtid.
Införliva insikter i realtid i ditt program via datalager
De flesta webbtjänster och webbprogram använder idag ett mönster för begäran/svar för att hantera presentationsskiktet. Mönstret för begäran/svar är enkelt att skapa och kan enkelt skalas med låg svarstid med hjälp av en tillståndslös klientdel och skalbara butiker som Azure Cosmos DB.
Hög datavolym skapar ofta flaskhalsar i prestanda i ett CRUD-baserat system. Lösningsmönstret för händelsekällor används för att hantera prestandaflaskhalsarna. Tidsmönster och insikter är också svåra och ineffektiva att extrahera från ett traditionellt datalager. Moderna datadrivna program med stora volymer använder ofta en dataflödesbaserad arkitektur. Azure Stream Analytics som beräkningsmotor för data i rörelse är en grundbult i den arkitekturen.
I det här lösningsmönstret bearbetas och aggregeras händelser till datalager av Azure Stream Analytics. Programlagret interagerar med datalager med det traditionella mönstret för begäran/svar. På grund av Stream Analytics förmåga att bearbeta ett stort antal händelser i realtid är programmet mycket skalbart utan att behöva massindela datalagerlagret. Datalagringslagret är i princip en materialiserad vy i systemet. Azure Stream Analytics-utdata till Azure Cosmos DB beskriver hur Azure Cosmos DB används som Stream Analytics-utdata.
I verkliga program där bearbetningslogik är komplext och det finns behov av att uppgradera vissa delar av logiken oberoende av varandra, kan flera Stream Analytics-jobb bestå tillsammans med Event Hubs som förmedlande händelsekoordinator.
Det här mönstret förbättrar systemets återhämtning och hanterbarhet. Men även om Stream Analytics garanterar exakt en gång bearbetning finns det en liten chans att duplicerade händelser hamnar i mellanliggande Event Hubs. Det är viktigt för det nedströms Stream Analytics-jobbet att dedupliceringshändelser med hjälp av logiknycklar i ett återblicksfönster. Mer information om händelseleverans finns i Referens för händelseleveransgarantier .
Använda referensdata för programanpassning
Referensdatafunktionen i Azure Stream Analytics är särskilt utformad för slutanvändaranpassning som tröskelvärde för aviseringar, bearbetningsregler och geofences. Programlagret kan acceptera parameterändringar och lagra dem i SQL Database. Stream Analytics-jobbet frågar regelbundet efter ändringar från databasen och gör anpassningsparametrarna tillgängliga via en referensdataanslutning. Mer information om hur du använder referensdata för programanpassning finns i SQL-referensdata och referensdataanslutning.
Det här mönstret kan också användas för att implementera en regelmotor där tröskelvärdena för reglerna definieras från referensdata. Mer information om regler finns i Bearbeta konfigurerbara tröskelvärdesbaserade regler i Azure Stream Analytics.
Lägga till Machine Learning i dina insikter i realtid
Azure Stream Analytics inbyggda modell för avvikelseidentifiering är ett bekvämt sätt att introducera Machine Learning i ditt realtidsprogram. Ett bredare utbud av Maskininlärningsbehov finns i Azure Stream Analytics integreras med Azure Machine Learnings bedömningstjänst.
Avancerade användare som vill införliva onlineträning och poängsättning i samma Stream Analytics-pipeline finns i det här exemplet på hur du gör det med linjär regression.
Datalagerhantering i realtid
Ett annat vanligt mönster är datalagerhantering i realtid, även kallat strömmande informationslager. Förutom händelser som anländer till Event Hubs och IoT Hub från ditt program kan Azure Stream Analytics som körs på IoT Edge användas för att uppfylla datarensning, dataminskning och datalager och framåtriktade behov. Stream Analytics som körs på IoT Edge kan hantera bandbreddsbegränsningar och anslutningsproblem i systemet på ett smidigt sätt. Stream Analytics har stöd för dataflödeshastigheter på upp till 200 MB/s när du skriver till Azure Synapse Analytics.
Arkivera realtidsdata för analys
De flesta datavetenskaps- och analysaktiviteter sker fortfarande offline. Du kan arkivera data i Azure Stream Analytics via Azure Data Lake Store Gen2-utdata och Parquet-utdataformat. Den här funktionen tar bort friktionen för att mata in data direkt i Azure Data Lake Analytics, Azure Databricks och Azure HDInsight. Azure Stream Analytics används som en ETL-motor (Extract-Transform-Load) i nära realtid i den här lösningen. Du kan utforska arkiverade data i Data Lake med hjälp av olika beräkningsmotorer.
Använda referensdata för berikning
Databerikning är ofta ett krav för ETL-motorer. Azure Stream Analytics stöder databerikning med referensdata från både SQL Database och Azure Blob Storage. Databerikning kan göras för datalandning i både Azure Data Lake och Azure Synapse Analytics.
Operationalisera insikter från arkiverade data
Om du kombinerar offlineanalysmönstret med programmönstret i nära realtid kan du skapa en feedbackslinga. Med feedbackloopen kan programmet automatiskt justera för att ändra mönster i data. Den här feedbackslingan kan vara lika enkel som att ändra tröskelvärdet för aviseringar eller så komplext som omträning av Machine Learning-modeller. Samma lösningsarkitektur kan tillämpas på både ASA-jobb som körs i molnet och på IoT Edge.
Övervaka ASA-jobb
Ett Azure Stream Analytics-jobb kan köras dygnet om för att bearbeta inkommande händelser kontinuerligt i realtid. Drifttidsgarantin är avgörande för hälsotillståndet för det övergripande programmet. Även om Stream Analytics är den enda tjänsten för streaminganalys i branschen som erbjuder en tillgänglighetsgaranti på 99,9 % får du fortfarande en viss stilleståndstid. Under årens lopp har Stream Analytics introducerat mått, loggar och jobbtillstånd för att återspegla jobbens hälsotillstånd. Alla visas via Azure Monitor-tjänsten och kan exporteras ytterligare till OMS. Mer information finns i Övervaka Stream Analytics-jobb med Azure-portalen.
Det finns två viktiga saker att övervaka:
-
Först och främst måste du se till att jobbet körs. Utan jobbet i körningstillståndet genereras inga nya mått eller loggar. Jobb kan ändras till ett misslyckat tillstånd av olika skäl, till exempel att ha en hög SU-användningsnivå (det vill säga att resurserna börjar ta slut).
Mått för vattenstämpelfördröjning
Det här måttet visar hur långt bakom din bearbetningspipeline ligger i klocktid (sekunder). En del av fördröjningen beror på den inbyggda bearbetningslogik. Därför är det mycket viktigare att övervaka den ökande trenden än att övervaka det absoluta värdet. Fördröjningen av stabilt tillstånd bör åtgärdas av programdesignen, inte genom övervakning eller aviseringar.
Vid fel är aktivitetsloggar och diagnostikloggar de bästa platserna att börja leta efter fel på.
Skapa motståndskraftiga och verksamhetskritiska program
Oavsett Azure Stream Analytics SLA-garanti och hur försiktig du kör ditt slutpunkt-till-slutpunkt-program uppstår avbrott. Om ditt program är verksamhetskritiskt måste du vara förberedd på avbrott för att kunna återställas korrekt.
För aviseringsprogram är det viktigaste att identifiera nästa avisering. Du kan välja att starta om jobbet från den aktuella tiden när du återställer och ignorerar tidigare aviseringar. Jobbets starttidssemantik är den första utdatatiden, inte den första indatatiden. Indatan rewound bakåt en lämplig tid för att garantera att de första utdata vid den angivna tidpunkten är fullständig och korrekt. Du får inte partiella aggregeringar och utlöser aviseringar oväntat som ett resultat.
Du kan också välja att starta utdata från en viss tid tidigare. Både Event Hubs och IoT Hubs kvarhållningsprinciper innehåller en rimlig mängd data för att tillåta bearbetning från det förflutna. Kompromissen är hur snabbt du kan komma ikapp den aktuella tiden och börja generera nya aviseringar i tid. Data förlorar sitt värde snabbt över tid, så det är viktigt att snabbt komma ikapp den aktuella tiden. Det finns två sätt att komma ikapp snabbt:
- Etablera fler resurser (SU) när du kommer ikapp.
- Starta om från aktuell tid.
Att starta om från aktuell tid är enkelt att göra, med kompromissen att lämna en lucka under bearbetningen. Att starta om på det här sättet kan vara OK för aviseringsscenarier, men kan vara problematiskt för instrumentpanelsscenarier och är en icke-startpunkt för arkivering och datalagerscenarier.
Etablering av fler resurser kan påskynda processen, men effekten av en ökning av bearbetningshastigheten är komplex.
Testa att jobbet är skalbart för ett större antal SUS:er. Alla frågor är inte skalbara. Du måste se till att frågan är parallelliserad.
Kontrollera att det finns tillräckligt med partitioner i de överordnade eventhubbarna eller IoT Hub som du kan lägga till fler dataflödesenheter (TU:er) för att skala indataflödet. Kom ihåg att varje Event Hubs TU maxar ut med en utdatahastighet på 2 MB/s.
Kontrollera att du har etablerat tillräckligt med resurser i utdatamottagare (dvs. SQL Database, Azure Cosmos DB), så att de inte begränsar ökningen av utdata, vilket ibland kan leda till att systemet låses.
Det viktigaste är att förutse bearbetningshastighetsändringen, testa dessa scenarier innan du går in i produktion och vara redo att skala bearbetningen korrekt under återställningstiden för fel.
I det extrema scenariot att inkommande händelser alla fördröjs är det möjligt att alla fördröjda händelser tas bort om du har tillämpat ett fönster för sen ankomst till jobbet. Att ta bort händelserna kan verka vara ett mystiskt beteende i början. Men med tanke på att Stream Analytics är en realtidsbearbetningsmotor förväntar den sig att inkommande händelser kommer att vara nära klocktiden på väggen. Den måste släppa händelser som bryter mot dessa begränsningar.
Lambda-arkitekturer eller återfyllnadsprocess
Lyckligtvis kan det tidigare dataarkiveringsmönstret användas för att bearbeta dessa sena händelser på ett korrekt sätt. Tanken är att arkiveringsjobbet bearbetar inkommande händelser vid ankomsttid och arkiverar händelser i rätt tidshink i Azure Blob eller Azure Data Lake Store med sin händelsetid. Det spelar ingen roll hur sent en händelse kommer, den kommer aldrig att släppas. Det kommer alltid att landa i rätt tidshink. Under återställningen är det möjligt att bearbeta de arkiverade händelserna igen och fylla i resultaten i det arkiv som du väljer. Detta liknar hur lambda-mönster implementeras.
Återfyllnadsprocessen måste göras med ett batchbearbetningssystem offline, som troligen har en annan programmeringsmodell än Azure Stream Analytics. Det innebär att du måste implementera om hela bearbetningslogiken.
För återfyllnad är det fortfarande viktigt att åtminstone tillfälligt etablera mer resurs till utdatamottagare för att hantera högre dataflöde än behovet av bearbetning av stabilt tillstånd.
| Scenarier | Starta endast om från och med nu | Starta om från senast stoppad tid | Starta om från och med nu + återfyll med arkiverade händelser |
|---|---|---|---|
| Instrumentpaneler | Skapar mellanrum | OK för kort avbrott | Använd vid långa avbrott |
| Aviseringar | Acceptabelt | OK för kort avbrott | Inte nödvändigt |
| Händelsekällor | Acceptabelt | OK för kort avbrott | Använd vid långa avbrott |
| Datalagerhantering | Dataförluster | Acceptabelt | Inte nödvändigt |
| Offlineanalys | Dataförluster | Acceptabelt | Inte nödvändigt |
Färdigställa allt
Det är inte svårt att föreställa sig att alla lösningsmönster som nämnts tidigare kan kombineras i ett komplext system från slutpunkt till slutpunkt. Det kombinerade systemet kan innehålla instrumentpaneler, aviseringar, program för händelsekällor, informationslager och offlineanalysfunktioner.
Nyckeln är att utforma systemet i komposterbara mönster, så att varje undersystem kan skapas, testas, uppgraderas och återställas oberoende av varandra.
Nästa steg
Nu har du sett olika lösningsmönster med Hjälp av Azure Stream Analytics. Härnäst kan du gå på djupet och skapa ditt första Stream Analytics-jobb: