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é obnovení, protože je potřeba znovu spustit pouze poslední dávku.	Zpoždění vyššího restartování, protože více než v mikrodávce může být potřeba znovu spustit.

Tady jsou charakteristiky úlohy streamování, které můžou mít prospěch z asynchronního vytváření kontrolních bodů stavu:

• Úloha má jednu nebo více stavových operací (např. agregace, flatMapGroupsWithState, , mapGroupsWithStatespojení 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 jsou také v protokolech protokolu 4j v ovladači Sparku. Tady je příklad průběhu dotazu streamování a zjištění dopadu kontrolního bodu stavu na celkovou latenci dávkového spouštění.

  • {
       "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 nad událostí průběhu 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 vzal pro kontrolní bod průměr 50 sekund (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 krok kontrolního bodu přibližně 9 % (50 sekund / 547 sekund) doby 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 založeného na 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ích prostředků má omezení vertikálního snížení kapacity clusteru pro úlohy strukturovaného streamování. Databricks doporučuje pro úlohy streamování používat kanály Delta Live Table s rozšířeným automatickým škálováním. Viz Optimalizace využití clusteru kanálů Delta Live Tables s využitím rozšířeného automatického škálování.

• Jakékoli selhání v asynchronním kontrolním bodu v libovolném nebo více úložištích dotaz selže. 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. Při použití opakovaných pokusů o úlohu Databricks je ale možné tyto chyby automaticky opakovat.
• 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.