Pontos de verificação de estado assíncronos para consultas com estado

nota

Disponível em Databricks Runtime 10.4 LTS e acima.

O checkpointing assíncrono de estado mantém as garantias de exatamente uma vez para consultas de transmissão, mas pode reduzir a latência geral para algumas cargas de trabalho com estado estruturado de transmissão com gargalo nas atualizações de estado. Isso é feito começando a processar as próximas microlotes assim que o cálculo das microlotes anteriores é concluído, sem esperar que o checkpointing de estado seja concluído. A tabela a seguir compara as vantagens e desvantagens do ponto de verificação síncrono e assíncrono:

Característica	Ponto de verificação síncrono	Apontamento de verificação assíncrono
Latência	Maior latência para cada micro-lote.	Latência reduzida, pois os micro-lotes podem se sobrepor.
Reiniciar	Recuperação rápida, pois somente os últimos lotes precisam ser reexecutados.	Maior atraso na reinicialização, pois mais de um microlote pode precisar ser reexecutado.

A seguir, as características do trabalho de transmissão que podem se beneficiar do checkpointing de estado assíncrono:

• Job tem uma ou mais operações stateful (por exemplo, agregação, flatMapGroupsWithState, mapGroupsWithState, transmissão-transmissão join)

• A latência do ponto de verificação do estado é um dos principais fatores que contribuem para a latência geral da execução de lotes. Essas informações podem ser encontradas nos eventos StreamingQueryProgress. Esses eventos também são encontrados nos logs do log4j no driver do Spark. Aqui está um exemplo de progresso de consulta de transmissão e como encontrar o impacto do ponto de verificação de estado na latência geral de execução do lotes.

  JSON

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

  • Análise da latência do ponto de verificação do estado do evento de progresso da consulta acima

    • lotes duração (durationMs.triggerDuration) é de aproximadamente 547 segundos.
    • armazenamento do estado commit latência (stateOperations[0].commitTimeMs) é de cerca de 3,186 segundos. A latência do commit é agregada na tarefa que contém um armazenamento do estado. Nesse caso, há 64 tarefas desse tipo (stateOperators[0].numShufflePartitions).
    • Cada tarefa contendo o operador de estado levou em média 50 segundos (3.186/64) para o ponto de verificação. Esta é uma latência extra que contribui para a duração dos lotes. Assumindo que todas as 64 tarefas estão sendo executadas simultaneamente, a passo do ponto de verificação contribuiu com cerca de 9% (50 segundos / 547 segundos) da duração dos lotes. A porcentagem fica ainda maior quando o máximo de tarefas concorrentes é menor que 64.

Habilitando o ponto de verificação de estado assíncrono

O senhor deve usar o armazenamento do estado baseado emRocksDB para checkpointing de estado assíncrono. Defina as seguintes configurações:

Scala

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

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

Limitações e requisitos para pontos de verificação assíncronos

nota

O dimensionamento automático da computação tem limitações na redução do tamanho do clustering para cargas de trabalho de transmissão estruturada. Databricks recomenda o uso de DLT com autoescala aprimorada para cargas de trabalho de transmissão. Consulte Otimizar a utilização de clustering do pipeline DLT com autoescala aprimorada.

• Qualquer falha em um ponto de verificação assíncrono em uma ou mais lojas falha na consulta. No modo de ponto de verificação síncrono, o ponto de verificação é executado como parte da tarefa e o Spark tenta novamente a tarefa várias vezes antes de falhar na consulta. Esse mecanismo não está presente no ponto de verificação de estado assíncrono. Databricks recomenda o uso do Job contínuo para novas tentativas automáticas em caso de falha do Job. Ver execução do trabalho continuamente.
• O checkpointing assíncrono funciona melhor quando os locais de armazenamento do estado não são alterados entre as execuções de microlotes. O redimensionamento do clustering, em combinação com o checkpointing assíncrono do estado, pode não funcionar bem porque a instância dos armazenamentos de estado pode ser redistribuída à medida que os nós são adicionados ou excluídos como parte do evento de redimensionamento do clustering.
• O checkpointing assíncrono do estado é compatível apenas com a implementação do provedor RocksDB armazenamento do estado. A implementação do default in-memory armazenamento do estado não oferece suporte a isso.