Kontrollpunkts- och reprisbegrepp i Azure Stream Analytics-jobb
Den här artikeln beskriver de interna kontrollpunkts- och återspelningsbegreppen i Azure Stream Analytics och hur de påverkar jobbåterställning. Varje gång ett Stream Analytics-jobb körs underhålls tillståndsinformationen internt. Tillståndsinformationen sparas regelbundet i en kontrollpunkt. I vissa scenarier används kontrollpunktsinformationen för jobbåterställning om ett jobb misslyckas eller uppgraderas. I andra fall kan kontrollpunkten inte användas för återställning och en repris krävs.
Tillståndskänslig frågelogik i temporala element
En av de unika funktionerna i Azure Stream Analytics-jobbet är att utföra tillståndskänslig bearbetning, till exempel fönsterade aggregat, temporala kopplingar och temporala analysfunktioner. 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önsterade aggregat (GROUP BY av rullande, hoppande och glidande fönster)
Temporala kopplingar (JOIN med DATEDIFF)
Temporala analysfunktioner (ISFIRST, LAST och LAG med LIMIT DURATION)
Jobbåterställning från nodfel, inklusive operativsystemuppgradering
Varje gång ett Stream Analytics-jobb körs skalas det ut internt för att fungera över flera arbetsnoder. Varje arbetsnods tillstånd är kontrollpunkt med några minuters mellanrum, vilket hjälper systemet att återställas om ett fel inträffar.
Ibland kan en viss arbetsnod misslyckas, eller så kan en uppgradering av operativsystemet ske för den arbetsnoden. För att återställa automatiskt hämtar Stream Analytics en ny felfri nod och den tidigare arbetsnodens tillstånd återställs från den senaste tillgängliga kontrollpunkten. För att återuppta arbetet krävs en liten mängd repris för att återställa tillståndet från den tidpunkt då kontrollpunkten tas. Vanligtvis är återställningsgapet bara några minuter. När tillräckligt många strömningsenheter har valts för jobbet bör reprisen slutföras snabbt.
I en helt parallell fråga är den tid det tar att komma ikapp efter ett arbetsnodfel proportionellt mot:
[indatahändelsehastigheten] x [mellanrumslängden] / [antal bearbetningspartitioner]
Om du någonsin ser betydande bearbetningsfördröjning på grund av nodfel och uppgradering av operativsystemet kan du överväga 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.
Aktuell Stream Analytics visar ingen rapport när den här typen av återställningsprocess pågår.
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 uppgraderas användarnas jobb som körs till en nyare version och jobbet startas 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. I scenarier där interna kontrollpunkter inte kan användas återställs strömningsfrågans tillstånd helt med hjälp av en återspelningsteknik. För att Stream Analytics-jobb ska kunna spela upp exakt samma indata från tidigare är det viktigt att ange kvarhållningsprincipen för källdata till minst fönsterstorlekarna i frågan. Om du inte gör det kan det resultera i felaktiga eller partiella resultat under tjänstuppgradering, eftersom källdata kanske inte behålls tillräckligt långt tillbaka för att inkludera den fullständiga fönsterstorleken.
I allmänhet är mängden repris som behövs proportionell mot fönstrets storlek multiplicerat med den genomsnittliga händelsefrekvensen. För ett jobb med en indatafrekvens på 1 000 händelser per sekund anses till exempel en fönsterstorlek som är större än en timme ha en stor uppspelningsstorlek. Upp till en timmes data kan behöva bearbetas på nytt för att initiera tillståndet så att det kan ge fullständiga och korrekta resultat, vilket kan orsaka fördröjda utdata (inga utdata) under en längre period. Frågor utan fönster eller andra temporala operatorer, som JOIN eller LAG, skulle ha noll repris.
Beräkna återspelningens upphämtningstid
Om du vill beräkna fördröjningens längd på grund av en tjänstuppgradering kan du följa den här tekniken:
Läs in indatahändelsehubbarna med tillräckligt med data för att täcka den största fönsterstorleken i frågan, med förväntad händelsefrekvens. Händelsernas tidsstämpel bör vara nära väggklockans tid under den tidsperioden, som om det vore ett live-indataflöde. Om du till exempel har ett 3-dagarsfönster i frågan skickar du händelser till Event Hubs i tre dagar och fortsätter att skicka händelser.
Starta jobbet med Now som starttid.
Mät tiden mellan starttiden och när de första utdata genereras. Tiden är grov hur lång fördröjning jobbet skulle medföra under en tjänstuppgradering.
Om fördröjningen är för lång försöker du partitionera jobbet och öka antalet SU:er, så att belastningen sprids ut till fler noder. Du kan också överväga att minska fönsterstorlekarna i frågan och utföra ytterligare aggregering eller annan tillståndskänslig bearbetning av utdata som genereras av Stream Analytics-jobbet i den underordnade mottagaren (till exempel med hjälp av Azure SQL Database).
Överväg att köra duplicerade jobb i kopplade Azure-regioner för allmän stabilitet vid uppgradering av verksamhetskritiska jobb. Mer information finns i Garantera Stream Analytics-jobbtillförlitlighet under tjänstuppdateringar.
Jobbåterställning från en användare initierad stoppa och starta
Om du vill redigera frågesyntaxen för ett direktuppspelningsjobb eller justera indata och utdata måste jobbet stoppas för att göra ändringarna och uppgradera jobbdesignen. I sådana scenarier, när en användare stoppar strömningsjobbet och startar det igen, liknar återställningsscenariot tjänstuppgradering.
Kontrollpunktsdata kan inte användas för att starta om ett användarinitierat jobb. Om du vill beräkna fördröjningen av utdata under en sådan omstart använder du samma procedur som beskrivs i föregående avsnitt och tillämpar liknande åtgärd om fördröjningen är för lång.
Nästa steg
Mer information om tillförlitlighet och skalbarhet finns i följande artiklar: