Spark
Nivel medio¿Cómo elijo el intervalo de trigger y tamaño de micro-batch correctos en Structured Streaming?
Structured Streaming no es continuo por defecto - son micro-batches por temporizador. El intervalo que elija intercambia latencia por overhead fijo por batch, y ese intercambio puede salir mal.
Un intervalo de trigger más corto suena como si siempre significara menor latencia. Pasado cierto punto, solo significa más batches gastados en contabilidad en vez de en datos.
Qué controla realmente el intervalo de trigger
Trigger.ProcessingTime agrupa en un micro-batch todos los datos nuevos que llegaron dentro de esa ventana, y luego lo planifica, ejecuta, confirma y checkpointea como una unidad. Un intervalo más corto significa menor latencia de extremo a extremo por registro, pero cada uno de esos pasos - planificación, commit, checkpoint - tiene un costo aproximadamente fijo sin importar cuántos datos haya realmente en el batch.
Por qué reducir el intervalo puede empeorar el throughput
Si ese overhead fijo por batch está cerca del intervalo mismo, el job gasta más tiempo real en contabilidad de batches que en procesamiento real. Se ve como batches que "se completan" casi al instante en la Spark UI mientras un backlog de entrada creciente se acumula detrás - el pipeline se ve sano batch por batch y en conjunto se va quedando atrás.
Trigger.AvailableNow para backfills acotados
Un backfill puntual o una corrida para ponerse al día no es un job de streaming permanente y no debería usar el trigger de intervalo estándar en absoluto - Trigger.AvailableNow procesa exactamente lo que está disponible ahora, en batches, y luego se detiene solo. Usar el tipo de trigger equivocado aquí es una causa común de que un "backfill" nunca termine realmente.
Vea cómo se ve esto en su propio pipeline.
Suba un event log real de Spark, un run_results.json de dbt o una exportación de métricas de Flink y obtenga recomendaciones concretas, que debe aprobar antes de aplicar - no otra regla general.