Ponto de verificação de estado assíncrono para querycom estado

Observação

Disponível em Databricks Runtime 10.4 LTS e acima.

O ponto de verificação de estado assíncrono mantém garantias exatamente uma vez para query de transmissão, mas pode reduzir a latência geral para algumas cargas de trabalho de estado estruturadas de transmissão com gargalo nas atualizações de estado. Isso é feito começando a processar os próximos microlotes assim que a computação dos microlotes anteriores for concluída, sem esperar que o ponto de verificação de estado seja concluído. A tabela a seguir compara as compensações para pontos de verificação síncronos e assíncronos:

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

A seguir estão as características Job de transmissão que podem se beneficiar do ponto de verificação de estado assíncrono:

• Job tem uma ou mais operações com estado (por exemplo, agregação, flatMapGroupsWithState, mapGroupsWithState, junções de transmissão-transmissão)

• A latência do ponto de verificação do estado é um dos principais contribuintes para a latência geral da execução dos lotes. Esta informação pode ser encontrada nos eventos StreamingQueryProgress . Esses eventos também são encontrados nos logs log4j no driver Spark. Aqui está um exemplo do progresso query de transmissão e como encontrar o impacto do ponto de verificação de estado na latência geral de execução dos lotes.

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

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

    • a duração dos lotes (durationMs.triggerDuration) é de cerca de 547 segundos.

    • a latência commit do armazenamento do estado (stateOperations[0].commitTimeMs) é de cerca de 3.186 segundos. a latência commit é agregada entre as tarefas que contêm um armazenamento do estado. Neste caso, existem 64 dessas tarefas (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.

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

Você deve usar o armazenamento do estado baseado em RocksDB para verificação de estado assíncrona. Defina as seguintes configurações:

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 ponto de verificação assíncrono

Observação

O dimensionamento automático de computação tem limitações ao reduzir o tamanho do cluster para cargas de trabalho de streaming estruturado. A Databricks recomenda usar Delta Live Tables com Autoscale aprimorado para cargas de trabalho de streaming. Consulte Otimize a utilização do cluster dos pipelines do Delta Live Tables com escalonamento automático aprimorado.

• 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 micro-lotes. o redimensionamento clusters , em combinação com o ponto de verificação de estado assíncrono, pode não funcionar bem porque a instância de armazenamentos de estado pode ser redistribuída à medida que os nós são adicionados ou excluídos como parte do evento de redimensionamento clusters .

• O ponto de verificação de estado assíncrono é suportado apenas na implementação do provedor RocksDB armazenamento do estado. A implementação default do armazenamento do estado em memória não o suporta.