Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
I den här artikeln beskrivs hur du konfigurerar och använder händelseprinciper för sen ankomst och out-of-order i Azure Stream Analytics. Dessa principer tillämpas endast när du använder TIMESTAMP BY-satsen i din fråga och de tillämpas endast för molnindatakällor.
Händelsetid och ankomsttid
Ditt Stream Analytics-jobb kan bearbeta händelser baserat på antingen händelsetid eller ankomsttid. Händelse-/programtid är tidsstämpeln som finns i händelsenyttolasten (när händelsen genererades). Ankomsttid är tidsstämpeln när händelsen togs emot vid indatakällan (Event Hubs/IoT Hub/Blob Storage).
Som standard bearbetar Stream Analytics händelser efter ankomsttid, men du kan välja att bearbeta händelser efter händelsetid med hjälp av TIMESTAMP BY-satsen i din fråga. Principer för sen ankomst och inaktivitet gäller endast om du bearbetar händelser efter händelsetid. Överväg krav på svarstid och korrekthet för ditt scenario när du konfigurerar de här inställningarna.
Vad är principen för händelser som kommer sent?
Ibland kommer händelser sent på grund av olika orsaker. Till exempel kommer en händelse som kommer 40 sekunder för sent att ha händelsetid = 00:10:00 och ankomsttid = 00:10:40. Om du anger principen för sen ankomst till 15 sekunder kommer alla händelser som kommer senare än 15 sekunder antingen att tas bort (inte bearbetas av Stream Analytics) eller få sin händelsetid justerad. I exemplet ovan, när händelsen kom 40 sekunder för sent (mer än principuppsättningen), justeras dess händelsetid till det maximala värdet för principen för sen ankomst 00:10:25 (ankomsttid – principvärde för sen ankomst). Standardprincipen för sen ankomst är 5 sekunder.
Vad är en out-of-order-princip?
Händelsen kan också komma i fel ordning. När händelsetiden har justerats baserat på en policy för sen ankomst kan du också välja att automatiskt släppa eller justera händelser som är oordnade. Om du anger den här principen till 8 sekunder ordnas alla händelser som kommer ur ordning, men inom 8-sekundersfönstret, efter händelsetid. Händelser som kommer senare kommer antingen att tas bort eller justeras till det maximala out-of-order-principvärdet. Standardprincipen är 0 sekunder.
Justera eller släppa händelser
Om händelser kommer sent eller i fel ordning baserat på de principer som du har konfigurerat kan du antingen släppa sådana händelser (inte bearbetas av Stream Analytics) eller få deras händelsetid justerad.
Låt oss se ett exempel på dessa principer i praktiken.
Policy för sen ankomst: 15 sekunder
Out-of-order-princip: 5 sekunder
Händelsenr. | Händelsetid | Ankomsttid | System.Timestamp | Förklaring |
---|---|---|---|---|
1 | 00:10:00 | 00:10:40 | 00:10:25 | Händelsen kom sent och utanför toleransnivån. Så händelsetiden justeras till maximal tolerans för sena ankomster. |
2 | 00:10:30 | 00:10:41 | 00:10:30 | Händelsen kom sent men inom toleransnivå. Så händelsetiden justeras inte. |
3 | 00:10:42 | 00:10:42 | 00:10:42 | Händelsen anlände i tid. Ingen justering krävs. |
4 | 00:10:38 | 00:10:43 | 00:10:38 | Händelsen kom i fel ordning men inom toleransen på 5 sekunder. Händelsetiden justeras därför inte. I analyssyfte betraktas den här händelsen som föregående händelsenummer 3 (med tanke på de totalt 5 händelserna. Den faktiska ordningen är: 1, 2, 5, 4, 3). |
5 | 00:10:35 | 00:10:45 | 00:10:37 | Händelsen kom i fel ordning och utanför toleransen på 5 sekunder. Händelsetiden justeras därför till maximalt antal out-of-order-toleranser. |
Kan de här inställningarna fördröja utdata från mitt jobb?
Ja. Som standard är out-of-order-principen inställd på noll (00 minuter och 00 sekunder). Om du ändrar standardvärdet fördröjs jobbets första utdata med det här värdet (eller större).
Om någon av partitionerna i dina indata inte tar emot händelser bör du förvänta dig att dina utdata fördröjs av värdet för principen för sen ankomst. Läs avsnittet InputPartition error (Indatapartition-fel) nedan om du vill veta varför.
Jag ser LateInputEvents-meddelanden i min aktivitetslogg
Dessa meddelanden visas för att informera dig om att händelser har kommit sent och antingen tas bort eller justeras enligt din konfiguration. Du kan ignorera dessa meddelanden om du har konfigurerat principen för sen ankomst på rätt sätt.
Exempel på det här meddelandet är:
{"message Time":"2019-02-04 17:11:52Z","error":null,
"message":"First Occurred: 02/04/2019 17:11:48 | Resource Name: ASAjob | Message: Source 'ASAjob' had 24 data errors of kind 'LateInputEvent' between processing times '2019-02-04T17:10:49.7250696Z' and '2019-02-04T17:11:48.7563961Z'. Input event with application timestamp '2019-02-04T17:05:51.6050000' and arrival time '2019-02-04T17:10:44.3090000' was sent later than configured tolerance.","type":"DiagnosticMessage","correlation ID":"aaaa0000-bb11-2222-33cc-444444dddddd"}
Jag ser InputPartitionNotProgressing i min aktivitetslogg
Din indatakälla (Event Hub/IoT Hub) har troligen flera partitioner. Azure Stream Analytics genererar utdata för tidsstämpel t1 först när alla partitioner som kombineras är minst vid tid t1. Anta till exempel att frågan läser från en händelsehubbpartition som har två partitioner. En av partitionerna, P1, har händelser fram till tid t1. Den andra partitionen, P2, har händelser fram till tid t1 + x. Utdata genereras sedan fram till tid t1. Men om det finns en explicit Partition by PartitionId-sats går båda partitionerna oberoende av varandra.
När flera partitioner från samma indataström kombineras är toleransen för sen ankomst den maximala tid som varje partition väntar på nya data. Om det finns en partition i händelsehubben eller om IoT Hub inte tar emot indata går tidslinjen för partitionen inte förrän den når tröskelvärdet för tolerans för sena ankomster. Detta fördröjer dina utdata med tröskelvärdet för tolerans för sena ankomster. I sådana fall kan följande meddelande visas:
{"message Time":"2/3/2019 8:54:16 PM UTC","message":"Input Partition [2] does not have additional data for more than [5] minute(s). Partition will not progress until either events arrive or late arrival threshold is met.","type":"InputPartitionNotProgressing","correlation ID":"0000000000-0000-0000-0000-00000000000000"}
Det här meddelandet informerar dig om att minst en partition i dina indata är tom och fördröjer dina utdata med tröskelvärdet för sen ankomst. För att lösa detta rekommenderar vi att du antingen:
- Se till att alla partitioner av din Händelsehubb/IoT Hub tar emot indata.
- Använd Partition by PartitionID-sats i din fråga.
Varför ser jag en fördröjning på 5 sekunder även när min policy för sen ankomst är inställd på 0?
Detta inträffar när det finns en indatapartition som aldrig har tagit emot några indata. Du kan verifiera indatamåtten efter partition för att verifiera det här beteendet.
När en partition inte har några data för mer än det konfigurerade tröskelvärdet för sen ankomst, avancerar Stream Analytics tidsstämpeln för programmet enligt beskrivningen i avsnittet om överväganden vid ordningsföljd. Detta kräver uppskattad ankomsttid. Om partitionen aldrig hade några data beräknar Stream Analytics ankomsttiden som lokal tid – 5 sekunder. På grund av detta kan partitioner som aldrig hade några data visa en vattenstämpelfördröjning på 5 sekunder.