Förstå tidshantering i Azure Stream Analytics
I den här artikeln får du lära dig hur du gör designval för att lösa praktiska tidshanteringsproblem i Azure Stream Analytics-jobb. Beslut om tidshanteringsdesign är nära relaterade till händelseordningsfaktorer.
Begrepp för bakgrundstid
För att bättre rama in diskussionen ska vi definiera några bakgrundsbegrepp:
Händelsetid: Den tid då den ursprungliga händelsen inträffade. Till exempel när en bil i rörelse på motorvägen närmar sig en avgiftsbelagd monter.
Bearbetningstid: Den tid då händelsen når bearbetningssystemet och observeras. Till exempel när en vägtullssensor ser bilen och datorsystemet tar en stund att bearbeta data.
Vattenstämpel: En markör för händelsetid som indikerar upp till vilken tidpunkt händelser har inträtt i den strömmande processorn. Med vattenstämplar kan systemet ange tydliga framsteg vid inmatning av händelserna. Av typen av strömmar stoppas aldrig inkommande händelsedata, så vattenstämplar indikerar förloppet till en viss punkt i strömmen.
Vattenstämpelkonceptet är viktigt. Med vattenstämplar kan Stream Analytics avgöra när systemet kan generera fullständiga, korrekta och repeterbara resultat som inte behöver återkallas. Bearbetningen kan utföras på ett förutsägbart och repeterbart sätt. Om till exempel en omräkning behöver göras för vissa felhanteringsvillkor är vattenstämplar säkra start- och slutpunkter.
Ytterligare resurser om detta ämne finns i Tyler Akidaus blogginlägg Streaming 101 och Streaming 102.
Välj den bästa starttiden
Stream Analytics ger användarna två alternativ för att välja händelsetid: ankomsttid och programtid.
Ankomsttid
Ankomsttiden tilldelas vid indatakällan när händelsen når källan. Du kan komma åt ankomsttiden med hjälp av egenskapen EventEnqueuedUtcTime för Event Hubs-indata, egenskapen IoTHub.EnqueuedTime för IoT Hub-indata och egenskapen BlobProperties.LastModified för blobindata.
Ankomsttid används som standard och används bäst för dataarkiveringsscenarier där tidslogik inte behövs.
Programtid (kallas även händelsetid)
Programtiden tilldelas när händelsen genereras och det är en del av händelsenyttolasten. Om du vill bearbeta händelser efter programtid använder du timestamp by-satsen i SELECT-frågan. Om Tidsstämpel efter saknas bearbetas händelser efter ankomsttid.
Det är viktigt att använda en tidsstämpel i nyttolasten när tidslogik används för att ta hänsyn till fördröjningar i källsystemet eller i nätverket. Tiden som tilldelas till en händelse är tillgänglig i SYSTEM. TIDSSTÄMPEL.
Hur tiden går i Azure Stream Analytics
När du använder programtid baseras tidsförloppet på inkommande händelser. Det är svårt för dataströmbearbetningssystemet att veta om det inte finns några händelser eller om händelser fördröjs. Därför genererar Azure Stream Analytics heuristiska vattenstämplar på följande sätt för varje indatapartition:
När det finns en inkommande händelse är vattenstämpeln den största händelsetid som Stream Analytics har sett hittills minus out-of-order-toleransfönstrets storlek.
När det inte finns någon inkommande händelse är vattenstämpeln den aktuella uppskattade ankomsttiden minus toleransfönstret för sen ankomst. Den uppskattade ankomsttiden är den tid som har förflutit från den senaste gången en indatahändelse sågs plus den indatahändelsens ankomsttid.
Ankomsttiden kan bara beräknas eftersom den faktiska ankomsttiden genereras på indatahändelsekoordinatorn, till exempel Event Hubs eller på den virtuella Azure Stream Analytics-datorn som bearbetar händelserna.
Designen har två andra syften än att generera vattenstämplar:
Systemet genererar resultat i rätt tid med eller utan inkommande händelser.
Du har kontroll över hur snabbt du vill se utdataresultaten. På sidan Händelseordning i Stream Analytics-jobbet i Azure-portalen kan du konfigurera inställningen Oordnade händelser. När du konfigurerar den inställningen bör du överväga att kompromissa med aktualitet med tolerans för out-of-order-händelser i händelseströmmen.
Toleransfönstret för sen ankomst är nödvändigt för att fortsätta generera vattenstämplar, även i avsaknad av inkommande händelser. Ibland kan det finnas en period där inga inkommande händelser kommer in, till exempel när en händelseindataström är gles. Det problemet förvärras av användningen av flera partitioner i händelsehanteraren för indata.
Strömmande databehandlingssystem utan ett toleransfönster för sen ankomst kan drabbas av fördröjda utdata när indata är glesa och flera partitioner används.
Systembeteendet måste vara repeterbart. Repeterbarhet är en viktig egenskap för ett strömmande databehandlingssystem.
Vattenstämpeln härleds från ankomsttid och programtid. Båda sparas i händelsekoordinatorn och kan därför upprepas. När en ankomsttid uppskattas i avsaknad av händelser, journalar Azure Stream Analytics den uppskattade ankomsttiden för upprepning under omspelning för återställning av fel.
När du väljer att använda ankomsttid som händelsetid behöver du inte konfigurera tolerans och tolerans för sen ankomst. Eftersom ankomsttiden garanterat kommer att öka i meddelandeköerna för indatahändelser ignorerar Azure Stream Analytics helt enkelt konfigurationerna.
Händelser som inkommer sent
Azure Stream Analytics jämför händelsetiden med ankomsttiden för varje inkommande händelse per definition. Om händelsetiden ligger utanför toleransfönstret kan du konfigurera systemet att släppa händelsen eller justera händelsens tid så att den ligger inom toleransen.
När vattenstämplar har genererats kan tjänsten ta emot händelser med en händelsetid som är lägre än vattenstämpeln. Du kan konfigurera tjänsten att antingen släppa dessa händelser eller justera händelsens tid till vattenstämpelvärdet.
Som en del av justeringen är händelsens System.Timestamp inställd på det nya värdet, men själva händelsetidsfältet ändras inte. Den här justeringen är den enda situationen där en händelses System.Timestamp kan skilja sig från värdet i fältet händelsetid och kan orsaka oväntade resultat.
Hantera tidsvariation med underströmmar
Den heuristiska mekanismen för vattenstämpelgenerering som beskrivs fungerar bra i de flesta fall där tiden mestadels synkroniseras mellan de olika händelseavsändare. Men i verkligheten, särskilt i många IoT-scenarier, har systemet liten kontroll över klockan på händelseavsändare. Händelseavsändare kan vara alla typer av enheter i fältet, kanske på olika versioner av maskinvara och programvara.
I stället för att använda en vattenstämpel som är global för alla händelser i en indatapartition har Stream Analytics en annan mekanism som kallas underström. Du kan använda underströmmar i jobbet genom att skriva en jobbfråga som använder TIMESTAMP BY-satsen och nyckelordet OVER. Om du vill ange underströmmen anger du ett nyckelkolumnnamn efter nyckelordet OVER , till exempel en deviceid, så att systemet tillämpar tidsprinciper för den kolumnen. Varje underström får en egen oberoende vattenstämpel. Den här mekanismen är användbar för att möjliggöra generering av utdata i tid när du hanterar stora klocksnedvridningar eller nätverksfördröjningar bland händelseavsändare.
Underströmmar är en unik lösning som tillhandahålls av Azure Stream Analytics och erbjuds inte av andra databehandlingssystem för direktuppspelning.
När du använder underströmmar tillämpar Stream Analytics toleransfönstret för sena ankomster på inkommande händelser. Toleransen för sen ankomst avgör hur mycket olika underströmmar kan skiljas från varandra. Om enhet 1 till exempel är på Timestamp 1 och Enhet 2 är på Timestamp 2, är toleransen för sena ankomster tidsstämpel 2 minus tidsstämpel 1. Standardinställningen är 5 sekunder och är troligen för liten för enheter med avvikande tidsstämplar. Vi rekommenderar att du börjar med 5 minuter och gör justeringar enligt deras snedställningsmönster för enhetsklockan.
Händelser som kommer tidigt
Du kanske har lagt märke till ett annat koncept som kallas för tidig ankomst som ser ut som motsatsen till toleransfönstret för sena ankomster. Det här fönstret är fast vid 5 minuter och har ett annat syfte än toleransfönstret för sen ankomst.
Eftersom Azure Stream Analytics garanterar fullständiga resultat kan du bara ange starttid för jobbet som den första utdatatiden för jobbet, inte indatatiden. Starttiden för jobbet krävs så att hela fönstret bearbetas, inte bara från mitten av fönstret.
Stream Analytics härleder starttiden från frågespecifikationen. Men eftersom indatahändelsekoordinatorn endast indexeras efter ankomsttid måste systemet översätta starthändelsetiden till ankomsttiden. Systemet kan börja bearbeta händelser från den tidpunkten i koordinatorn för indatahändelser. Med den tidiga ankommande fönstergränsen är översättningen enkel: starta händelsetiden minus fönstret 5 minuters tidig ankomst. Den här beräkningen innebär också att systemet tar bort alla händelser som anses ha en händelsetid 5 minuter tidigare än ankomsttiden. Måttet för tidiga indatahändelser ökar när händelserna tas bort.
Det här konceptet används för att säkerställa att bearbetningen kan upprepas oavsett var du börjar mata ut från. Utan en sådan mekanism skulle det inte vara möjligt att garantera repeterbarhet, som många andra strömningssystem hävdar att de gör.
Biverkningar av tidstoleranser för händelseordning
Stream Analytics-jobb har flera alternativ för händelsebeställning . Två kan konfigureras i Azure-portalen: inställningen Out of order events (out-of-order tolerance) och inställningen Händelser som anländer sent (tolerans för sena ankomster). Toleransen för tidig ankomst är fast och kan inte justeras. Dessa tidsprinciper används av Stream Analytics för att ge starka garantier. De här inställningarna har dock vissa ibland oväntade konsekvenser:
Skicka händelser som är för tidiga av misstag.
Tidiga händelser bör inte matas ut normalt. Det är möjligt att tidiga händelser skickas till utdata om avsändarens klocka körs för snabbt. Alla händelser som kommer tidigt släpps, så du kommer inte att se någon av dem från utdata.
Skicka gamla händelser till Event Hubs som ska bearbetas av Azure Stream Analytics.
Medan gamla händelser kan verka ofarliga först, på grund av tillämpningen av toleransen för sen ankomst, kan de gamla händelserna släppas. Om händelserna är för gamla ändras värdet System.Timestamp under händelseinmatning. På grund av det här beteendet är Azure Stream Analytics för närvarande mer anpassat för scenarier för händelsebearbetning i nästan realtid, i stället för historiska scenarier för händelsebearbetning. Du kan ange de händelser som kommer sent till det största möjliga värdet (20 dagar) för att i vissa fall kringgå det här beteendet.
Utdata verkar vara fördröjda.
Den första vattenstämpeln genereras vid den beräknade tidpunkten: den maximala händelsetid som systemet hittills har observerat, minus out-of-order-toleransfönstrets storlek. Som standard är out-of-order-toleransen konfigurerad till noll (00 minuter och 00 sekunder). När du anger ett högre tidsvärde som inte är noll fördröjs det strömmande jobbets första utdata med det tidsvärdet (eller större) på grund av den första vattenstämpeltiden som beräknas.
Indata är glesa.
När det inte finns några indata i en viss partition beräknas vattenstämpeltiden som ankomsttid minus toleransfönstret för sen ankomst. Om indatahändelser därför är ovanliga och glesa kan utdata fördröjas med den tiden. Standardvärdet händelser som anländer sent är 5 sekunder. Du bör till exempel förvänta dig en viss fördröjning när du skickar indatahändelser en i taget. Fördröjningarna kan bli värre när du anger Händelser som kommer sent till ett stort värde.
System.Timestamp-värdet skiljer sig från tiden i fältet händelsetid .
Som tidigare beskrivits justerar systemet händelsetiden med out-of-order-toleransen eller de sena ankomsttoleransfönstren. Värdet System.Timestamp för händelsen justeras, men inte fältet händelsetid . Detta kan användas för att identifiera för vilka händelser tidsstämplarna har justerats. Om systemet ändrade tidsstämpeln på grund av en av toleranserna är de normalt desamma.
Mått att observera
Du kan observera ett antal tidstoleranseffekter för händelseordning via Azure Stream Analytics-jobbmått. Följande mått är relevanta:
| Mätvärde | Beskrivning |
|---|---|
| Out-of-Order-händelser | Anger antalet händelser som tagits emot i fel ordning, som antingen har tagits bort eller fått en justerad tidsstämpel. Det här måttet påverkas direkt av konfigurationen av inställningen oordnade händelser på sidan Händelseordning på jobbet i Azure-portalen. |
| Händelser för sena indata | Anger antalet händelser som kommer sent från källan. Det här måttet innehåller händelser som har släppts eller fått tidsstämpeln justerad. Det här måttet påverkas direkt av konfigurationen av inställningen Händelser som kommer sent på sidan Händelseordning på jobbet i Azure-portalen. |
| Tidiga indatahändelser | Anger antalet händelser som kommer tidigt från källan som antingen har släppts eller att tidsstämpeln har justerats om de är längre än 5 minuter för tidigt. |
| Fördröjning av vattenstämpel | Anger fördröjningen av databearbetningsjobbet för direktuppspelning. Mer information finns i följande avsnitt. |
Information om vattenstämpelfördröjning
Måttet för vattenstämpelfördröjning beräknas som klocktid på väggen för bearbetningsnoden minus den största vattenstämpeln hittills. Mer information finns i blogginlägget om vattenstämpelfördröjning.
Det kan finnas flera orsaker till att det här måttvärdet är större än 0 under normal drift:
Inbyggd bearbetningsfördröjning för strömningspipelinen. Normalt är denna fördröjning nominell.
Fönstret för out-of-order-tolerans medförde en fördröjning eftersom vattenstämpeln minskas av storleken på toleransfönstret.
Fönstret för sen ankomst medförde en fördröjning eftersom vattenstämpeln minskas med storleken på toleransfönstret.
Klockförskjutning av bearbetningsnoden som genererar måttet.
Det finns ett antal andra resursbegränsningar som kan göra att strömningspipelinen blir långsammare. Måttet för vattenstämpelfördröjning kan öka på grund av:
Det finns inte tillräckligt med bearbetningsresurser i Stream Analytics för att hantera volymen av indatahändelser. Information om hur du skalar upp resurser finns i Förstå och justera strömningsenheter.
Det finns inte tillräckligt med dataflöde i indatahändelseköerna, så de begränsas. Möjliga lösningar finns i Skala upp dataflödesenheter för Azure Event Hubs automatiskt.
Utdatamottagare etableras inte med tillräckligt med kapacitet, så de begränsas. De möjliga lösningarna varierar kraftigt beroende på vilken typ av utdatatjänst som används.
Händelsefrekvens för utdata
Azure Stream Analytics använder vattenstämpelns förlopp som den enda utlösaren för att skapa utdatahändelser. Eftersom vattenstämpeln härleds från indata kan den upprepas under återställning av fel och även vid användarinitierad ombearbetning. När du använder fönsteraggregeringar producerar tjänsten endast utdata i slutet av fönstren. I vissa fall kanske användarna vill se partiella aggregeringar som genereras från fönstren. Partiella aggregeringar stöds för närvarande inte i Azure Stream Analytics.
I andra strömningslösningar kan utdatahändelser materialiseras vid olika utlösarpunkter, beroende på externa omständigheter. I vissa lösningar är det möjligt att utdatahändelserna för ett visst tidsfönster kan genereras flera gånger. När indatavärdena förfinas blir de aggregerade resultaten mer exakta. Händelser kan först spekuleras och revideras över tid. När en viss enhet till exempel är offline från nätverket kan ett uppskattat värde användas av ett system. Senare kommer samma enhet online till nätverket. Då kan faktiska händelsedata inkluderas i indataströmmen. Utdataresultaten från bearbetningen av tidsfönstret ger mer exakta utdata.
Illustrerat exempel på vattenstämplar
Följande bilder illustrerar hur vattenstämplar utvecklas under olika omständigheter.
Den här tabellen visar exempeldata som visas nedan. Observera att händelsetiden och ankomsttiden varierar, ibland matchning och ibland inte.
| Händelsetid | Ankomsttid | DeviceId |
|---|---|---|
| 12:07 | 12:07 | device1 |
| 12:08 | 12:08 | device2 |
| 12:17 | 12:11 | device1 |
| 12:08 | 12:13 | enhet3 |
| 12:19 | 12:16 | device1 |
| 12:12 | 12:17 | enhet3 |
| 12:17 | 12:18 | device2 |
| 12:20 | 12:19 | device2 |
| 12:16 | 12:21 | enhet3 |
| 12:23 | 12:22 | device2 |
| 12:22 | 12:24 | device2 |
| 12:21 | 12:27 | enhet3 |
I den här bilden används följande toleranser:
- Fönster för tidig ankomst är 5 minuter
- Sent ankommande fönster är 5 minuter
- Omordningsfönstret är 2 minuter
Bild av vattenstämpeln som fortsätter genom dessa händelser:
Anmärkningsvärda processer som illustreras i föregående bild:
Den första händelsen (device1) och den andra händelsen (device2) har justerade tider och bearbetas utan justeringar. Vattenstämpeln fortsätter för varje händelse.
När den tredje händelsen (device1) bearbetas föregår ankomsttiden (12:11) händelsetiden (12:17). Händelsen anlände 6 minuter för tidigt, så händelsen släpps på grund av toleransen för tidig ankomst på 5 minuter.
Vattenstämpeln utvecklas inte i det här fallet av en tidig händelse.
Den fjärde händelsen (device3) och den femte händelsen (device1) har justerade tider och bearbetas utan justering. Vattenstämpeln fortsätter för varje händelse.
När den sjätte händelsen (enhet3) bearbetas ligger ankomsttiden (12:17) och händelsetiden (12:12) under vattenstämpelnivån. Händelsetiden justeras till vattenmärkesnivån (12:17).
När den tolfte händelsen (enhet3) bearbetas är ankomsttiden (12:27) 6 minuter före händelsetiden (12:21). Principen för sen ankomst tillämpas. Händelsetiden justeras (12:22), som är ovanför vattenstämpeln (12:21) så ingen ytterligare justering tillämpas.
Andra bilden av vattenstämpeln som utvecklas utan en policy för tidig ankomst:
I det här exemplet tillämpas ingen princip för tidig ankomst. Avvikande händelser som anländer tidigt höjer vattenstämpeln avsevärt. Observera att den tredje händelsen (deviceId1 vid tidpunkten 12:11) inte tas bort i det här scenariot och vattenstämpeln höjs till 12:15. Den fjärde händelsetiden justeras framåt 7 minuter (12:08 till 12:15) som ett resultat.
I den sista bilden används underströmmar (OVER the DeviceId). Flera vattenstämplar spåras, en per ström. Det finns färre händelser med tiden justerad som ett resultat.
