Asynchronní vytváření kontrolních bodů stavu pro stavové dotazy

Poznámka:

K dispozici ve službě Databricks Runtime 10.4 LTS a vyšší.

Asynchronní vytváření kontrolních bodů stavu udržuje přesně jednou záruky pro dotazy streamování, ale může snížit celkovou latenci některých stavových úloh strukturovaného streamování, které jsou kvůli aktualizacím stavu kritické. Toho dosáhnete tak, že začneme zpracovávat další mikrodávku hned po dokončení výpočtu předchozí mikrodávkové dávky bez čekání na dokončení kontrolního bodu stavu. Následující tabulka porovnává kompromisy pro synchronní a asynchronní kontrolní body:

Charakteristika	Synchronní vytváření kontrolních bodů	Asynchronní vytváření kontrolních bodů
Latence	Vyšší latence pro každou mikrodávku	Nižší latence, protože mikrodávkové dávky se můžou překrývat.
Restartovat	Rychlá obnova, protože je potřeba znovu spustit pouze poslední dávku.	Vyšší zpoždění při restartu, protože může být potřeba znovu spustit více než jednu mikrodávku.

Následující jsou charakteristiky streamovacích úloh, které mohou těžit z asynchronního vytváření kontrolních bodů stavu:

• Úloha má jednu nebo více stavových operací (např. agregace, flatMapGroupsWithState, mapGroupsWithState spojení datových proudů)

• Latence kontrolního bodu stavu je jedním z hlavních přispěvatelů celkové latence dávkového spouštění. Tyto informace najdete v událostech StreamingQueryProgress . Tyto události se také nacházejí v logech log4j u ovladače Spark. Tady je příklad průběhu dotazu v reálném čase a jak zjistit dopad kontrolního bodu stavu na celkovou latenci provedení dávky.

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

  • Analýza latence kontrolního bodu stavu během události pokroku dotazu

    • Doba trvání dávky (durationMs.triggerDuration) je přibližně 547 sekund.
    • Latence potvrzení úložiště stavu (stateOperations[0].commitTimeMs) je přibližně 3 186 sekund. Latence potvrzení se agreguje napříč úlohami obsahujícími úložiště stavu. V tomto případě existuje 64 takových úkolů (stateOperators[0].numShufflePartitions).
    • Každý úkol obsahující operátor stavu vyžadoval průměrně 50 sekund k vytvoření kontrolního bodu (3 186/64). Jedná se o dodatečnou latenci, která přispívá k dávkové době trvání. Za předpokladu, že všechny úkoly běží souběžně, přispěl kontrolní krok přibližně 9 % (50 sekund / 547 sekund) k trvání dávky. Procento je ještě vyšší, pokud je maximální počet souběžných úloh menší než 64.

Povolení asynchronního vytváření kontrolních bodů stavu

K asynchronnímu vytváření kontrolních bodů stavu je nutné použít úložiště stavu RocksDB. Nastavte následující konfigurace:

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

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

Omezení a požadavky pro asynchronní vytváření kontrolních bodů

Poznámka:

Automatické škálování výpočetní kapacity má omezení při snižování velikosti clusteru pro strukturované streamovací úlohy. Databricks doporučuje používat DLT s vylepšeným automatickým škálováním pro úlohy streamování. Viz Optimalizace využití clusterů kanálů DLT s vylepšeným automatickým škálováním.

• Selhání v asynchronním kontrolním bodu v jednom nebo více úložištích způsobí selhání dotazu. V synchronním režimu vytváření kontrolních bodů se kontrolní bod spustí jako součást úlohy a Spark několikrát opakuje úlohu, než dotaz selže. Tento mechanismus není k dispozici s asynchronním kontrolním bodem stavu. Databricks doporučuje používat průběžné úlohy pro automatické opakování při selhání úlohy. Viz průběžné spouštění úloh.
• Asynchronní vytváření kontrolních bodů funguje nejlépe, když se umístění úložiště stavů mezi mikrodávkovými spuštěními nezmění. Změna velikosti clusteru v kombinaci s asynchronním vytvářením kontrolních bodů stavu nemusí dobře fungovat, protože instance úložišť stavů se může znovu distribuovat, protože uzly se přidají nebo odstraní jako součást události změny velikosti clusteru.
• Asynchronní vytváření kontrolních bodů stavu je podporováno pouze v implementaci zprostředkovatele úložiště stavů RocksDB. Výchozí implementace úložiště stavu v paměti ji nepodporuje.