Dela via

Principer för tidsförskjutning (Azure Stream Analytics)

  • Artikel

I Stream Analytics har alla dataströmshändelser en associerad tidsstämpel . Användare kan använda nyckelordet TIMESTAMP BY för att välja mellan en av dessa två olika gånger:

  • Programtid, det vill säga den tid då händelserna skapas (som markeras 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 händelsehubb).

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 kom från
  • 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. Klockfö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 antingen vara:

  • 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.

Princip som inte är i ordning

Att ha händelser ordnade efter tid är mycket viktigt i strömningsanalyser. 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 se ut att ha kommit fram till den senaste godtagbara tidpunkten.
  • Borttagen: Ignorerad.

Den här inställningen kan justeras i Azure Portal (på fliken "Händelseordning" 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 fram 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 en 3 sekunders fönster först är en bra metod och sedan justera 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 steg. 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 Portal (på fliken "Händelseordning" 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 tas bort, beroende på vilken åtgärd som valts). När flera partitioner från samma indataström eller flera indataströmmar kombineras är toleransen för sen ankomst den maximala tid som varje partition väntar på nya data.

Tolerans för sen ankomst 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 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.

Se även

Tidshantering (Azure Stream Analytics)
System.Timestamp() (Stream Analytics)
TIMESTAMP BY (Azure Stream Analytics)
Händelsebeställningsövervägande