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 Espaces de travail dans la console DataWorks. Dans la barre de navigation supérieure, sélectionnez la région souhaitée. Localisez 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 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 construire 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 pour le 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évelopper 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:05 tous les jours).

2. Sur le côté droit de l'éditeur de 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. Configurer les 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écuter 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 centralement 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 du 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	Achemine vers différentes logiques en aval en fonction des résultats en amont. Par exemple, si le total quotidien des commandes est de 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 en 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 branche 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 en 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 des données 31 fois, traitant une partition de données de province à chaque fois.
Nœud Do-while	Répète l'exécution jusqu'à ce qu'une condition soit remplie. Par exemple, appelez une API externe toutes les 10 minutes pour interroger l'état de la 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 combler le fossé de 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 en amont a terminé la clôture quotidienne, il appelle une API HTTP pour déclencher le pipeline de traitement des 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 en 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 en 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éer un sous-workflow.

Paramètres de dépendance de planification

Les dépendances de planification connectent les 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 en 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épendance de planification.

Pour plus d'informations, consultez la rubrique Configurer les dépendances de planification.

Conception et flux de paramètres

Les paramètres de workflow, les variables de workflow et les paramètres au niveau de l'espace de travail sont pris en charge uniquement lorsque vous utilisez un groupe de ressources serverless.

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 de nœud. Classés de la portée la plus basse à la plus élevée :

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 en vérifiant 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 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 à l'aide du format ${parameter_name}, vous devez définir le Parameter name et la 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 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 pour 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 d'exécution en bas du nœud.

Débogage du flux de travail

Le débogage du flux de travail 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 flux de travail.

1. Sur la page du canevas DAG du flux de travail, 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 flux de travail (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 flux de travail.

   L'historique d'exécution situé à droite affiche tous les enregistrements d'exécution de débogage du flux de travail.

Gérer les nœuds de flux de travail

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

Importer des nœuds existants dans un flux de travail

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

1. Double-cliquez sur le flux de travail 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 trouvé, faites-le glisser vers le canevas pour terminer l'importation.

Supprimer des nœuds d'un flux de travail

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

• Retirer d'un flux de travail en tant que nœud autonome

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

  1. Dans l'arborescence du projet ou sur le canevas du flux de travail, 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 cible où le nœud sera stocké après suppression, puis confirmez.

• Déplacer vers un autre flux de travail

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

  1. Dans l'arborescence du projet ou sur le canevas du flux de travail, 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 flux de travail cible et confirmez.

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

Cloner un flux de travail

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

Le clonage copie presque toutes les configurations, ce qui peut introduire des risques. Avant de déployer le flux de travail 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 flux de travail cloné écrit dans les mêmes tables cibles que le flux de travail 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 flux de travail. Par défaut, le flux de travail 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 flux de travail 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 flux de travail, vous pouvez également cloner des nœuds au sein d'un flux de travail, mais la copie de nœuds entre différents flux de travail n'est pas prise en charge.

Gestion des versions

La gestion des versions enregistre automatiquement chaque modification apportée au flux de travail, 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 flux de travail, 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 flux de travail dans l'environnement de production. Il s'agit de la version exécutée par le planificateur de production. Lorsque des problèmes surviennent avec les tâches de production, 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 à la dernière version de déploiement stable en un clic, 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 modification de code.

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

Points importants à considérer

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

• Un nouveau déploiement est requis après une restauration : 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/flux de travail : Une fois le développement du flux de travail terminé, déployez les nœuds/flux de travail 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 Déployer des nœuds et des flux de travail.

• Opérations sur les nœuds/flux de travail : Les flux de travail dans l'environnement de production sont planifiés périodiquement en fonction des paramètres de planification. Accédez au Operation and Maintenance Center pour consulter l'état de planification des flux de travail planifiés et effectuer les opérations connexes. Pour plus d'informations, consultez 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 flux de travail dépend de l'état d'exécution de ses tâches internes.

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

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

• Gel/Pause : Si un nœud au sein du flux de travail 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 flux de travail est également marqué comme échoué.

• Nœud de jonction : Si le flux de travail utilise un nœud de jonction, même si un nœud d'une branche en amont échoue, l'ensemble du flux de travail 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 data d'une tâche de flux de travail, l'instance du flux de travail est définie sur l'état succès.

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