Considerações sobre a produção de transmissão estruturada
Esta página contém recomendações para programar transmissões estruturadas de cargas de trabalho usando Job no Databricks.
A Databricks recomenda que você sempre configure o seguinte:
- Remova o código desnecessário dos notebooks que retornariam resultados, como
displayecount. - Não execute cargas de trabalho de transmissão estruturada usando o site compute para todos os fins. Sempre programar a transmissão como Job usando o Job compute.
- Tarefa programada usando o modo
Continuous. Isso se refere ao recurso programático Databricks Jobs, não ao intervalo de acionamento de transmissão estruturada. - Não habilite o escalonamento automático para compute para trabalho de transmissão estruturada.
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.
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
Databricks recomenda sempre configurar o Job de transmissão para reiniciar automaticamente em caso de falha. Alguns recursos, incluindo a evolução do esquema, exigem que as cargas de trabalho de transmissão estruturada sejam configuradas para tentar novamente automaticamente. Consulte Configurar Job 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.
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. |
Configurar transmissão estruturada Job para reiniciar as consultas de transmissão em caso de falha
Databricks recomenda a configuração de todas as cargas de trabalho de transmissão usando o acionador contínuo. Ver execução do trabalho 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.
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 trabalhos do Databricks, não use streamingQuery.awaitTermination() ou spark.streams.awaitAnyTermination(). Estas funções não são necessárias porque o serviço Jobs impede automaticamente a conclusão de uma execução quando uma consulta de transmissão está ativa. Ambas as funções impedem que as células do Notebook sejam concluídas e evitam que o serviço Jobs acompanhe a consulta de transmissão, o que interrompe as métricas de backlog e as notificações de Jobs.
Utilize awaitTermination() nos seguintes casos:
Caso de uso | Comportamento |
|---|---|
Notebook interativo em computede uso geral |
|
Ambientes locais e de desenvolvimento | Ao executar um programa Spark localmente, o processo é encerrado quando a thread principal termina. Chame |
Propagação da falha para o driver | Sem |
Usar o pool de programadores para várias consultas de transmissão
Você pode configurar o pool de programadores para atribuir capacidade compute às consultas ao executar várias consultas de transmissão a partir do mesmo código-fonte.
Por default, todas as consultas começam em uma execução do Notebook na mesma feira programar pool. Apache Spark Trabalho gerado por acionadores de todas as consultas de transmissão em um Notebook, executado um após o outro na ordem "primeiro a entrar, primeiro a sair" (FIFO). Isso pode causar atrasos desnecessários nas consultas, porque elas não estão compartilhando eficientemente o recurso de clustering.
programador pool permite que o senhor declare quais consultas de transmissão estruturada compartilham compute recurso.
O exemplo a seguir atribui query1 a um pool dedicado, enquanto query2 e query3 compartilham um pool de programador.
# Run streaming query1 in scheduler pool1
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool1")
df.writeStream.queryName("query1").toTable("table1")
# Run streaming query2 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query2").toTable("table2")
# Run streaming query3 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query3").toTable("table3")
A configuração da propriedade local deve estar na mesma célula do Notebook em que o senhor iniciou a consulta de transmissão.
Para obter mais informações sobre o pool de programadores justos Apache , consulte a documentação do programador justoApache.