Considerações sobre a produção de transmissão estruturada

Esta página contém recomendações para programar cargas de trabalho de Transmissão estructurada usando jobs do LakeFlow no Databricks. Veja Jobs do Lakeflow.

A 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 transmissão estructurada usando compute de uso geral. Sempre programe as transmissões como Jobs do LakeFlow usando o compute de Jobs.
• Programe Jobs do LakeFlow usando o Continuous modo. Isso se refere ao recurso de programação do Databricks Jobs, e não ao intervalo de trigger da transmissão estructurada.
• Não ative Autoscale para compute em jobs de transmissão estructurada.

Algumas cargas de trabalho se beneficiam do seguinte:

• Configurar RocksDB armazenamento do estado em Databricks
• Ponto de verificação de estado assíncrono para consultas com estado
• Monitoramento de progresso assíncrono

Databricks introduziu o pipeline declarativo LakeFlow Spark para reduzir as complexidades do gerenciamento da infraestrutura de produção para cargas de trabalho de transmissão estruturada. Databricks recomenda o uso do pipeline declarativo LakeFlow Spark para novos pipelines de transmissão estruturada. Veja o pipeline declarativoLakeFlow Spark.

nota

O dimensionamento automático de computação tem limitações na redução do tamanho cluster para cargas de trabalho de transmissão estruturada. Databricks recomenda o uso do pipeline declarativo LakeFlow Spark com escalonamento automático aprimorado para cargas de trabalho de transmissão. Consulte Otimizar a utilização cluster do pipeline declarativo LakeFlow Spark com escalonamento automático.

:::nota computesem servidor

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

Para transmissão contínua em compute serverless , use o modo de pipeline acionado em vez do modo pipeline contínuo no modo contínuo.

Veja limitações de transmissão.

:::

Projetar cargas de trabalho de transmissão para prever falhas

A Databricks recomenda que você sempre configure Jobs de transmissão para reiniciar automaticamente em caso de falha. Algumas capacidades, incluindo a evolução do esquema, exigem que as cargas de trabalho de transmissão estructurada tentem novamente automaticamente. Consulte Configurar jobs de Transmissão Estruturada para reiniciar consultas de transmissão 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, certifique-se de que seu pipeline de processamento seja idempotente. Consulte Usar foreachBatch para gravar em destinos de dados arbitrários.

nota

Quando uma consulta é reiniciada, as microlotes planejadas durante os processos de execução anteriores. Se o trabalho falhou devido a um erro de falta de memória ou se o senhor cancelou manualmente um trabalho devido ao excesso de microlotes, talvez seja necessário escalonar o compute para processar com êxito os microlotes.

Se o senhor alterar as configurações entre as execuções, essas configurações serão aplicadas aos primeiros novos lotes planejados. Consulte Recuperação após alterações em uma consulta de transmissão estruturada.

Quando um trabalho é repetido?

O senhor pode programar várias tarefas como parte de um Databricks Job. Quando o senhor configura uma tarefa usando o acionador contínuo, não é possível definir dependências entre tarefas.

O senhor pode optar por programar várias transmissões em um único trabalho usando uma das seguintes abordagens:

• Tarefa múltipla : Definir um trabalho com várias tarefas que executam cargas de trabalho de transmissão usando o acionador contínuo.
• Várias consultas : Defina várias consultas de transmissão 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	Tarefa múltipla	Várias consultas
Como o site compute é compartilhado?	Databricks recomenda implantar o Job compute adequadamente dimensionado para cada transmissão de tarefa. Opcionalmente, o senhor pode compartilhar o site compute entre as tarefas.	Todas as consultas compartilham o mesmo compute. Opcionalmente, você pode atribuir consultas ao pool de programadores.
Como as novas tentativas são tratadas?	Todas as tarefas devem falhar antes que o trabalho tente novamente.	A tarefa tentará novamente se alguma consulta falhar.

Para mais detalhes sobre como trabalhar com múltiplas tarefas ou consultas, veja Execução de Múltiplas Consultas de Transmissão Estruturada no Mesmo Cluster.

Configurar transmissão estruturada Job para reiniciar as consultas de transmissão em caso de falha

A Databricks recomenda que você configure todas as cargas de trabalho de transmissão usando o gatilho contínuo. Consulte Executar jobs continuamente.

O gatilho contínuo tem o seguinte comportamento por default:

• Evita mais de uma execução concorrente do trabalho.
• começar uma nova execução quando uma execução anterior falhar.
• Usa o recuo exponencial para novas tentativas.

Databricks recomenda sempre usar o Job compute em vez do compute para todos os fins ao programar fluxo de trabalho. Em caso de falha e nova tentativa de trabalho, novo compute recurso implantado.

nota

A 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 a thread atual até que uma consulta de transmissão termine. A utilização dessas funções depende do seu ambiente de execução.

Para os Jobs do Lakeflow, não utilize streamingQuery.awaitTermination() ou spark.streams.awaitAnyTermination(). Estas funções não são necessárias porque o Serviço de Jobs impede automaticamente que uma execução seja concluída quando uma consulta de transmissão está ativa. Ambas as funções impedem que as células do Notebook sejam concluídas e impedem que o serviço Jobs faça o acompanhamento da consulta de transmissão, o que interrompe as métricas de backlog e as notificações de Job.

Utilize awaitTermination() nos seguintes casos:

Caso de uso	Comportamento
Notebook interativo em computede uso geral	awaitTermination() Mantém a célula em execução, permite observar o estado da consulta e garante 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 a thread principal termina. Chame awaitTermination() para manter o programa ativo até que a consulta de transmissão termine ou falhe.
Propagação da falha para o driver	Sem awaitTermination(), uma falha de consulta de transmissão em um contexto sem Job pode não se propagar para o thread de chamada. A query pode falhar silenciosamente, tornando as falhas mais difíceis de detectar e diagnosticar. Invocar awaitTermination() levanta a exceção da query no driver novamente.