Une dépendance inter-cycles lie l'instance d'un nœud pour le cycle en cours à la réussite de l'exécution d'une instance issue d'un cycle précédent.
DataWorks prend en charge les trois types suivants de dépendances inter-cycles :
-
Instances des nœuds enfants
Avec cette dépendance, un nœud repose sur ses nœuds directs en aval. Par exemple, si le nœud A possède trois nœuds en aval (B, C et D), son instance actuelle ne s'exécute qu'une fois que les instances du cycle précédent des nœuds B, C et D ont toutes abouti.
Ce type de dépendance est couramment utilisé lorsque l'exécution actuelle d'un nœud dépend du nettoyage des données dans sa table de sortie par les nœuds en aval lors du cycle précédent. Pour vérifier que les nœuds en aval ont nettoyé les données comme prévu, configurez des règles de qualité des données pour leurs tables de sortie.
-
Instances du nœud actuel
Il s'agit d'une dépendance automatique inter-cycles. L'instance actuelle d'un nœud dépend de la réussite de sa propre instance issue du cycle précédent.
Cette dépendance est généralement employée lorsque l'exécution actuelle d'un nœud repose sur les données métier produites par son exécution précédente. Pour vérifier que les résultats du nettoyage des données sont conformes aux attentes, configurez des règles de surveillance de la qualité des données pour la table de sortie du nœud.
-
Instances de nœuds personnalisés : spécifiez les dépendances envers d'autres nœuds en saisissant manuellement leurs ID. Si vous indiquez plusieurs nœuds, séparez leurs ID par des virgules (,), par exemple
12345,23456.Avec ce paramétrage, l'instance du nœud actuel ne s'exécute qu'après la réussite des instances du cycle précédent de tous les nœuds personnalisés spécifiés.
Un cas d'usage fréquent survient lorsque la logique métier impose une dépendance vis-à-vis des données produites par un autre processus, alors que le code du nœud actuel n'interagit pas directement avec ces données.
Lorsque vous consultez les dépendances des nœuds dans Operation Center, les dépendances inter-cycles apparaissent sous forme de lignes pointillées pour les distinguer des dépendances intra-cycles.
Lorsque vous désactivez un nœud, supprimez ses dépendances de planification. Cela inclut à la fois les dépendances inter-cycles et les dépendances intra-cycles.
Choisissez le cycle de dépendance pour les nœuds amont en fonction de vos besoins métier. En règle générale, configurez soit une dépendance intra-cycle, soit une dépendance inter-cycles, mais pas les deux simultanément. La fonction d'analyse automatique crée par défaut une dépendance intra-cycle. Pour modifier ce comportement, supprimez d'abord la dépendance intra-cycle, puis ajoutez la nouvelle. Pour plus d'informations, consultez la rubrique Logique des dépendances de planification.
La figure suivante illustre les dépendances entre les nœuds d'un workflow.
La page Operation Center affiche les dépendances au sein du workflow.
Prenons l'exemple du nœud xc_create : après avoir saisi les instructions DDL CREATE TABLE xc_1 et CREATE TABLE xc_2 dans l'éditeur de code, cliquez sur Parse Input and Output from Code dans le panneau de configuration de la planification. Le système génère automatiquement deux enregistrements de sortie (test.xc_1 et test.xc_2) dans la section Node Output Name, avec la méthode indiquée comme étant Code Parsing. Dans la section Cross-Cycle Dependencies, sélectionnez Instances of Current Node, Instances of Child Nodes ou Instances of Custom Nodes.
L'éditeur de code du nœud xc_select contient deux instructions SQL : SELECT * FROM xc_1; et SELECT * FROM xc_2;. Grâce à la fonctionnalité Parse Input and Output from Code, le système identifie automatiquement test.xc_1 et test.xc_2 comme dépendances amont pour ce nœud, ce qui signifie que xc_select dépend des deux tables produites par le nœud xc_create.
Dépendance inter-cycles : Nœuds enfants
Faites dépendre un nœud de la réussite de ses nœuds en aval issus du cycle précédent. Par exemple, si le nœud A possède des nœuds en aval B, C et D, son instance du cycle en cours ne s'exécutera qu'après la réussite des instances du cycle précédent de B, C et D.
Utilisez cette dépendance lorsque l'exécution actuelle d'un nœud dépend du nettoyage des données effectué par ses nœuds en aval lors du cycle précédent. Ces nœuds en aval nettoient les données de sortie générées par le nœud parent lors de son exécution précédente. L'instance du cycle en cours du nœud parent démarre uniquement si les instances du cycle précédent de ses nœuds en aval se sont exécutées avec succès.
Le nœud xc_create est configuré pour dépendre de ses nœuds enfants du cycle précédent. Dans la section Cross-Cycle Dependencies (formerly Previous Cycle) située en bas du panneau Scheduling Configuration, cochez la case Instances of Child Nodes.
La page Operation Center affiche les dépendances entre les nœuds.
Dépendance inter-cycles : Nœud actuel
L'exécution du cycle en cours d'un nœud peut dépendre de la réussite de sa propre instance du cycle précédent. Une instance du cycle précédent échouée ou incomplète bloque l'exécution de l'instance du cycle en cours.
Recourez à cette dépendance lorsqu'une tâche de nettoyage des données dans le cycle en cours dépend du résultat de la même tâche lors du cycle précédent. Dans cet exemple, le nœud est planifié en tant que tâche horaire afin de faciliter l'observation de la dépendance.
Consultez les dépendances du nœud sur la page .
Si un nœud horaire est configuré avec une dépendance automatique (Cross-Cycle Dependencies: Current Node), la prochaine instance horaire de ce nœud ne s'exécutera pas si l'instance du cycle précédent n'a pas abouti.
Par exemple, si la première instance d'une tâche horaire échoue ou ne s'exécute pas un jour donné, toutes les instances horaires suivantes de cette tâche pour ce jour-là ne s'exécuteront pas non plus.
Dépendance inter-cycles : Nœuds personnalisés
Dans ce scénario, le nœud xc_create dépend de l'instance du cycle précédent du nœud 1000374815 en raison de la logique métier, bien que son code n'utilise pas la table de sortie produite par le nœud 1000374815.
Utilisez cette dépendance lorsque votre logique métier requiert des données produites par un autre nœud (ici, le nœud 1000374815), mais que le nœud actuel (xc_create) n'interagit pas directement avec ces données, par exemple en effectuant une sélection depuis la table de résultats du nœud 1000374815.
Le nœud xc_create est configuré avec une dépendance amont envers le nœud personnalisé 1000374815. Dans la section Cross-Cycle Dependencies du panneau Scheduling Configuration, sélectionnez Instances of Custom Nodes, saisissez l'ID du nœud 1000374815 dans le champ de saisie, puis cliquez sur Add.
Consultez les dépendances du nœud sur la page .
Paramètres avancés pour les dépendances inter-cycles
Dans les workflows comportant un nœud de branchement avec deux chemins en aval, généralement un seul chemin est exécuté tandis que l'autre est défini en mode simulation (dry run). Ce statut de simulation se propage à tous les nœuds en aval suivants. Pour gérer ce comportement, DataWorks propose l'option Upstream node air running attribute does not conduct cross-cycle.
Toutefois, si un nœud situé dans un chemin de branchement possède une dépendance automatique et que son instance du cycle précédent a été définie en mode simulation car sa branche n'a pas été empruntée, le nœud peut rester bloqué indéfiniment dans un état de simulation.
Par exemple, si le nœud de gauche est défini en mode simulation, son nœud en aval sera également défini en mode simulation.
Pour garantir que l'exécution d'un nœud lors du prochain cycle soit déterminée par la logique de branchement de ce même cycle, plutôt que d'être affectée par un statut de simulation issu d'un cycle précédent, suivez ces étapes :
Sur la page de configuration du nœud, cliquez sur Scheduling dans le panneau de droite.
Dans la section Schedule, sélectionnez Dependency on Last Cycle.
Cliquez sur Advanced Settings.
Sélectionnez Upstream node air running attribute does not conduct cross-cycle. La tâche ne sera plus affectée par le statut de simulation d'un nœud de branchement du cycle précédent. Dans la section Cross-Cycle Dependencies (formerly Previous Cycle), sélectionnez Instances of Current Node. Définissez Skip Upstream Dry-Run Status sur Yes.
Cette option s'applique uniquement au statut de simulation propagé depuis un nœud de branchement non sélectionné. Elle n'affecte pas le statut de simulation hérité de l'instance du cycle précédent d'un nœud standard.
Cas d'utilisation typiques des dépendances inter-cycles
-
Cas d'utilisation 1 :
Scénario : Une tâche quotidienne dépend d'une tâche horaire. Vous souhaitez que la tâche quotidienne s'exécute à l'heure prévue de 12:00 sans attendre la fin des 24 instances horaires.
-
Solution : Configurez la tâche horaire amont pour qu'elle dépende de sa propre instance précédente en sélectionnant . Planifiez l'exécution de la tâche quotidienne en aval à 12:00 et ne configurez aucune dépendance inter-cycles pour celle-ci.
Une fois que l'instance de 12:00 de la tâche horaire amont s'est exécutée avec succès, la tâche quotidienne en aval démarrera.
-
Cas d'utilisation 2 :
Scénario : Une tâche quotidienne dépend des données générées par une tâche horaire du jour précédent.
Solution : Configurez la tâche quotidienne en aval en sélectionnant . Ensuite, saisissez l'ID du nœud de la tâche horaire amont.
-
Cas d'utilisation 3 :
Scénario : Une tâche horaire dépend d'une tâche quotidienne. Une fois la tâche quotidienne terminée, plusieurs heures d'exécution planifiées pour la tâche horaire peuvent déjà être passées, provoquant le démarrage simultané de plusieurs instances. Comment éviter cela ?
Solution : Configurez la tâche horaire en aval pour qu'elle dépende de sa propre instance précédente en sélectionnant . Cela garantit que les instances horaires s'exécutent de manière séquentielle.
-
Cas d'utilisation 4 :
Scénario : Un nœud dépend des données qu'il a produites lors de son propre cycle précédent. Comment s'assurer que les données du cycle précédent sont prêtes ?
Solution : Configurez le nœud pour qu'il dépende de sa propre instance précédente en sélectionnant .