Configurez les propriétés de planification des tâches (nœuds) dans DataWorks, notamment le calendrier, les dépendances, les politiques d'exécution et les paramètres, afin de garantir l'exécution automatique et fiable des tâches.
Concepts clés
Avant de configurer les propriétés de planification, familiarisez-vous avec les concepts fondamentaux suivants :
Tâches et instances : Une tâche (ou nœud) correspond au code métier développé dans DataWorks. Lorsqu'une tâche s'exécute selon ses Scheduling Settings, une ou plusieurs instances d'exécution sont générées. Dans le Operation and Maintenance Center, vous gérez et surveillez les instances en cours d'exécution des tâches, par exemple en consultant les journaux ou en relançant des instances.
Instances périodiques : Pour les tâches planifiées périodiquement, le système de planification génère des instances correspondant à la Scheduling Frequency configurée (quotidienne, horaire, etc.), produisant ainsi les instances périodiques associées. Par exemple, une tâche horaire génère 24 instances horaires en attente chaque jour.
Date métier : Il s'agit de la date de traitement des données pour une instance, généralement T-1 (la veille). Par exemple, une instance exécutée tôt le matin du 02/01/2023 a pour date métier le 01/01/2023, ce qui signifie qu'elle traite les données du 1er janvier. Le remplacement des paramètres de planification se fait généralement sur la base de la date métier.
Prérequis
Un nœud a été créé. DataWorks utilise des nœuds pour le développement de tâches. Les tâches de différents moteurs sont encapsulées sous forme de types de nœuds distincts. Sélectionnez le nœud approprié à vos besoins. Pour plus de détails, consultez la section Présentation du développement de nœuds.
L'interrupteur Enable Periodic Scheduling est activé dans la page Scheduling Settings. Une fois activé, toutes les tâches de l'espace de travail peuvent s'exécuter automatiquement selon leur configuration. Pour plus de détails, consultez la section Configurer les propriétés de planification de l'espace de travail.
Configurer les propriétés de planification
Dans le panneau Scheduling Settings situé à droite de la page de l'éditeur de nœuds, définissez diverses propriétés pour déterminer le comportement automatisé de la tâche.
1. Accéder à la page de configuration de la planification
Accédez à la page Workspaces dans la console DataWorks. Dans la barre de navigation supérieure, sélectionnez la région souhaitée. Repérez l'espace de travail cible et choisissez dans la colonne Actions.
Dans Data Studio, double-cliquez sur le nœud cible pour ouvrir sa page d'édition.
Cliquez sur Scheduling Settings à droite de la page de l'éditeur de nœuds pour ouvrir le panneau de configuration.
2. Configurer les propriétés de planification
Le panneau de configuration de la planification comprend les onglets Scheduling time, Scheduling Dependency, Scheduling Policy, Scheduling Parameters, Node output parameters et Associated Role. Configurez-les selon vos besoins.
Heure de planification : Définir quand une tâche s'exécute
Définissez le moment et la fréquence d'exécution automatique d'une tâche.
Pour les nœuds intégrés à un workflow, l'Scheduling time est configurée uniformément par le workflow et ne peut pas être modifiée ici. Pour les nœuds autonomes, effectuez la configuration à cet endroit.
Paramètre | Description |
Scheduling Frequency | Définit la fréquence d'exécution automatique d'une tâche en production. Prend en charge les périodes à la minute, à l'heure, quotidiennes, hebdomadaires, mensuelles et annuelles.
|
Effective Date | Définissez les dates de début et de fin pour la planification automatique des tâches. Après la période de validité, la tâche ne génère plus de nouvelles instances périodiques. |
Cron expression | Cette expression est générée automatiquement en fonction des propriétés temporelles configurées dans l'interface utilisateur. Aucune configuration manuelle n'est nécessaire. |
Heure de planification vs heure d'exécution réelle : L'Scheduling time configurée ici représente l'heure de démarrage prévue de la tâche. L'heure de démarrage réelle dépend également de la finalisation des tâches en amont, de la disponibilité du groupe de ressources et d'autres facteurs.
Mécanisme de test à blanc les jours non planifiés : Pour les tâches hebdomadaires, mensuelles ou annuelles, les jours non désignés pour la planification, le système génère une instance de test à blanc. Cette instance aboutit immédiatement et déclenche les tâches en aval, mais n'exécute aucun code ni ne consomme de ressources de calcul.
Indépendance de la fréquence de planification : La fréquence de planification d'une tâche est déterminée uniquement par sa propre Scheduling Frequency, indépendamment des tâches en amont. DataWorks prend en charge les dépendances entre tâches ayant des périodes de planification différentes (par exemple, une tâche horaire dépendant d'une tâche quotidienne).
Dépendances de planification : Définir les prérequis pour l'exécution des tâches
Définissez quelles tâches en amont doivent être terminées avec succès avant que la tâche actuelle ne puisse démarrer. Une configuration correcte des dépendances est essentielle pour garantir l'ordre de traitement des données et l'exactitude des résultats.
DataWorks analyse automatiquement et recommande les dépendances en amont en se basant sur la lignée des tables dans le code afin de garantir l'intégrité des données. Vous pouvez également ajouter ou modifier manuellement les dépendances si nécessaire.
Configurer les dépendances en amont
Dans l'onglet Scheduling Dependency, consultez la liste des nœuds de dépendance en amont analysés à partir du code par le système.
-
Sélectionnez le mode de dépendance pour chaque nœud en amont :
Dépendance de même cycle : L'instance en aval d'aujourd'hui (T) dépend de l'instance en amont d'aujourd'hui (T). Il s'agit de la dépendance la plus courante. Par exemple, si la tâche quotidienne B lit une table produite par la tâche quotidienne A, la tâche B doit dépendre du même cycle de la tâche A.
Dépendance de cycle précédent : L'instance en aval d'aujourd'hui (T) dépend de l'instance en amont d'hier (T-1). Par exemple, la tâche d'aujourd'hui doit lire les données agrégées d'hier. Pour plus de détails, consultez la section Dépendances inter-cycles.
(Facultatif) Si le système n'a pas analysé automatiquement les dépendances ou si vous devez dépendre d'un nœud ne produisant pas de données (tel qu'un nœud à charge nulle), cliquez sur Add upstream node pour configurer manuellement.
Dépendances de workflow : Les dépendances entre nœuds au sein d'un workflow sont gérées uniformément par le workflow. Cette section couvre uniquement la configuration des dépendances pour les nœuds autonomes. Pour la configuration de la planification des workflows, consultez la section Configurer les propriétés de planification du workflow.
Scénarios de dépendance complexes : DataWorks prend en charge divers scénarios de dépendance complexes. Avant de procéder à la configuration, consultez la documentation sur la configuration des dépendances complexes pour comprendre les règles de dépendance prédéfinies.
Scénarios de dépendance non pris en charge : Pour les données non produites par la planification périodique de DataWorks (telles que les tables synchronisées en temps réel, les tables téléchargées manuellement ou les tables de dimension), le système ne peut pas détecter l'état de mise à jour des données ; il est donc impossible de configurer des dépendances de planification. Dans ces scénarios, dépendez du nœud racine de l'espace de travail ou d'un nœud à charge nulle pour une orchestration de planification unifiée.
Politique de planification : Définir le comportement d'exécution et les ressources des tâches
Définissez comment les instances sont générées, le comportement d'exécution (comme le délai d'expiration et la relance) ainsi que les ressources requises.
Paramètre | Description |
Instance generation method | Définit le moment où les instances périodiques commencent à être générées après le déploiement d'une tâche.
|
Scheduling Type |
|
Timeout Definition | Définissez la durée maximale d'exécution de la tâche. Au-delà de ce délai, la tâche est automatiquement arrêtée et marquée comme échouée. La valeur par défaut est de 3 à 7 jours, avec un réglage manuel maximal de 168 heures (7 jours). |
RUN Attribute | Définissez les conditions dans lesquelles la tâche peut être relancée manuellement.
|
Auto Rerun upon Failure | Lorsque cette option est activée, si une tâche échoue en raison de problèmes transitoires (comme des fluctuations réseau), le système réessaie automatiquement pour améliorer la stabilité de la planification.
Remarque Les tâches qui échouent en raison d'un délai d'expiration ne déclenchent pas de relances automatiques. |
Max Parallel Instances | Limite le nombre maximal d'instances concurrentes de la même tâche pour le contrôle de la concurrence. La plage de valeurs est de 1 à 10 000. Lorsque cette option est activée, les instances excédentaires sont mises en file d'attente jusqu'à ce que les instances existantes soient terminées. |
Resource Group | Configurez le groupe de ressources de planification pour la tâche. |
Compute Resource/Compute quota | Configurez les ressources du moteur de calcul (telles que MaxCompute Quota) pour la tâche. |
Datasets | Montez un dataset (tel que Object Storage Service (OSS) ou Apsara File Storage (NAS)) sur des types de nœuds spécifiques (comme Shell) afin qu'ils puissent être accessibles comme des fichiers locaux dans le code. Vous pouvez configurer le Mount Path, les Advanced Settings (comme la read method) et les autorisations Read Only. |
Configuration des paramètres : Activer le passage dynamique de valeurs entre les tâches
La configuration paramétrée rend le code des tâches plus flexible, permettant le passage dynamique de valeurs et le transfert de contexte entre les tâches.
Paramètres de planification (paramètres d'entrée)
Si des variables sont utilisées dans le code du nœud (comme ${pt_time}), attribuez-leur des valeurs ici. Les valeurs peuvent être des constantes fixes ou des expressions dynamiques utilisant les paramètres intégrés de DataWorks (comme $bizdate).
Utilisez Add parameters pour définir manuellement, ou utilisez Loading parameters in code pour une identification automatique. De plus, vous pouvez utiliser l'icône 
pour lier les valeurs des paramètres aux paramètres de sortie des nœuds en amont.
La valeur finale des paramètres de planification est déterminée par la date métier de l'instance et les expressions de paramètre de planification configurées.
Bonnes pratiques : Après le déploiement d'une tâche, vérifiez la configuration des paramètres de planification sur la page Operation and Maintenance Center > Auto Triggered Task en production pour vous assurer que la configuration répond aux attentes.
Paramètres de sortie du nœud (paramètres de sortie)
Définissez la sortie du nœud actuel sous forme de paires clé-valeur pour que les nœuds en aval puissent les référencer. Les nœuds en aval peuvent consommer ces valeurs via la configuration des Scheduling Parameters grâce à l'option Associate Output Parameter of Ancestor Node.
La Parameter Value peut être une Constant (chaînes fixes) ou une Variable (référençant des paramètres système ou d'entrée personnalisés).
Types de nœuds pris en charge :
EMR Hive,EMR Spark SQL,ODPS Script,Hologres SQL,AnalyticDB for PostgreSQLetMySQL.Transmettre les résultats de requête : Les Node output parameters ne peuvent transmettre que des valeurs de type chaîne. Pour transmettre les jeux de résultats de requêtes SQL en amont vers l'aval, utilisez un nœud d'affectation.
Rôle associé : Accéder en toute sécurité à d'autres ressources cloud
Spécifiez un rôle RAM pour une tâche afin d'obtenir dynamiquement des identifiants d'accès temporaires via Alibaba Cloud STS (Security Token Service) au moment de l'exécution. Cela permet d'accéder à d'autres ressources cloud (comme OSS) sans coder en dur les paires AccessKey, améliorant ainsi la sécurité.
Limites
Restriction de groupe de ressources : Seuls les nœuds s'exécutant sur des groupes de ressources serverless sont pris en charge.
Restriction de type de nœud : Seuls les nœuds Python, Shell, Notebook, PyODPS 2, PyODPS 3 et PAI DLC sont pris en charge.
1. Configurer le rôle associé pour un nœud
À droite de la page de l'éditeur de nœuds, repérez et cliquez sur Run Configuration.
Dans le panneau de configuration de la planification, basculez vers l'onglet Associated Role.
-
Dans la liste déroulante RAM Role, sélectionnez le rôle RAM que vous avez préparé.
ImportantSi la liste déroulante est vide ou si vous ne trouvez pas le rôle souhaité, consultez la section Configurer un rôle associé à l'aide de STS pour terminer la configuration du rôle RAM.
Une fois la configuration terminée, soumettez le nœud. Cette configuration prend effet uniquement pour les exécutions de débogage.
2. Exécuter et vérifier
PyODPS : Lors de l'accès à d'autres produits cloud (comme OSS), l'identité du rôle RAM configuré est utilisée. Cependant, lors de l'accès aux données MaxCompute, l'identité d'accès configurée pour les ressources de calcul (au niveau du projet) est toujours utilisée automatiquement.
Configurer les propriétés de planification
Après avoir débogué le nœud, synchronisez la Run Configuration depuis Associated Role vers les Scheduling Settings dans . Après le déploiement, la tâche s'exécute avec l'identité du rôle spécifié.
Si vous avez configuré une image personnalisée dans Run Configuration , vous devez également synchroniser les paramètres avec la configuration de planification.
Afficher le rôle d'exécution dans Operation Center
Une fois la tâche terminée, dans l'Operation and Maintenance Center, consultez les détails de l'instance de tâche pour confirmer que le rôle spécifié a bien été utilisé.
Accédez à .
Repérez l'instance de nœud que vous avez exécutée et cliquez dessus pour ouvrir sa page de détails.
Dans la page de détails, vérifiez le champ Execution Identity pour confirmer que la tâche a bien utilisé le rôle RAM spécifié.
3. (Facultatif) Afficher ou utiliser les identifiants temporaires dans le code
Après avoir configuré un rôle associé, la tâche utilise automatiquement l'identité du rôle RAM pour accéder à d'autres ressources cloud au moment de l'exécution. Dans la plupart des cas, vous pouvez exécuter la tâche sans obtenir explicitement les identifiants dans votre code.
Si vous devez utiliser explicitement les identifiants temporaires dans votre code ou si vous souhaitez afficher les identifiants temporaires injectés par le système, vous pouvez les obtenir en utilisant les méthodes suivantes. DataWorks obtient automatiquement les identifiants temporaires au moment de l'exécution et les injecte dans l'environnement d'exécution sous forme de variables d'environnement.
Les nœuds PAI DLC ne prennent pas en charge l'obtention d'identifiants temporaires selon les méthodes décrites dans cette section.
Méthode 1 : Lire les variables d'environnement (recommandé pour Shell et Python)
Le système définit automatiquement les trois variables d'environnement suivantes, que vous pouvez lire directement dans votre code.
LINKED_ROLE_ACCESS_KEY_ID: L'ID AccessKey temporaire.LINKED_ROLE_ACCESS_KEY_SECRET: La clé secrète AccessKey temporaire.LINKED_ROLE_SECURITY_TOKEN: Le jeton de sécurité temporaire.
Exemple de code (Python) :
Cet exemple nécessite une image Python personnalisée avec oss2 installé. Pour plus de détails, consultez la section Image personnalisée.
import os
import oss2
# 1. Obtain temporary credentials from environment variables
access_key_id = os.environ.get('LINKED_ROLE_ACCESS_KEY_ID')
access_key_secret = os.environ.get('LINKED_ROLE_ACCESS_KEY_SECRET')
security_token = os.environ.get('LINKED_ROLE_SECURITY_TOKEN')
# Verify credentials obtained
if not all([access_key_id, access_key_secret, security_token]):
raise Exception("Failed to get linked role credentials from environment variables.")
# 2. Initialize the OSS client with temporary credentials
# Assume the role has been granted access to 'your-bucket-name'
auth = oss2.StsAuth(access_key_id, access_key_secret, security_token)
bucket = oss2.Bucket(auth, 'http://oss-<regionID>-internal.aliyuncs.com', 'your-bucket-name')
# 3. Access OSS resources using the client
try:
# List objects in the bucket
for obj in oss2.ObjectIterator(bucket):
print('object name: ' + obj.key)
print("Successfully accessed OSS with linked role.")
except oss2.exceptions.OssError as e:
print(f"Error accessing OSS: {e}")Exemple de code (Shell) :
#!/bin/bash
access_key_id=${LINKED_ROLE_ACCESS_KEY_ID}
access_key_secret=${LINKED_ROLE_ACCESS_KEY_SECRET}
security_token=${LINKED_ROLE_SECURITY_TOKEN}
# Access OSS. Replace regionID, bucket_name, and file_name with actual values
echo "ID："$access_key_id
echo "token:"$security_token
ls -al /home/admin/usertools/tools/
# Example: Download a file from OSS to local test_dw.py using ossutil and print its content.
/home/admin/usertools/tools/ossutil64 cp --access-key-id $access_key_id --access-key-secret $access_key_secret --sts-token $security_token --endpoint http://oss-<regionID>-internal.aliyuncs.com oss://<bucket_name>/<file_name> test_dw.py
echo "************************ Success ************************, printing"
cat test_dw.pyMéthode 2 : Utiliser Credentials Client (recommandé pour Python)
Exemple de code (Python) :
Cet exemple nécessite une image Python personnalisée avec oss2 et alibabacloud_credentials installés. Pour plus de détails, consultez la section Image personnalisée.
from alibabacloud_credentials.client import Client as CredentialClient
import oss2
# 1. Use the SDK to automatically obtain credentials
# It automatically reads LINKED_ROLE_* credential info from environment variables
cred_client = CredentialClient()
credential = cred_client.get_credential()
access_key_id = credential.get_access_key_id()
access_key_secret = credential.get_access_key_secret()
security_token = credential.get_security_token()
if not all([access_key_id, access_key_secret, security_token]):
raise Exception("Failed to get linked role credentials via SDK.")
# 2. Initialize the OSS client with credentials
auth = oss2.StsAuth(access_key_id, access_key_secret, security_token)
bucket = oss2.Bucket(auth, 'http://oss-cn-hangzhou.aliyuncs.com', 'your-bucket-name')
# 3. Access OSS
print("Listing objects in bucket...")
for obj in oss2.ObjectIterator(bucket):
print(' - ' + obj.key)
print("Successfully accessed OSS with linked role via SDK.")Étapes suivantes : Soumettre et déployer
Les configurations de planification ne prennent pas effet immédiatement après leur définition dans l'environnement de développement. Le nœud doit être soumis et déployé dans l'environnement de production avant que le système de planification ne génère des instances périodiques et n'exécute automatiquement les tâches selon la dernière configuration.
Documentation connexe
Paramètres de planification : Référence du format des paramètres de planification
Heure de planification : Référence de l'heure de planification
-
Dépendances de planification :
Paramètres de sortie du nœud : Référence des paramètres de sortie du nœud