Inzicht in tijdsafhandeling in Azure Stream Analytics

Artikel
01/23/2024

In dit artikel leert u hoe u ontwerpkeuzes kunt maken om praktische problemen met het verwerken van tijd in Azure Stream Analytics-taken op te lossen. Ontwerpbeslissingen voor tijdsafhandeling zijn nauw gerelateerd aan factoren voor gebeurtenisvolgorde.

Concepten van achtergrondtijd

Laten we enkele achtergrondconcepten definiëren om de discussie beter te kaderen:

Gebeurtenistijd: de tijd waarop de oorspronkelijke gebeurtenis heeft plaatsgevonden. Bijvoorbeeld wanneer een rijdende auto op de snelweg een tolhuisje nadert.
Verwerkingstijd: de tijd waarop de gebeurtenis het verwerkingssysteem bereikt en wordt waargenomen. Wanneer een tolpoortsensor bijvoorbeeld de auto ziet en het computersysteem even nodig heeft om de gegevens te verwerken.
Watermerk: een gebeurtenistijdmarkering die aangeeft tot op welk punt gebeurtenissen zijn binnengekomen bij de streamingprocessor. Met watermerken kan het systeem een duidelijke voortgang bij het opnemen van de gebeurtenissen aangeven. Door de aard van stromen stoppen de binnenkomende gebeurtenisgegevens nooit, zodat watermerken de voortgang naar een bepaald punt in de stroom aangeven.

Het watermerkconcept is belangrijk. Met watermerken kan Stream Analytics bepalen wanneer het systeem volledige, corrigerende en herhaalbare resultaten kan produceren die niet hoeven te worden ingetrokken. De verwerking kan op een voorspelbare en herhaalbare manier worden uitgevoerd. Als er bijvoorbeeld een hertelling moet worden uitgevoerd voor een foutafhandelingsvoorwaarde, zijn watermerken veilige begin- en eindpunten.

Zie de blogberichten van Tyler Akidau Streaming 101 en Streaming 102 voor aanvullende informatie over dit onderwerp.

Kies de beste begintijd

Stream Analytics biedt gebruikers twee keuzes voor het kiezen van gebeurtenistijd: aankomsttijd en toepassingstijd.

Aankomsttijd

De aankomsttijd wordt toegewezen aan de invoerbron wanneer de gebeurtenis de bron bereikt. U hebt toegang tot de aankomsttijd met behulp van de eigenschap EventEnqueuedUtcTime voor Event Hubs-invoer, de eigenschap IoTHub.EnqueuedTime voor IoT Hub invoer en de eigenschap BlobProperties.LastModified voor blobinvoer.

De aankomsttijd wordt standaard gebruikt en wordt het beste gebruikt voor scenario's voor gegevensarchivering waarbij tijdelijke logica niet nodig is.

Toepassingstijd (ook wel gebeurtenistijd genoemd)

Toepassingstijd wordt toegewezen wanneer de gebeurtenis wordt gegenereerd en maakt deel uit van de nettolading van de gebeurtenis. Als u gebeurtenissen per toepassingstijd wilt verwerken, gebruikt u de component Timestamp by in de SELECT-query. Als Tijdstempel op afwezig is, worden gebeurtenissen verwerkt op de aankomsttijd.

Het is belangrijk om een tijdstempel in de nettolading te gebruiken wanneer er tijdelijke logica bij betrokken is om rekening te houden met vertragingen in het bronsysteem of in het netwerk. De tijd die aan een gebeurtenis is toegewezen, is beschikbaar in SYSTEM. TIMESTAMP.

Hoe de tijd vordert in Azure Stream Analytics

Wanneer u toepassingstijd gebruikt, is de voortgang van de tijd gebaseerd op de binnenkomende gebeurtenissen. Het is moeilijk voor het stroomverwerkingssysteem om te weten of er geen gebeurtenissen zijn of dat gebeurtenissen zijn vertraagd. Daarom genereert Azure Stream Analytics heuristische watermerken op de volgende manieren voor elke invoerpartitie:

Wanneer er een binnenkomende gebeurtenis is, is het watermerk de grootste gebeurtenis die Stream Analytics tot nu toe heeft gezien, minus de grootte van de out-of-order-tolerantievensters.
Wanneer er geen binnenkomende gebeurtenis is, is het watermerk de huidige geschatte aankomsttijd minus het tolerantievenster voor late aankomst. De geschatte aankomsttijd is de tijd die is verstreken vanaf de laatste keer dat een invoergebeurtenis is gezien plus de aankomsttijd van die invoergebeurtenis.

De aankomsttijd kan alleen worden geschat omdat de werkelijke aankomsttijd wordt gegenereerd op de gebeurtenisbroker voor invoer, zoals Event Hubs, of op de Azure Stream Analytics-VM die de gebeurtenissen verwerkt.

Het ontwerp dient twee andere doeleinden dan het genereren van watermerken:

Het systeem genereert resultaten tijdig met of zonder binnenkomende gebeurtenissen.

U kunt bepalen hoe tijdig u de uitvoerresultaten wilt zien. In de Azure Portal, op de pagina Gebeurtenisvolgorde van uw Stream Analytics-taak, kunt u de instelling Niet-bestelde gebeurtenissen configureren. Wanneer u deze instelling configureert, moet u rekening houden met de afweging van tijdigheid met tolerantie van niet-op-volgordegebeurtenissen in de gebeurtenisstroom.

Het tolerantievenster voor late aankomst is nodig om watermerken te blijven genereren, zelfs als er geen binnenkomende gebeurtenissen zijn. Soms kan er een periode zijn waarin er geen binnenkomende gebeurtenissen binnenkomen, zoals wanneer een gebeurtenisinvoerstroom schaars is. Dit probleem wordt verergerd door het gebruik van meerdere partities in de invoergebeurtenisbroker.

Systemen voor streaminggegevensverwerking zonder een tolerantievenster voor late aankomst kunnen last hebben van vertraagde uitvoer wanneer invoer schaars is en meerdere partities worden gebruikt.
Het systeemgedrag moet herhaalbaar zijn. Herhaalbaarheid is een belangrijke eigenschap van een systeem voor streaminggegevensverwerking.

Het watermerk is afgeleid van de aankomsttijd en toepassingstijd. Beide worden opgeslagen in de gebeurtenisbroker en kunnen dus worden herhaald. Wanneer een geschatte aankomsttijd wordt geschat als er geen gebeurtenissen zijn, wordt in Azure Stream Analytics de geschatte aankomsttijd vastgelegd voor herhaalbaarheid tijdens het opnieuw afspelen voor foutherstel.

Wanneer u ervoor kiest om de aankomsttijd als de tijd van de gebeurtenis te gebruiken, hoeft u de tolerantie voor buiten-order en tolerantie voor late aankomst niet te configureren. Omdat de aankomsttijd gegarandeerd toeneemt in de invoer-gebeurtenisbroker, worden de configuraties in Azure Stream Analytics gewoon genegeerd.

Te laat binnenkomende gebeurtenissen

Volgens de definitie van het tolerantievenster voor late aankomst vergelijkt Azure Stream Analytics voor elke binnenkomende gebeurtenis de tijd van de gebeurtenis met de aankomsttijd. Als de tijd van de gebeurtenis zich buiten het tolerantievenster bevindt, kunt u het systeem configureren om de gebeurtenis te verwijderen of de tijd van de gebeurtenis aan te passen zodat deze binnen de tolerantie valt.

Zodra watermerken zijn gegenereerd, kan de service mogelijk gebeurtenissen ontvangen met een gebeurtenistijd die lager is dan het watermerk. U kunt de service configureren om deze gebeurtenissen te verwijderen of de tijd van de gebeurtenis aan te passen aan de waarde van het watermerk.

Als onderdeel van de aanpassing wordt system.timestamp van de gebeurtenis ingesteld op de nieuwe waarde, maar het gebeurtenistijdveld zelf wordt niet gewijzigd. Deze aanpassing is de enige situatie waarin de System.Timestamp van een gebeurtenis kan afwijken van de waarde in het gebeurtenistijdveld en onverwachte resultaten kan genereren.

Tijdvariatie verwerken met substromen

Het beschreven mechanisme voor het genereren van heuristische watermerken werkt goed in de meeste gevallen waarbij de tijd meestal wordt gesynchroniseerd tussen de verschillende afzenders van de gebeurtenis. In de praktijk, met name in veel IoT-scenario's, heeft het systeem echter weinig controle over de klok op de afzenders van gebeurtenissen. De afzenders van de gebeurtenis kunnen allerlei apparaten in het veld zijn, bijvoorbeeld op verschillende versies van hardware en software.

In plaats van een watermerk te gebruiken dat globaal is voor alle gebeurtenissen in een invoerpartitie, heeft Stream Analytics een ander mechanisme met de naam substreams. U kunt substromen in uw taak gebruiken door een taakquery te schrijven die gebruikmaakt van de component TIMESTAMP BY en het trefwoord OVER. Als u de substroom wilt aanwijzen, geeft u een sleutelkolomnaam op na het trefwoord OVER , zoals een deviceid, zodat het systeem tijdbeleid toepast op basis van die kolom. Elke substroom krijgt een eigen onafhankelijk watermerk. Dit mechanisme is handig om het tijdig genereren van uitvoer mogelijk te maken bij het omgaan met grote klokscheefheid of netwerkvertragingen tussen afzenders van gebeurtenissen.

Substreams zijn een unieke oplossing die wordt geleverd door Azure Stream Analytics en worden niet aangeboden door andere systemen voor streaminggegevensverwerking.

Wanneer u substromen gebruikt, past Stream Analytics het tolerantievenster voor late aankomst toe op binnenkomende gebeurtenissen. De tolerantie voor late aankomst bepaalt de maximale hoeveelheid waarmee verschillende substromen van elkaar kunnen worden gescheiden. Als apparaat 1 zich bijvoorbeeld op Tijdstempel 1 bevindt en Apparaat 2 op Tijdstempel 2, is de tolerantie voor maximaal late aankomst Tijdstempel 2 minus Tijdstempel 1. De standaardinstelling is 5 seconden en is waarschijnlijk te klein voor apparaten met afwijkende tijdstempels. We raden u aan met 5 minuten te beginnen en aanpassingen aan te brengen op basis van het scheeftrekken van de klok van het apparaat.

Vroeg binnenkomende gebeurtenissen

Misschien hebt u een ander concept met de naam venster voor vroege aankomst opgemerkt, dat lijkt op het tegenovergestelde van het tolerantievenster voor late aankomst. Dit venster is vastgezet op 5 minuten en dient een ander doel dan het tolerantievenster voor late aankomst.

Omdat Azure Stream Analytics volledige resultaten garandeert, kunt u de begintijd van de taak alleen opgeven als de eerste uitvoertijd van de taak, niet de invoertijd. De begintijd van de taak is vereist, zodat het volledige venster wordt verwerkt, niet alleen vanuit het midden van het venster.

Stream Analytics leidt de begintijd af van de queryspecificatie. Omdat de invoergebeurtenisbroker echter alleen wordt geïndexeerd op aankomsttijd, moet het systeem de begingebeurtenistijd omzetten in de aankomsttijd. Het systeem kan beginnen met het verwerken van gebeurtenissen vanaf dat punt in de invoer-gebeurtenisbroker. Met de limiet voor het vroeg binnenkomende venster is de vertaling eenvoudig: de starttijd van de gebeurtenis minus het venster van 5 minuten vroeg aankomen. Deze berekening betekent ook dat het systeem alle gebeurtenissen verwijdert die worden gezien als een gebeurtenistijd die 5 minuten eerder is dan de aankomsttijd. De metrische gegevens voor vroege invoergebeurtenissen worden verhoogd wanneer de gebeurtenissen worden verwijderd.

Dit concept wordt gebruikt om ervoor te zorgen dat de verwerking herhaalbaar is, ongeacht waar u begint met uitvoeren. Zonder een dergelijk mechanisme zou het niet mogelijk zijn om herhaalbaarheid te garanderen, zoals veel andere streamingsystemen beweren.

Neveneffecten van tijdtoleranties voor gebeurtenisvolgorde

Stream Analytics-taken hebben verschillende opties voor het ordenen van gebeurtenissen. Er kunnen twee worden geconfigureerd in de Azure Portal: de instelling Niet-ordergebeurtenissen (tolerantie buiten orde) en de instelling Gebeurtenissen die te laat aankomen (tolerantie voor late aankomst). De tolerantie voor vroege aankomst is vast en kan niet worden aangepast. Deze tijdbeleidsregels worden door Stream Analytics gebruikt om sterke garanties te bieden. Deze instellingen hebben echter soms onverwachte gevolgen:

Het per ongeluk verzenden van gebeurtenissen die te vroeg zijn.

Vroege gebeurtenissen moeten niet normaal worden uitgevoerd. Het is echter mogelijk dat vroege gebeurtenissen naar de uitvoer worden verzonden als de klok van de afzender te snel loopt. Alle eerder binnenkomende gebeurtenissen worden verwijderd, zodat u geen van deze gebeurtenissen in de uitvoer ziet.
Het verzenden van oude gebeurtenissen naar Event Hubs om te worden verwerkt door Azure Stream Analytics.

Hoewel oude gebeurtenissen in eerste instantie onschadelijk kunnen lijken, kunnen de oude gebeurtenissen vanwege de toepassing van de tolerantie voor late aankomst worden verwijderd. Als de gebeurtenissen te oud zijn, wordt de waarde System.Timestamp gewijzigd tijdens het opnemen van gebeurtenissen. Vanwege dit gedrag is Azure Stream Analytics momenteel meer geschikt voor scenario's voor het verwerken van gebeurtenissen in bijna realtime, in plaats van scenario's voor het verwerken van historische gebeurtenissen. U kunt de gebeurtenissen die te laat aankomen instellen op de grootst mogelijke waarde (20 dagen) om dit gedrag in sommige gevallen te omzeilen.
Uitvoer lijkt vertraagd te zijn.

Het eerste watermerk wordt gegenereerd op het berekende tijdstip: de maximale gebeurtenistijd die het systeem tot nu toe heeft waargenomen, minus de venstergrootte van de out-of-order-tolerantie. Standaard is de out-of-order tolerantie geconfigureerd op nul (00 minuten en 00 seconden). Wanneer u deze instelt op een hogere tijdwaarde dan nul, wordt de eerste uitvoer van de streamingtaak vertraagd door die waarde van tijd (of hoger) vanwege de eerste watermerktijd die wordt berekend.
Invoer is sparse.

Wanneer er geen invoer in een bepaalde partitie is, wordt de watermerktijd berekend als de aankomsttijd minus het tolerantievenster voor late aankomst. Als invoerevenementen onregelmatig en sparse zijn, kan de uitvoer hierdoor worden vertraagd. De standaardwaarde voor gebeurtenissen die te laat binnenkomen , is 5 seconden. U moet bijvoorbeeld enige vertraging verwachten bij het één voor één verzenden van invoerevenementen. De vertragingen kunnen erger worden wanneer u Gebeurtenissen die te laat binnenkomen instelt op een grote waarde.
De waarde van System.Timestamp verschilt van de tijd in het gebeurtenistijdveld .

Zoals eerder beschreven, past het systeem de tijd van gebeurtenissen aan op basis van de tolerantievensters Buiten-Of-Order of Late Arrival. De System.Timestamp-waarde van de gebeurtenis wordt aangepast, maar niet het tijdveld voor de gebeurtenis. Dit kan worden gebruikt om te bepalen voor welke gebeurtenissen de tijdstempels zijn aangepast. Als het systeem de tijdstempel heeft gewijzigd vanwege een van de toleranties, zijn deze normaal gesproken hetzelfde.

Te observeren metrische gegevens

U kunt een aantal tijdtolerantieeffecten voor gebeurtenisvolgorde bekijken via metrische gegevens van Azure Stream Analytics-taken. De volgende metrische gegevens zijn relevant:

Metrisch	Beschrijving
Out-of-Order-gebeurtenissen	Geeft het aantal gebeurtenissen aan dat buiten de volgorde is ontvangen, die zijn verwijderd of een aangepast tijdstempel hebben gekregen. Deze metrische waarde wordt rechtstreeks beïnvloed door de configuratie van de instelling Niet-bestelde gebeurtenissen op de pagina Gebeurtenisvolgorde voor de taak in de Azure Portal.
Late invoer gebeurtenissen	Hiermee wordt het aantal gebeurtenissen aangegeven dat te laat arriveert vanuit de bron. Dit metrische gegeven omvat gebeurtenissen die zijn verwijderd of waarvoor de tijdstempel is aangepast. Deze metrische waarde wordt rechtstreeks beïnvloed door de configuratie van de instelling Gebeurtenissen die te laat binnenkomen op de pagina Gebeurtenisvolgorde op de taak in de Azure Portal.
Vroege invoerevenementen	Geeft het aantal gebeurtenissen aan dat vroeg vanuit de bron arriveert en die zijn verwijderd of dat hun tijdstempel is aangepast als ze langer dan 5 minuten te vroeg zijn.
Watermerkvertraging	Hiermee wordt de vertraging van de verwerkingstaak voor streaminggegevens aangegeven. Zie de volgende sectie voor meer informatie.

Details van watermerkvertraging

De meetwaarde Watermerkvertraging wordt berekend als de wandkloktijd van het verwerkingsknooppunt minus het grootste watermerk dat tot nu toe is gezien. Zie het blogbericht over het uitstellen van watermerken voor meer informatie.

Er kunnen verschillende redenen zijn waarom deze metrische waarde groter is dan 0 onder normale werking:

Inherente verwerkingsvertraging van de streaming-pijplijn. Normaal gesproken is deze vertraging nominaal.
Het out-of-order tolerantievenster heeft vertraging geïntroduceerd, omdat het watermerk wordt verminderd door de grootte van het tolerantievenster.
Het venster voor late aankomst introduceerde vertraging, omdat watermerk wordt verminderd door de grootte van het tolerantievenster.
Klokverschil van het verwerkingsknooppunt dat de metrische waarde genereert.

Er zijn een aantal andere resourcebeperkingen die ervoor kunnen zorgen dat de streaming-pijplijn trager wordt. De meetwaarde voor watermerkvertraging kan stijgen als gevolg van:

Er zijn onvoldoende verwerkingsresources in Stream Analytics om het volume van invoerevenementen af te handelen. Zie Streaming-eenheden begrijpen en aanpassen om resources omhoog te schalen.
Er is onvoldoende doorvoer binnen de invoergebeurtenisbrokers, dus deze worden beperkt. Zie Automatisch omhoog schalen Azure Event Hubs doorvoereenheden voor mogelijke oplossingen.
Uitvoersinks zijn niet ingericht met voldoende capaciteit, dus ze worden beperkt. De mogelijke oplossingen variëren sterk, afhankelijk van de smaak van de uitvoerservice die wordt gebruikt.

Frequentie van uitvoer gebeurtenis

Azure Stream Analytics maakt gebruik van watermerkvoortgang als enige trigger om uitvoerevenementen te produceren. Omdat het watermerk is afgeleid van invoergegevens, kan het worden herhaald tijdens foutherstel en ook bij door de gebruiker geïnitieerde herverwerking. Wanneer u vensteraggregaties gebruikt, produceert de service alleen uitvoer aan het einde van de vensters. In sommige gevallen willen gebruikers mogelijk gedeeltelijke aggregaties zien die zijn gegenereerd op basis van de vensters. Gedeeltelijke aggregaties worden momenteel niet ondersteund in Azure Stream Analytics.

In andere streamingoplossingen kunnen uitvoergebeurtenissen op verschillende triggerpunten worden gerealiseerd, afhankelijk van externe omstandigheden. In sommige oplossingen is het mogelijk dat de uitvoer gebeurtenissen voor een bepaald tijdvenster meerdere keren worden gegenereerd. Naarmate de invoerwaarden worden verfijnd, worden de samengevoegde resultaten nauwkeuriger. Gebeurtenissen kunnen in eerste instantie worden gespeculeerd en in de loop van de tijd worden herzien. Wanneer een bepaald apparaat bijvoorbeeld offline is vanaf het netwerk, kan een geschatte waarde worden gebruikt door een systeem. Later komt hetzelfde apparaat online op het netwerk. Vervolgens kunnen de werkelijke gebeurtenisgegevens worden opgenomen in de invoerstroom. De uitvoer is het resultaat van de verwerking van dat tijdvenster dat nauwkeurigere uitvoer produceert.

Geïllustreerd voorbeeld van watermerken

In de volgende afbeeldingen ziet u hoe watermerken zich in verschillende omstandigheden ontwikkelen.

In deze tabel ziet u de voorbeeldgegevens die hieronder in een grafiek worden weergegeven. U ziet dat de tijd van de gebeurtenis en de aankomsttijd variëren, soms overeenkomend en soms niet.

Tijdstip van gebeurtenis	Aankomsttijd	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

In deze afbeelding worden de volgende toleranties gebruikt:

Vroege aankomst windows is 5 minuten
Het venster voor late aankomst is 5 minuten
Het venster Opnieuw ordenen is 2 minuten

Afbeelding van de voortgang van het watermerk door deze gebeurtenissen:

Belangrijke processen die in de voorgaande afbeelding worden geïllustreerd:
1. De eerste gebeurtenis (apparaat1) en de tweede gebeurtenis (apparaat2) hebben uitgelijnde tijden en worden zonder aanpassingen verwerkt. De voortgang van het watermerk bij elke gebeurtenis.
2. Wanneer de derde gebeurtenis (apparaat1) wordt verwerkt, gaat de aankomsttijd (12:11) vooraf aan de tijd van de gebeurtenis (12:17). De gebeurtenis is 6 minuten te vroeg aangekomen, dus de gebeurtenis wordt verwijderd vanwege de tolerantie voor vroege aankomst van 5 minuten.
  
  Het watermerk maakt geen voortgang in dit geval van een vroege gebeurtenis.
3. De vierde gebeurtenis (apparaat3) en de vijfde gebeurtenis (apparaat1) hebben de tijden uitgelijnd en worden zonder aanpassing verwerkt. De voortgang van het watermerk bij elke gebeurtenis.
4. Wanneer de zesde gebeurtenis (apparaat3) wordt verwerkt, ligt de aankomsttijd (12:17) en de tijd van de gebeurtenis (12:12) onder het watermerkniveau. De tijd van de gebeurtenis wordt aangepast aan het niveau van de watermarkering (12:17).
5. Wanneer de twaalfde gebeurtenis (apparaat3) is verwerkt, ligt de aankomsttijd (12:27) 6 minuten voor op de tijd van de gebeurtenis (12:21). Het beleid voor late aankomst wordt toegepast. De tijd van de gebeurtenis wordt aangepast (12:22), die zich boven het watermerk (12:21) bevindt, zodat er geen verdere aanpassing wordt toegepast.
Tweede afbeelding van de voortgang van een watermerk zonder beleid voor vroegtijdige aankomst:

In dit voorbeeld wordt geen beleid voor vroegtijdige aankomst toegepast. Uitbijters die vroeg aankomen, verhogen het watermerk aanzienlijk. U ziet dat de derde gebeurtenis (deviceId1 op tijdstip 12:11) in dit scenario niet wordt verwijderd en het watermerk wordt verhoogd naar 12:15. De vierde gebeurtenistijd wordt hierdoor 7 minuten vooruit (12:08 tot 12:15) aangepast.
In de laatste afbeelding worden substromen gebruikt (OVER de DeviceId). Er worden meerdere watermerken bijgehouden, één per stroom. Er zijn minder gebeurtenissen met als gevolg dat hun tijden zijn aangepast.