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

Execute cargas de trabalho de produção do Streaming Estruturado como Trabalhos do Lakeflow agendados no Azure Databricks. Consulte Trabalhos do Lakeflow.

O Databricks recomenda que você sempre configure o seguinte:

  • 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 habilite o dimensionamento automático para computação para trabalhos de Streaming Estruturado.

Algumas cargas de trabalho se beneficiam do seguinte:

O Databricks introduziu os pipelines do Lakeflow para reduzir as complexidades do gerenciamento da infraestrutura de produção para cargas de trabalho de Streaming Estruturado. O Databricks recomenda o uso de pipelines do Lakeflow para novos pipelines de Streaming Estruturado. Consulte Pipelines Declarativos do Spark.

Observação

O dimensionamento automático de computação tem limitações ao reduzir o tamanho do cluster para cargas de trabalho do Streaming Estruturado. A Databricks recomenda usar os Pipelines Declarativos do Spark no Lakeflow com escalonamento automático aprimorado para cargas de trabalho de streaming. Consulte Otimizar utilização do cluster de pipeline do Lakeflow com dimensionamento automático.

:::observação Computação sem servidor

Na computação sem servidor, apenas Trigger.AvailableNow() e Trigger.Once() são suportados. O Databricks recomenda Trigger.AvailableNow().

Para streaming contínuo na computação sem servidor, use o Modo de pipeline disparado versus contínuo no modo contínuo.

Consulte Limitações de streaming.

:::

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.

Para a menor latência de ponta a ponta, use o modo em tempo real, que alcança latência de ponta a ponta abaixo de um segundo na cauda e cerca de 300 milissegundos nos casos comuns. 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? Todas as tarefas devem falhar antes que o trabalho seja repetido. A tarefa será repetida se alguma consulta falhar.

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.
  • Last updated on