Realtime Compute for Apache Flink:Configurer les ressources d'un job

Utilisez les formules suivantes pour calculer les besoins en ressources :

• Nombre d'UC = MAX(CPU total pour JobManager et TaskManagers, Mémoire totale pour JobManager et TaskManagers / 4)

• Nombre réel de TaskManagers = ceil(Parallélisme / Slots par TaskManager)

• Slots réels par TaskManager = Parallélisme / Nombre réel de TaskManagers

Par exemple, supposons que vous définissiez le parallélisme sur 12 et les slots par TaskManager sur 4.

Dans cet exemple, le Job Manager CPU est de 2 cœurs, la JobManager Memory est de 4 GiB, le Task Manager CPU est de 2 cœurs et la TaskManager Memory est de 4 GiB.

Dans la console Realtime Compute for Apache Flink, le nombre réel de TaskManagers est de 3, et chaque TaskManager dispose de 4 slots.

Le nombre réel de TaskManagers et de slots par TaskManager se calcule comme suit :

1. Nombre réel de TaskManagers = ceil(Parallélisme configuré / Slots configurés par TaskManager) = ceil(12 / 4) = 3.

2. Slots réels par TaskManager = Parallélisme / Nombre réel de TaskManagers = 12 / 3 = 4.

Configurer les ressources de base

Configurer les ressources des slots

1. Sous Expert, cliquez sur Get Plan Now pour récupérer le graphe du plan de ressources.

2. Cliquez sur l'icône Modifier sur une boîte de slot. Le graphe du plan de ressources généré affiche plusieurs boîtes slot, chacune contenant les informations de l'opérateur VERTEX et une valeur PARALLELISM.

3. Modifiez la configuration du slot. Dans la boîte de dialogue, vous pouvez configurer les paramètres CPU, Heap Memory, Off-Heap Memory et parallelism.

   Le parallélisme que vous définissez ici s'applique à tous les opérateurs de ce Slot Sharing Group. Après avoir enregistré la configuration, le système effectue automatiquement les actions suivantes :

   • Définit le même parallélisme pour tous les opérateurs de ce Slot Sharing Group.

   • Alloue la mémoire requise pour le backend d'état, Python et les opérateurs en fonction de la logique de calcul du job. Cette allocation est automatique.

   Remarque

   • Pour un nœud Source, nous recommandons de définir un parallélisme proportionnel au nombre de partitions. Autrement dit, le parallélisme doit être un diviseur du nombre de partitions. Par exemple, si un topic Kafka comporte 16 partitions, définissez le parallélisme sur 16, 8 ou 4 pour éviter la dissymétrie des données.

   • Une définition trop faible du parallélisme d'un nœud Source peut créer un goulot d'étranglement, car une seule source risque de lire trop de données et de réduire le débit du job.

   • Pour les autres nœuds, définissez le parallélisme en fonction de leur trafic de données, en attribuant un parallélisme plus élevé aux nœuds générant plus de trafic.

   Remarque

   En mode expert, la boîte de dialogue de configuration des slots expose les paramètres CPU, Heap Memory et Off-Heap Memory pour une configuration manuelle. Les autres composants mémoire, y compris la surcharge JVM, les tampons réseau et la mémoire du framework, sont automatiquement alloués par le système selon leurs proportions par défaut. Ces composants sont pré-alloués au démarrage du TaskManager et ne sont pas ajustés dynamiquement pendant l'exécution du job.

   Si vous rencontrez des erreurs de mémoire insuffisante causées par ces composants alloués automatiquement, configurez les paramètres suivants dans le champ Other Configurations sous Running Parameters Configuration :

   • taskmanager.memory.jvm-overhead.fraction : Taille de la surcharge JVM exprimée en fraction de la mémoire totale du TaskManager. Valeur par défaut : 0.1 (10 %).

   • taskmanager.memory.jvm-overhead.max : Taille maximale de la surcharge JVM.

   • taskmanager.memory.jvm-overhead.min : Taille minimale de la surcharge JVM.

4. Cliquez sur OK.

Configurer les ressources des opérateurs

Par défaut, tous les opérateurs partagent un seul Slot Sharing Group, ce qui empêche de configurer leurs ressources individuellement. Pour configurer les ressources d'un opérateur spécifique, activez l'option Multiple SSG. Cela attribue un slot indépendant à chaque opérateur, vous permettant ainsi de configurer ses ressources sur ce slot.

1. Sous l'onglet Configuration, cliquez sur Edit dans la section Resources, puis définissez le paramètre Mode sur Expert.

2. (Facultatif) Si aucun plan de ressources n'est affiché, cliquez sur Get Plan Now.

   Par défaut, le graphe du plan de ressources généré affiche tous les opérateurs dans une seule boîte slot.

3. Activez l'interrupteur Multiple SSG puis cliquez sur Re-fetch.

   Cette action divise les opérateurs du groupe de partage en slots individuels.

4. Cliquez sur l'icône Modifier sur la boîte de slot correspondant à l'opérateur cible, puis modifiez les ressources de l'opérateur.

   Dans la boîte de dialogue Modify slot, vous pouvez configurer les paramètres CPU, Heap Memory, Off-Heap Memory et parallelism.

5. Cliquez sur OK.

Parallélisme des opérateurs, stratégie de chaînage et paramètres d'expiration de l'état

Vous pouvez configurer le parallélisme, la stratégie de chaînage et les State Expiration Time Settings pour des opérateurs individuels.

1. Cliquez sur l'icône Développer sur la boîte VERTEX cible.

   Après développement, la boîte VERTEX affiche chaque nœud d'opérateur, sa valeur PARALLELISM et une icône Modifier à côté de chaque opérateur.

   Remarque

   Vous pouvez cliquer sur l'icône Modifier sur un VERTEX pour définir le parallélisme de tous les opérateurs de ce VERTEX en lot.

2. Cliquez sur l'icône Modifier pour l'opérateur.

3. Configurez les ressources de l'opérateur.

   Le tableau suivant décrit les paramètres.

   Paramètre	Description
   Parallélisme	Parallélisme de l'opérateur.
   Stratégie de chaînage	Le chaînage connecte plusieurs opérateurs en une seule tâche, améliorant ainsi les performances en réduisant les frais généraux liés au transfert et à la sérialisation des données. Toutefois, vous pouvez rompre une chaîne pour obtenir un contrôle plus fin du flux d'exécution. Les stratégies suivantes sont disponibles : ALWAYS (Par défaut) : L'opérateur peut toujours être chaîné avec les opérateurs amont et aval. HEAD : L'opérateur actuel agit comme la tête d'une chaîne. Il n'est pas chaîné avec les opérateurs amont mais reste chaîné avec les opérateurs aval. NEVER : L'opérateur actuel n'est chaîné avec aucun opérateur amont ou aval.
   State Expiration Time Settings	Vous pouvez définir le délai d'expiration en secondes, minutes, heures ou jours. Par défaut, l'opérateur hérite du délai d'expiration de l'état du job, qui est par défaut de 1,5 jour. Pour configurer le délai d'expiration au niveau du job, consultez la rubrique Configurer les paramètres d'exécution. Remarque Cette fonctionnalité est prise en charge uniquement dans les versions Ververica Runtime (VVR) 8.0.7 et ultérieures. La configuration TTL est prise en charge uniquement pour les opérateurs avec état. L'expiration de l'état est un mécanisme de nettoyage approximatif. Le système ne garantit pas que l'état expiré est supprimé immédiatement après l'écoulement du TTL. Le temps de nettoyage réel dépend des modèles d'accès à l'état en arrière-plan et des politiques de nettoyage.

4. Cliquez sur OK.

La définition du parallélisme équivaut-elle à la consommation du même nombre d'UC ?

Non. Le Parallélisme désigne le nombre de tâches concurrentes exécutées dans un job. L'UC (Unité de calcul) est l'unité de facturation et de ressource utilisée par Realtime Compute for Apache Flink. Il n'existe pas de relation 1:1 entre les deux.

La consommation totale d'UC se calcule à l'aide de la formule suivante :

Consommation totale d'UC = Parallélisme × UC par tâche

Les UC consommées par chaque tâche sont déterminées par la spécification de ressource par slot configurée pour le job. L'augmentation du parallélisme accroît la consommation totale d'UC, mais cette augmentation est proportionnelle à la spécification d'UC par tâche, et non à un simple ratio 1:1.

Pourquoi SET 'parallelism.default' ne prend-il pas effet dans les jobs SQL ?

L'utilisation directe de SET 'parallelism.default' = 'N'; dans les instructions de job SQL n'est pas effective dans Realtime Compute for Apache Flink. Pour configurer le parallélisme, utilisez l'une des méthodes suivantes :

1. Définissez le parallélisme dans la clause WITH de l'instruction SQL concernée.

2. Modifiez le parallélisme dans l'interface de modification de la configuration des ressources sur la page O&M > Deployments.

Que faire lorsqu'un opérateur Print Sink ou Join provoque une insuffisance de ressources ou de mauvaises performances ?

L'action appropriée dépend du symptôme spécifique :

• Le Print Sink provoque un manque de ressources du TaskManager — Ce problème ne peut pas être résolu par le seul réglage des paramètres. Évaluez vos besoins en ressources en fonction du volume de données réel, vérifiez que les types de champs de la table source sont correctement définis (par exemple, utilisez BIGINT au lieu de STRING le cas échéant) et allouez suffisamment de ressources TaskManager pour prendre en charge la charge de débogage du Print Sink.

• Les performances de Join sont médiocres malgré une faible utilisation de la mémoire — Augmentez le nombre d'UC. Toutefois, si la cause profonde est une dissymétrie des données, l'ajout de ressources peut ne pas résoudre le problème. Résolvez d'abord le problème de dissymétrie des données, puis évaluez si des ressources supplémentaires sont nécessaires.

• Le job redémarre fréquemment avec une latence de bout en bout élevée — Si le job se trouve dans une phase de synchronisation complète de l'état suite à un redémarrage sans état, essayez de définir le nombre de slots sur 1, de configurer un parallélisme approprié séparément et d'utiliser une spécification TaskManager de 1 cœur et 4 GiB avec une concurrence modérée (par exemple, 10) pour tester et optimiser les performances.