Traiter efficacement de nombreux fichiers en utilisant le traitement des tâches

Supposons que vous disposiez de nombreux fichiers stockés dans un compartiment IBM Cloud Object Storage et que vous souhaitiez utiliser le traitement par lots dans Code Engine. L'objectif est de lire les fichiers d'un compartiment, de les manipuler et de les stocker dans un autre compartiment Object Storage de la manière la plus efficace. Supposons que vous ayez 2000 fichiers dans le compartiment d'entrée chaque jour. Tous les fichiers ont un nom de fichier différent et les noms de fichier commencent par un caractère alphabétique (A-Z, a-z).

Lorsque vous planifiez une solution pour ce scénario, vous commencez par penser à une solution basée sur les événements. Dans ce cas, pour chaque fichier écrit dans le compartiment Object Storage d'entrée, un événement est créé et une application Code Engine est appelée. A l'aide d'événements, un fichier unique peut déclencher un traitement individuel, ce qui peut s'avérer inefficace pour de nombreux fichiers.

L'exécution d'un travail par lots peut-elle être une meilleure approche? Oui, c'est possible ! Voyons pourquoi les travaux par lots sont mieux adaptés à la gestion de plusieurs fichiers ensemble.

1. Déterminez une approche pour diviser l'ensemble de fichiers en flux parallèles. Divisons les fichiers en fonction du premier caractère du nom de fichier. Avec cette approche, vous pouvez avoir 26 flux, chaque flux étant responsable des fichiers qui commencent par un caractère spécifique. Vous pouvez identifier un flux spécifique en lisant la variable d'environnement JOB_INDEX automatiquement injectée d'une instance de travail en cours d'exécution. Voir Variables d'environnement injectées automatiquement pour les travaux. Pour cet exemple, vous pouvez configurer vos instances de travail en spécifiant le nombre d'instances en tant que 26 ou les index de tableau en tant que 0-25.

   Un index de 0 à 25 est affecté à chaque instance de travail en cours d'exécution. Dans votre code, utilisez le modèle suivant pour distribuer les données d'entrée aux instances de travail.

   • L'instance de travail avec JOB_INDEX=0 fonctionne sur les fichiers qui commencent par A ou a
   • L'instance de travail avec JOB_INDEX=1 fonctionne sur les fichiers qui commencent par B ou b
   • L'instance de travail avec JOB_INDEX=2 fonctionne sur les fichiers qui commencent par C ou c
   • [D ... y]
   • L'instance de travail avec JOB_INDEX=25 fonctionne sur les fichiers qui commencent par Z ou z

   Etant donné que chaque flux traite plusieurs fichiers, définissez la longueur de la file d'attente d'un flux comme le nombre de fichiers traités par le flux unique.

2. Dans Code Engine, créez le travail et sa configuration.

   • Indiquez les index de tableau de travaux sous la forme 0-25, qui représente les 26 flux parallèles.
   • Indiquez les ressources d'UC et de mémoire pour votre travail ou prenez les valeurs par défaut. Chaque index de travail obtient les mêmes ressources d'UC et de mémoire que celles que vous spécifiez pour le travail ; par exemple, 1 vCPU et 4 Go de mémoire.

3. Exécutez votre travail. Dans la console Code Engine, vous pouvez afficher le nombre d'index de travaux en attente, en cours d'exécution et terminés. Le travail se termine lorsque le dernier index de travail termine son exécution.

Traiter un sous-ensemble de données et attribuer dynamiquement le travail à des instances d'exécution parallèles

Supposons que vous ne souhaitiez pas être limité à un nombre spécifique d'instances parallèles.

Dans le scénario précédent, 26 flux parallèles ont été définis et les exécutions de travail qui ont été soumises ont été exécutées dans les 26 flux parallèles définis.

Toutefois, supposons que vous ne souhaitiez pas être limité à un nombre spécifique d'instances parallèles et que vous souhaitiez exécuter un travail qui affecte dynamiquement des flux de travaux à une instance d'exécution de travail particulière. Dans ce cas, vous pouvez utiliser les variables d'environnement JOB_INDEX et JOB_ARRAY_SIZE pour dériver une valeur qui détermine quel flux de travaux est traité. Ces variables d'environnement sont injectées automatiquement pour les travaux.

• La variable d'environnement JOB_INDEX est la valeur de l'index d'une instance d'exécution de travail spécifique.
• La variable d'environnement JOB_ARRAY_SIZE indique le nombre d'instances de travail à exécuter en parallèle. Cette valeur est spécifiée directement en tant que taille de tableau d'exécution de travail, ou calculée en comptant les index de tableau spécifiés.

Par exemple, supposez que vous avez configuré une taille de tableau de 10 de sorte que chaque instance d'exécution de travail fonctionne sur 10% des données globales (10 instances d'exécution de travail exécutées en parallèle). Avec ce paramètre de configuration, la variable d'environnement JOB_INDEX détermine lequel des 10% de blocs de données est utilisé et la valeur calculée pour JOB_ARRAY_SIZE est 10.

Toutefois, supposez que vous souhaitiez réexécuter 3 des 10 instances d'exécution de travail initiales car elles ont échoué précédemment. Les autres 70% des données ont été traitées avec succès. Vous souhaitez spécifier les 3 index en échec particuliers lorsque vous soumettez à nouveau l'exécution de travail. Supposons que vous souhaitiez réexécuter les index 3, 7 et 9.

Pour cette nouvelle exécution de travail, supposez que vous ne mettez à jour que les index de tableau ; par exemple, "3, 7, 9". Etant donné que la valeur de la variable d'environnement JOB_ARRAY_SIZE est automatiquement calculée lorsque des index de tableau sont spécifiés à la place de la taille de tableau, la valeur de JOB_ARRAY_SIZE est désormais 3 au lieu de 10, puisque 3 index de tableau ont été spécifiés.

A la place, pour vous assurer que l'action de soumission (ou de nouvelle soumission) de votre exécution de travail traite les blocs de données corrects pour les index spécifiés 3, 7 et 9, vous pouvez remplacer la valeur automatiquement calculée de la variable d'environnement JOB_ARRAY_SIZE à l'aide de l'option --array-size-var-override de l'interface de ligne de commande ou en spécifiant une valeur personnalisée dans la zone d'entrée JOB_ARRAY_SIZE de la console.

En définissant la valeur de remplacement de la taille du tableau personnalisé sur 10, les instances d'exécution de tâches calculent correctement la taille du bloc (10 %) et les instances d'exécution de tâches soumises à nouveau traitent les données que vous souhaitez (indices 3, 7, et 9). Vous pouvez utiliser cette option pour appliquer une valeur de taille de tableau constante pour les scénarios de réexécution de travail, où seules certaines instances de travail sont soumises ou soumises à nouveau.

Une fois que vous avez implémenté cette approche d'exécution de travail, vous pouvez augmenter ou diminuer dynamiquement le nombre d'exécutions de travail parallèles.

Contrairement à l'approche consistant à utiliser la variable d'environnement JOB_INDEX pour définir la relation de flot de travaux d'exécution de travail, cette méthode de remplacement de la variable d'environnement JOB_ARRAY_SIZE pour affecter dynamiquement des flots de travaux est plus flexible et vous permet d'adapter une exécution de travail particulière à vos besoins.

Avantages de l'exécution de travaux par lots parallèles

Cette approche de la mise en oeuvre de travaux par lots parallèles offre des avantages.

• Initialisation réduite-Etant donné qu'un index de travail traite des fichiers avec des caractères de début similaires, une seule configuration d'initialisation ou de connexion est requise par index de travail. Cette approche permet d'économiser des ressources et des coûts par rapport à une initialisation individuelle par fichier. Avec la solution de travail parallèle, il y a 26 initialisations au lieu de 2000.

• Utilisation efficace des ressources-En divisant la tâche en flux parallèles à exécution plus longue, cette solution utilise les ressources disponibles plus efficacement, tout en maximisant la vitesse de traitement.

Remarques relatives à la planification de travaux par lots parallèles

Tenez compte des points suivants lorsque vous planifiez des solutions de travail par lots parallèles.

• Equilibrage des index de travaux parallèles et de la longueur de la file d'attente-Il est essentiel de trouver un bon équilibre entre le nombre de flux (index de travaux parallèles) et la longueur de la file d'attente. Trop peu d'index de travail ne peuvent pas utiliser complètement les ressources disponibles, alors qu'un trop grand nombre d'index peut augmenter le traitement d'initialisation et la charge sur les services de cloud, tels que Object Storage. Cet effet peut entraîner des limites de débit lorsque vous appelez d'autres services de cloud.

• Temps de traitement de travail similaire-Lorsque vous planifiez votre solution, tenez compte du fait que chaque index de travail prend à peu près le même temps pour terminer sa tâche. Evitez les scénarios où un index de travail prend beaucoup plus de temps que d'autres, car le temps de traitement peut entraîner des inefficacités dans l'utilisation des ressources et augmenter le temps de traitement du travail.

• Utilisation de plusieurs travaux-Pour le scénario précédent, une approche différente consiste à utiliser plusieurs travaux. Ces travaux multiples ne reposent pas sur les index de tableau configurés. Au lieu de cela, envisagez de créer 2 travaux par lots, un pour les fichiers qui commencent par A - Z et un autre pour les fichiers qui commencent par a - z. Sans aucune modification de votre code, vous pouvez déclencher ces 2 travaux en parallèle ou séquentiellement, en fonction de vos besoins de traitement et de la disponibilité des ressources.

• Mécanisme de déclenchement de travail-Vous pouvez choisir de déclencher le travail avec un abonnement cron à des intervalles spécifiques, ou avec une application de déclenchement qui surveille le compartiment Object Storage pour les nouveaux fichiers et lance le traitement par lots selon les besoins. En fonction de votre scénario, vous pouvez optimiser l'utilisation de Code Engine à des fins de rentabilité par rapport au temps de réponse pour déterminer la vitesse de traitement des fichiers après leur écriture dans le compartiment.