Partilhar via

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

  • Artigo

Este artigo contém recomendações para agendar cargas de trabalho de Streaming Estruturado usando trabalhos no Azure Databricks.

A Databricks recomenda sempre fazer o seguinte:

  • Remova códigos desnecessários de blocos de anotações que retornariam resultados, como display e count.
  • Não execute cargas de trabalho de Streaming Estruturado usando computação multiuso. Sempre agende fluxos como trabalhos usando a computação de trabalhos.
  • Agende trabalhos usando o Continuous modo.
  • Não habilite o dimensionamento automático para computação para trabalhos de Streaming Estruturado.

Algumas cargas de trabalho se beneficiam do seguinte:

O Azure Databricks introduziu o Delta Live Tables para reduzir as complexidades do gerenciamento da infraestrutura de produção para cargas de trabalho de Streaming Estruturado. A Databricks recomenda o uso de Delta Live Tables para novos pipelines de Streaming Estruturado. Consulte O que é Delta Live Tables?.

Nota

O dimensionamento automático de computação tem limitações para reduzir o tamanho do cluster para cargas de trabalho de Streaming Estruturado. O Databricks recomenda a utilização do Delta Live Tables com dimensionamento automático melhorado para cargas de trabalho de transmissão em fluxo. Consulte Otimizar a utilização de cluster de pipelines Delta Live Tables com dimensionamento automático aprimorado.

Projete cargas de trabalho de streaming para esperar falhas

O Databricks recomenda sempre configurar trabalhos de streaming para reiniciar automaticamente em caso de falha. Algumas funcionalidades, incluindo a evolução do esquema, pressupõem que as cargas de trabalho do Streaming Estruturado estejam configuradas para repetir automaticamente. Consulte Configurar trabalhos de streaming estruturado para reiniciar consultas de streaming em caso de falha.

Algumas operações, como foreachBatch fornecer pelo menos uma vez, em vez de exatamente uma vez, garantias. Para essas operações, você deve fazer com que seu pipeline de processamento seja idempotente. Veja Utilizar foreachBatch para escrever em sinks de dados arbitrários.

Nota

Quando uma consulta é reiniciada, o microlote planejado durante os processos de execução anteriores. 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 em uma consulta de Streaming estruturado.

Quando é que um emprego volta a tentar?

Você pode agendar várias tarefas como parte de um trabalho do 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: defina um trabalho com várias tarefas que executam 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.

Múltiplas tarefas Várias consultas
Como a computação é compartilhada? O Databricks recomenda a implantação de trabalhos dimensionados adequadamente para cada tarefa de streaming. Opcionalmente, você pode compartilhar computação entre tarefas. Todas as consultas compartilham o mesmo cálculo. Opcionalmente, você pode atribuir consultas a pools de agendadores.
Como são tratadas as novas tentativas? Todas as tarefas devem falhar antes que o trabalho seja iniciado. A tarefa tenta novamente se alguma consulta falhar.

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

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

O gatilho contínuo fornece 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 backoff exponencial para tentativas.

O Databricks recomenda sempre o uso de computação de trabalhos em vez de computação para todos os fins ao agendar fluxos de trabalho. Em caso de falha e repetição do trabalho, novos recursos de computação são implantados.

Nota

Você não precisa usar streamingQuery.awaitTermination() ou spark.streams.awaitAnyTermination(). Os trabalhos impedem automaticamente que uma execução seja concluída quando uma consulta de streaming está ativa.

Usar pools de agendadores para várias consultas de streaming

Você pode configurar pools de agendamento para atribuir capacidade de computação a consultas ao executar várias consultas de streaming do mesmo código-fonte.

Por padrão, todas as consultas iniciadas em um bloco de anotações são executadas no mesmo pool de agendamento justo. Os trabalhos do Apache Spark gerados por gatilhos de todas as consultas de streaming em um notebook são executados 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 os recursos do cluster.

Os pools do Agendador permitem que você declare quais consultas de Streaming Estruturado compartilham recursos de computação.

O exemplo a seguir atribui query1 a um pool dedicado, enquanto query2 e query3 compartilha um pool de agendadores.

# 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")

Nota

A configuração da propriedade local deve estar na mesma célula do bloco de anotações em que você inicia a consulta de streaming.

Consulte a documentação do Apache fair scheduler para obter mais detalhes.