Anteriormente, o Amazon Managed Service for Apache Flink era conhecido como Amazon Kinesis Data Analytics for Apache Flink.
As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
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 recursos de CPU 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
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 aumentar a escala horizontalmente para o trabalho vinculado à CPU/memória ou aumentar
ParallelismPerKPU
para o trabalho vinculado à 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
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).