Asynkron tillståndskontroll för tillståndskänsliga frågor

Kommentar

Finns i Databricks Runtime 10.4 LTS och senare.

Asynkron kontrollpunkt för tillstånd upprätthåller exakt en gång-garantier för strömmande frågor, men kan minska den totala svarstiden för vissa tillståndskänsliga arbetsbelastningar med strukturerad direktuppspelning som är flaskhalsade på tillståndsuppdateringar. Detta uppnås genom att börja bearbeta nästa mikrobatch så snart beräkningen av den tidigare mikrobatchen har slutförts utan att vänta på att tillståndskontrollerna ska slutföras. I följande tabell jämförs kompromisserna för synkrona och asynkrona kontrollpunkter:

Characteristic	Synkrona kontrollpunkter	Asynkron kontrollpunkt
Svarstid	Högre svarstid för varje mikrobatch.	Kortare svarstid eftersom mikrobatch kan överlappa varandra.
Starta om	Snabb återställning som endast den sista batchen måste köras igen.	Högre omstartsfördröjning eftersom mer än på mikrobatch kan behöva köras igen.

Följande är egenskaper för direktuppspelningsjobb som kan dra nytta av asynkrona kontrollpunkter för tillstånd:

• Jobbet har en eller flera tillståndskänsliga åtgärder (t.ex. aggregering, flatMapGroupsWithState, mapGroupsWithState, stream-stream-kopplingar)
• Svarstid för tillståndskontroll är en av de viktigaste bidragsgivarna till den övergripande svarstiden för batchkörning. Den här informationen finns i StreamingQueryProgress-händelserna . Dessa händelser finns även i log4j-loggar på Spark-drivrutinen. Här är ett exempel på förlopp för strömmande frågor och hur du hittar statuskontrollpunktens inverkan på den övergripande svarstiden för batchkörning.

  • {
       "id" : "2e3495a2-de2c-4a6a-9a8e-f6d4c4796f19",
       "runId" : "e36e9d7e-d2b1-4a43-b0b3-e875e767e1fe",
       "...",
       "batchId" : 0,
       "durationMs" : {
         "...",
         "triggerExecution" : 547730,
         "..."
       },
       "stateOperators" : [ {
         "...",
         "commitTimeMs" : 3186626,
         "numShufflePartitions" : 64,
         "..."
       }]
    }
    

  • Svarstidsanalys för tillståndskontroll för ovanstående frågeförloppshändelse

    • Batchvaraktighet (durationMs.triggerDuration) är cirka 547 sekunder.
    • Svarstiden för incheckning av tillståndsarkiv (stateOperations[0].commitTimeMs) är cirka 3 186 sekunder. Svarstiden för incheckning aggregeras mellan aktiviteter som innehåller ett tillståndslager. I det här fallet finns det 64 sådana uppgifter (stateOperators[0].numShufflePartitions).
    • Varje uppgift som innehåller tillståndsoperatorn tog i genomsnitt 50 sek (3 186/64) för kontrollpunkt. Det här är en extra svarstid som har bidragit till batchvaraktigheten. Förutsatt att alla 64 aktiviteter körs samtidigt bidrog kontrollpunktssteget med cirka 9 % (50 sek/547 sek) av batchvaraktigheten. Procentandelen blir ännu högre när de maximala samtidiga uppgifterna är mindre än 64.

Aktivera asynkrona kontrollpunkter för tillstånd

Du måste använda det RocksDB-baserade tillståndsarkivet för asynkrona kontrollpunkter för tillstånd. Ange följande konfigurationer:

spark.conf.set(
  "spark.databricks.streaming.statefulOperator.asyncCheckpoint.enabled",
  "true"
)

spark.conf.set(
  "spark.sql.streaming.stateStore.providerClass",
  "com.databricks.sql.streaming.state.RocksDBStateStoreProvider"
)

Begränsningar och krav för asynkron kontrollpunkt

Kommentar

Automatisk skalning av beräkning har begränsningar för att skala ned klusterstorleken för arbetsbelastningar med strukturerad direktuppspelning. Databricks rekommenderar att du använder Delta Live Tables med förbättrad automatisk skalning för strömmande arbetsbelastningar. Se Optimera klusteranvändningen av Delta Live Tables-pipelines med förbättrad autoskalning.

• Eventuella fel i en asynkron kontrollpunkt i ett eller flera butiker misslyckas med frågan. I synkront kontrollpunktsläge körs kontrollpunkten som en del av uppgiften och Spark försöker utföra aktiviteten flera gånger innan frågan misslyckas. Den här mekanismen finns inte med asynkrona kontrollpunkter för tillstånd. Men med hjälp av Databricks-jobbförsöken kan sådana fel göras om automatiskt.
• Asynkron kontrollpunkt fungerar bäst när platserna för tillståndsarkivet inte ändras mellan mikrobatchkörningar. Storleksändring av kluster i kombination med asynkrona kontrollpunkter för tillstånd kanske inte fungerar bra eftersom tillståndslagerinstansen kan distribueras om när noder läggs till eller tas bort som en del av klusterändringshändelsen.
• Asynkrona kontrollpunkter för tillstånd stöds endast i implementeringen av RocksDB-tillståndslagerprovidern. Standardimplementeringen för minnesinternt tillstånd har inte stöd för det.