Förstå tidshantering i Azure Stream Analytics

Artikel
01/23/2024

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 tidshantering av design är nära relaterade till händelseordningsfaktorer.

Begrepp inom bakgrundstid

För att bättre rama in diskussionen ska vi definiera några bakgrundsbegrepp:

Händelsetid: Tiden 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 anger upp till vilken punkt händelser har ingresserats till strömningsprocessorn. Med vattenstämplar kan systemet ange tydliga förlopp 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 producera fullständiga, korrekta och repeterbara resultat som inte behöver återkallas. Bearbetningen kan göras på ett förutsägbart och repeterbart sätt. Om en omräkning till exempel behöver göras för felhantering ä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

Ankomsttid tilldelas vid indatakällan när händelsen når källan. Du kan komma åt ankomsttiden med 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 temporal logik inte är nödvändig.

Programtid (kallas även händelsetid)

Programtiden tilldelas när händelsen genereras och ä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ämpeln är frånvarande bearbetas händelserna efter ankomsttid.

Det är viktigt att använda en tidsstämpel i nyttolasten när tidslogik är inblandad 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 storleken på toleransen för out-of-order-fönstret.
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 förflutit från den senaste gången en indatahändelse sågs plus den indatahändelsens ankomsttid.

Ankomsttiden kan bara beräknas eftersom realtids ankomsttiden genereras i den asynkrona meddelandekön för indatahändelser, till exempel Event Hubs, eller på den virtuella Azure Stream Analytics-dator 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 utdataresultatet. I Azure Portal på sidan Händelseordning i Stream Analytics-jobbet kan du konfigurera inställningen Out of order events (Out of order-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.

Toleransperioden för sen ankomst är nödvändig för att fortsätta generera vattenstämplar, även om det inte finns några inkommande händelser. Ibland kan det finnas en period då 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 den asynkrona meddelandekön för indatahändelser.

Databearbetningssystem för direktuppspelning 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 ansökningstid. Båda sparas i händelseutjämningen och kan därför upprepas. När en ankomsttid uppskattas i avsaknad av händelser, journalerAr Azure Stream Analytics den uppskattade ankomsttiden för upprepning under återuppspelning för återställning av fel.

När du väljer att använda ankomsttid som händelsetid behöver du inte konfigurera toleransen för oordnad tolerans och tolerans för sen ankomst. Eftersom ankomsttiden garanterat ökar i den asynkrona meddelandekön för indatahändelser ignorerar Azure Stream Analytics helt enkelt konfigurationerna.

Händelser som inkommer sent

För varje inkommande händelse jämför Azure Stream Analytics händelsetiden med ankomsttiden. 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 anges händelsens System.Timestamp till 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 generering av vattenstämplar 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ömmar. 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 efter 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 klockskevhet 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 system för databearbetning med 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 den maximala mängd som olika underströmmar kan skilja sig från varandra. Om enhet 1 till exempel är på Timestamp 1 och Enhet 2 är på Timestamp 2, är toleransen för senaste ankomst tidsstämpel 2 minus tidsstämpel 1. Standardinställningen är 5 sekunder och är förmodligen för liten för enheter med avvikande tidsstämplar. Vi rekommenderar att du börjar med 5 minuter och gör justeringar enligt enhetens snedställningsmönster.

Händelser som inkommer tidigt

Du kanske har lagt märke till ett annat koncept som kallas fönster för tidig ankomst som ser ut som motsatsen till toleransfönstret för sen ankomst. 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 jobbets starttid som jobbets första utdatatid, inte indatatiden. Jobbets starttid 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 den asynkrona meddelandekön för indatahändelser 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 den asynkrona meddelandekön för indatahändelser. Med den tidiga ankommande fönstergränsen är översättningen enkel: startar händelsetiden minus 5 minuters tidigt ankommande fönster. 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 ökas 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.

Sidoeffekter av tidstoleranser för händelseordning

Stream Analytics-jobb har flera alternativ för händelseordning . Två kan konfigureras i Azure Portal: inställningen Out-of-order events (out-of-order tolerance) och inställningen Händelser som anländer sent (tolerans för sen ankomst). 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 tas bort, 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.

Även om gamla händelser kan verka ofarliga till en början, kan de gamla händelserna tas bort på grund av tillämpningen av toleransen för sen ankomst. Om händelserna är för gamla ändras värdet System.Timestamp under händelseinmatningen. På grund av det här beteendet är Azure Stream Analytics för närvarande mer lämpligt för scenarier för händelsebearbetning i nära realtid, i stället för historiska scenarier för händelsebearbetning. Du kan i vissa fall ställa in händelser som anländer sent till det största möjliga värdet (20 dagar) för att kringgå det här beteendet.
Utdata verkar vara fördröjda.

Den första vattenstämpeln genereras vid den beräknade tiden: den maximala händelsetid som systemet har observerat hittills, minus den out-of-order tolerans fönsterstorleken. 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 av det värdet för tid (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 blir ovanliga och glesa kan utdata därför fördröjas med den tiden. Standardvärdet för händelser som kommer sent är 5 sekunder. Du bör till exempel förvänta dig en 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-tolerans eller fönster för sen ankomsttolerans. System.Timestamp-värdet för händelsen justeras, men inte händelsetidsfältet. Detta kan användas för att identifiera för vilka händelser tidsstämplarna justerats. Om systemet ändrade tidsstämpeln på grund av en av toleranserna är de normalt desamma.

Mått att observera

Du kan se ett antal tidstoleranseffekter för händelseordning via Azure Stream Analytics-jobbmått. Följande mått är relevanta:

Metric	Beskrivning
Out-of-Order-händelser	Anger antalet händelser som tagits emot i fel ordning, som antingen har släppts eller fått en justerad tidsstämpel. Det här måttet påverkas direkt av konfigurationen av inställningen Out of order events (Out of order-händelser) på sidan Händelseordning för jobbet i Azure Portal.
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 tagits bort 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 för jobbet i Azure Portal.
Tidiga indatahändelser	Anger antalet händelser som kommer tidigt från källan som antingen har släppts eller deras tidsstämpel har justerats om de är längre än 5 minuter för tidigt.
Vattenstämpelfördröjning	Anger fördröjningen för det strömmande databearbetningsjobbet. Mer information finns i följande avsnitt.

Information om vattenstämpelfördröjning

Måttet för vattenstämpelns fördröjning beräknas som klocktid på väggen för bearbetningsnoden minus den största vattenstämpeln den har sett 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.
Den out-of-order tolerans fönstret introducerade 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 minskar med storleken på toleransfönstret.
Klocksnedställning 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ämpelns fördröjning kan stiga 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 de asynkrona meddelandeköerna för indatahändelser, så de begränsas. Möjliga lösningar finns i Skala upp Azure Event Hubs dataflödesenheter automatiskt.
Utdatamottagare etableras inte med tillräckligt med kapacitet, så de begränsas. Möjliga lösningar varierar mycket 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 vid felåterställning 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 en viss tidsperiod kan genereras flera gånger. När indatavärdena förfinas blir de aggregerade resultaten mer exakta. Händelser kan spekuleras först 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 tas med i indataströmmen. Utdataresultatet från bearbetningen av tidsperioden ger mer exakta utdata.

Illustrerat exempel på vattenstämplar

Följande bilder illustrerar hur vattenstämplarna utvecklas under olika omständigheter.

Den här tabellen visar exempeldata som visas nedan. Observera att händelsetiden och ankomsttiden varierar, ibland matchande 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	device3
12:19	12:16	device1
12:12	12:17	device3
12:17	12:18	device2
12:20	12:19	device2
12:16	12:21	device3
12:23	12:22	device2
12:22	12:24	device2
12:21	12:27	device3

I den här bilden används följande toleranser:

Fönster för tidig ankomst är 5 minuter
Fönstret som kommer sent är 5 minuter
Ordningsföljdsfönstret är 2 minuter

Bild av vattenstämpel som går igenom dessa händelser:

Anmärkningsvärda processer som illustreras i föregående bild:
1. Den första händelsen (device1) och den andra händelsen (device2) har justerade tider och bearbetas utan justeringar. Vattenstämpeln förlopp för varje händelse.
2. När den tredje händelsen (enhet1) bearbetas föregår ankomsttiden (12:11) händelsetiden (12:17). Evenemanget 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 förlöper inte i det här fallet av en tidig händelse.
3. Den fjärde händelsen (device3) och den femte händelsen (device1) har justerade tider och bearbetas utan justering. Vattenstämpeln förlopp för varje händelse.
4. När den sjätte händelsen (enhet3) bearbetas är ankomsttiden (12:17) och händelsetiden (12:12) under vattenstämpelnivån. Händelsetiden justeras till vattenmärkesnivån (12:17).
5. När den tolfte händelsen (enhet3) bearbetas är ankomsttiden (12:27) 6 minuter före händelsetiden (12:21). Policyn för sen ankomst tillämpas. Händelsetiden justeras (12:22), som ligger ovanför vattenstämpeln (12:21) så ingen ytterligare justering tillämpas.
Andra illustrationen av vattenstämpeln som utvecklas utan en politik 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 har släppts i det här scenariot och att 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.