Checkpointing no Flink: por que ele falha em silêncio, e como ajustar o intervalo e o timeout

Intervalo de checkpoint e timeout de checkpoint soam como uma única configuração. Eles controlam dois riscos separados, e confundi-los é como um job acaba com uma falsa sensação de segurança.

Intervalo vs. timeout: dois trabalhos diferentes

checkpointing.interval define de quanto em quanto tempo um checkpoint é tentado - mais curto significa menos dados para reproduzir na recuperação, ao custo de overhead mais frequente. checkpointing.timeout define quanto tempo uma tentativa de checkpoint tem antes do Flink desistir dela - curto demais e um checkpoint perfeitamente saudável sob carga momentânea é cancelado sem motivo real; longo demais e um job com problemas continua tentando checkpoints que nunca iam terminar, queimando recursos em novas tentativas em vez de processamento real.

A falha silenciosa: checkpoints expirando sob backpressure

Sob backpressure, uma barreira de checkpoint precisa atravessar o buffer de entrada de cada operador antes do checkpoint poder completar - se esses buffers estão cheios (que é justamente o que backpressure significa), a barreira entra na fila atrás deles e o checkpoint demora muito mais que o normal. Nada quebra; o job continua processando registros. Mas os checkpoints continuam expirando, em silêncio, até alguém notar que o ponto de recuperação real do job está desatualizado em minutos ou horas em vez de segundos.

Um ponto de partida razoável, e a métrica que diz que está errado

Um par comum: intervalo na faixa de dezenas de segundos a poucos minutos, timeout em várias vezes sua duração típica de checkpoint - não a melhor duração. Depois acompanhe a duração do checkpoint como tendência, não como valor pontual.