Contrapressão

O Flink usa contrapressão para adaptar a velocidade de processamento de operadores individuais.

O operador pode ter dificuldade em continuar processando o volume de mensagens que recebe por vários motivos. A operação pode exigir mais CPU recursos do que o operador tem disponíveis. O operador pode esperar que as operações de E/S sejam concluídas. Se um operador não consegue processar eventos com rapidez suficiente, isso gera contrapressão nos operadores a montante, alimentando o operador lento. Isso faz com que os operadores a montante diminuam a velocidade, o que pode propagar ainda mais a contrapressão para a fonte e fazer com que a fonte se adapte ao throughput geral do aplicativo, diminuindo também a velocidade. Você pode encontrar uma descrição mais detalhada da contrapressão e de como ela funciona em Como o Apache Flink™ lida com a contrapressão.

Saber quais operadores em um aplicativo são lentos fornece informações cruciais para entender a causa raiz dos problemas de desempenho no aplicativo. As informações de contrapressão são expostas por meio do painel do Flink. Para identificar o operador lento, procure o operador com um valor alto de contrapressão que esteja mais próximo de um coletor (operador B no exemplo a seguir). O operador que causa a lentidão é então um dos operadores a jusante (operador C no exemplo). O B pode processar eventos mais rapidamente, mas sofre contrapressão, pois não pode encaminhar a saída para o verdadeiro operador lento C.

A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)

Depois de identificar o operador lento, tente entender por que ele é lento. Pode haver uma infinidade de motivos e, às vezes, não é óbvio o que está errado e pode exigir dias de depuração e criação de perfil para ser resolvido. A seguir estão alguns motivos óbvios e mais comuns, alguns dos quais são explicados mais detalhadamente abaixo:

• O operador está fazendo E/S lentas, por exemplo, chamadas de rede (considere usar o AsynciO em vez disso).

• Há uma distorção nos dados, e um operador está recebendo mais eventos do que outros (verifique observando o número de mensagens de entrada/saída de subtarefas individuais (ou seja, instâncias do mesmo operador) no painel do Flink.

• É uma operação que consome muitos recursos (se não houver distorção de dados, considere escalar para trabalho limitado a CPU /memória ou aumentar ParallelismPerKPU para trabalho limitado a E/S)

• Registro de logs extensivo no operador (reduza o registro de logs ao mínimo para o aplicativo de produção ou considere enviar a saída de depuração para um fluxo de dados).

Testando a produtividade com o coletor de descarte

O Coletor de descarte simplesmente ignora todos os eventos que recebe enquanto ainda executa o aplicativo (um aplicativo sem nenhum coletor falha na execução). Isso é muito útil para testes de throughput, criação de perfis e para verificar se o aplicativo está escalando adequadamente. Também é uma verificação de integridade muito pragmática para verificar se os coletores estão causando contrapressão ou o aplicativo (mas verificar apenas as métricas de contrapressão geralmente é mais fácil e direto).

Ao substituir todos os coletores de um aplicativo por um coletor de descarte e criar uma fonte simulada que gera dados que se assemelham aos dados de produção, você pode medir o throughput máximo do aplicativo para uma determinada configuração de paralelismo. Em seguida, você também pode aumentar o paralelismo para verificar se o aplicativo está escalando adequadamente e não tem um gargalo que só surge com um throughput mais alto (por exemplo, devido à distorção de dados).