Considerações de produção para o Streaming Estruturado

Esta página contém recomendações para agendar cargas de trabalho de Streaming Estruturado usando trabalhos no Azure Databricks.

O Databricks recomenda que você sempre configure o seguinte:

• Remova o código desnecessário de notebooks que poderiam retornar resultados, como display e count.
• Não execute cargas de trabalho de Structured Streaming usando computação genérica. Sempre agende fluxos como trabalhos usando a computação de trabalhos.
• Agendar trabalhos usando Continuous modo. Isso se refere ao recurso de agendamento de Jobs no Azure Databricks, e não ao intervalo de trigger do Structured Streaming.
• Não habilite o dimensionamento automático para computação para trabalhos de Streaming Estruturado.

Algumas cargas de trabalho se beneficiam do seguinte:

• Configure 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 de progresso assíncrono?

Azure Databricks introduziu o Lakeflow Spark Declarative Pipelines para reduzir as complexidades do gerenciamento da infraestrutura de produção para cargas de trabalho de Streaming Estruturado. O Databricks recomenda Lakeflow Spark Declarative Pipelines para novos pipelines de Streaming Estruturado. Consulte Pipelines Declarativos do Lakeflow Spark.

:::note computação sem servidor

Na computação sem servidor, apenas Trigger.AvailableNow() e Trigger.Once() são suportados. O Databricks recomenda Trigger.AvailableNow().

Para streaming contínuo na computação sem servidor, use o modo de pipeline disparado versus contínuo no modo contínuo.

Consulte Limitações de streaming.

:::

Projetar cargas de trabalho de streaming para esperar falhas

A Databricks recomenda sempre configurar os trabalhos de streaming para reiniciar automaticamente em caso de falha. Alguns recursos, incluindo a evolução do esquema, exigem que as cargas de trabalho de Streaming Estruturado sejam configuradas para tentar novamente automaticamente. Consulte Configurar trabalhos de Streaming Estruturado para reiniciar consultas de streaming em caso de falha.

Algumas operações como foreachBatch oferecem garantias de pelo menos uma vez, em vez de exatamente uma vez. Para essas operações, verifique se o pipeline de processamento é idempotente. Consulte Usar o foreachBatch para gravar nos coletores de dados arbitrários.

Quando um trabalho é repetido?

Você pode agendar várias tarefas como parte de um trabalho Azure Databricks. Ao configurar um trabalho usando o gatilho contínuo, você não pode definir dependências entre tarefas.

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

• Várias tarefas: defina um trabalho com várias tarefas que executem 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.

Configurar processos de Streaming Estruturado para reiniciar as consultas de streaming de dados 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 tem 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 recuo exponencial para novas tentativas.

O Databricks recomenda sempre usar a computação de trabalhos em vez da computação para todas as finalidades ao agendar fluxos de trabalho. Em caso de falha e repetição do trabalho, novos recursos de computação são implantados.

Quando usar awaitTermination()

streamingQuery.awaitTermination() e spark.streams.awaitAnyTermination() bloqueiam o thread atual até que uma consulta de streaming seja encerrada. Se usar essas funções depende do ambiente de execução.

Para trabalhos do Databricks, não use streamingQuery.awaitTermination() ou spark.streams.awaitAnyTermination(). Essas funções não são necessárias porque o serviço Jobs impede automaticamente a execução quando uma consulta de streaming está ativa. Ambas as funções impedem que as células do notebook sejam concluídas e impedem que o serviço Trabalhos acompanhe a consulta de streaming, o que interrompe as métricas de backlog e as notificações de trabalho.

Use awaitTermination() nos seguintes casos:

Use os pools de agendador para várias consultas de streaming

Você pode configurar pools de agendador 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 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 FIFO (primeiro a entrar, primeiro a sair). Isso pode causar atrasos desnecessários nas consultas, pois eles não compartilham com eficiência os recursos do cluster.

Os pools de agendador permitem declarar 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 agendador.

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

Para obter mais informações sobre pools de agendadores justos do Apache, consulte a documentação do agendador justo do Apache.