Configurar intervalos de gatilho do Streaming Estruturado
O Apache Spark Structured Streaming processa dados de forma incremental; controlar o intervalo de gatilho para processamento em lote permite que você use o Streaming Estruturado para cargas de trabalho, incluindo processamento quase em tempo real, atualização de bancos de dados a cada 5 minutos ou uma vez por hora, ou processamento em lote de todos os novos dados por um dia ou semana.
Como o Databricks Auto Loader usa Streaming Estruturado para carregar dados, entender como os gatilhos funcionam oferece a maior flexibilidade para controlar os custos enquanto ingere dados com a frequência desejada.
Especificando intervalos de gatilho baseados em tempo
Streaming estruturado refere-se a intervalos de gatilho baseados em tempo como "microlotes de intervalo fixo". Usando a processingTime palavra-chave, especifique uma duração de tempo como uma cadeia de caracteres, como .trigger(processingTime='10 seconds').
Quando você especifica um trigger intervalo muito pequeno (menos de dezenas de segundos), o sistema pode executar verificações desnecessárias para ver se novos dados chegam. Configure o tempo de processamento para equilibrar os requisitos de latência e a taxa de chegada dos dados na origem.
Configurando o processamento incremental em lote
Importante
No Databricks Runtime 11.3 LTS e superior, a Trigger.Once configuração foi preterida. O Databricks recomenda o uso Trigger.AvailableNow para todas as cargas de trabalho incrementais de processamento em lote.
A opção de gatilho agora disponível consome todos os registros disponíveis como um lote incremental com a capacidade de configurar o tamanho do lote com opções como maxBytesPerTrigger (as opções de dimensionamento variam de acordo com a fonte de dados).
O Azure Databricks dá suporte ao uso Trigger.AvailableNow para processamento em lote incremental de muitas fontes de Streaming Estruturado. A tabela a seguir inclui a versão mínima suportada do Databricks Runtime necessária para cada fonte de dados:
| Origem | Versão mínima do Databricks Runtime |
|---|---|
| Fontes de ficheiros (JSON, Parquet, etc.) | 9,1 LTS |
| Delta Lake | 10.4 LTS |
| Carregador Automático | 10.4 LTS |
| Apache Kafka | 10.4 LTS |
| Cinesis | 13,1 |
Qual é o intervalo de gatilho padrão?
O Streaming Estruturado assume como padrão microlotes de intervalo fixo de 500ms. A Databricks recomenda que você sempre especifique um personalizado trigger para minimizar os custos associados à verificação da chegada de novos dados e ao processamento de lotes subdimensionados.
Alterando intervalos de gatilho entre execuções
Você pode alterar o intervalo de gatilho entre as execuções usando o mesmo ponto de verificação.
Se um trabalho de Streaming Estruturado parar enquanto um microlote estiver sendo processado, esse microlote deverá ser concluído antes que o novo intervalo de gatilho se aplique. Como tal, você pode observar um processamento de microlote com as configurações especificadas anteriormente depois de alterar o intervalo de disparo.
Ao passar do intervalo baseado no tempo para o uso AvailableNowdo , isso pode resultar em um processamento de microlote antes do processamento de todos os registros disponíveis como um lote incremental.
Ao mudar de um intervalo baseado AvailableNow em tempo, isso pode resultar em continuar a processar todos os registros que estavam disponíveis quando o último AvailableNow trabalho foi acionado. Este é o comportamento esperado.
Nota
Se você estiver tentando se recuperar de uma falha de consulta associada a um lote incremental, alterar o intervalo de gatilho não resolve esse problema porque o lote ainda deve ser concluído. O Databricks recomenda aumentar a capacidade de computação usada para processar o lote para tentar resolver o problema. Em casos raros, talvez seja necessário reiniciar o fluxo com um novo ponto de verificação.
O que é o modo de processamento contínuo?
O Apache Spark suporta um intervalo de gatilho adicional conhecido como Processamento Contínuo. Este modo tem sido classificado como experimental desde Spark 2.3; consulte sua equipe de conta do Azure Databricks para garantir que você entenda as compensações desse modelo de processamento.
Observe que esse modo de processamento contínuo não está relacionado ao processamento contínuo conforme aplicado no Delta Live Tables.