Controlepunten en concepten voor opnieuw afspelen in Azure Stream Analytics-taken
In dit artikel worden de concepten voor interne controlepunten en herhalingen in Azure Stream Analytics beschreven, en de impact die deze hebben op taakherstel. Telkens wanneer een Stream Analytics-taak wordt uitgevoerd, wordt de statusinformatie intern bijgehouden. Deze statusgegevens worden periodiek opgeslagen in een controlepunt. In sommige scenario's worden de controlepuntgegevens gebruikt voor taakherstel als er een taakfout of upgrade optreedt. In andere omstandigheden kan het controlepunt niet worden gebruikt voor herstel en is een herhaling noodzakelijk.
Stateful querylogica in tijdelijke elementen
Een van de unieke mogelijkheden van een Azure Stream Analytics-taak is het uitvoeren van stateful verwerking, zoals aggregaties in vensters, tijdelijke joins en tijdelijke analysefuncties. Elk van deze operators bewaart statusinformatie 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:
Vensteraggregaties (GROUP BY van Tumbling-, Hopping- en Sliding-vensters)
Tijdelijke joins (JOIN met DATEDIFF)
Tijdelijke analytische functies (ISFIRST, LAST en LAG met LIMIT DURATION)
Taakherstel na knooppuntfout, inclusief upgrade van het besturingssysteem
Telkens wanneer een Stream Analytics-taak wordt uitgevoerd, wordt deze intern uitgeschaald om werk te doen op meerdere werkknooppunten. De status van elk werkknooppunt wordt om de paar minuten gecontroleerd, zodat het systeem kan worden hersteld als er een fout optreedt.
Soms kan een bepaald werkknooppunt mislukken of kan er een upgrade van het besturingssysteem worden uitgevoerd voor dat werkknooppunt. Als u automatisch wilt herstellen, krijgt Stream Analytics een nieuw knooppunt dat in orde is en wordt de status van het eerdere werkrolknooppunt hersteld vanaf het meest recent beschikbare controlepunt. Als u het werk wilt hervatten, is een kleine hoeveelheid herhaling nodig om de status te herstellen vanaf het moment dat het controlepunt wordt genomen. Meestal is de herstelkloof slechts enkele minuten. Wanneer er voldoende streaming-eenheden zijn geselecteerd voor de taak, moet de herhaling snel worden voltooid.
In een volledig parallelle query is de tijd die nodig is om het in te halen na een fout in een werkknooppunt evenredig met:
[de invoer gebeurtenissnelheid] x [de lengte van de tussenruimte] / [aantal verwerkingspartities]
Als u ooit een aanzienlijke verwerkingsvertraging ziet vanwege een fout in het knooppunt en de upgrade van het besturingssysteem, kunt u overwegen de query volledig parallel te maken en de taak te schalen om meer streaming-eenheden toe te wijzen. Zie Een Azure Stream Analytics-taak schalen om de doorvoer te verhogen voor meer informatie.
Current Stream Analytics geeft geen rapport weer wanneer dit soort herstelproces plaatsvindt.
Taakherstel na een service-upgrade
Microsoft voert af en toe een upgrade uit van de binaire bestanden die de Stream Analytics-taken uitvoeren in de Azure-service. Op deze momenten worden actieve taken van gebruikers bijgewerkt naar een nieuwere versie en wordt de taak automatisch opnieuw gestart.
Azure Stream Analytics maakt waar mogelijk gebruik van controlepunten om gegevens te herstellen vanaf de laatste controlepuntstatus. In scenario's waarin interne controlepunten niet kunnen worden gebruikt, wordt de status van de streamingquery volledig hersteld met behulp van een herhalingstechniek. Als u wilt toestaan dat Stream Analytics-taken exact dezelfde invoer als voorheen opnieuw kunnen afspelen, is het belangrijk om het bewaarbeleid voor de brongegevens in te stellen op ten minste de venstergrootten in uw query. Als u dit niet doet, kan dit leiden tot onjuiste of gedeeltelijke resultaten tijdens de service-upgrade, omdat de brongegevens mogelijk niet ver genoeg worden bewaard om de volledige venstergrootte op te nemen.
Over het algemeen is de benodigde hoeveelheid herhaling evenredig met de grootte van het venster vermenigvuldigd met het gemiddelde gebeurtenispercentage. Voor een taak met een invoersnelheid van 1000 gebeurtenissen per seconde wordt een venstergrootte van meer dan één uur beschouwd als een grote herhalingsgrootte. Mogelijk moet er maximaal één uur aan gegevens opnieuw worden verwerkt om de status te initialiseren, zodat deze volledige en juiste resultaten kan produceren, wat kan leiden tot vertraagde uitvoer (geen uitvoer) gedurende een langere periode. Query's zonder vensters of andere tijdelijke operatoren, zoals JOIN of LAG, hebben geen herhaling.
Inhaaltijd van herhaling schatten
Als u de lengte van de vertraging als gevolg van een service-upgrade wilt schatten, kunt u deze techniek volgen:
Laad de Event Hubs-invoer met voldoende gegevens om de grootste venstergrootte in uw query te dekken, met de verwachte gebeurtenissnelheid. Het tijdstempel van de gebeurtenissen moet gedurende die periode dicht bij de tijd van de wandklok liggen, alsof het een live-invoerfeed is. Als uw query bijvoorbeeld een venster van 3 dagen bevat, verzendt u gedurende drie dagen gebeurtenissen naar Event Hubs en gaat u door met het verzenden van gebeurtenissen.
Start de taak met Nu als begintijd.
Meet de tijd tussen de begintijd en het moment waarop de eerste uitvoer wordt gegenereerd. De tijd is ruw hoeveel vertraging de taak zou oplopen tijdens een service-upgrade.
Als de vertraging te lang is, probeert u uw taak te partitioneren en het aantal SU's te verhogen, zodat de belasting wordt verdeeld over meer knooppunten. U kunt ook de venstergrootten in uw query verkleinen en verdere aggregatie of andere stateful verwerking uitvoeren op de uitvoer die wordt geproduceerd door de Stream Analytics-taak in de downstream-sink (bijvoorbeeld met behulp van Azure SQL Database).
Voor algemene problemen met de servicestabiliteit tijdens het upgraden van bedrijfskritieke taken kunt u overwegen dubbele taken uit te voeren in gekoppelde Azure-regio's. Zie Betrouwbaarheid van Stream Analytics-taken garanderen tijdens service-updates voor meer informatie.
Taakherstel van een door de gebruiker geïnitieerde stop en start
Als u de querysyntaxis voor een streamingtaak wilt bewerken of de invoer en uitvoer wilt aanpassen, moet de taak worden gestopt om de wijzigingen aan te brengen en het taakontwerp te upgraden. In dergelijke scenario's, wanneer een gebruiker de streamingtaak stopt en opnieuw start, is het herstelscenario vergelijkbaar met een service-upgrade.
Controlepuntgegevens kunnen niet worden gebruikt voor het opnieuw opstarten van een door de gebruiker geïnitieerde taak. Als u de vertraging van de uitvoer tijdens een dergelijke herstart wilt schatten, gebruikt u dezelfde procedure als beschreven in de vorige sectie en past u een vergelijkbare beperking toe als de vertraging te lang is.
Volgende stappen
Zie de volgende artikelen voor meer informatie over betrouwbaarheid en schaalbaarheid: