Jobs et workflows

Un job s’exécute sans que personne soit devant l’écran : il se planifie, se déclenche sur un événement et se suit après coup. Cette page décrit les types de job, les runs et les workflows de graal Data Platform.

Les types de job

Chaque job a un type, qui décide de ce qu’il exécute et de l’image dans laquelle il tourne.

Type	Ce qu’il exécute	Image
python	un script ou un paquet Python, dépendances installées au démarrage	python
bash	une commande shell, pour les tâches d’exploitation	toolbox
spark	un traitement Spark (spark-submit), dimensionné par type d’instance	spark-py
lowcode	un graphe de l’éditeur low-code, traduit en code	python

Le contrat porte aussi des types spécialisés — docker, dbt, dask, flink, ray —, chacun servi par sa propre image d’exécution. Un type dont l’image n’est pas configurée sur votre installation répond 501 feature_disabled (voir images de runtime).

La création d’un job, pas à pas et en commandes, est dans le démarrage rapide.

Un run, et ce qu’on en voit

Un job lancé produit un run. Pendant son exécution, quatre choses sont lisibles :

• les logs, paginés par curseur — la console les suit en direct, un client d’API les rejoue depuis n’importe quel point ;
• les événements, horodatés : mise en file, démarrage, étape, fin ;
• les métriques du conteneur ;
• les fichiers produits, dans le bucket du projet.

Un run porte un statut (en file, en attente, en cours, réussi, échec, annulé, nouvelle tentative, ignoré) et une durée. C’est ce que montre la liste des jobs. L’API rend le statut de fin d’un run sous la forme complete, failed ou killed ; la console l’affiche « réussi », « échec » ou « annulé ».

Un job porte aussi son délai maximal (timeout_seconds) et son nombre de reprises (max_retries) : un run qui échoue est relancé automatiquement jusqu’à ce nombre.

Workflows et planification

Un workflow enchaîne des étapes en graphe : chaque étape est un job, les dépendances sont des arêtes. Une étape en échec arrête la branche qui en dépend sans emporter les autres. Chaque étape porte ses propres reprises : retries (de 0 à 10 nouvelles tentatives) et retry_delay_seconds (le délai avant une nouvelle tentative, 10 secondes par défaut, 24 heures au plus). Chaque tentative est un nouveau run du job, qui reçoit son numéro dans la variable GRAAL_ATTEMPT.

Un workflow ou un job se déclenche :

• à la main, depuis la console, l’API ou un agent ;
• par une planification cron standard — sur un job, elle se pose par JSON Patch sur le champ schedule (exemple sur la page API REST) ;
• sur un événement : l’arrivée d’un fichier, la fin d’un autre workflow, ou l’appel d’un webhook signé.

Les backfills rejouent un job ou un workflow planifié sur une plage de dates passées, de 1 à 5 exécutions à la fois ; chaque run reçoit la date logique qu’il traite dans la variable GRAAL_LOGICAL_DATE, et un backfill en cours peut être annulé.

Les alertes préviennent par courriel ou par webhook quand un run échoue.

Pour aller plus loin

• Orchestration, la page du site
• Images de runtime
• API REST