Spark
Nível médioComo escolho o intervalo de trigger e o tamanho de micro-batch certos no Structured Streaming?
O Structured Streaming não é contínuo por padrão - são micro-batches num timer. O intervalo escolhido troca latência por overhead fixo por batch, e essa troca pode sair pela culatra.
Um intervalo de trigger mais curto parece que deveria sempre significar menor latência. Depois de certo ponto, só significa mais batches gastos em burocracia em vez de dados.
O que o intervalo de trigger realmente controla
O Trigger.ProcessingTime agrupa em um micro-batch todos os dados novos que chegaram dentro daquela janela, e então planeja, executa, comita e faz checkpoint dele como uma unidade. Um intervalo mais curto significa menor latência de ponta a ponta por registro, mas cada um desses passos - planejamento, commit, checkpoint - tem um custo mais ou menos fixo, não importa quantos dados realmente tenha o batch.
Por que diminuir o intervalo pode piorar o throughput
Se esse overhead fixo por batch está próximo do próprio intervalo, o job gasta mais tempo real em burocracia de batch do que em processamento de fato. Isso aparece como batches que "completam" quase instantaneamente na Spark UI enquanto um backlog de entrada crescente se acumula atrás deles - o pipeline parece saudável batch a batch e no todo vai ficando para trás.
Trigger.AvailableNow para backfills delimitados
Um backfill pontual ou uma execução para colocar em dia não é um job de streaming permanente e não deveria usar o trigger de intervalo padrão de jeito nenhum - Trigger.AvailableNow processa exatamente o que está disponível agora, em batches, e então para sozinho. Usar o tipo de trigger errado aqui é uma causa comum de um "backfill" que nunca termina de verdade.
Veja como isso fica no seu próprio pipeline.
Envie um event log real do Spark, um run_results.json do dbt ou uma exportação de métricas do Flink e receba recomendações concretas, para aprovar antes de aplicar - não mais uma regra geral.