DataWorks:Orchestration de workflows planifiés

Étape 1 : Préparer le moteur de calcul et les données

1. Dans l'espace de travail cible, associez un moteur de calcul MaxCompute.

2. Dans MaxCompute, créez la table suivante pour stocker les résultats.

   -- Create a simple result table
   CREATE TABLE IF NOT EXISTS dw_order_count_test (
       order_date STRING,
       total_count BIGINT
   ) 
   PARTITIONED BY (ds STRING); -- Partitioned by ds to store daily aggregation results

Étape 2 : Créer un workflow planifié

1. Accédez à la page Workspaces de la console DataWorks. Dans la barre de navigation supérieure, sélectionnez la région souhaitée. Repérez l'espace de travail désiré et choisissez Shortcuts > Data Studio dans la colonne Actions.

   Si le bouton est libellé Data Development, il ouvre l'ancienne version de Data Studio. Ne cliquez pas dessus.

2. Cliquez sur l'icône dans le volet de navigation de gauche, puis, à droite de Project Directory, cliquez sur > Create Workflow pour ouvrir la page Create Workflow.

3. Dans la boîte de dialogue Create Workflow, définissez le paramètre Scheduling Type sur Periodic Scheduling, saisissez les informations requises (par exemple, définissez le nom sur minimal_daily_demo), puis finalisez la création.

Étape 3 : Orchestrer le workflow : faire glisser les nœuds et connecter les dépendances

1. Sur le canevas du workflow, faites glisser un nœud Zero-Load Node depuis le panneau de composants de gauche et nommez-le start_node.

   Le nœud Zero-Load Node sert uniquement à définir le point de départ d'un processus métier et ne s'exécute pas réellement.

2. Faites glisser un nœud MaxCompute SQL et nommez-le count_orders.

3. Cliquez sur le cercle situé en bas de start_node et tracez une ligne vers le haut de count_orders pour créer un pipeline de traitement simple.

Étape 4 : Développer le code du nœud

1. Double-cliquez sur le nœud count_orders pour ouvrir l'éditeur de code du nœud.

2. Rédigez le code de logique métier du nœud (des données statistiques simulées sont utilisées ici).

   -- bizdate is a defined scheduling variable whose meaning needs to be specified in the scheduling configuration
   INSERT OVERWRITE TABLE dw_order_count_test PARTITION (ds='${bizdate}')
   SELECT 
       '${bizdate}' as order_date,
       COUNT(*) as total_count
   FROM (SELECT 1 as id UNION ALL SELECT 2 as id) t; -- Simulated data

   Pour plus d'informations sur le développement de nœuds, consultez la rubrique Développement d'un nœud MaxCompute SQL .

3. Cliquez sur le bouton Save en haut de l'éditeur de nœud pour enregistrer la configuration.

Étape 5 : Configurer la planification et les paramètres

1. Revenez au workflow. Sur le côté droit du canevas du workflow, cliquez sur l'onglet Scheduling Settings > Scheduling time :

   1. Définissez la Scheduling Frequency sur Day.

   2. Définissez l'heure de Scheduling time sur 00:05 (c'est-à-dire 00 h 05 chaque jour).

2. Sur le côté droit de l'éditeur du nœud count_orders , configurez les options Scheduling Settings > Scheduling Parameters. Ajoutez un paramètre avec le Parameter name défini sur bizdate et la Parameter Value définie sur $[yyyymmdd-1] (cela représente la date actuelle moins un jour, c'est-à-dire la veille).

Étape 6 : Déboguer un nœud unique et l'ensemble du workflow

1. Débogage du nœud count_orders :

   1. Configuration des paramètres de débogage : cliquez sur Debug Configuration sur le côté droit de la page d'édition du nœud.

      1. Dans la section Compute Resource, sélectionnez la ressource de calcul MaxCompute préparée à l'étape 1.

      2. Dans la section Script Parameters, saisissez la Value Used in This Run. La valeur par défaut correspond à la veille de la date actuelle.

   2. Exécution de la tâche de débogage : cliquez sur le bouton Run dans la barre d'outils. Le nœud s'exécute avec les paramètres de débogage que vous avez configurés dans Debug Configuration.

   3. Une fois que les résultats d'exécution répondent aux attentes, cliquez sur Sync to Scheduling dans le coin supérieur droit pour synchroniser la configuration d'exécution avec les paramètres de planification.

2. Débogage du workflow :

   1. Revenez au canevas du workflow et cliquez sur l'icône dans la barre d'outils supérieure.

   2. Dans la boîte de dialogue qui s'affiche, saisissez la Value Used in This Run pour le workflow (par exemple, si nous sommes le 20/01/2026, bizdate doit être remplacé par 20260119).

Étape 7 : Déployer en production

1. Revenez au workflow et cliquez sur le bouton dans la barre d'outils supérieure.

2. Dans le panneau de déploiement, le système effectue des vérifications de dépendances et de configuration. Après avoir confirmé que tout est correct, cliquez sur Start Release Production et définissez la méthode de déploiement sur Full Publishing.

3. Après un déploiement réussi, accédez au Operation and Maintenance Center pour vérifier si le workflow apparaît dans la liste des tâches planifiées.

Orchestration de nœuds/workflows

Orchestration complexe : contrôle de flux

Remarque

Les nœuds de branchement/jonction et les nœuds for-each/do-while sont disponibles uniquement dans DataWorks Standard Edition et versions ultérieures.

Les nœuds de contrôle de flux font évoluer le développement de données de l'intégration de tâches à l'orchestration métier. Ils vont au-delà du modèle de dépendance linéaire unique des DAG traditionnels en ajoutant une logique avancée grâce à un ensemble de nœuds de contrôle précis.

Nom du nœud	Description du nœud
Nœud virtuel	Un nœud virtuel n'effectue pas de calculs réels. Il gère de manière centralisée plusieurs sous-tâches et sert de nœud de départ d'un workflow. Par exemple, dans un workflow d'analyse des commandes produits, un nœud virtuel nommé workshop peut connecter deux tâches de synchronisation par lots, rendant le chemin de flux de données plus clair. Remarque Pour le développement de nœuds autonomes, vous devez utiliser le nœud racine de l'espace de travail comme nœud de dépendance de départ.
Nœud de branchement	Oriente vers différentes logiques aval en fonction des résultats amont. Par exemple, si le total quotidien des commandes est égal à 0, déclenchez un nœud d'alerte et arrêtez les calculs suivants ; si le total est supérieur à 0, poursuivez vers le nœud de génération de rapports.
Nœud de jonction	Fusionne les résultats d'exécution de plusieurs branches pour résoudre les problèmes de dépendance aval. Par exemple, une tâche de règlement financier dépend de deux branches : « règlement normal » et « logique d'ajustement ». Le nœud de jonction garantit que l'archivage final du rapport est déclenché dès qu'une des branches se termine avec succès.
Nœud For-each	Itère sur l'ensemble de résultats provenant d'un nœud d'affectation et exécute des opérations aval sur chaque élément. Par exemple, pour 31 noms de provinces obtenus par un nœud d'affectation, le nœud for-each exécute une tâche de nettoyage de données 31 fois, en traitant une partition de données de province à chaque itération.
Nœud Do-while	Répète l'exécution jusqu'à ce qu'une condition soit satisfaite. Par exemple, appelez une API externe toutes les 10 minutes pour interroger l'état de synchronisation des données. Si la valeur renvoyée est « Processing », la boucle continue. Si la valeur renvoyée est « Completed », la boucle se termine et le traitement suivant commence.

Pour plus d'informations, consultez la rubrique Nœuds courants dans Data Studio .

Orchestration complexe : conscience de l'état et intégration externe

Remarque

Les nœuds de vérification sont disponibles uniquement dans DataWorks Professional Edition et versions ultérieures. Les autres nœuds sont disponibles uniquement dans DataWorks Enterprise Edition.

Ces nœuds évaluent si les ressources physiques requises ou les tâches précédentes sont prêtes, et s'intègrent aux systèmes tiers pour assurer la communication entre les plateformes de données et les systèmes métier.

Nom du nœud	Description du nœud
Déclencheur HTTP	Reçoit des requêtes HTTP de systèmes externes pour déclencher des tâches DataWorks. Par exemple, après qu'un système métier amont a terminé la clôture quotidienne, il appelle une API HTTP pour déclencher le pipeline de traitement de données T+1 de DataWorks.
Nœud de vérification	Surveille si les ressources externes (telles que les fichiers OSS ou les partitions MaxCompute) sont prêtes, et déclenche les tâches aval dès qu'elles deviennent disponibles. Par exemple, un nœud de vérification attend que le fichier journal du jour apparaisse dans OSS, puis démarre la tâche d'analyse des journaux.
Nœud de vérification des dépendances	Utilise l'interrogation active, les combinaisons logiques et les vérifications de disponibilité des dépendances inter-cycles ou inter-espaces de travail pour déclencher les tâches aval une fois que toutes les conditions sont remplies. Par exemple, un nœud planifié quotidiennement attend que les 24 tâches horaires de la veille soient terminées.

Pour plus d'informations, consultez la rubrique Nœuds courants dans Data Studio .

Encapsuler des sous-workflows pour la réutilisation de la logique

Vous pouvez encapsuler un pipeline de sous-tâches stable et réutilisable dans un sous-workflow via un nœud SUB_PROCESS, auquel d'autres workflows peuvent ensuite faire référence. Par exemple, les lignes métier e-commerce, publicité et IoT peuvent partager un pipeline standardisé pour le nettoyage des données, les statistiques récapitulatives et les contrôles Data Quality.

Procédure :

1. Dans le workflow child_workflow que vous prévoyez de référencer, définissez la propriété General du workflow sur Can be cited. Cela convertit le workflow en sous-workflow.

2. Dans le workflow principal, faites glisser un nœud SUB_PROCESS et définissez le workflow référencé sur child_workflow.

Les sous-workflows présentent les contraintes suivantes :

• Internalité : le workflow et tous ses nœuds internes ne peuvent avoir aucune dépendance envers des tâches externes.

• Isolation : le workflow ne peut pas être directement défini comme dépendance par une tâche externe.

• Déclenchement passif : après le déploiement, le workflow ne génère pas automatiquement d'instances planifiées. Il s'exécute uniquement lorsqu'il est appelé par un nœud SUB_PROCESS dans un autre workflow.

  Pour plus d'informations, consultez la rubrique Création d'un sous-workflow .

Paramétrage des dépendances de planification

Les dépendances de planification relient des tâches isolées en un pipeline de production de données ordonné grâce à deux conditions : respect de l'heure planifiée et succès des tâches amont. Lorsque vous orchestrez des nœuds au sein d'un workflow, les dépendances de planification sont établies automatiquement. Vous pouvez également configurer des dépendances plus complexes via les paramètres de dépendances de planification.

Pour plus d'informations, consultez la rubrique Configuration des dépendances de planification .

Conception et flux des paramètres

DataWorks Data Studio prend en charge quatre niveaux de transmission de paramètres et permet un transfert dynamique de données flexible entre les nœuds via les paramètres de contexte des nœuds. Classés du périmètre le plus restreint au plus large :

Paramètres de planification

Les planifications sont définies au niveau du workflow. Les nœuds internes peuvent uniquement définir un délai d'exécution, calculé en ajoutant le délai à l'heure de planification définie par le workflow.

Débogage d'un nœud unique

Le débogage d'un nœud unique permet de valider la logique du code au sein d'un seul nœud, par exemple une instruction SQL, un script Python ou une tâche de synchronisation Data Integration. Ce mode exécute uniquement le nœud actuel sans déclencher les dépendances en amont ou en aval.

1. Dans le panneau Debug Configuration situé à droite du nœud, configurez les paramètres suivants :

   Nom du paramètre	Description
   Ressource de calcul	Sélectionnez la ressource de calcul associée. Si aucune ressource de calcul n'est disponible, choisissez Create Compute Resource dans la liste déroulante. Important Assurez-vous que la ressource de calcul et le groupe de ressources sont connectés. Pour plus d'informations, consultez la rubrique Connectivité réseau.
   Groupe de ressources	Sélectionnez un groupe de ressources ayant réussi le test de connectivité lors de l'association de la ressource de calcul. Certains nœuds permettent de configurer des packages de dépendance sur le groupe de ressources pour étendre l'environnement d'exécution.
   (Facultatif) Jeu de données	Certains nœuds (tels que Shell et Python) prennent en charge le montage de jeux de données pour accéder aux données non structurées stockées dans OSS ou NAS.
   (Facultatif) Paramètres de script	Lorsque vous configurez le contenu du nœud et définissez des variables au format ${parameter_name}, vous devez renseigner les champs Parameter name et Parameter Value dans la section Script Parameters. À l'exécution, les variables sont remplacées dynamiquement par les valeurs réelles. Pour plus d'informations, consultez la rubrique Configurer les paramètres de planification.
   (Facultatif) Rôle associé	Certains nœuds (tels que Shell et Python) permettent de configurer des rôles associés afin d'accéder aux ressources d'autres services Alibaba Cloud.

2. Dans la barre d'outils située au-dessus du nœud, cliquez sur Save puis sur Run pour exécuter la tâche du nœud.

3. Consultez le journal d'exécution et les résultats en bas du nœud.

Débogage du workflow

Le débogage du workflow permet de vérifier l'exactitude des dépendances de données, du passage des paramètres et de l'ordre d'exécution entre plusieurs nœuds du pipeline. Après avoir débogué chaque nœud individuellement, vous pouvez déboguer une partie du pipeline ou l'intégralité du workflow.

1. Sur la page du canevas DAG du workflow, cliquez sur le bouton Run dans la barre d'outils supérieure. Vous pouvez également sélectionner un nœud, cliquer dessus avec le bouton droit de la souris et choisir Run to this node ou Run from this node pour effectuer une vérification partielle.

2. Dans la boîte de dialogue qui s'affiche, attribuez des valeurs temporaires à toutes les variables des nœuds du workflow (telles que ${bizdate}) pour cette session de débogage.

3. Le système exécute strictement les nœuds de haut en bas selon les relations de dépendance définies dans le DAG. Vous pouvez surveiller l'état des nœuds en temps réel sur le canevas et cliquer sur n'importe quel nœud pour afficher le journal d'exécution.

4. Cliquez sur le bouton Return situé à gauche du canevas pour revenir à l'état de développement du workflow.

   L'historique d'exécution sur la droite affiche tous les enregistrements des exécutions de débogage du workflow.

Gérer les nœuds de workflow

DataWorks vous permet d'importer des nœuds autonomes existants dans un workflow, de supprimer des nœuds d'un workflow ou de déplacer des nœuds entre workflows pour une réutilisation efficace et une gestion modulaire.

Importer des nœuds existants dans un workflow

Vous pouvez ajouter des nœuds autonomes existants n'appartenant à aucun workflow au canevas du workflow actuel via l'option Import Node afin de les réutiliser.

1. Double-cliquez sur le workflow cible pour ouvrir la page d'édition du canevas.

2. Dans le panneau des composants à gauche, accédez à l'onglet Import Node.

3. Le panneau répertorie tous les nœuds autonomes pouvant être ajoutés. Filtrez et effectuez une recherche par Node Type, Path ou Node Name pour localiser rapidement le nœud cible.

4. Une fois le nœud identifié, faites-le glisser vers le canevas pour terminer l'importation.

Supprimer des nœuds d'un workflow

Vous pouvez retirer un nœud d'un workflow pour en faire un nœud autonome, ou le déplacer directement vers un autre workflow.

• Retirer d'un workflow en tant que nœud autonome

  Utilisez cette fonctionnalité lorsque vous devez découpler un nœud d'un workflow afin qu'il n'en fasse plus partie.

  1. Dans l'arborescence du projet ou sur le canevas du workflow, cliquez avec le bouton droit de la souris sur le nœud cible.

  2. Dans le menu contextuel, sélectionnez Remove from workflow.

  3. Dans la boîte de dialogue de confirmation, sélectionnez le chemin de destination où le nœud sera stocké après suppression, puis confirmez.

• Déplacer vers un autre workflow

  Utilisez cette fonctionnalité lorsque vous devez restructurer un processus métier et migrer un nœud du workflow actuel vers un autre workflow.

  1. Dans l'arborescence du projet ou sur le canevas du workflow, cliquez avec le bouton droit de la souris sur le nœud cible.

  2. Dans le menu contextuel, sélectionnez Move to another workflow.

  3. Dans la liste qui s'affiche, sélectionnez le workflow cible et confirmez.

     Vous pouvez également sélectionner un nœud et le faire glisser directement vers le workflow cible pour le déplacer.

Cloner un workflow

Le clonage copie un workflow existant — y compris tous ses nœuds internes, son code et ses dépendances — pour générer un workflow indépendant. Pour cloner, accédez à Project Directory, cliquez avec le bouton droit de la souris sur le workflow cible et sélectionnez Cloning.

Le clonage copie presque toutes les configurations, ce qui peut introduire des risques. Avant de déployer le workflow cloné, vérifiez les points suivants (vérification de « l'isolation de l'environnement ») :

1. Tables de sortie et sources de données cibles : Le code du workflow cloné écrit dans les mêmes tables cibles que le workflow d'origine. Vous devez modifier les noms des tables cibles dans le code (par exemple, changez ods_user_table en dev_ods_user_table) ou modifier la configuration de sortie du nœud pour éviter que plusieurs tâches n'opèrent sur la même table, ce qui provoquerait des conflits de données.

2. Dépendances en amont : Vérifiez la configuration des dépendances en amont du workflow. Par défaut, le workflow cloné dépend toujours des tâches en amont d'origine. Confirmez que cela correspond à vos attentes. Sinon, cela pourrait entraîner une confusion dans le pipeline de données ou l'exécution à vide des tâches.

3. Configuration des paramètres : Vérifiez les paramètres personnalisés du workflow et de ses nœuds internes, en particulier les paramètres liés aux partitions de date (tels que ${bizdate}), les chemins d'entrée/sortie et autres paramètres. Assurez-vous qu'ils sont corrects dans le nouvel environnement.

En plus de cloner des workflows, vous pouvez également cloner des nœuds au sein d'un workflow, mais la copie de nœuds entre workflows n'est pas prise en charge.

Gestion des versions

La gestion des versions enregistre automatiquement chaque modification apportée au workflow, permet de consulter et de comparer les versions historiques, et offre la possibilité de restaurer n'importe quel état historique si nécessaire.

À droite du canevas du workflow, le panneau Version affiche deux types d'enregistrements :

• Enregistrement de développement : Généré chaque fois que vous cliquez sur Save sur le canevas. Cet instantané prévient la perte accidentelle de code pendant le développement et n'affecte pas les tâches en cours d'exécution en production.

• Enregistrement de déploiement : Généré après le déploiement d'un workflow dans l'environnement de production. Il s'agit de la version exécutée par le planificateur de production. Lorsque des tâches de production rencontrent des problèmes, concentrez-vous sur les enregistrements de déploiement pour la restauration.

Cas d'utilisation typiques

• Restauration rapide en cas d'échec : Lorsqu'une tâche de production échoue en raison de modifications de code, utilisez Restore pour revenir en un clic à la dernière version de déploiement stable du workflow, afin de minimiser les temps d'arrêt.

• Audit et traçabilité des modifications : Pour enquêter sur le moment et l'auteur d'une modification logique, utilisez la liste des versions et les fonctionnalités Diff pour retracer chaque changement de code.

• Récupération de code : Si vous supprimez accidentellement une logique de code sans l'enregistrer, restaurez-la à partir du dernier enregistrement de développement.

Points importants à considérer

• La restauration écrase la zone de développement actuelle : L'option Restore utilise la version historique sélectionnée pour écraser tout le code et les configurations présents sur le canevas actuel. Avant de restaurer, sauvegardez les modifications non validées en les copiant dans un éditeur de texte local.

• Un redéploiement est requis après une restauration : L'option Restore ne fait que restaurer le code à l'état de développement. Vous devez le déployer manuellement pour que la restauration prenne effet en production.

Déploiement et opérations

• Déploiement de nœuds/workflows : Une fois le développement du workflow terminé, déployez les nœuds/workflows dans l'environnement de production. À ce stade, les nœuds de l'environnement de développement génèrent des tâches planifiées correspondantes dans l'environnement de production. Pour plus d'informations, consultez la rubrique Déployer des nœuds et des workflows.

• Opérations sur les nœuds/workflows : Les workflows de l'environnement de production sont planifiés périodiquement selon les paramètres de planification. Accédez au Operation and Maintenance Center pour consulter l'état de planification des workflows planifiés et effectuer les opérations associées. Pour plus d'informations, consultez les rubriques Tâches planifiées et Instances planifiées.

Mécanisme d'exécution des tâches

Dans les scénarios de planification, la réussite globale d'un workflow dépend de l'état d'exécution de ses tâches internes.

La réussite globale d'un workflow est déterminée par l'état final de ses nœuds internes :

• Échec : Si un nœud critique échoue, l'instance de workflow entière est généralement marquée comme ayant échoué.

• Gel/Pause : Si un nœud au sein du workflow est manuellement gelé ou mis en pause, et que ce nœud est un nœud en amont pour les nœuds suivants, le pipeline est interrompu et l'ensemble du workflow est également marqué comme ayant échoué.

• Nœud de jonction : Si le workflow utilise un nœud de jonction, même si un nœud d'une branche en amont échoue, l'ensemble du workflow peut renvoyer « succès » tant que la logique propre au nœud de jonction détermine le succès. Par conséquent, concevez soigneusement les vérifications en amont pour les nœuds de jonction afin d'éviter que des tâches ne s'exécutent avec des erreurs non détectées.

Scénarios particuliers :

• Lorsque vous gelez une instance de backfill de données d'une tâche de workflow, l'instance de workflow est définie sur l'état succès.

• Dans les scénarios de backfill de données, si le système détermine qu'une tâche ne peut pas être exécutée, le workflow est défini sur l'état échec.