Contre-pression

Flink utilise la contre-pression pour adapter la vitesse de traitement de chaque opérateur.

L’opérateur peut avoir du mal à traiter le volume de messages qu’il reçoit pour de nombreuses raisons. L'opération peut nécessiter plus de CPU ressources que celles dont dispose l'opérateur. L'opérateur peut attendre la fin des opérations d'E/S. Si un opérateur ne parvient pas à traiter les événements assez rapidement, cela crée une contre-pression chez les opérateurs en amont qui alimentent l’opérateur lent. Cela ralentit les opérateurs en amont, ce qui peut propager davantage la contre-pression vers la source et amener la source à s’adapter au débit global de l’application en ralentissant également. Vous trouverez une description plus détaillée de la contre-pression et de son fonctionnement dans How Apache Flink™ handles backpressure.

Le fait de savoir quels opérateurs d’une application sont lents vous fournit des informations cruciales pour comprendre la cause première des problèmes de performances de l’application. Les informations sur la contre-pression sont affichées via le tableau de bord Flink. Pour identifier l’opérateur lent, recherchez l’opérateur présentant une valeur de contre-pression élevée qui est le plus proche d’un récepteur (l’opérateur B dans l’exemple suivant). L’opérateur à l’origine de la lenteur est alors l’un des opérateurs en aval (l’opérateur C dans l’exemple). L’opérateur B peut traiter les événements plus rapidement, mais il est soumis à une contre-pression, car il ne peut pas transmettre le résultat à l’opérateur C lent.

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

Une fois que vous avez identifié l’opérateur lent, essayez de comprendre pourquoi il est lent. Il peut y avoir une multitude de raisons. Parfois, le problème n’est pas évident et peut nécessiter plusieurs jours de débogage et de profilage pour être résolu. Voici quelques raisons évidentes et courantes, dont certaines sont expliquées plus en détail ci-dessous :

• L’opérateur effectue des opérations d’I/O lentes, par exemple des appels réseau (pensez plutôt à utiliser AsyncIO à la place).

• Il y a une asymétrie dans les données et un opérateur reçoit plus d’événements que les autres (vérifiez en regardant le nombre de messages entrée/sortie de sous-tâches individuelles (c’est-à-dire les instances du même opérateur) dans le tableau de bord Flink.

• Il s'agit d'une opération gourmande en ressources (s'il n'y a pas de distorsion des données, pensez à augmenter la taille pour le travail lié à CPU /memory ou à augmenter ParallelismPerKPU pour le travail lié aux E/S)

• Journalisation étendue dans l’opérateur (réduisez la journalisation au minimum pour les applications de production ou envisagez plutôt d’envoyer les résultats de débogage vers un flux de données).

Débit de test avec l'évier de mise au rebut

Discarding Sink ignore simplement tous les événements qu’il reçoit pendant l’exécution de l’application (une application sans récepteur ne s’exécute pas). Cela est très utile pour les tests de débit, le profilage et pour vérifier si l’application est correctement mise à l’échelle. Il s’agit également d’un contrôle de santé très pragmatique pour vérifier si les récepteurs sont à l’origine de la contre-pression ou cela vient de l’application (mais il est souvent plus facile et plus simple de vérifier les métriques de contre-pression).

En remplaçant tous les récepteurs d’une application par un récepteur de rejet et en créant une source fictive qui génère des données similaires aux données de production, vous pouvez mesurer le débit maximal de l’application pour un certain paramètre de parallélisme. Vous pouvez également augmenter le parallélisme pour vérifier que l’application évolue correctement et qu’elle ne présente pas de goulot d’étranglement qui n’apparaît qu’à un débit plus élevé (par exemple, en raison d’une asymétrie de données).