Le service géré Amazon pour Apache Flink était auparavant connu sous le nom d’Amazon Kinesis Data Analytics pour Apache Flink.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Asymétrie d’état
Pour les opérateurs dynamiques, c’est-à-dire les opérateurs qui maintiennent l’état de leur logique métier, comme les fenêtres, l’asymétrie de données entraîne toujours une asymétrie d’état. Certaines sous-tâches reçoivent plus d’événements que d’autres en raison de l’asymétrie des données et conservent donc un plus grand nombre de données dans leur état. Cependant, même pour une application dont les partitions sont équilibrées, il peut y avoir une asymétrie dans la quantité de données conservées dans leur état. Par exemple, pour les fenêtres de session, certains utilisateurs et certaines sessions peuvent respectivement être beaucoup plus longs que d’autres. Si les sessions les plus longues font partie de la même partition, cela peut entraîner un déséquilibre de la taille des états conservés par les différentes sous-tâches du même opérateur.
L’asymétrie d’état augmente non seulement la mémoire et les ressources disque requises par les sous-tâches individuelles, mais elle peut également diminuer les performances globales de l’application. Lorsqu’une application atteint un point de contrôle ou un point de sauvegarde, l’état de l’opérateur est conservé dans Amazon S3, afin de protéger l’état contre l’échec d’un nœud ou d’un cluster. Au cours de ce processus (en particulier avec la sémantique unique activée par défaut sur le service géré pour Apache Flink), le traitement s’arrête d’un point de vue externe jusqu’à ce que le point de contrôle/de sauvegarde soit terminé. En cas d’asymétrie des données, le temps nécessaire pour terminer l’opération peut être limité par une seule sous-tâche ayant accumulé un nombre d’états particulièrement élevé. Dans les cas extrêmes, la prise de points de contrôle/de sauvegarde peut échouer parce qu’une seule sous-tâche ne parvient pas à conserver son état.
Tout comme l’asymétrie de données, l’asymétrie d’état peut considérablement ralentir une application.
Pour identifier une asymétrie d’état, vous pouvez utiliser le tableau de bord Flink. Trouvez un point de contrôle ou de sauvegarde récent et comparez la quantité de données stockées pour chaque sous-tâche dans les détails.
