Checkpointing en Flink: por qué falla en silencio, y cómo ajustar el intervalo y el timeout

El intervalo de checkpoint y el timeout de checkpoint suenan como una sola configuración. Controlan dos riesgos separados, y confundirlos es la forma más común de terminar con una falsa sensación de seguridad.

Intervalo vs. timeout: dos trabajos distintos

checkpointing.interval define cada cuánto se intenta un checkpoint - más corto significa menos datos que reproducir en la recuperación, a costa de overhead más frecuente. checkpointing.timeout define cuánto tiempo se permite a un intento de checkpoint antes de que Flink lo abandone - demasiado corto y un checkpoint perfectamente sano bajo una carga momentánea se cancela sin razón real; demasiado largo y un job con problemas sigue intentando checkpoints que nunca iban a terminar, quemando recursos en reintentos en lugar de procesamiento real.

El fallo silencioso: checkpoints que expiran bajo backpressure

Bajo backpressure, una barrera de checkpoint tiene que atravesar el buffer de entrada de cada operador antes de que el checkpoint pueda completarse - si esos buffers están llenos (que es justo lo que significa backpressure), la barrera se encola detrás de ellos y el checkpoint tarda mucho más de lo habitual. Nada se cae; el job sigue procesando registros. Pero los checkpoints siguen expirando, en silencio, hasta que alguien nota que el punto de recuperación real del job está desactualizado por minutos u horas en vez de segundos.

Un punto de partida razonable, y la métrica que te dice que está mal

Un par habitual: intervalo entre decenas de segundos y pocos minutos, timeout en varias veces tu duración típica de checkpoint - no tu mejor caso. Luego vigila la duración del checkpoint como tendencia, no como valor puntual.