Dela via

Principer för hantering av tidsskevheter

✅ Azure Stream Analytics

Alla dataströmshändelser har en tidsstämpel associerad med dem. Användare kan använda nyckelordet TIMESTAMP BY för att välja mellan någon av dessa två olika gånger:

  • Programtid, det vill säga den tid då händelserna skapas (som markerats av programmet/enheten som genererar händelserna). När du använder programtid kan du antingen bearbeta alla händelser med hjälp av en global tidslinje eller analysera varje enhet/partition med hjälp av sin egen tidslinje med hjälp av underströmmar.
  • Ankomsttid, den tid då händelsen nådde molnet (t.ex. ankomsttid i IoT Hub eller Event Hub).

Utöver valet av tidsstämpel kan användarna behöva definiera principen för sen ankomst och out of order på grund av följande problem:

  • Producenter av händelserna har klocksnedvridningar. Detta är vanligt när producenter kommer från olika datorer, så de har olika klockor.
  • På grund av nätverksfördröjning kan händelser som kommer från samma klocka komma till Event Hub eller IoT Hub i en annan ordning än när de har sitt ursprung
  • Klockan snedställs mellan partitioner. När du använder icke-partitionerade frågor sammanfogas händelser från alla partitioner med den tidsstämpel som användaren väljer. Tidsförskjutningar mellan partitionerna kan leda till fördröjning av bearbetningen, eftersom sammanslagningen måste vänta på den långsammaste partitionen.

Indataströmmar som inte är i ordning kan vara antingen:

  • Sorterad (och därför fördröjd).
  • Justeras av systemet enligt den användardefinierade principen.

Stream Analytics tolererar sena och oordnade händelser vid bearbetning efter programtid.

Out-of-order-princip

Det är mycket viktigt att ordna händelser efter tid i strömningsanalysen. Men på grund av de tre problem som nämns ovan är det ofta så att de tas emot i fel ordning, vilket kan påverka resultatet av våra frågor. Med principen Out of Order kan du ordna om händelser efter tidsstämpel när de tas emot inom det definierade toleransfönstret. Händelser som kommer senare än toleransen tas antingen bort eller justeras, beroende på vilken inställning du väljer.

  • Justerad: Justerad för att verka ha anlänt vid den senaste godtagbara tidpunkten.
  • Dropped: Discarded.

Den här inställningen kan justeras i Azure-portalen (på fliken "Händelsebeställning" i ett jobb). Mer information finns på sidan med överväganden för händelseordning.

När du ställer in en out of order-princip som är större än 0 buffras händelser upp till det fönstret och ordnas om med hjälp av den användardefinierade tidsstämpeln innan den tidsmässiga omvandlingen tillämpas. Vanligtvis börjar med ett 3 sekunders fönster först är en bra metod och justera sedan värdet för att minska antalet händelser som justeras tid. Observera att på grund av buffring är sidoeffekten att utdata fördröjs med samma tid. Därför måste du justera värdet för att minska antalet out of-order-händelser och hålla svarstiden låg.

Tolerans för sen ankomst

Toleransfönstret för sen ankomst används för att ta hänsyn till fördröjningar i händelser som når indatakällan på grund av olika orsaker som beskrivs ovan. Kort sagt är fönstret för sen ankomst den maximala fördröjningen mellan händelsegenerering och mottagande av händelsen vid indatakällan. Justering baserat på tolerans för sen ankomst görs först och i fel ordning görs nästa gång. Kolumnen System.Timestamp() har den sista tidsstämpeln tilldelad till händelsen.

Den här inställningen gäller endast vid bearbetning efter programtid, annars ignoreras den. Den kan också anges i Azure-portalen (på fliken "Händelsebeställning" i ett jobb). Mer information finns på sidan med överväganden för händelseordning.

När en händelse är sen justeras tidsstämpeln till den aktuella kötiden vid indatakällan minus toleransfönstret för sen ankomst (eller släpps, beroende på vilken åtgärd som valts). När flera partitioner från samma indataström eller flera indataströmmar kombineras är tolerans för sen ankomst den maximala tiden varje partition väntar på nya data.

Tolerans för sena ankomster och glesa händelser

Med en policy för sen ankomst kan Stream Analytics flytta tiden framåt och generera utdata i tid i avsaknad av indatahändelser. Detta är mycket användbart när indatahändelser är glesa (eller inte tas emot alls i några av Event Hub-partitionerna).

Till exempel genereras indatahändelser en gång i minuten för en select*-fråga. Utan att använda den här principen kan Stream Analytics inte generera utdataresultat förrän händelser kommer till alla Event Hub-partitioner (för att flytta tiden framåt). Det kan innebära 16 minuter om händelsehubben har 16 partitioner och att varje händelse levereras till en annan partition. Med standardprincipen på 5 sekunder flyttas klockan framåt 5 sekunder efter den första händelsen, så utdatahändelsen genereras 5 sekunder efter den första händelsen.

See Also

Time Management
System.Timestamp() (Stream Analytics)
TIMESTAMP BY
Överväganden för händelsebeställning