Considerações de produção para a Transmissão em Fluxo Estruturada
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 o código desnecessário dos blocos de anotações que retornariam resultados, como
displayecount. - Não execute cargas de trabalho de Streaming Estruturado usando computação multiuso. Sempre agende fluxos como trabalhos usando a computação de tarefas.
- Agende trabalhos usando o
Continuousmodo. - Não habilite o dimensionamento automático para computação para trabalhos de Streaming Estruturado.
Algumas cargas de trabalho se beneficiam do seguinte:
- Configurar o armazenamento de estado do RocksDB no Azure Databricks
- Ponto de verificação de estado assíncrono para consultas com estado
- O que é o acompanhamento assíncrono do progresso?
O Azure Databricks introduziu a DLT para reduzir as complexidades do gerenciamento da infraestrutura de produção para cargas de trabalho de Streaming Estruturado. A Databricks recomenda o uso de DLT para novos pipelines de Streaming Estruturado. Consulte O que é DLT?.
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 o uso de DLT com dimensionamento automático aprimorado para cargas de trabalho de streaming. Veja Otimizar a utilização do cluster das pipelines DLT com o aprimoramento do dimensionamento automático.
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, fornecem garantias de pelo menos uma vez em vez de exatamente uma vez. Para estas operações, deves assegurar que a tua linha de processamento seja 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 é que uma tarefa recomeça?
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: 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.
| 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. 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 tentado novamente. | A tarefa é retomada 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 tarefas 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 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
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 grupos de agendamento para atribuir recursos de computação a estas ao executar várias consultas de streaming do mesmo código-fonte.
Por padrão, todas as consultas iniciadas num notebook 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 onde se inicia a consulta de streaming.
Consulte a documentação do Apache fair scheduler para obter mais detalhes.