Configurar intervalos de gatilho do Fluxo Estruturado
O Fluxo Estruturado do Apache Spark processa dados incrementalmente. Controlar o intervalo de gatilho para processamento em lotes permite que você use o Fluxo 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 lotes de todos os novos dados por um dia ou semana.
Como o Carregador Automático do Databricks usa o Fluxo Estruturado para carregar dados, entender como os gatilhos funcionam oferece a maior flexibilidade para controlar os custos ao ingerir dados com a frequência desejada.
Especificar intervalos de gatilho baseados em tempo
O Fluxo Estruturado refere-se a intervalos de gatilho baseados em tempo como "micro-lotes de intervalo fixo". Usando a palavra-chave processingTime, especifique uma duração de tempo como uma cadeia de caracteres, como .trigger(processingTime='10 seconds').
Quando você especifica um intervalo trigger muito pequeno (menos de dez segundos), o sistema pode executar verificações desnecessárias para ver se novos dados chegaram. Configure o tempo de processamento para equilibrar os requisitos de latência e a taxa com a qual os dados chegam na origem.
Configuração do processamento em lote incremental
Importante
No Databricks Runtime 11.3 LTS e superior, a configuração Trigger.Once foi preterida. O Databricks recomenda que você use Trigger.AvailableNow para todas as cargas de trabalho de processamento em lote incremental.
A opção de gatilho disponível agora consome todos os registros disponíveis como um lote incremental com a capacidade de configurar o tamanho do lote e opções como maxBytesPerTrigger (as opções de dimensionamento variam de acordo com a fonte de dados).
O Azure Databricks dá suporte ao uso de Trigger.AvailableNow para processamento em lote incremental de várias fontes de Fluxo Estruturado. A tabela a seguir inclui a versão mínima do Databricks Runtime com suporte necessária para cada fonte de dados:
| Fonte | Versão mínima do Databricks Runtime |
|---|---|
| Fontes de arquivos (JSON, Parquet etc.) | 9.1 LTS |
| Delta Lake | 10.4 LTS |
| Carregador Automático | 10.4 LTS |
| Apache Kafka | 10.4 LTS |
| Kinesis | 13.1 |
Qual é o intervalo de gatilho padrão?
O Fluxo Estruturado é padronizado para micro-lotes de intervalo fixo de 500 ms. A Databricks recomenda que você sempre especifique um trigger personalizado para minimizar os custos associados à verificação se novos dados chegaram e ao processamento de lotes subdimensionados.
Como alterar intervalos de gatilho entre as execuções
Você pode alterar o intervalo de gatilho entre as execuções ao usar o mesmo ponto de verificação.
Se um trabalho do Streaming Estruturado for interrompido enquanto um microlote estiver sendo processado, esse microlote precisará ser concluído para que o novo intervalo de gatilho seja aplicado. Dessa forma, talvez você observe um processamento de microlote com as configurações especificadas anteriormente depois de alterar o intervalo de gatilho.
Ao passar do intervalo baseado em tempo para o uso o AvailableNow, isso pode resultar em um processamento de microlote antes do processamento de todos os registros disponíveis como um lote incremental.
Ao passar de AvailableNow para um intervalo baseado em tempo, isso pode resultar na continuidade do processamento de todos os registros que estavam disponíveis quando o último trabalho AvailableNow foi disparado. Esse é o comportamento esperado.
Observação
Se você estiver tentando se recuperar de uma falha de consulta associada a um lote incremental, a alteração do intervalo de gatilho não resolverá esse problema, porque o lote ainda precisa ser concluído. O Databricks recomenda o aumento da capacidade de computação usada para processar o lote a fim de 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 dá suporte a um intervalo de gatilho adicional conhecido como Processamento Contínuo. Esse modo foi classificado como experimental desde o Spark 2.3; confira 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 nas Tabelas Dinâmicas Delta.