Considerações de produção para a Transmissão em Fluxo Estruturada

Executar cargas de trabalho de Streaming Estruturado em produção como trabalhos Lakeflow agendados no Azure Databricks. Veja Lakeflow Jobs.

O Databricks recomenda que configure sempre o seguinte:

  • Remova o código desnecessário dos blocos de anotações que retornariam resultados, como display e count.
  • Não execute cargas de trabalho de Structured Streaming usando computação multiusos. Agenda sempre os fluxos como Lakeflow Jobs usando o cálculo de jobs.
  • Agendar as tarefas do Lakeflow utilizando o Continuousmodo. Isto refere-se à funcionalidade de agendamento de tarefas do Azure Databricks, não ao intervalo de disparo do Structured Streaming.
  • Não ative o autoscaling para computação em trabalhos de Structured Streaming.

Algumas cargas de trabalho se beneficiam do seguinte:

A Databricks introduziu os pipelines Lakeflow para reduzir a complexidade associada à gestão de infraestruturas de produção para cargas de trabalho de Structured Streaming. A Databricks recomenda a utilização de pipelines Lakeflow para novos pipelines de Streaming Estruturado. Ver Pipelines Declarativos Spark.

Nota

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 a utilização de Spark Declarative Pipelines no Lakeflow com dimensionamento automático melhorado para cargas de trabalho de streaming. Consulte Otimize a utilização do cluster do pipeline Lakeflow com dimensionamento automático.

:::note Computação sem servidor

Em computação serverless, apenas Trigger.AvailableNow() e Trigger.Once() são suportados. Databricks recomenda Trigger.AvailableNow().

Para streaming contínuo em computação serverless, use o modo Triggered ou o modo pipeline contínuo.

Consulte Limitações de streaming.

:::

Reduza a latência para streaming operacional

As cargas de trabalho de streaming operacional ingerem, transformam e atuam sobre os dados quase em tempo real. Exemplos comuns incluem deteção de fraude, deteção de anomalias, personalização e monitorização e alerta em tempo real, onde o processamento atrasado afeta diretamente os resultados do negócio. A baixa latência para estas cargas de trabalho normalmente significa dezenas a centenas de milissegundos, embora muitas equipas definam acordos de nível de serviço (SLAs) na gama de segundos para compensar a variabilidade nos percentis mais altos.

Para a menor latência de ponta a ponta, use o modo em tempo real, que atinge uma latência de ponta a ponta em menos de um segundo na cauda e cerca de 300 milissegundos nos casos comuns. Ver conceitos do modo em tempo real.

Quando o modo em tempo real não se adequa à sua carga de trabalho, as seguintes melhores práticas reduzem a latência para o Streaming Estruturado em micro-batch:

  • Modo de saída: Use o modo de atualização onde os operadores de consulta e o sink o suportam. O modo de atualização emite linhas atualizadas após cada disparo e continua a atualizá-las até à expiração da marca de água, por isso assegura-te de que o teu sink downstream é idempotente para processar resultados atualizados. Utilize o modo append para cargas de trabalho que o modo update não suporta, como junções stream-stream, ou quando pode descartar dados que chegam tardiamente. Não uses o modo completo para baixa latência. Consulte para selecionar um modo de saída para o Structured Streaming.
  • Acionador: Utilize um acionador processingTime com um intervalo 0, que inicia o micro-lote seguinte assim que o anterior terminar e houver novos dados disponíveis. Isto proporciona a menor latência micro-batch, mas aumenta os custos da API de armazenamento na cloud. Não uses AvailableNow, Once, nem Continuous para cargas de trabalho operacionais. Consulte Configurar intervalos de ativação do Streaming Estruturado.
  • Marca de água: Defina a marca de água suficientemente longa para incluir os dados que chegam tarde e que a sua carga de trabalho não deve diminuir. A watermark controla durante quanto tempo a consulta aceita dados de eventos fora de ordem no tempo do evento antes de os descartar e remover o estado, pelo que uma watermark demasiado curta descarta silenciosamente registos válidos que chegam com atraso. Dentro dessa restrição, uma marca de água mais curta reduz a latência e mantém menos estado, e uma marca de água mais longa tolera dados mais tardios à custa da latência e do estado. Um múltiplo baixo do seu SLA de latência, como 2x, constitui um ponto de partida razoável para o ajuste. Consulte Aplicação de marcas d'água para controlar os limites de processamento de dados.
  • Fontes e sumidouros: Lê de fontes de baixa latência, como barramentos de mensagens (Apache Kafka, Amazon Kinesis, Apache Pulsar ou Google Cloud Pub/Sub) ou altera feeds de dados das tabelas Delta Lake e Apache Iceberg. Escreva em sumidouros de baixa latência e alto rendimento, como barramentos de mensagens, bases de dados operacionais ou foreach dispersões. Projetar operações de sumidouro para serem idempotentes, de modo a que os consumidores a jusante tratem de duplicados e dados que chegam tardiamente.
  • Estado e criação de pontos de verificação: Para consultas com estado, utilize o armazenamento de estado do RocksDB, que é necessário tanto para a criação de pontos de verificação do registo de alterações como para a criação assíncrona de pontos de verificação do estado. Ative o ponto de verificação do registo de alterações para guardar apenas as alterações incrementais do estado. Quando a criação de pontos de verificação do estado constituir o gargalo na duração do seu lote, ative a criação assíncrona de pontos de verificação do estado para sobrepor a escrita desses pontos de verificação ao micro-lote seguinte, depois de analisar as limitações relacionadas com a recuperação após falha e o redimensionamento do cluster. Atribua a cada consulta o seu próprio diretório de ponto de controlo em armazenamento persistente na cloud. Veja Configurar o armazenamento 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.
  • Gestão de offsets: Para reduzir a latência da verificação periódica dos offsets em fluxos contínuos, ative a monitorização assíncrona do progresso, que atualiza os registos dos offsets e das consolidações sem bloquear o processamento de dados. Não é compatível com os acionadores AvailableNow ou Once. Ver Acompanhamento assíncrono do progresso.
  • 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.

Projete cargas de trabalho de streaming para esperar falhas

A Databricks recomenda que configure sempre os trabalhos de streaming para reiniciarem automaticamente em caso de falha. Algumas capacidades, incluindo a evolução de esquemas, exigem que as workloads do Structured Streaming sejam repetidas automaticamente. Consulte Configurar trabalhos de streaming estruturado para reiniciar consultas de streaming quando ocorrer uma falha.

Algumas operações, como foreachBatch, fornecem garantias de pelo menos uma vez em vez de exatamente uma vez. Para estas operações, certifique-se de que o seu pipeline de processamento é idempotente. Veja Utilizar foreachBatch para escrever em sinks de dados arbitrários.

Nota

Quando uma consulta é reiniciada, o microlote planeado durante a execução anterior é processado. Se o seu trabalho falhou devido a um erro de falta de memória ou se você cancelou manualmente um trabalho devido a um microlote superdimensionado, talvez seja necessário aumentar a computação para processar com êxito o microlote.

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

Quando uma tarefa é novamente executada

Pode agendar múltiplas tarefas como parte de um trabalho no Azure Databricks. Quando você configura um trabalho usando o gatilho contínuo, não pode definir dependências entre tarefas.

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

  • Várias tarefas: definir um trabalho com várias tarefas que executam trabalhos 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 Múltiplas tarefas Várias consultas
Como a computação é compartilhada? O Databricks recomenda a implementação de recursos computacionais de tamanho adequado para cada tarefa de streaming. Opcionalmente, você pode compartilhar computação entre tarefas. Todas as consultas compartilham o mesmo cálculo. Pode, opcionalmente, atribuir consultas a pools de agendadores.
Como são tratadas as novas tentativas? Todas as tarefas devem falhar antes que o trabalho seja tentado novamente. A tarefa é retomada se alguma consulta falhar.

Para mais detalhes sobre como trabalhar com múltiplas tarefas ou consultas, consulte Executar múltiplas consultas de Streaming Estruturado no mesmo cluster.

Configurar trabalhos de Streaming Estruturado para reiniciar consultas de streaming em caso de falha

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

O gatilho contínuo apresenta o seguinte comportamento por defeito:

  • Impede mais de uma execução simultânea do trabalho.
  • Inicia uma nova execução quando uma execução anterior falha.
  • Usa backoff exponencial para novas tentativas.

Databricks recomenda sempre o uso de computação específica para tarefas em vez de computação geral ao agendar fluxos de trabalho. Em caso de falha e repetição do trabalho, novos recursos de computação são implantados.

Nota

O Databricks recomenda que não use streamingQuery.awaitTermination() nem spark.streams.awaitAnyTermination(). Veja Quando usar awaitTermination().

Quando usar awaitTermination()

streamingQuery.awaitTermination() e spark.streams.awaitAnyTermination() bloqueiam a thread atual até que uma consulta de streaming termine. Se deve usar estas funções depende do seu ambiente de execução.

Para empregos Lakeflow, não use streamingQuery.awaitTermination() nem spark.streams.awaitAnyTermination(). Estas funções não são necessárias porque o serviço Jobs impede automaticamente que uma execução seja concluída quando uma consulta de streaming está ativa. Ambas as funções bloqueiam a conclusão das células do caderno e impedem o serviço Jobs de rastrear a consulta em streaming, o que perturba métricas de backlog e notificações de trabalho.

Utilize o awaitTermination() nos seguintes casos:

Caso de utilização Comportamento
Cadernos interativos em computação de uso geral awaitTermination() mantém a célula a funcionar, permite-lhe observar o estado da consulta e garante que as falhas apareçam na saída do notebook.
Ambientes locais e de desenvolvimento Ao executar um programa Spark localmente, o processo encerra quando o thread principal termina. Chame awaitTermination() para manter o programa ativo até que a consulta de streaming termine ou falhe.
Propagação de falhas para o controlador Sem awaitTermination(), uma falha de consulta de streaming num contexto que não seja trabalho pode não se propagar para o thread que chama. A consulta pode falhar silenciosamente, tornando as falhas mais difíceis de detetar e diagnosticar. Chamar awaitTermination() levanta novamente a exceção de consulta no driver.
  • Last updated on