Inzicht in tijdafhandeling in Azure Stream Analytics

In dit artikel leert u hoe u ontwerpkeuzes maakt om praktische problemen met de verwerking van problemen in Azure Stream Analytics-taken op te lossen. Beslissingen over het verwerken van tijdsontwerpen zijn nauw gerelateerd aan factoren voor het ordenen van gebeurtenissen.

Concepten voor achtergrondtijd

Om de discussie beter te kaderen, gaan we enkele achtergrondconcepten definiëren:

  • Gebeurtenistijd: de tijd 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 tolstandsensor 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. Watermerken geven het systeem duidelijke voortgang aan bij het opnemen van de gebeurtenissen. Door de aard van stromen stopt de binnenkomende gebeurtenisgegevens nooit, dus watermerken geven de voortgang aan op een bepaald punt in de stroom.

    Het watermerkconcept is belangrijk. Met watermerken kan Stream Analytics bepalen wanneer het systeem volledige, juiste 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 bepaalde foutafhandelingsvoorwaarde, zijn watermerken veilige begin- en eindpunten.

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

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

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 per toepassingstijd wilt verwerken, gebruikt u de tijdstempel per component in de SELECT-query. Als de tijdstempel afwezig is, worden gebeurtenissen verwerkt op 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 van de out-of-ordertolerantie.

  • 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 van 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 voor twee andere doeleinden dan het genereren van watermerken:

  1. Het systeem genereert tijdig resultaten met of zonder binnenkomende gebeurtenissen.

    U hebt controle over hoe tijdig u de uitvoerresultaten wilt zien. In de Azure Portal kunt u op de pagina Gebeurtenisvolgorde van uw Stream Analytics-taak de instelling Voor niet-order gebeurtenissen configureren. Wanneer u deze instelling configureert, moet u rekening houden met de tolerantie van time-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 voor tolerantie voor late aankomst kunnen last hebben van vertraagde uitvoer wanneer invoer wordt geparseerd en meerdere partities worden gebruikt.

  2. 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 kunnen dus worden herhaald. Wanneer een aankomsttijd wordt geschat bij het ontbreken van gebeurtenissen, wordt in Azure Stream Analytics de geschatte aankomsttijd voor herhaalbaarheid geregistreerd tijdens het opnieuw afspelen voor herstel van fouten.

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

Gebeurtenissen die te laat aankomen

Bij elke binnenkomende gebeurtenis vergelijkt Azure Stream Analytics de tijd van de gebeurtenis met de aankomsttijd. Als de gebeurtenistijd buiten het tolerantievenster valt, kunt u het systeem zo configureren dat de gebeurtenis wordt verwijderd of de tijd van de gebeurtenis wordt aangepast aan de tolerantie.

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 de tijd van de gebeurtenis wordt aangepast aan de watermerkwaarde.

Als onderdeel van de aanpassing wordt het System.Timestamp van de gebeurtenis ingesteld op de nieuwe waarde, maar het veld gebeurtenistijd zelf wordt niet gewijzigd. Deze aanpassing is de enige situatie waarin de System.Timestamp van een gebeurtenis kan verschillen van de waarde in het veld gebeurtenistijd en onverwachte resultaten kan veroorzaken.

Tijdvariatie afhandelen met substreams

Het heuristische mechanisme voor het genereren van watermerken werkt in de meeste gevallen goed, waarbij de tijd meestal wordt gesynchroniseerd tussen de verschillende afzenders van gebeurtenissen. 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 gebeurteniszenders 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 substreams. U kunt substreams in uw taak gebruiken door een taakquery te schrijven die gebruikmaakt van de TIMESTAMP BY-component en het trefwoord 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 substream krijgt een eigen onafhankelijk watermerk. Dit mechanisme is handig om tijdige uitvoergeneratie mogelijk te maken bij het omgaan met grote klok scheeftrekken of netwerkvertragingen tussen gebeurteniszenders.

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

Wanneer u substreams gebruikt, past Stream Analytics het venster late aankomsttolerantie toe op binnenkomende gebeurtenissen. De tolerantie voor late aankomst bepaalt het maximumbedrag waarmee verschillende substromen van elkaar kunnen worden gescheiden. Als apparaat 1 bijvoorbeeld timestamp 1 is en Apparaat 2 op Timestamp 2 staat, is de maximaal late aankomsttolerantie Timestamp 2 min Timestamp 1. De standaardinstelling is vijf 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 scheeftrekkenpatroon van de klok 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 punt beginnen met het verwerken van gebeurtenissen in de invoer-gebeurtenisbroker. Met de limiet voor vroeg aankomend venster is de vertaling eenvoudig: de begintijd van de gebeurtenis minus het eerste aankomstvenster van 5 minuten. Deze berekening betekent ook dat het systeem alle gebeurtenissen die worden gezien als een gebeurtenistijd van 5 minuten eerder dan de aankomsttijd, wordt verwijderd. De meetwaarde voor vroege invoergebeurtenissen wordt 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 gebeurtenisvolgorde

Stream Analytics-taken hebben verschillende opties voor gebeurtenisvolgorde . Er kunnen twee worden geconfigureerd in de Azure Portal: de instelling Voor niet-ordergebeurtenissen (out-of-ordertolerantie) en de gebeurtenissen die te laat aankomen (verdraagzaamheid 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:

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

  2. Oude gebeurtenissen verzenden naar Event Hubs om te worden verwerkt door Azure Stream Analytics.

    Hoewel oude gebeurtenissen in eerste instantie onschadelijk kunnen lijken, vanwege de toepassing van de verdraagzaamheid 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 gebeurtenisverwerkingsscenario's. In sommige gevallen kunt u de gebeurtenissen instellen die te laat aankomen op de grootst mogelijke waarde (20 dagen) om dit gedrag te omzeilen.

  3. Uitvoer lijkt te worden 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.

  4. 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 sparse 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 wanneer invoerevenementen één voor één worden verzonden. De vertragingen kunnen erger worden wanneer u gebeurtenissen instelt die te laat binnenkomen op een grote waarde.

  5. 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 veld gebeurtenistijd . 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 gesproken 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
Niet-ordergebeurtenissen 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 Voor niet-ordergebeurtenissen op de pagina Gebeurtenisvolgorde op de taak in de Azure Portal.
Gebeurtenissen met late invoer Geeft het aantal gebeurtenissen aan dat te laat komt van de bron. Deze metrische waarde bevat gebeurtenissen die zijn verwijderd of hun tijdstempel zijn 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 het Azure Portal.
Vroege invoerevenementen Geeft het aantal gebeurtenissen aan dat vroeg van de bron komt die zijn verwijderd, of dat de tijdstempel is aangepast als ze langer dan 5 minuten vroeg zijn.
Watermerkvertraging Geeft de vertraging van de streaminggegevensverwerkingstaak aan. Zie meer informatie in de volgende sectie.

Details van watermerkvertraging

De meetwaarde Voor watermerkvertraging wordt berekend als de kloktijd van de wand 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:

  1. Inherente verwerkingsvertraging van de streaming-pijplijn. Normaal gesproken is deze vertraging nominaal.

  2. Het out-of-ordertolerantievenster heeft vertraging geïntroduceerd, omdat het watermerk wordt verkleind door de grootte van het tolerantievenster.

  3. Het venster voor late aankomst heeft vertraging geïntroduceerd, omdat het watermerk wordt verkleind door de grootte van het tolerantievenster.

  4. Klok scheeftrekken van het verwerkingsknooppunt dat de metrische waarde genereert.

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

  1. Er zijn onvoldoende verwerkingsresources in Stream Analytics om het volume van invoerevenementen te verwerken. Zie Streaming-eenheden begrijpen en aanpassen om resources op te schalen.

  2. Onvoldoende doorvoer binnen de invoergebeurtenisbrokers, zodat ze worden beperkt. Zie Automatisch omhoog schalen Azure Event Hubs doorvoereenheden voor mogelijke oplossingen.

  3. Uitvoersinks zijn niet ingericht met voldoende capaciteit, dus 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 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 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 statistische 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 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 voordoen.

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:

  • De ramen voor vroege aankomst zijn 5 minuten
  • Het venster voor late aankomst is 5 minuten
  • Het venster Opnieuw ordenen is 2 minuten
  1. Afbeelding van de voortgang van het watermerk via deze gebeurtenissen:

    Afbeelding van azure Stream Analytics-watermerk

    Belangrijke processen die in de vorige afbeelding worden geïllustreerd:

    1. De eerste gebeurtenis (device1) en de tweede gebeurtenis (device2) zijn uitgelijnd en worden zonder aanpassingen verwerkt. Het watermerk wordt voor elke gebeurtenis voortgezet.

    2. Wanneer de derde gebeurtenis (device1) wordt verwerkt, wordt de aankomsttijd (12:11) voorafgegaan door de tijd van de gebeurtenis (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 (apparaat3) 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, bevindt de aankomsttijd (12:17) en de gebeurtenistijd (12:12) zich 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), dat zich boven het watermerk (12:21) bevindt, zodat er geen verdere aanpassing wordt toegepast.

  2. Tweede afbeelding van het watermerk dat vordert zonder beleid voor vroege aankomst:

    Afbeelding van het watermerk van Azure Stream Analytics niet vroeg beleid

    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 tijd 12:11) niet in dit scenario wordt verwijderd en het watermerk wordt verhoogd naar 12:15. De vierde gebeurtenistijd wordt als gevolg hiervan 7 minuten vooruitgesteld (12:08 tot 12:15).

  3. In de laatste afbeelding worden substreams gebruikt (OVER de DeviceId). Meerdere watermerken worden bijgehouden, één per stroom. Er zijn minder gebeurtenissen waarbij hun tijden als gevolg hiervan zijn aangepast.

    Afbeelding van watermerk in Azure Stream Analytics-substreams

Volgende stappen