Inzicht in de verwerking van tijd in Azure Stream Analytics

Artikel
07/17/2024

In dit artikel leert u hoe u ontwerpkeuzen maakt om praktische problemen op te lossen in Azure Stream Analytics-taken. Ontwerpbeslissingen voor het verwerken van tijd zijn nauw gerelateerd aan factoren voor het ordenen van gebeurtenissen.

Concepten van achtergrondtijd

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

Gebeurtenistijd: het tijdstip waarop de oorspronkelijke gebeurtenis is opgetreden. Bijvoorbeeld wanneer een bewegende auto op de snelweg een tolhokje nadert.
Verwerkingstijd: de tijd waarop de gebeurtenis het verwerkingssysteem bereikt en wordt waargenomen. Wanneer een tolcelsensor bijvoorbeeld de auto ziet en het computersysteem enkele ogenblikken nodig heeft om de gegevens te verwerken.
Watermerk: Een markering voor gebeurtenistijd die aangeeft tot welk punt gebeurtenissen naar de streamingprocessor zijn binnengegaan. Met watermerken kan het systeem de voortgang van het opnemen van de gebeurtenissen duidelijk aangeven. Door de aard van stromen worden de binnenkomende gebeurtenisgegevens nooit gestopt, 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, correcte 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 overzicht moet worden uitgevoerd voor een foutafhandelingsvoorwaarde, zijn watermerken veilige begin- en eindpunten.

Zie voor meer informatie over dit onderwerp de blogposts van Tyler Akidau Streaming 101 en Streaming 102.

Kies de beste begintijd

Stream Analytics biedt gebruikers twee opties 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 blob-invoer.

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

Toepassingstijd (ook gebeurtenistijd genoemd)

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

Het is belangrijk om een tijdstempel in de nettolading te gebruiken wanneer tijdelijke logica wordt gebruikt 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. TIJDSTEMPEL.

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 als 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 venstergrootte buiten de volgorde.
Wanneer er geen binnenkomende gebeurtenis is, is het watermerk de huidige geschatte aankomsttijd minus het venster voor late aankomsttolerantie. De geschatte aankomsttijd is de tijd die is verstreken vanaf de laatste keer dat een invoergebeurtenis is gezien plus de aankomsttijd van de invoergebeurtenis.

De aankomsttijd kan alleen worden geschat omdat de werkelijke aankomsttijd wordt gegenereerd op de invoer-gebeurtenisbroker, zoals Event Hubs, noch 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 hebt controle over hoe tijdig u de uitvoerresultaten wilt zien. In Azure Portal kunt u op de pagina Gebeurtenisvolgorde van uw Stream Analytics-taak de instelling Out-of-order-gebeurtenissen configureren. Wanneer u deze instelling configureert, kunt u rekening houden met de tolerantie van tijdigheid met tolerantie voor out-of-ordergebeurtenissen in de gebeurtenisstroom.

Het venster voor latere aankomsttolerantie is nodig om watermerken te blijven genereren, zelfs als er geen binnenkomende gebeurtenissen zijn. Soms kan er een periode zijn waarin geen binnenkomende gebeurtenissen binnenkomen, bijvoorbeeld wanneer een gebeurtenisinvoerstroom is geparseerd. Dit probleem wordt verergerd door het gebruik van meerdere partities in de invoergebeurtenisbroker.

Streaminggegevensverwerkingssystemen zonder een venster met vertragingstolerantie kunnen leiden tot vertraagde uitvoer wanneer invoer wordt geparseerd en meerdere partities worden gebruikt.
Het systeemgedrag moet herhaalbaar zijn. Herhaalbaarheid is een belangrijke eigenschap van een streaminggegevensverwerkingssysteem.

Het watermerk is afgeleid van de aankomsttijd en toepassingstijd. Beide worden bewaard in de gebeurtenisbroker en dus herhaalbaar. Wanneer een aankomsttijd wordt geschat bij afwezigheid van gebeurtenissen, wordt in Azure Stream Analytics de geschatte aankomsttijd vermeld voor herhaalbaarheid tijdens het opnieuw afspelen voor herstel na fouten.

Wanneer u ervoor kiest om de aankomsttijd als gebeurtenistijd te gebruiken, hoeft u de out-of-ordertolerantie en late aankomsttolerantie niet te configureren. Omdat de aankomsttijd gegarandeerd toeneemt in de invoer event broker, negeert Azure Stream Analytics de configuraties.

Gebeurtenissen die te laat binnenkomen

Azure Stream Analytics vergelijkt de tijd van de gebeurtenis met de aankomsttijd per definitie van het venster voor late aankomst. Als de tijd van de gebeurtenis zich buiten het tolerantievenster bevindt, kunt u het systeem zo configureren dat de gebeurtenis wordt verwijderd of dat de tijd van de gebeurtenis 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 zo configureren dat deze gebeurtenissen worden verwijderd of dat de tijd van de gebeurtenis wordt aangepast aan de grenswaarde.

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

Tijdvariatie verwerken met substromen

Het heuristische mechanisme voor het genereren van watermerken werkt goed in de meeste gevallen waarin de tijd meestal wordt gesynchroniseerd tussen de verschillende gebeurteniszenders. In het echte leven, met name in veel IoT-scenario's, heeft het systeem echter weinig controle over de klok op de afzenders van gebeurtenissen. De afzenders van gebeurtenissen kunnen allerlei soorten apparaten in het veld zijn, mogelijk 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 genaamd substromen. U kunt substromen in uw taak gebruiken door een taakquery te schrijven die gebruikmaakt van de TIMESTAMP BY-component en het sleutelwoord OVER. Als u de substream wilt aanwijzen, geeft u een sleutelkolomnaam op na het trefwoord OVER , zoals een deviceid, zodat het systeem tijdbeleid toepast op die kolom. Elke substroom krijgt een eigen onafhankelijk watermerk. Dit mechanisme is handig voor het tijdig genereren van uitvoer, wanneer u te maken krijgt met grote klok scheeftrekken 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 substreams gebruikt, past Stream Analytics het venster voor late aankomsttolerantie toe op binnenkomende gebeurtenissen. De tolerantie voor late aankomst bepaalt het maximumbedrag waarmee verschillende substromen van elkaar kunnen verschillen. Als apparaat 1 zich bijvoorbeeld op Timestamp 1 bevindt en Apparaat 2 zich op Timestamp 2 bevindt, is de maximaal late aankomsttolerantie timestamp 2 min tijdstempel 1. De standaardinstelling is 5 seconden en is waarschijnlijk te klein voor apparaten met afwijkende tijdstempels. We raden u aan om met 5 minuten te beginnen en aanpassingen aan te brengen op basis van het patroon van de klokklok van het apparaat.

Vroeg aankomende gebeurtenissen

Mogelijk hebt u een ander concept gezien dat vroeg aankomstvenster wordt genoemd dat lijkt op het tegenovergestelde van het venster voor late aankomsttolerantie. Dit venster is opgelost op 5 minuten en dient een ander doel dan het venster voor late aankomsttolerantie.

Omdat Azure Stream Analytics volledige resultaten garandeert, kunt u alleen de begintijd van de taak 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 de aankomsttijd, moet het systeem de begintijd van de gebeurtenis vertalen naar de aankomsttijd. Het systeem kan vanaf dat moment beginnen met het verwerken van gebeurtenissen in de invoer gebeurtenisbroker. Met de limiet voor het vroegtijdig binnenkomende venster is de vertaling eenvoudig: de begintijd van de gebeurtenis minus het 5 minuten vroege aankomstvenster. Deze berekening betekent ook dat het systeem alle gebeurtenissen verwijdert die worden gezien als een gebeurtenistijd van 5 minuten eerder 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 dat ze dat doen.

Bijwerkingen van tijdtoleranties voor het ordenen van gebeurtenissen

Stream Analytics-taken hebben verschillende opties voor het ordenen van gebeurtenissen. Er kunnen twee worden geconfigureerd in De Azure-portal: de instelling Buiten bestellingsgebeurtenissen (niet-ordertolerantie) en de 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:

Per ongeluk gebeurtenissen verzenden die te vroeg zijn.

Vroege gebeurtenissen mogen niet normaal worden uitgevoerd. Het is mogelijk dat vroege gebeurtenissen naar de uitvoer worden verzonden als de klok van de afzender te snel wordt uitgevoerd. Alle gebeurtenissen die vroeg binnenkomen, worden verwijderd, zodat u geen van deze gebeurtenissen uit de uitvoer ziet.
Oude gebeurtenissen verzenden naar Event Hubs die moeten worden verwerkt door Azure Stream Analytics.

Hoewel oude gebeurtenissen in het begin ongevaarlijk lijken, vanwege de toepassing van de tolerantie voor late aankomst, kunnen de oude gebeurtenissen 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 geschikter voor bijna realtime gebeurtenisverwerkingsscenario's, in plaats van historische scenario's voor gebeurtenisverwerking. In sommige gevallen kunt u de gebeurtenissen instellen die te laat aankomen op de grootst mogelijke waarde (20 dagen) om dit gedrag te omzeilen.
Uitvoer lijkt te zijn vertraagd.

Het eerste watermerk wordt gegenereerd op het berekende tijdstip: de maximale gebeurtenistijd die het systeem tot nu toe heeft waargenomen, minus de venstergrootte buiten de volgorde. Standaard is de out-of-ordertolerantie geconfigureerd op nul (00 minuten en 00 seconden). Wanneer u deze instelt op een hogere, niet-nul-tijdwaarde, wordt de eerste uitvoer van de streamingtaak vertraagd door die tijdwaarde (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 venster voor late aankomsttolerantie. Als invoer gebeurtenissen niet vaak en parserend zijn, kan de uitvoer worden vertraagd door die hoeveelheid tijd. De standaardwaarden voor gebeurtenissen die te laat aankomen, zijn vijf seconden. U zou bijvoorbeeld een vertraging moeten verwachten bij het één voor één verzenden van invoerevenementen. De vertragingen kunnen erger worden wanneer u gebeurtenissen instelt die te laat binnenkomen op een grote waarde.
System.Timestamp-waarde verschilt van de tijd in het veld gebeurtenistijd .

Zoals eerder beschreven, past het systeem de tijd van gebeurtenissen aan door de out-of-ordertolerantie- of late aankomsttolerantievensters. De waarde system.Timestamp van de gebeurtenis wordt aangepast, maar niet het tijdveld van 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 ze normaal hetzelfde.

Metrische gegevens om te observeren

U kunt een aantal tijdtolerantie-effecten 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 aangepaste tijdstempel hebben gekregen. Deze metrische waarde wordt rechtstreeks beïnvloed door de configuratie van de instelling Out-of-ordergebeurtenissen op de pagina Gebeurtenisvolgorde op de taak in Azure Portal.
Gebeurtenissen met late invoer	Geeft het aantal gebeurtenissen aan dat te laat komt vanaf de bron. Deze metrische waarde bevat gebeurtenissen die zijn verwijderd of waarop hun tijdstempel is aangepast. Deze metrische waarde wordt rechtstreeks beïnvloed door de configuratie van de gebeurtenissen die te laat aankomen op de pagina Gebeurtenisvolgorde op de taak in Azure Portal.
Vroege invoerevenementen	Geeft het aantal gebeurtenissen aan dat vroeg afkomstig is van de bron die zijn verwijderd, of dat de tijdstempel is aangepast als deze langer dan 5 minuten eerder zijn.
Watermerkvertraging	Geeft de vertraging aan van de streaminggegevensverwerkingstaak. Zie meer informatie in de volgende sectie.

Details van watermerkvertraging

De meetwaarde watermerkvertraging wordt berekend als de kloktijd van de wandklok van het verwerkingsknooppunt minus het grootste watermerk dat tot nu toe is gezien. Zie het blogbericht over watermerkvertraging voor meer informatie.

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

Inherente verwerkingsvertraging van de streamingpijplijn. Normaal gesproken is deze vertraging nominaal.
In het venster buiten orde tolerantie werd vertraging geïntroduceerd, omdat het watermerk wordt verkleind door de grootte van het tolerantievenster.
Het venster voor late aankomst heeft vertraging geïntroduceerd, omdat het watermerk wordt verkleind door de grootte van het tolerantievenster.
Klok scheeftrekken van het verwerkingsknooppunt dat de metrische waarde genereert.

Er zijn een aantal andere resourcebeperkingen waardoor de streamingpijplijn kan vertragen. De meetwaarde voor watermerkvertraging kan toenemen vanwege:

Er zijn onvoldoende verwerkingsresources in Stream Analytics om het volume van invoer gebeurtenissen te verwerken. Zie Streaming-eenheden begrijpen en aanpassen om resources omhoog te schalen.
Onvoldoende doorvoer binnen de invoergebeurtenisbrokers, zodat ze worden beperkt. Zie Azure Event Hubs-doorvoereenheden automatisch omhoog schalen voor mogelijke oplossingen.
Uitvoersinks worden niet ingericht met voldoende capaciteit, zodat ze worden beperkt. De mogelijke oplossingen variëren sterk op basis van de smaak van de uitvoerservice die wordt gebruikt.

Frequentie van uitvoer gebeurtenis

Azure Stream Analytics maakt gebruik van watermerkvoortgang als enige trigger voor het produceren van uitvoerevenementen. Omdat het watermerk is afgeleid van invoergegevens, kan het worden herhaald tijdens het herstellen van fouten 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 statistische functies zien die zijn gegenereerd op basis van de vensters. Gedeeltelijke aggregaties worden momenteel niet ondersteund in Azure Stream Analytics.

In andere streamingoplossingen kunnen uitvoergebeurtenissen worden gerealiseerd op verschillende triggerpunten, afhankelijk van externe omstandigheden. Het is mogelijk in sommige oplossingen dat de uitvoer gebeurtenissen voor een bepaald tijdvenster meerdere keren kunnen worden gegenereerd. Naarmate de invoerwaarden worden verfijnd, worden de geaggregeerde resultaten nauwkeuriger. Gebeurtenissen kunnen eerst worden gespeculeerd en na verloop van tijd herzien. Als een bepaald apparaat bijvoorbeeld offline is vanuit het netwerk, kan een geschatte waarde door een systeem worden gebruikt. Later komt hetzelfde apparaat online naar het netwerk. Vervolgens kunnen de werkelijke gebeurtenisgegevens worden opgenomen in de invoerstroom. De uitvoerresultaten van de verwerking van dat tijdvenster produceren nauwkeurigere uitvoer.

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 worden weergegeven. U ziet dat de gebeurtenistijd 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	apparaat3
12:19	12:16	device1
12:12	12:17	apparaat3
12:17	12:18	device2
12:20	12:19	device2
12:16	12:21	apparaat3
12:23	12:22	device2
12:22	12:24	device2
12:21	12:27	apparaat3

In deze afbeelding worden de volgende toleranties gebruikt:

Vroege aankomst ramen is 5 minuten
Het venster laat binnenkomt is 5 minuten
Het venster Opnieuw ordenen is 2 minuten

Afbeelding van het watermerk dat door deze gebeurtenissen wordt uitgevoerd:

Belangrijke processen die in de vorige afbeelding worden geïllustreerd:
1. De eerste gebeurtenis (device1) en de tweede gebeurtenis (device2) hebben uitgelijnde tijden en worden zonder aanpassingen verwerkt. Het watermerk wordt voor elke gebeurtenis voortgezet.
2. Wanneer de derde gebeurtenis (apparaat1) wordt verwerkt, wordt de aankomsttijd (12:11) voorafgegaan door de gebeurtenistijd (12:17). De gebeurtenis kwam 6 minuten vroeg aan, dus de gebeurtenis wordt verwijderd vanwege de tolerantie voor vroege aankomst van 5 minuten.
  
  Het watermerk wordt niet voortgezet in dit geval van een vroege gebeurtenis.
3. De vierde gebeurtenis (device3) en de vijfde gebeurtenis (device1) hebben uitgelijnde tijden en worden zonder aanpassing verwerkt. Het watermerk wordt voor elke gebeurtenis voortgezet.
4. Wanneer de zesde gebeurtenis (apparaat3) wordt verwerkt, ligt de aankomsttijd (12:17) en de gebeurtenistijd (12:12) onder het watermerkniveau. De gebeurtenistijd wordt aangepast aan het watermarkeringsniveau (12:17).
5. Wanneer de twaalfde gebeurtenis (apparaat3) wordt verwerkt, is de aankomsttijd (12:27) 6 minuten voor de gebeurtenistijd (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 het watermerk dat wordt voortgezet zonder beleid voor vroege aankomst:

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