Asynchrone statuscontrolepunten voor stateful query's

Notitie

Beschikbaar in Databricks Runtime 10.4 LTS en hoger.

Controlepunten voor Asynchrone statussen onderhouden exact één keer garanties voor streamingquery's, maar kunnen de algehele latentie verminderen voor sommige stateful workloads van Structured Streaming die in statusupdates zijn opgeslagen. Dit wordt bereikt door de volgende microbatch te verwerken zodra de berekening van de vorige microbatch is voltooid zonder te wachten tot statuscontrolepunten zijn voltooid. In de volgende tabel worden de afwegingen voor synchrone en asynchrone controlepunten vergeleken:

Characteristic	Synchrone controlepunten	Asynchrone controlepunten
Latentie	Hogere latentie voor elke microbatch.	Verminderde latentie omdat microbatches elkaar kunnen overlappen.
Opnieuw starten	Snel herstel omdat alleen de laatste batch opnieuw moet worden uitgevoerd.	Een hogere herstartvertraging omdat er mogelijk meer dan in microbatch opnieuw moet worden uitgevoerd.

Hier volgen de kenmerken van streamingtaken die kunnen profiteren van asynchrone statuscontrolepunten:

• Taak heeft een of meer stateful bewerkingen (bijvoorbeeld aggregatie, flatMapGroupsWithState, mapGroupsWithState, stream-stream joins)
• Statuscontrolepuntlatentie is een van de belangrijkste inzenders voor de algehele latentie van batchuitvoering. Deze informatie vindt u in de StreamingQueryProgress-gebeurtenissen . Deze gebeurtenissen vindt u ook in logboek4j-logboeken in het Spark-stuurprogramma. Hier volgt een voorbeeld van de voortgang van streamingquery's en hoe u de invloed van het statuscontrolepunt kunt vinden op de algehele latentie van batchuitvoering.

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

  • Statuscontrolepuntlatentieanalyse van de bovenstaande queryvoortgangs gebeurtenis

    • De batchduur (durationMs.triggerDuration) bedraagt ongeveer 547 sec.
    • Doorvoerlatentie voor statusopslag (stateOperations[0].commitTimeMs) is ongeveer 3186 sec. Doorvoerlatentie wordt geaggregeerd voor taken die een statusarchief bevatten. In dit geval zijn er 64 dergelijke taken (stateOperators[0].numShufflePartitions).
    • Elke taak met statusoperator duurde gemiddeld 50 sec (3.186/64) voor controlepunt. Dit is een extra latentie die wordt bijgedragen aan de batchduur. Ervan uitgaande dat alle 64 taken gelijktijdig worden uitgevoerd, heeft de controlepuntstap ongeveer 9% (50 sec/ 547 sec) van de batchduur bijgedragen. Het percentage wordt nog hoger wanneer het maximum aantal gelijktijdige taken kleiner is dan 64.

Asynchrone statuscontrolepunten inschakelen

U moet het op RocksDB gebaseerde statusarchief gebruiken voor asynchrone statuscontrolepunten. Stel de volgende configuraties in:

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

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

Beperkingen en vereisten voor asynchrone controlepunten

Notitie

Automatisch schalen van berekeningen heeft beperkingen bij het omlaag schalen van clustergrootte voor structured streaming-workloads. Databricks raadt het gebruik van Delta Live Tables aan met verbeterde automatische schaalaanpassing voor streamingworkloads. Zie Het clustergebruik van Delta Live Tables-pijplijnen optimaliseren met verbeterde automatische schaalaanpassing.

• Elke fout in een asynchroon controlepunt in een of meer winkels mislukt de query. In de synchrone controlepuntmodus wordt het controlepunt uitgevoerd als onderdeel van de taak en voert Spark de taak meerdere keren opnieuw uit voordat de query mislukt. Dit mechanisme is niet aanwezig met asynchrone statuscontrolepunten. Als u de Databricks-taak opnieuw probeert, kunnen dergelijke fouten echter automatisch opnieuw worden geprobeerd.
• Asynchrone controlepunten werken het beste wanneer de locaties van de statusopslag niet worden gewijzigd tussen microbatchuitvoeringen. Het wijzigen van het formaat van het cluster, in combinatie met asynchrone statuscontrolepunten, werkt mogelijk niet goed omdat het exemplaar van de statusarchieven mogelijk opnieuw wordt gedistribueerd wanneer knooppunten worden toegevoegd of verwijderd als onderdeel van de gebeurtenis voor het wijzigen van de grootte van het cluster.
• Asynchrone statuscontrolepunten worden alleen ondersteund in de implementatie van de RocksDB-statusarchiefprovider. De standaard implementatie van het statusarchief in het geheugen biedt geen ondersteuning voor deze opslag.