Concepten voor controlepunten en opnieuw afspelen in Azure Stream Analytics-taken

Azure Stream Analytics houdt intern statusinformatie bij elke keer dat een taak wordt uitgevoerd, en slaat die status periodiek op bij een checkpoint. Als een taak faalt of wordt geüpgraded, kan Stream Analytics het laatste checkpoint gebruiken om te herstellen. Wanneer de taak het checkpoint niet kan gebruiken, voert hij in plaats daarvan een replay uit waarbij recente invoergebeurtenissen worden verwerkt om zijn status opnieuw op te bouwen.

Dit artikel legt uit hoe checkpoints en herhalingen werken in Azure Stream Analytics en hoe ze de tijd beïnvloeden die een taak nodig heeft om te herstellen.

Staatgebonden querylogica in temporele elementen

Een van de unieke mogelijkheden van een Azure Stream Analytics-taak is het uitvoeren van stateful processing, zoals windowed aggregates, temporele joins en temporele analytische functies. Elk van deze operators bewaart statusgegevens wanneer de taak wordt uitgevoerd. De maximale venstergrootte voor deze query-elementen is zeven dagen.

Het tijdelijke vensterconcept wordt weergegeven in verschillende Stream Analytics-queryelementen:

  • Gevensterde aggregaties (GROUP BY van Tumbling-, Hopping- en Schuifvensters)
  • Tijdgebonden joins (JOIN met DATEDIFF)
  • Tijdelijke analysefuncties (ISFIRST, LAST en LAG met LIMIT DURATION)

Herstel van taken na fout in een knooppunt, inclusief upgrade van het besturingssysteem

Elke keer dat een Stream Analytics-taak draait, schaalt de service deze intern uit om werk te doen over meerdere worker-nodes. De service controleert elke paar minuten de status van elke worker-node, wat helpt bij het herstellen van een storing.

Soms kan een bepaalde worker-node falen, of kan er een upgrade van het besturingssysteem plaatsvinden voor die worker-node. Om automatisch te herstellen, verkrijgt Stream Analytics een nieuwe gezonde node en herstelt de status van de vorige worker-node vanaf het laatst beschikbare checkpoint. Om het werk te hervatten, verwerkt de taak opnieuw een kleine hoeveelheid gegevens om de toestand vanaf het laatste checkpoint te herstellen. Normaal gesproken duurt het herstel slechts een paar minuten. Wanneer je genoeg streamingunits hebt geselecteerd voor de klus, is de herhaling snel afgerond.

In een volledig parallelle query is de tijd die nodig is om bij te komen na een storing van een werkknooppunt evenredig aan:

[de snelheid van de invoer gebeurtenis] x [de lengte van de tussenruimte] / [aantal verwerkingspartities]

Als je ooit aanzienlijke verwerkingsvertraging merkt door een node-storing en OS-upgrade, overweeg dan om de query volledig parallel te maken en de taak op te schalen om meer streaming-units toe te wijzen. Zie Een Azure Stream Analytics-taak schalen om de doorvoer te verhogen voor meer informatie.

Stream Analytics toont momenteel geen rapport wanneer dit soort herstelproces plaatsvindt.

Taakherstel vanaf een service-upgrade

Microsoft werkt af en toe de binaire bestanden bij die de Stream Analytics-taken uitvoeren in de Azure-service. Op die momenten upgrade Microsoft de uitvoerende taken naar een nieuwere versie, en start de taak automatisch opnieuw.

Azure Stream Analytics maakt waar mogelijk gebruik van controlepunten om gegevens te herstellen van de laatste status van het controlepunt. Wanneer Stream Analytics geen interne checkpoints kan gebruiken, herstelt een replay-techniek de volledige status van de streamingquery. Om Stream Analytics-taken exact dezelfde input te laten afspelen, stel je het retentiebeleid voor de brondata in op minstens de venstergroottes in je query. Als dit niet wordt gedaan, kan dit resulteren in onjuiste of gedeeltelijke resultaten tijdens een service-upgrade, omdat Stream Analytics de brongegevens mogelijk niet ver genoeg naar achteren bewaart om de volledige venstergrootte te bevatten.

Over het algemeen is de hoeveelheid benodigde herhaling evenredig met de grootte van het venster vermenigvuldigd met het gemiddelde gebeurtenispercentage. Bijvoorbeeld, voor een taak met een invoersnelheid van 1.000 gebeurtenissen per seconde heeft een venstergrootte groter dan één uur een grote herhalingsgrootte. De service moet mogelijk tot een uur aan data herverwerken om de toestand te initialiseren, zodat volledige en correcte resultaten kunnen worden geproduceerd, wat kan leiden tot vertraagde output (geen output) gedurende een langere periode. Queries zonder vensters of andere temporele operatoren, zoals JOIN of LAG, hebben geen enkele replay.

Inhaaltijd voor terugkijken schatten

Om de duur van de vertraging door een service-upgrade te schatten, volg deze techniek:

  • Laad de input event hub met voldoende data om de grootste venstergrootte in je query te dekken, tegen de verwachte event rate. De tijdstempels van de gebeurtenissen moeten gedurende die periode dicht bij de klok van de muur liggen, alsof het een live invoer is. Als je bijvoorbeeld een venster van drie dagen hebt in je query, stuur dan evenementen drie dagen naar de event hub en blijf evenementen versturen.
  • Begin de baan door Nu als starttijd te gebruiken.
  • Meet de tijd tussen het startmoment en het moment waarop de taak zijn eerste output genereert. Deze tijd is ongeveer de hoeveelheid vertraging die de klus ondervindt tijdens een service-upgrade.
  • Als de vertraging te lang is, probeer dan je taak te partitioneren en het aantal streaming-units te verhogen zodat de belasting over meer knooppunten wordt verspreid. Alternatief kun je overwegen de venstergroottes in je query te verkleinen en verdere aggregatie of andere stateful processing uit te voeren op de output die de Stream Analytics-taak produceert in de downstream-sink (bijvoorbeeld door gebruik te maken van Azure SQL Database).

Overweeg dubbele taken uit te voeren in gekoppelde Azure-regio's voor algemene servicestabiliteit tijdens het upgraden van bedrijfskritieke taken. Zie De betrouwbaarheid van Stream Analytics-taken garanderen tijdens service-updates voor meer informatie.

Herstel van taken na een door de gebruiker geïnitieerde stop en herstart

Om de querysyntaxis van een streamingjob te bewerken, of om invoer en output aan te passen, moet je de job stoppen om de wijzigingen aan te brengen en het taakontwerp te upgraden. In zulke scenario's, wanneer je de streamingtaak stopt en opnieuw start, lijkt het herstelscenario op een service-upgrade.

Een door de gebruiker geïnitieerde taakherstart kan geen checkpointdata gebruiken. Om de vertraging van de output tijdens zo'n herstart te schatten, gebruik je dezelfde procedure die in de vorige sectie wordt beschreven, en pas vergelijkbare mitigatie toe als de vertraging te lang is.

Verwante onderwerpen

Zie de volgende artikelen voor meer informatie over betrouwbaarheid en schaalbaarheid:

  • Last updated on