Kontrollpunkts- och reprisbegrepp i Azure Stream Analytics-jobb

Azure Stream Analytics håller intern statusinformation varje gång ett jobb körs, och sparar periodvis det tillståndet till en kontrollpunkt. Om ett jobb misslyckas eller uppgraderas kan Stream Analytics använda den senaste kontrollpunkten för att återställa. När jobbet inte kan använda checkpointen utför det i stället en omspelning och bearbetar de senaste inmatningshändelserna på nytt för att återskapa sitt tillstånd.

Den här artikeln förklarar hur checkpoints och repriser fungerar i Azure Stream Analytics och hur de påverkar den tid det tar för ett jobb att återhämta sig.

Tillståndskänslig frågelogik i temporala element

En av de unika funktionerna hos ett Azure Stream Analytics-jobb är att utföra tillståndsbaserad bearbetning, såsom fönsteraggregat, temporala joins och temporala analytiska funktioner. Var och en av dessa operatorer behåller tillståndsinformation när jobbet körs. Den maximala fönsterstorleken för dessa frågeelement är sju dagar.

Begreppet temporalfönster visas i flera Stream Analytics-frågeelement:

  • Fönsteraggregeringar (GROUP BY för rullande, hoppande och skjutbara fönster)
  • Temporala kopplingar (JOIN med DATEDIFF)
  • Temporala analysfunktioner (ISFIRST, LAST och LAG med BEGRÄNSAD VARAKTIGHET)

Jobbåterställning från nodfel, inklusive os-uppgradering

Varje gång ett Stream Analytics-jobb körs skalar tjänsten ut det internt för att utföra arbete över flera arbetsnoder. Servicen kontrollerar varje arbetarnods tillstånd var några minuter, vilket hjälper den att återhämta sig om ett fel inträffar.

Ibland kan en viss arbetsnod gå sönder, eller så kan en operativsystemuppgradering ske för den arbetsnoden. För att återställa automatiskt hämtar Stream Analytics en ny frisk nod och återställer tillståndet för den tidigare arbetsnoden från den senaste tillgängliga kontrollpunkten. För att återuppta arbetet spelar jobbet upp en liten mängd data för att återställa tillståndet från den senaste kontrollpunkten. Vanligtvis är återställningsgapet bara några minuter. När du väljer tillräckligt många streamingenheter för uppgiften slutförs reprisen snabbt.

I en fullständigt parallellfråga är den tid det tar att återhämta sig efter ett fel på en arbetsnod proportionellt mot:

[indatahändelsehastigheten] x [mellanrumslängden] / [antal bearbetningspartitioner]

Om du någonsin märker betydande bearbetningsfördröjning på grund av nodfel och OS-uppgradering, överväg att göra frågan helt parallell och skala jobbet för att allokera fler strömningsenheter. Mer information finns i Skala ett Azure Stream Analytics-jobb för att öka dataflödet.

Stream Analytics visar för närvarande ingen rapport när denna typ av återställningsprocess sker.

Jobbåterställning från en tjänstuppgradering

Microsoft uppgraderar ibland binärfilerna som kör Stream Analytics-jobben i Azure-tjänsten. Vid dessa tillfällen uppgraderar Microsoft körjobben till en nyare version, och jobbet startar om automatiskt.

Azure Stream Analytics använder kontrollpunkter där det är möjligt för att återställa data från det senaste kontrollpunktstillståndet. När Stream Analytics inte kan använda interna kontrollpunkter återställer en replay-teknik hela tillståndet för strömningsfrågan. För att låta Stream Analytics-jobb spela upp exakt samma indata, ställ in lagringspolicyn för källdata till minst fönsterstorlekarna i din fråga. Att misslyckas med detta kan resultera i felaktiga eller partiella resultat under en tjänsteuppgradering, eftersom Stream Analytics kanske inte behåller källdata tillräckligt långt bak för att inkludera hela fönsterstorleken.

I allmänhet är mängden repris som behövs proportionell mot fönstrets storlek multiplicerat med den genomsnittliga händelsefrekvensen. Till exempel, för ett jobb med en inmatningshastighet på 1 000 händelser per sekund, har ett fönster som är större än en timme en stor reprisstorlek. Tjänsten kan behöva bearbeta upp till en timmes data för att initiera tillståndet så att den kan producera fullständiga och korrekta resultat, vilket kan orsaka fördröjd utdata (ingen utdata) under en längre tid. Frågor utan fönster eller andra temporala operatorer, som JOIN eller LAG, har noll replay.

Beräkna tiden för att synkronisera uppspelningar

För att uppskatta längden på fördröjningen på grund av en serviceuppgradering, följ denna teknik:

  • Ladda inmatningshändelsehubben med tillräckligt med data för att täcka den största fönsterstorleken i din fråga, vid förväntad händelsehastighet. Händelsernas tidsstämplar bör vara nära väggklockans tid under hela perioden, som om det vore en levande inmatning. Till exempel, om du har ett tredagarsfönster i din fråga, skicka händelser till event hub i tre dagar och fortsätt skicka händelser.
  • Börja jobbet med att använda Nu som starttid.
  • Mät tiden mellan starttiden och när jobbet genererar sitt första resultat. Den här tiden motsvarar ungefär hur mycket försening jobbet får under en serviceuppgradering.
  • Om fördröjningen är för lång, försök att partitionera ditt jobb och öka antalet strömningsenheter så att belastningen sprider sig över fler noder. Alternativt kan du överväga att minska fönsterstorlekarna i din fråga och utföra ytterligare aggregering eller annan tillståndsbaserad bearbetning på de utdata som Stream Analytics-jobbet genererar i nedströmsmottagaren (till exempel med Azure SQL Database).

Överväg att köra duplicerade jobb i länkade Azure-regioner för allmän servicestabilitet vid uppgradering av verksamhetskritiska jobb. Mer information finns i Garantera Stream Analytics-jobbtillförlitlighet under tjänstuppdateringar.

Jobbåterställning från användarinitierad stopp och start

För att redigera frågesyntaxen på ett streamingjobb, eller för att justera indata och utdata, måste du stoppa jobbet för att göra ändringarna och uppgradera jobbdesignen. I sådana scenarier, när du stoppar streamingjobbet och startar det igen, liknar återställningsscenariot en serviceuppgradering.

En användarinitierad jobbomstart kan inte använda checkpoint-data. För att uppskatta fördröjningen av utgången under en sådan omstart, använd samma procedur som föregående avsnitt beskriver och tillämpa liknande åtgärder om fördröjningen är för lång.

Relaterat innehåll

Mer information om tillförlitlighet och skalbarhet finns i följande artiklar:

  • Last updated on