Beleid voor het ordenen van gebeurtenissen configureren voor Azure Stream Analytics

In dit artikel wordt beschreven hoe u beleid voor te late en niet-op-volgorde binnenkomende gebeurtenissen instelt en gebruikt in Azure Stream Analytics. Deze beleidsregels worden alleen toegepast wanneer u de TIMESTAMP BY-component in uw query gebruikt en ze worden alleen toegepast op cloudinvoerbronnen.

Tijdstip van gebeurtenis en aankomsttijd

Uw Stream Analytics-taak kan gebeurtenissen verwerken op basis van gebeurtenistijd of aankomsttijd. Gebeurtenis-/toepassingstijd is de tijdstempel die aanwezig is in de nettolading van de gebeurtenis (wanneer de gebeurtenis is gegenereerd). Aankomsttijd is de tijdstempel wanneer de gebeurtenis is ontvangen bij de invoerbron (Event Hubs/IoT Hub/Blob-opslag).

Stream Analytics verwerkt gebeurtenissen standaard op aankomsttijd, maar u kunt ervoor kiezen om gebeurtenissen te verwerken op gebeurtenistijd met behulp van de TIMESTAMP BY-component in uw query. Beleid voor te late aankomsten en niet-op-volgorde-beleid is alleen van toepassing als u gebeurtenissen verwerkt op basis van gebeurtenistijd. Overweeg latentie- en juistheidsvereisten voor uw scenario wanneer u deze instellingen configureert.

What is late arrival policy? (Wat is beleid voor late aankomst?)

Soms komen gebeurtenissen om verschillende redenen te laat. Een gebeurtenis die 40 seconden laat aankomt, heeft bijvoorbeeld tijd voor gebeurtenissen = 00:10:00 en aankomsttijd = 00:10:40. Als u het beleid voor late aankomst instelt op 15 seconden, worden gebeurtenissen die later dan 15 seconden binnenkomen, verwijderd (niet verwerkt door Stream Analytics) of worden de gebeurtenistijd aangepast. In het bovenstaande voorbeeld, omdat de gebeurtenis 40 seconden laat is aangekomen (meer dan beleid ingesteld), wordt de gebeurtenistijd aangepast aan het maximum van het beleid voor late aankomst 00:10:25 (aankomsttijd - beleidswaarde voor late aankomst). Het standaardbeleid voor late aankomst is 5 seconden.

Wat is het beleid voor niet-beschikbaarheid?

Gebeurtenissen kunnen ook in een andere volgorde binnenkomen. Nadat de gebeurtenistijd is aangepast op basis van beleid voor late aankomst, kunt u er ook voor kiezen om gebeurtenissen die niet in orde zijn, automatisch te verwijderen of aan te passen. Als u dit beleid instelt op 8 seconden, worden alle gebeurtenissen die niet in de juiste volgorde binnenkomen, maar wel binnen het venster van 8 seconden, opnieuw geordend op basis van de gebeurtenistijd. Gebeurtenissen die later binnenkomen, worden verworpen of aangepast aan de maximaal toegestane waarde volgens het beleid voor niet-op-volgorde. Het standaardbeleid voor niet-op-volgorde bedraagt 0 seconden.

Te late of niet-volgordelijke gebeurtenissen aanpassen of verwijderen

Als gebeurtenissen te laat of niet in orde zijn op basis van het beleid dat u hebt geconfigureerd, kunt u dergelijke gebeurtenissen (niet verwerkt door Stream Analytics) verwijderen of de tijd van de gebeurtenis laten aanpassen.

In het volgende voorbeeld ziet u dit beleid in actie.

  • Beleid voor late aankomst: 15 seconden
  • Beleid voor onjuiste volgorde: 5 seconden
Gebeurtenisnr. Tijdstip van gebeurtenis Aankomsttijd System.Timestamp Uitleg
1 00:10:00 00:10:40 00:10:25 De gebeurtenis is te laat aangekomen en valt buiten de tolerantiemarge. De tijd van de gebeurtenis wordt dus aangepast aan maximale tolerantie voor late aankomst.
2 00:10:30 00:10:41 00:10:30 De gebeurtenis kwam te laat aan, maar bleef binnen de tolerantiegrens. Gebeurtenistijd wordt dus niet aangepast.
3 00:10:42 00:10:42 00:10:42 Gebeurtenis is op tijd aangekomen. Geen aanpassing nodig.
4 00:10:38 00:10:43 00:10:38 Gebeurtenis is buiten de volgorde aangekomen, maar binnen de tolerantie van 5 seconden. Gebeurtenistijd wordt dus niet aangepast. Voor analysedoeleinden wordt deze gebeurtenis beschouwd als het voorgaande gebeurtenisnummer 3 (waarbij rekening wordt gehouden met het totaal van 5 gebeurtenissen. De werkelijke volgorde is: 1, 2, 5, 4, 3).
5 00:10:35 00:10:45 00:10:37 Gebeurtenis is in de verkeerde volgorde en buiten de tolerantie van 5 seconden aangekomen. De eventtijd wordt dus aangepast aan de maximale tolerantie voor gebeurtenissen buiten volgorde.

Kan beleid voor late aankomst en verkeerde volgorde de taakuitvoer vertragen?

Ja. Standaard is het beleid buiten volgorde ingesteld op nul (00 minuten en 00 seconden). Als u de standaardwaarde wijzigt, wordt de eerste uitvoer van uw taak vertraagd door deze waarde (of hoger).

Als een van de partities van uw invoer geen gebeurtenissen ontvangt, moet u verwachten dat de uitvoer wordt vertraagd door de waarde van het beleid voor late aankomst. Zie InputPartitionNotProgressing-berichten om te begrijpen waarom.

Ik zie LateInputEvents-berichten in mijn activiteitenlogboek

Deze berichten worden weergegeven om u te informeren dat gebeurtenissen te laat zijn aangekomen en worden verwijderd of aangepast volgens uw configuratie. U kunt deze berichten negeren als u het beleid voor late aankomst op de juiste manier hebt geconfigureerd.

Hier volgt een voorbeeld van dit bericht:

{"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"}

Ik zie InputPartitionNotProgressing in mijn activiteitenlogboek

Uw invoerbron (Event Hub/IoT Hub) heeft waarschijnlijk meerdere partities. Azure Stream Analytics produceert alleen uitvoer voor tijdstempel t1 nadat alle partities die zijn gecombineerd, ten minste op tijd t1 zijn. Stel dat de query wordt gelezen uit een Event Hub-partitie met twee partities. Een van de partities, P1, heeft gebeurtenissen tot tijd t1. De andere partitie, P2, heeft gebeurtenissen tot tijd t1 + x. Vervolgens wordt uitvoer geproduceerd tot tijdstip t1. Maar als er een expliciete Partition by PartitionId-clausule is, gaan beide partities onafhankelijk van elkaar verder.

Wanneer meerdere partities uit dezelfde invoerstroom worden gecombineerd, is de tolerantie voor late aankomst de maximale hoeveelheid tijd die elke partitie wacht op nieuwe gegevens. Als er slechts één partitie in uw Event Hub is, of als IoT Hub geen invoer ontvangt, gaat de tijdlijn voor die partitie niet verder totdat de drempelwaarde voor tolerantie voor late binnenkomst is bereikt. Hierdoor wordt de uitvoer vertraagd door de drempelwaarde voor late aankomsttolerantie. In dergelijke gevallen ziet u mogelijk het volgende bericht:

{"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"}

In dit bericht wordt aangegeven dat ten minste één partitie in uw invoer leeg is en dat de uitvoer wordt vertraagd door de drempelwaarde voor late aankomst. U kunt dit oplossen door het volgende te doen:

  • Zorg ervoor dat alle partities van uw Event Hub/IoT Hub invoer ontvangen.
  • Gebruik Partition by PartitionID-component in uw query.

Waarom zie ik een vertraging van 5 seconden, zelfs als mijn beleid voor late aankomst is ingesteld op 0?

Dit gebeurt wanneer er een invoerpartitie is die nooit invoer heeft ontvangen. U kunt de metrische invoergegevens per partitie controleren om dit gedrag te valideren.

Wanneer een partitie geen gegevens bevat voor meer dan de geconfigureerde drempelwaarde voor late aankomst, wordt de tijdstempel van de toepassing door Stream Analytics uitgebreid, zoals wordt uitgelegd in de sectie overwegingen voor het ordenen van gebeurtenissen. Hiervoor is een geschatte aankomsttijd vereist. Als de partitie nooit gegevens had, schat Stream Analytics de aankomsttijd in als lokale tijd - 5 seconden. Als gevolg hiervan konden partities die nooit gegevens hadden, een watermerkvertraging van 5 seconden weergeven.

Volgende stappen