Tous vos types de job
Python, Spark, SQL, bash, notebooks, SAS et dbt, chacun dans son image d’exécution, avec ses bibliothèques et ses secrets.
← graal Data Platform
Orchestration et calcul
Des jobs et des workflows qui tournent seuls
Un job se déclare en quelques champs, un workflow s’assemble en graphe de dépendances, et la planification se règle sans une ligne de YAML. Chaque run s’exécute dans votre Kubernetes, à la taille que vous avez choisie, et se suit en direct.
Un run suivi en direct : qui l’a déclenché, depuis quand, et ses logs ligne à ligne.
Interface réelle de la console graal, non retouchée ; données de démonstration fictives (locataire energie-demo — personnes, projets et jetons inventés).
Capacités clés
Tout ce qui tourne, au même endroit
Des workflows en graphe
Vous enchaînez des jobs de types différents, vous posez les dépendances, et chaque étape a sa propre politique de reprise.
Cron, événements et backfills
Une expression cron, l’arrivée d’un fichier dans un bucket, ou un rattrapage sur une plage de dates : chaque run connaît sa date logique.
Reprises et alertes
Nombre de tentatives et durée maximale par job ; une alerte part à l’échec ou au succès, vers les destinataires que vous choisissez.
Spark distribué
Un driver et ses workers, créés pour le run et détruits après lui, sur votre Kubernetes. Aucun cluster Spark permanent à entretenir.
GPU et types d’instance
Vous choisissez un type d’instance par job, GPU compris. Les quotas du projet bornent ce qu’un run peut demander.
Comment ça marche
Du code au run planifié
Étape 01
Déclarer le job
Un type, un fichier de code, une image, un type d’instance. Les paramètres et les secrets sont injectés par référence.
Étape 02
Assembler et planifier
Vous reliez les jobs en workflow et choisissez le déclencheur : cron, événement, ou lancement à la demande.
Étape 03
Suivre chaque run
Logs en direct, événements étape par étape, fichiers produits et métriques : chaque run garde sa trace.
Chaque run est isolé
Un run naît avec ses propres conteneurs, son identité et ses règles réseau, et disparaît avec eux. Il ne voit que les secrets de son projet et ne joint que les destinations autorisées. Les conteneurs tournent sans privilèges, sous le profil de sécurité restreint de Kubernetes.
La planification vit dans la Data Platform
Les cron, les déclencheurs et les workflows sont tenus par la Data Platform elle-même, pas par un ordonnanceur de plus à installer. Une planification se modifie dans la console, par l’API ou par un agent, et prend effet au prochain déclenchement.
Standards et intégrations
Des moteurs ouverts
- Kubernetes
- Apache Spark
- Python
- bash
- SQL
- Trino
- dbt
- Jupyter
- SAS
- cron
- GPU
Gouvernance
Qui lance quoi, et à quel coût
- Droits de création, de lancement et de planification distincts, par projet
- Quotas de vCPU, de mémoire et de GPU vérifiés avant chaque run
- Chaque run est attribué à une personne ou à un agent, et son coût au projet
Questions fréquentes
Pouvons-nous reprendre nos jobs existants ?
Oui. Un script Python, un job Spark ou un projet dbt se dépose tel quel ; vos enchaînements se recréent en workflow.
Faut-il un cluster Spark à part ?
Non. Spark s’exécute sur votre Kubernetes, dimensionné run par run : un driver et ses workers, puis plus rien.
Comment se règlent les reprises et les alertes ?
Job par job : le nombre de tentatives, la durée maximale, et les destinataires de l’alerte à l’échec ou au succès. Les logs de chaque tentative restent dans la console.
Comment recalculer un historique ?
Par un backfill : vous choisissez une plage de dates, la Data Platform crée un run par date, sans doublon, sous les quotas du projet.
Planifiez votre premier workflow
Un job, un workflow à deux étapes, une planification : en démonstration, de bout en bout.