Como configuro corretamente parallelism e backpressure em um job de streaming no Flink?

Backpressure costuma ser tratado como um alarme para silenciar. Na verdade é um dos sinais mais úteis que o Flink te dá de graça: ele diz, com precisão, qual operador do seu pipeline é o gargalo que está fazendo todo o resto esperar.

Lendo backpressure corretamente

Backpressure se propaga para trás pelo grafo do job — se o operador C é lento, os operadores A e B upstream dele também vão mostrar backpressure alto, mesmo sem serem o problema real. A correção é achar o primeiro operador (lendo o grafo na ordem do fluxo de dados) que mostra backpressure alto sem nada downstream também em backpressure — esse é o seu gargalo real, não o operador com a métrica mais chamativa.

Parallelism deve seguir o gargalo, não ser uniforme

Definir um único valor global de parallelism para o job inteiro é a configuração errada mais comum no Flink — ou superprovisiona operadores baratos, ou subprovisiona os caros. Parallelism por operador, elevado especificamente no operador identificado acima como o gargalo real, quase sempre é mais barato e mais rápido que subir o parallelism global até o operador mais lento dar conta.

Duração do checkpoint é um segundo sinal, independente

Duração de checkpoint crescendo com o tempo — separado do backpressure — geralmente significa que o tamanho do estado está crescendo mais rápido do que seu parallelism/recursos conseguem fazer checkpoint dentro do intervalo configurado. Se não for tratado, isso eventualmente causa timeouts de checkpoint, que por sua vez podem disparar reinícios desnecessários do job. Esse é um indicador antecedente que vale a pena observar mesmo quando o backpressure parece bem hoje.

Configuração de watermark causa uma versão específica e traiçoeira disso

Uma estratégia de watermark desatualizada ou permissiva demais pode fazer com que janelas segurem estado por muito mais tempo do que o pretendido, o que parece um problema de parallelism/capacidade mas na verdade é um problema de lógica de janelamento — aumentar o parallelism não vai corrigir isso, só corrigir a configuração de watermark/allowed-lateness vai.