:Configuration des dépendances de même cycle

Sortie de nœud

La sortie de nœud correspond au nom de sortie du nœud actuel. Elle sert d'identifiant (intermédiaire) permettant à d'autres nœuds d'établir des dépendances avec ce nœud, plutôt que de représenter les données physiques produites. Les autres nœuds localisent ce nœud via son nom de sortie, définissant ainsi ce dernier comme une dépendance en amont.

DataWorks génère automatiquement deux noms de sortie pour chaque nœud :

• ID aléatoire : globalement unique, il ne peut ni être modifié ni supprimé.

• projectName.nodeName : une sortie incluant le nom du nœud et pouvant être modifiée. Ce nom de sortie n'est pas mis à jour automatiquement lorsque le nom du nœud change.

Par ailleurs, DataWorks permet d'ajouter manuellement des sorties ou d'utiliser la fonctionnalité Parse Inputs and Outputs from Code. Pour connaître les types de nœuds pris en charge par l'analyse syntaxique du code, reportez-vous à la rubrique Types de nœuds pris en charge pour l'analyse automatique du code.

Entrée de nœud

L'entrée de nœud désigne les nœuds en amont dont dépend le nœud actuel. Vous pouvez les spécifier via le nom de sortie (recommandé), le nom du nœud ou l'ID du nœud en amont.

L'ID du nœud n'est généré qu'après le déploiement du nœud en amont dans l'environnement de production.

1. Définir les dépendances de nœud en analysant la lignée des tables depuis le code

L'analyse du code configure automatiquement les noms de sortie du nœud et ses dépendances en amont en examinant la lignée des tables présentes dans le code. Après l'analyse, les tables vers lesquelles le nœud écrit sont automatiquement ajoutées comme sorties de nœud au format projectname.tablename, tandis que les tables interrogées par le nœud sont ajoutées comme entrées de nœud.

Par exemple, lorsque vous effectuez un SELECT sur une table, celle-ci est automatiquement analysée comme une dépendance en amont du nœud actuel ; lorsque vous insérez des données dans une table (INSERT), elle est automatiquement analysée comme une sortie du nœud actuel. Pour consulter les mots-clés pris en charge par l'analyse automatique pour chaque type de nœud, voir Mots-clés pris en charge par l'analyse automatique du code pour chaque type de nœud .

• Configurer les dépendances

  L'analyse du code propose deux méthodes : cliquer manuellement sur Parse Inputs and Outputs from Code ou utiliser l'option Automatic Parsing Before Committing. Ces deux méthodes reposent sur le même principe. La méthode d'analyse automatique avant la soumission analyse les entrées et les sorties lors de la soumission du code et vous invite à configurer les dépendances.

  Par exemple, dans l'espace de travail yunwan_lingyi, un nœud MaxCompute mc2 dépend de la table de sortie dws_user_info_all_di du nœud MaxCompute mc1. Le code du nœud mc2 est le suivant :

  INSERT OVERWRITE TABLE ads_user_info_1d PARTITION (dt='${workflow.var}')
  SELECT uid
    , MAX(region)
    , MAX(device)
    , COUNT(0) AS pv
    , MAX(gender)
    , MAX(age_range)
    , MAX(zodiac)
  FROM dws_user_info_all_di
  WHERE dt = '${workflow.var}'
  GROUP BY uid;

  Après avoir cliqué sur Parse Inputs and Outputs from Code, le système analyse l'entrée du nœud actuel comme étant la table dws_user_info_all_di et fait correspondre automatiquement le nom de la table de sortie du nœud en amont ainsi que le nom du nœud en amont :

  |
  **Nom de sortie du nœud en amont**
  |
  **Nom de la table de sortie du nœud en amont**
  |
  **Nom du nœud en amont**
  |
  **ID du nœud**
  |
  **Espace de travail**
  |
  **Propriétaire**
  |
  **Cycle d'ordonnancement**
  |
  **Méthode**
  |
  **État d'exécution récent**
  |
  **Action**
  | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | |
  yunwan_lingyi.dws_user_info_all_di
  |
  yunwan_lingyi.dws_user_info_all_di
  |
  mc1
  |
  -
  |
  Test Workspace
  |
  lingyi01_testcloud_com
  |
  Day
  |
  Code parsing
  |
  No data
  |
  Delete
  |

  Le système analyse également la sortie de ce nœud comme étant la table ads_user_info_1d . Voici le résultat de l'analyse :

  |
  **Nom de sortie**
  |
  **Nom de la table de sortie**
  |
  **Nom du nœud en aval**
  |
  **Propriétaire**
  |
  **Méthode**
  |
  **Baseline affectée par le nœud en aval**
  |
  **Action**
  | | --- | --- | --- | --- | --- | --- | --- | |
  ide.505487297_out
  |
  -
  |
  -
  |
  -
  |
  Added by system by default
  |
  -
  |
  Delete
  | |
  ide.mc2
  |
  -
  |
  -
  |
  -
  |
  Manually added
  |
  -
  |
  Delete
  | |
  yunwan_lingyi.ads_user_info_1d
  |
  yunwan_lingyi.ads_user_info_1d
  |
  -
  |
  -
  |
  Code parsing
  |
  -
  |
  Delete
  |

  À ce stade, la configuration des dépendances entre le nœud mc2 et le nœud mc1 est terminée.

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

• Modifier les dépendances analysées depuis le code

  Si les dépendances issues de l'analyse du code ne correspondent pas à vos attentes, ou si des scénarios ne prenant pas en charge les dépendances d'ordonnancement (tables avec production de données non périodique) nécessitent une suppression manuelle des dépendances, vous pouvez vous référer au contenu ci-dessous pour modifier les dépendances analysées automatiquement.

  Opération	Description
  Supprimer manuellement les résultats d'analyse	Dans la liste des dépendances de nœud en amont, supprimez l'entrée indésirable, effectuez l'opération de suppression, puis relancez l'analyse. Après la suppression, un commentaire correspondant est automatiquement ajouté au code pour empêcher l'ajout répété de la dépendance lors de la prochaine analyse : --@exclude_input=Remove input --@exclude_output=Remove output
  Ajouter manuellement des entrées et des sorties	Dans l'éditeur de code, effectuez un clic droit sur un nom de table et sélectionnez Add Input ou Add Output. Après l'ajout, un commentaire correspondant est automatiquement inséré dans le code. --@extra_output=Add output --@extra_input=Add input Vous pouvez également ajouter des dépendances en suivant les instructions pour ajouter manuellement des dépendances de nœud en amont via le panneau de configuration d'ordonnancement ou définir les dépendances de nœud en traçant des lignes dans le panneau de workflow.

  Important

  DataWorks n'autorise pas la suppression directe d'une sortie de nœud disposant de dépendances en aval. Une telle action entraînerait des échecs d'exécution des tâches en aval ou des erreurs de récupération des données. Nous vous recommandons d'abord d'ajuster les tâches en aval en supprimant la dépendance en amont depuis les nœuds en aval, puis de supprimer la sortie de nœud du nœud en amont.

• Scénarios exclus de l'analyse automatique

  Les tables temporaires dans DataWorks (tables au format fixe défini dans la gestion des tables de l'espace de travail, telles que les tables dont le nom commence par t_) ne sont pas automatiquement analysées comme sorties du nœud actuel ni comme dépendances de nœud en amont.

• Remarques sur l'utilisation de l'analyse automatique

  Lors de l'utilisation de l'analyse automatique pour configurer les dépendances, assurez-vous que les sorties de nœud sont uniques au sein de la région actuelle. Dans le cadre des scénarios de développement DataWorks, tenez compte des points suivants :

  • Création de nœud : chaque nœud possède une sortie de nœud par défaut portant le même nom que le nœud. Si des nœuds portant le même nom existent dans le même espace de travail, vous devez modifier manuellement la sortie de nœud de l'un d'eux.

  • Développement du code : l'analyse automatique utilise la table de sortie d'un nœud comme sortie de nœud. Si deux nœuds d'ordonnancement du même espace de travail insèrent des données dans la même table, l'analyse automatique générera une erreur pour l'un des nœuds. Pour plus d'informations, consultez la rubrique Plusieurs nœuds écrivent des données dans la même table et l'analyse automatique signale que les noms de sortie de nœud sont identiques.

  • Configuration des dépendances : si vous utilisez des tâches SQL pour traiter les tables de sortie des tâches de synchronisation par lots, afin de permettre aux tâches SQL de dépendre rapidement des tâches de synchronisation par lots via l'analyse automatique basée sur la lignée, vous devez configurer manuellement la table de sortie du nœud de synchronisation par lots comme sortie de nœud, ou utiliser le nom de la table de sortie de la tâche de synchronisation par lots comme nom du nœud de synchronisation par lots (la plateforme crée automatiquement une sortie de nœud portant le même nom que le nœud). Sinon, lors de la soumission du nœud SQL en aval, l'erreur suivante peut se produire : The parent node output name ${projectname.tablename} that the current node depends on does not exist. The current node cannot be submitted. Make sure the parent node with this output name has been submitted.

2. Ajouter manuellement des dépendances de nœud en amont via le panneau de configuration d'ordonnancement

Dans le panneau de configuration Scheduling Settings -> Scheduling Dependency -> Same cycle dependence, ajoutez manuellement des dépendances de nœud en amont en saisissant la sortie de nœud, le nom de nœud ou l'ID de nœud. Étant donné que les noms de nœud peuvent être dupliqués, nous vous recommandons d'utiliser les sorties de nœud pour établir les dépendances.

3. Définir les dépendances de nœud en traçant des lignes dans le panneau de workflow

Lorsque vous définissez des dépendances en traçant des lignes dans le panneau DAG d'un workflow, DataWorks ajoute automatiquement une sortie au format _out depuis le nœud en amont vers le nœud en aval afin d'établir la dépendance entre les nœuds.

Lorsqu'une ligne de dépendance est supprimée du panneau de workflow, la dépendance correspondante est également retirée de la configuration d'ordonnancement du nœud.

1. Dépendance la plus proche (dépendance standard de même cycle)

• Signification : il s'agit de la méthode de dépendance de même cycle la plus courante et fondamentale. Elle suit le principe de « montage le plus proche », où l'instance en aval s'associe automatiquement et attend l'instance la plus récente produite dans le même cycle métier par le nœud en amont, sans configuration supplémentaire (il existe quelques exceptions ; pour plus de détails, consultez la rubrique Principes et exemples de configuration d'ordonnancement pour les scénarios de dépendance complexes).

• Scénarios applicables :

  • Flux ETL quotidiens, hebdomadaires ou mensuels standards.

  • Relations de dépendance un-à-un entre les tâches en amont et en aval, par exemple une tâche quotidienne dépendant d'une autre tâche quotidienne.

2. Plage spécifiée (dépendre d'une fenêtre temporelle continue)

Lorsqu'une simple dépendance un-à-un ne répond pas à vos besoins — par exemple, lorsque la tâche en aval doit agréger les données de la tâche en amont sur une période donnée — vous pouvez utiliser l'option Specified Range pour une configuration plus flexible.

Cette fonctionnalité nécessite d'abord d'activer l'option Advanced Scheduling Dependency Configuration dans les paramètres d'ordonnancement du nœud.

• Méthode de configuration :

  1. Après avoir sélectionné le nœud dépendant, cliquez sur Configure dans la colonne Actions et définissez le type de dépendance sur Specified Range.

  2. Définissez les décalages gauche et droit par rapport à l'heure d'ordonnancement du nœud actuel. La plage de décalage maximale autorisée est de -1440 à 1440 minutes.

• Description : cela permet à une tâche en aval de dépendre de toutes les instances en amont situées dans une plage temporelle continue. La plage constitue une « fenêtre glissante » calculée dynamiquement par rapport à l'heure d'exécution planifiée de la tâche en aval, et seules les instances du jour actuel et de la veille situées dans la plage spécifiée sont prises en compte.

• Exemple de logique centrale : une tâche en aval horaire dépend d'une autre tâche en amont horaire, avec une plage configurée comme [-2h, +2h] .

  • Lorsque l'instance en aval de 12 h 00 s'exécute, elle dépend de toutes les instances en amont de 10 h 00 à 14 h 00.

  • Lorsque l'instance en aval de 13 h 00 s'exécute, la fenêtre de dépendance « glisse » automatiquement pour couvrir la période de 11 h 00 à 15 h 00.

• Scénarios applicables :

  • Agrégation de données transfrontalières : une tâche quotidienne en Chine (UTC+8) doit agréger les données de toutes les 24 tâches horaires en Inde (UTC+5:30). Vous pouvez configurer la plage comme [-3h, 21h] pour couvrir précisément la fenêtre temporelle physique correspondant à la journée métier locale de l'Inde.

  • Agrégation sur fenêtre inter-jours : une tâche quotidienne s'exécutant tôt le matin doit traiter des données allant de l'après-midi précédent au début de la matinée actuelle. Par exemple, vous pouvez configurer la plage comme [-12h, 4h] pour dépendre des instances horaires en amont de 12 h 00 hier à 04 h 00 aujourd'hui.

3. Ensemble spécifié (dépendre d'un groupe d'instances fixes discrètes)

Lorsque votre logique de dépendance est liée à des instances de sortie spécifiques et discrètes provenant de l'amont, l'« ensemble spécifié » constitue le meilleur choix.

Pour utiliser cette fonctionnalité, activez d'abord l'option Advanced Scheduling Dependency Configuration dans les paramètres d'ordonnancement du nœud.

• Méthode de configuration :

  1. Après avoir sélectionné le nœud dépendant, cliquez sur Configure dans la colonne Actions et définissez le type de dépendance sur Specified Set.

  2. Définissez les décalages gauche et droit par rapport à l'heure d'ordonnancement du nœud actuel. La plage de décalage maximale autorisée est de -1440 à 1440 minutes.

• Description : cela permet à une tâche en aval de dépendre d'un ensemble fixe et discret d'instances en amont. Contrairement à la fenêtre glissante de la « plage spécifiée », cet ensemble d'instances est statique et identique pour toutes les instances en aval.

• Exemple de logique centrale : une tâche en aval est configurée pour dépendre des instances en amont à {02:00, 06:00, 10:00} . Que ce soit l'instance en aval de 08 h 00 ou celle de 12 h 00, toutes deux attendront que ces trois instances spécifiques soient terminées avec succès avant de s'exécuter.

• Scénarios applicables :

  Dépendance vis-à-vis d'étapes clés : la condition de démarrage de la tâche en aval est que les données à plusieurs moments clés de la journée (comme les instantanés du matin, de midi et du soir) provenant de l'amont soient prêtes.