Considerações de produção para o Streaming Estruturado

Execute cargas de trabalho de Streaming Estruturado em produção como Jobs do Lakeflow programados ou pipelines do Lakeflow. Veja Lakeflow Jobs e Spark Declarative Pipelines no Lakeflow.

Use pipelines Lakeflow para gerenciar orquestração, checkpoints e recuperação. Use pipelines sem servidor para gerenciar e escalar automaticamente os recursos de computação. Consulte Configurar um pipeline sem servidor.

Configure cargas de trabalho de streaming que rodem como Lakeflow Jobs da seguinte forma:

  • Remova o código desnecessário dos notebooks que retornariam resultados, como display e count.
  • Não execute cargas de trabalho de streaming estruturado usando computação de uso geral. Sempre agende fluxos como Trabalhos do Lakeflow usando a computação de trabalhos.
  • Agendar Trabalhos do Lakeflow usando Continuous modo. Isso se refere ao recurso de agendamento de Trabalhos no Azure Databricks, e não ao intervalo de gatilho do Streaming Estruturado.
  • Não ative o autoscaling para trabalhos de Structured Streaming. O autoescalonamento tem limitações ao reduzir o tamanho do cluster para cargas de trabalho em streaming.

Algumas cargas de trabalho se beneficiam do seguinte:

Para notebooks e jobs em computação serverless, apenas Trigger.AvailableNow() e Trigger.Once() são suportados. O Databricks recomenda Trigger.AvailableNow(). Consulte Limitações de streaming.

Para transmissão contínua em computação sem servidor, use os pipelines do Lakeflow no modo contínuo. Confira Modo de pipeline disparado versus contínuo.

Reduzir a latência do streaming operacional

Cargas de trabalho de streaming operacionais ingerem, transformam e atuam sobre dados quase em tempo real. Exemplos comuns incluem detecção de fraude, detecção de anomalias, personalização e monitoramento e alerta em tempo real, onde o processamento atrasado afeta diretamente os resultados do negócio. Baixa latência para essas cargas de trabalho normalmente significa dezenas a centenas de milissegundos, embora muitas equipes definam acordos de nível de serviço (SLAs) na faixa de segundos para considerar a variabilidade em percentis mais altos.

Escolha um modo de processamento baseado nos requisitos de latência da sua carga de trabalho:

  • Use o modo em tempo real (RTM) para cargas de trabalho operacionais com latência inferior a um segundo. O RTM é até 100 vezes mais rápido que o modo micro-batch, com latência de ponta a ponta tão baixa quanto cinco milissegundos.
  • Use o modo micro-batch para pipelines analíticos e cargas de trabalho ETL com requisitos de latência medidos em segundos ou minutos.

Veja conceitos de modo em tempo real.

Quando o modo em tempo real não se encaixa na sua carga de trabalho, as seguintes melhores práticas reduzem a latência para o Streaming Estruturado em microlote:

  • Modo de saída: use o modo de atualização compatível com os operadores de consulta e o coletor. O modo de atualização emite linhas atualizadas após cada gatilho e continua a atualizá-las até que a marca-d’água expire; portanto, torne seu destino downstream idempotente para lidar com resultados atualizados. Use o modo de anexação para cargas de trabalho que não são compatíveis com o modo de atualização, como junções stream-stream, ou quando você pode descartar dados que chegam com atraso. Não use o modo completo para baixa latência. Consulte Selecionar um modo de saída para o Streaming Estruturado.
  • Gatilho: use um gatilho processingTime com intervalo 0, que inicia o próximo microlote assim que o microlote anterior termina e há novos dados disponíveis. Isso proporciona a menor latência em microlote, mas aumenta os custos da API de armazenamento em nuvem. Não use AvailableNow, Once, nem Continuous para cargas de trabalho operacionais. Confira Configurar intervalos de gatilho do Fluxo Estruturado.
  • Marca-d'água: defina a marca-d'água tempo suficiente para incluir os dados que chegam tarde e que sua carga de trabalho não deve descartar. A marca d’água controla por quanto tempo a consulta aceita dados com carimbo de tempo de evento fora de ordem antes de descartá-los e remover o estado da memória; assim, uma marca d’água curta demais descarta silenciosamente registros válidos que chegaram com atraso. Dentro dessa restrição, um watermark mais curto reduz a latência e mantém menos estado, enquanto um watermark mais longo tolera mais dados tardios à custa de maior latência e mais estado. Um múltiplo pequeno do seu SLA de latência, como 2x, é um ponto de partida razoável para o ajuste. Confira Aplicar marcas d’água para controlar os limites do processamento de dados.
  • Fontes e sumidouros: Leia de fontes de baixa latência, como barramentos de mensagens (Apache Kafka, Amazon Kinesis, Apache Pulsar ou Google Cloud Pub/Sub) ou altere os feeds de dados das tabelas Delta Lake e Apache Iceberg. Grave em coletores de baixa latência e alta taxa de transferência, como barramentos de mensagens, bancos de dados operacionais ou coletores foreach. Projete as operações de saída para que sejam idempotentes, de modo que os consumidores posteriores lidem com duplicatas e dados recebidos com atraso.
  • Estado e checkpointing: Para consultas stateful, use o estoque de estados do RocksDB, que é necessário tanto para checkpoint de changelog quanto para checkpoint de estado assíncrono. Ative o ponto de verificação do registro de alterações para persistir apenas alterações incrementais de estado. Quando o checkpoint de estado for o gargalo na duração do lote, ative o checkpoint assíncrono de estado para sobrepor as gravações de checkpoint ao próximo microlote, após revisar suas limitações de recuperação de falhas e redimensionamento do cluster. Dê a cada consulta seu próprio diretório de checkpoint em armazenamento durável na nuvem. Veja Configure o repositório de estado do RocksDB no Azure Databricks, Criação assíncrona de pontos de verificação de estado para consultas com estado e Pontos de verificação do Structured Streaming.
  • Gerenciamento de offset: Para reduzir a latência da verificação de offsets em fluxos contínuos, ative o rastreamento assíncrono do progresso, que atualiza os logs de offsets e de commits sem bloquear o processamento de dados. Não é compatível com os acionadores AvailableNow ou Once. Consulte o acompanhamento de progresso assíncrono.
  • Saltos de armazenamento: Mantenha a computação dentro de um único pipeline de streaming sempre que possível. Dividir a lógica entre múltiplos trabalhos ou pipelines adiciona saltos de armazenamento que aumentam a latência.

Projetar cargas de trabalho de streaming para esperar falhas

O Databricks recomenda que você sempre configure trabalhos de streaming para reiniciar automaticamente em caso de falha. Algumas funcionalidades, incluindo a evolução do esquema, exigem que as cargas de trabalho do Structured Streaming tentem novamente automaticamente. Consulte Configurar trabalhos de Streaming Estruturado para reiniciar consultas de streaming em caso de falha.

Algumas operações, como foreachBatch, fornecem garantias de pelo menos uma vez em vez de exatamente uma vez. Para essas operações, verifique se o pipeline de processamento é idempotente. Consulte Usar o foreachBatch para gravar nos coletores de dados arbitrários.

Observação

Quando uma consulta é reiniciada, o micro-lote planejado durante a execução anterior é processado. Se a tarefa falhou devido a um erro de falta de memória ou você cancelou manualmente uma tarefa devido a um microlote excessivamente grande, talvez seja necessário escalar a computação para processar o microlote de forma bem-sucedida.

Se você alterar as configurações entre as execuções, essas configurações se aplicarão ao primeiro novo lote planejado. Consulte Recuperar após alterações em uma consulta de Streaming Estruturado.

Quando uma tarefa é repetida

Você pode agendar várias tarefas como parte de um trabalho Azure Databricks. Ao configurar um trabalho usando o gatilho contínuo, você não pode definir dependências entre tarefas.

Você pode optar por planejar vários fluxos em um único trabalho usando uma das seguintes abordagens:

  • Várias tarefas: defina um trabalho com várias tarefas que executem cargas de trabalho de streaming usando o gatilho contínuo.
  • Várias consultas: defina várias consultas de streaming no código-fonte para uma única tarefa.

Você também pode combinar essas estratégias. A tabela a seguir compara essas abordagens.

Estratégia Várias tarefas Várias consultas
Como a computação é compartilhada? O Databricks recomenda o dimensionamento adequado dos recursos de computação para cada tarefa de streaming. Opcionalmente, você pode compartilhar a computação entre tarefas. Todas as consultas compartilham a mesma computação. Você pode, opcionalmente, atribuir consultas a pools de agendador.
Como as repetições são tratadas? Uma tarefa com falha tenta novamente sozinha apenas se modo de repetição da tarefa estiver Em caso de falha. Caso contrário, todas as tarefas devem falhar antes que o job seja reiniciado. A tarefa será repetida se alguma consulta falhar.

Warning

Se uma tarefa de streaming em um trabalho contínuo multitarefa falhar enquanto outras tarefas continuam rodando, o trabalho não inicia uma nova execução até que todas as outras tarefas também falhem. O stream falhado pode permanecer fora do ar enquanto o job parece saudável. Para reduzir esse risco, defina o modo de retentativa de tarefa como Em caso de falha e configure notificações para falhas de tarefa. Alternativamente, execute cada stream crítico como uma tarefa própria. Consulte o tratamento de falhas para trabalhos contínuos.

Para obter mais detalhes sobre como trabalhar com várias tarefas ou consultas, consulte Executar várias consultas de Streaming Estruturado no mesmo cluster.

Configurar processos de Streaming Estruturado para reiniciar as consultas de streaming de dados em caso de falha

O Databricks recomenda que você configure todas as cargas de trabalho de streaming usando o gatilho contínuo. Consulte Executar trabalhos continuamente.

O gatilho contínuo tem o seguinte comportamento por padrão:

  • Impede mais de uma execução simultânea do trabalho.
  • Inicia uma nova execução quando uma execução anterior falha.
  • Usa retirada exponencial para repetições.

O Databricks recomenda sempre usar a computação de trabalhos em vez da computação para todas as finalidades ao agendar fluxos de trabalho. Em caso de falha e repetição do trabalho, novos recursos de computação são implantados.

Observação

O Databricks recomenda que você não use streamingQuery.awaitTermination() ou spark.streams.awaitAnyTermination(). Veja quando usar awaitTermination().

Quando usar awaitTermination()

streamingQuery.awaitTermination() e spark.streams.awaitAnyTermination() bloqueiam o thread atual até que uma consulta de streaming seja encerrada. Se usar essas funções depende do ambiente de execução.

Para o Lakeflow Jobs, não use streamingQuery.awaitTermination() ou spark.streams.awaitAnyTermination(). Essas funções não são necessárias porque o serviço Jobs impede automaticamente a execução quando uma consulta de streaming está ativa. Ambas as funções impedem que as células do notebook sejam preenchidas e impedem que o serviço de Trabalhos acompanhe a consulta de streaming, o que interrompe as métricas de backlog e as notificações de trabalho.

Use awaitTermination() nos seguintes casos:

Caso de uso Comportamento
Notebooks interativos na computação geral awaitTermination() mantém a célula de código em execução, e permite observar o estado da consulta, garantindo que as falhas sejam exibidas na saída do notebook.
Ambientes locais e de desenvolvimento Ao executar um programa Spark localmente, o processo é encerrado quando o thread principal é concluído. Chame awaitTermination() para manter o programa ativo até que a consulta de streaming seja concluída ou falhe.
Propagação de falha para o driver Sem awaitTermination(), uma falha de consulta de streaming em um contexto que não seja de trabalho pode não se propagar para o thread de chamada. A consulta pode falhar silenciosamente, tornando as falhas mais difíceis de detectar e diagnosticar. A chamada awaitTermination() gera novamente a exceção de consulta no driver.
  • Última atualização em