Configurer les préférences d'exécution des jobs
Chaque action ou workflow du Data Processing Engine dispose de plusieurs paramètres de configuration gérables via l'onglet Preferences
Objectif
Chaque action ou workflow du Data Processing Engine dispose de plusieurs paramètres de configuration gérables via l'onglet Preferences.
Lorsqu'une action est exécutée, elle utilise ces préférences pour s'exécuter.
Lorsqu'un workflow est exécuté, ses préférences remplacent les préférences de toutes les actions qu'il contient. Si une certaine option de préférence est désactivée au niveau du workflow (comme la segmentation ou le perimeter), elle reviendra aux préférences de chaque action pendant l'exécution du workflow.
Ces préférences peuvent être modélisées pour être réutilisées en un clic à chaque fois, en les enregistrant dans un environnement.
Environnements
Les environnements sur la Platform sont un ensemble de préférences prédéfinies que vous pouvez rapidement assigner à vos actions ou workflows, afin de ne pas avoir à les configurer à chaque fois.
En savoir plus sur les environnements
Options de timeout
Les options de timeout ne sont pas modélisées dans un environnement, et doivent être configurées dans les préférences de chaque action/workflow
Timeout
Le timeout est une durée d'exécution après laquelle votre job sera traité comme un échec. La durée du timeout inclut le temps de provisionnement des ressources, le temps de build, et la durée réelle d'exécution du code.
La durée maximale de timeout que vous pouvez définir est de 24 heures, sauf pour les types de jobs suivants où vous pouvez la définir sur null, ce qui signifie infini (aucun timeout ne sera appliqué) :
Si une exécution de job dépasse le délai imparti, elle sera signalée dans la liste des jobs comme un échec dû à un timeout, afin de la différencier des autres sources d'échec.
Arrêter le workflow en cas d'échec
Si l'action est exécutée dans le cadre d'un workflow, et échoue en levant une erreur CRITICAL (qui sera affichée dans les logs), l'activation de cette option interrompra l'exécution du workflow et les stages ou actions suivants ne seront pas exécutés.
Options d'exécution
Compte de service
Chaque action, workflow ou environnement possède un compte de service associé, que l'action/le workflow emprunte lors de son exécution. Ce compte de service agit comme l'identité du job en cours d'exécution, et contrôle le niveau d'accès du job à travers les rôles du compte de service.
Même si vous lancez un job manuellement, son exécution sera authentifiée par le compte de service associé.
Perimeter
Ce paramètre n'est pas disponible pour les actions Custom PySpark.
Lors de l'exécution d'un job de traitement de données, lorsque vous atteignez de gros volumes de données à traiter, il peut être nécessaire de filtrer l'exécution d'une action. Le paramètre perimeter vous permet de définir un champ sur lequel filtrer le périmètre de traitement des données.
Plusieurs modes de perimeter sont disponibles selon la source de données et le type d'action que vous effectuez.
Le périmètre sert notamment à :
- Appliquer un filtre de traitement sur une colonne ;
- Accélérer l'exécution des actions ;
- Soulager la charge demandée à certaines sources de données ;
- Dans un workflow planifié quotidiennement, ne pas traiter les données de tout l'historique, mais seulement celles des X derniers jours.
Comment configurer le perimeter
Niveau de logs
Le niveau de logs définit la liste des logs qui seront stockés pendant l'exécution de l'action ou du workflow. Les différents niveaux vont de debug à critical. Tous les logs situés au-dessus de celui sélectionné (inclus) seront stockés.
Vider automatiquement tous les caches
Lorsque ce paramètre est activé, les caches des composants seront automatiquement vidés après chaque exécution de l'action/du workflow.
En savoir plus sur les caches dans cet article.
Stratégie d'écriture
Cette option n'est disponible que pour les actions Load, Aggregate, Load PySpark, et Aggregate PySpark.
La stratégie d'écriture définit la façon dont l'action écrit les nouvelles données dans la table de destination lorsque des lignes correspondent à des lignes existantes. La correspondance est basée sur les champs identifiants de la table.
Il existe trois stratégies :
- Upsert : l'action fait correspondre les nouvelles données aux données existantes en utilisant tous les champs identifiants. Si une nouvelle ligne a les mêmes champs identifiants qu'une ligne existante, la ligne existante est mise à jour. Sinon, la nouvelle ligne est ajoutée.
- Insert when not matched : si une nouvelle ligne correspond à une ligne existante (en utilisant les champs identifiants), rien n'est fait. Sinon, la nouvelle ligne est ajoutée.
- Insert all : toutes les nouvelles lignes sont insérées dans la table, même si certaines correspondent à des lignes existantes sur leurs champs identifiants. Cela peut créer des doublons.
Les actions Load et Aggregate utilisent Insert all par défaut. Sélectionnez Upsert (ou Insert when not matched) manuellement dans les préférences de l'action si vous souhaitez un comportement de correspondance.
Exemple
Considérons la table users suivante :
Nous exécutons l'action avec ces nouvelles données, en utilisant Firstname + Lastname comme champs identifiants :
Le résultat dépend de la stratégie d'écriture.
Upsert : Alice correspond à une ligne existante et est mise à jour ; Charles est nouveau et ajouté :
Insert when not matched : Alice correspond à une ligne existante, donc rien n'est fait ; Charles est nouveau et ajouté :
Insert all : les deux nouvelles lignes sont insérées telles quelles, laissant un doublon pour Alice :
Variables d'environnement
Cela n'est disponible que pour les actions Custom, les workflows, et les environnements.
Les variables d'environnement sont des paires clé-valeur que vous pouvez modéliser et injecter dans vos actions personnalisées, afin d'éviter de coder en dur les valeurs dans votre script personnalisé. Elles sont enregistrées dans l'objet dictionnaire PARAMS du package forepaas.core.settings (disponible dans le SDK).
Un extrait de code pour un cas d'usage typique est disponible sur cette page.
Les variables d'environnement ne passent pas par un cycle de vie KMS et ne doivent donc pas être utilisées pour stocker et injecter des secrets et des identifiants.
Déclencheurs
Les déclencheurs ne sont pas modélisés dans un environnement, et doivent être configurés dans les préférences de chaque action/workflow.
Avec les déclencheurs, vous pouvez configurer vos jobs pour qu'ils s'exécutent automatiquement. Les usages typiques incluent le lancement du job en accédant à un endpoint API, ou en planifiant des déclencheurs temporels (par exemple pour exécuter vos jobs tous les jours à minuit).
Déclencheur endpoint API
Cet endpoint vous permet de déclencher le job via API.
Il est toujours disponible via le déclencheur nommé Launch API Endpoint. Cliquez dessus pour voir les détails de l'endpoint.
Afin de déclencher votre job, vous devrez d'abord vous authentifier avec l'endpoint Authentication, puis déclencher le job avec l'endpoint Launch Job.
- Vous devez saisir vos clés API et Secret dans les détails du déclencheur, puis copier le texte de l'endpoint Authentication. Une fois connecté, vous obtiendrez un token.
- Saisissez ce token dans l'endpoint Launch job, puis accédez-y pour lancer votre job.
Déclencheur temporel
Utilisez les déclencheurs CRON pour planifier des exécutions de votre action ou workflow selon une période prédéfinie.
Vous pouvez utiliser le Complete mode pour définir la configuration visuellement, ou le Advanced mode pour des expressions CRON personnalisées. La configuration en mode Advanced suit la syntaxe CRON (décrite en détail ici).
Vous pouvez désactiver un déclencheur cron pour mettre en pause les exécutions planifiées, ou le réactiver quand vous souhaitez que la planification reprenne, sans perdre la configuration du déclencheur.
Resources
Modes d'exécution
Il existe deux modes d'exécution disponibles dans la page Preferences :
- Serverless : ressources de calcul déployées à la volée.
- Always-up : instances dédiées toujours actives pour exécuter rapidement vos jobs quand vous le souhaitez.
Serverless
Par défaut, chaque job que vous exécutez sur la Platform est exécuté avec le mode Serverless. Un environnement d'exécution est déployé lorsque vous démarrez l'exécution du job, et il est supprimé une fois cette exécution terminée.
Vous serez facturé pour :
- Les ressources de calcul utilisées pour effectuer la tâche.
En mode Serverless, votre environnement d'exécution n'est actif que pendant l'exécution de la tâche, car une fois la tâche terminée, il est automatiquement arrêté.
Always-up
Cette fonctionnalité est actuellement en version Alpha, des instabilités peuvent survenir.
Lorsque vous activez le mode Always-up, un environnement de calcul dédié est déployé pour l'action/le workflow/l'environnement concerné. Il restera déployé jusqu'à ce que vous remettiez le mode d'exécution sur Serverless, afin que vous n'ayez pas à attendre son déploiement à chaque fois que vous exécutez le job concerné.
Vous serez facturé pour :
- Les ressources de calcul utilisées pendant la durée où l'environnement d'exécution était actif (cela inclut le temps pris pour effectuer les jobs).
Avec le mode Always-up, votre environnement d'exécution NE sera PAS automatiquement supprimé une fois l'exécution du job terminée. Vous devez remettre le mode d'exécution sur Serverless pour l'arrêter.
Si vous modifiez la configuration d'une action/d'un workflow défini en mode Always-up, elle sera mise à jour selon un mode blue-green complet : le déploiement attendra que toutes les tâches en attente actuelles soient terminées avant de s'arrêter proprement pour la mise à jour.
Il est recommandé d'utiliser le mode d'exécution Always-up sur les environnements plutôt que sur des actions/workflows individuels, afin de réutiliser les ressources pour plusieurs charges de travail.
Dimensionnement des ressources
Vous pouvez découvrir tout ce qu'il faut savoir sur le dimensionnement de votre puissance de calcul dans l'article dédié ci-dessous.
Comment dimensionner les ressources de vos jobs
Options de parallélisation
Segmentation
Ce paramètre n'est pas disponible pour les actions Custom PySpark.
Les options de segmentation vous permettent de définir comment un job sera découpé en plusieurs tâches selon des critères spécifiques. Une fois découpée, la charge de travail du job peut ensuite être distribuée sur plusieurs workers en parallèle (calcul parallèle).
Parmi les usages les plus courants, la segmentation vous permet de :
- Appliquer un filtre de traitement spécifique à une colonne ;
- Accélérer le temps d'exécution des actions en parallélisant le traitement sur plusieurs workers en parallèle et en soulageant la charge sur les connectors de source de données ;
- Dans un workflow planifié quotidiennement par exemple, ne pas ingérer tout l'historique des données à chaque exécution de l'action Load, mais filtrer uniquement sur le(s) dernier(s) jour(s).
Comment configurer la segmentation
Exécutions concurrentes
Cette option permet à l'action/au workflow d'être exécuté plusieurs fois simultanément (au lieu de renvoyer une erreur si une exécution est déclenchée alors qu'une autre est déjà en cours).
En mode Serverless, chaque exécution concurrente utilisera la puissance de calcul allouée pour le job.
En mode Always-up, plusieurs exécutions concurrentes sont distribuées sur les workers disponibles en parallèle (calcul parallèle).
Plusieurs exécutions concurrentes ne peuvent être déclenchées que via API, pas via l'interface graphique.
Langage de développement
Cela n'est disponible que dans les workflows (et la page de configuration des actions Custom).
Cette option vous permet de spécifier quelle version de langage utiliser pour l'ensemble du workflow. Par défaut, un workflow utilisera la plus récente de toutes les versions qu'il contient.
Aller plus loin
Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.
Posez vos questions, faites-nous part de vos commentaires et interagissez directement avec l’équipe qui développe la Data Platform sur le canal Discord dédié.
Si vous avez besoin d'une assistance concernant vos services OVHcloud, créez une demande depuis notre centre d'aide.
Rejoignez notre communauté d'utilisateurs.