Share via

Ponto de verificação de estado assíncrono para consultas com estado

  • Artigo

Observação

Disponível no Databricks Runtime 10.4 LTS e versões superiores.

O ponto de verificação de estado assíncrono mantém garantias exatamente uma vez para consultas de streaming, mas pode reduzir a latência geral para algumas cargas de trabalho com estado de fluxo estruturado com gargalo em atualizações de estado. Isso é feito começando a processar o próximo microlote assim que a computação do microlote anterior é concluída, sem aguardar a conclusão do ponto de verificação de estado. 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
Latency Latência mais alta para cada microlote. Latência reduzida, pois os microlotes podem se sobrepor.
Reiniciar Recuperação rápida, pois apenas o último lote precisa ser executado novamente. Atraso de reinicialização maior, pois mais do que no microlote pode precisar ser executado novamente.

Veja a seguir características do trabalho de streaming que podem se beneficiar do ponto de verificação de estado assíncrono:

  • O trabalho tem uma ou mais operações com estado (por exemplo, agregação, flatMapGroupsWithState, mapGroupsWithState, junções de fluxo-fluxo)
  • A latência do ponto de verificação de estado é um dos principais colaboradores para a latência geral de execução em lote. Essas informações podem ser encontradas nos eventos StreamingQueryProgress. Esses eventos também são encontrados em logs log4j no driver do Spark. Aqui está um exemplo de progresso da consulta de streaming e como encontrar o impacto do ponto de verificação de estado na latência geral da execução em lote. 
    • {
   "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 de estado do evento de progresso da consulta acima

      • A duração do lote (durationMs.triggerDuration) é de cerca de 547 segundos.
      • A latência de commit do armazenamento de estado (stateOperations[0].commitTimeMs) é de cerca de 3.186 segundos. A latência de commit é agregada entre tarefas que contêm um armazenamento de estado. Nesse caso, há 64 tarefas desse tipo (stateOperators[0].numShufflePartitions).
      • Cada tarefa que contém o operador de estado levou uma média de 50 segundos (3.186/64) para o ponto de verificação. Essa é uma latência extra que é contribuído para a duração do lote. Supondo que todas as 64 tarefas estão sendo executadas simultaneamente, a etapa de ponto de verificação contribuiu em torno de 9% (50 segundos/547 segundos) da duração do lote. O percentual fica ainda maior quando o máximo de tarefas simultâneas é menor que 64.

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

Você deve usar o repositório de estado baseado em RocksDB para ponto de verificação de estado assíncrono. 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 o ponto de verificação assíncrono

Observação

O dimensionamento automático de computação tem limitação ao reduzir o tamanho do cluster para cargas de Fluxo Estruturado. O Databricks recomenda usar o Delta Live Tables com o Dimensionamento Automático Aprimorado para cargas de trabalho de fluxo. Consulte Otimizar a utilização de cluster dos pipelines do Delta Live Tables com Dimensionamento Automático Avançado.

  • Qualquer falha em um ponto de verificação assíncrono em qualquer um ou mais armazenamentos 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 recupera 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. No entanto, usando as recuperações de trabalho do Databricks, essas falhas podem ser automaticamente recuperadas.
  • O ponto de verificação assíncrono funciona melhor quando os locais de armazenamento de estado não são alterados entre execuções de microlote. O redimensionamento de cluster, 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, pois os nós são adicionados ou excluídos como parte do evento de redimensionamento do cluster.
  • O ponto de verificação de estado assíncrono só tem suporte na implementação do provedor de armazenamento de estado do RocksDB. A implementação padrão do armazenamento de estado na memória não dá suporte a ela.