Cette rubrique décrit les problèmes courants rencontrés lorsqu'une tâche s'exécute correctement mais ne génère aucune donnée.
Scénario 1 : Le nœud réussit avec un journal d'exécution
Le nœud exécute sa logique avec succès. Toutefois, lors de la planification automatique de l'instance périodique, il ne parvient pas à récupérer les données en amont ou signale que la partition de table n'existe pas. Une réexécution manuelle de l'instance permet de récupérer les données normalement.
Aucune dépendance n'est configurée sur la tâche en amont qui produit les données requises.
Une dépendance vis-à-vis du nœud en amont existe, mais la partition de table produite par ce dernier ne correspond pas à celle attendue. Cela indique que le cycle de planification est incorrect. Vérifiez la substitution des paramètres pour les instances en amont et en aval dans les paramètres de l'instance périodique et les détails du journal.
Reconfigurez les dépendances entre les nœuds.
Vérifiez les paramètres des nœuds en amont et en aval : sur la page Periodic Instances du centre d'opérations (Operation Center), le DAG affiche le nœud virtuel en amont xc_demo_start connecté au nœud de synchronisation hors ligne en aval xc_oss_data_sync. Sélectionnez un nœud et consultez l'onglet Properties pour vérifier le type de destination des données (MaxCompute), la durée d'exécution (40 s), le statut de l'instance (Success) et autres détails. Le paramètre d'exécution bizdate=20210614 indique que la date métier de cette instance est le 14 juin 2021.
Scénario 2 : Le nœud réussit sans journal d'exécution
Le nœud a effectué une exécution à blanc. Vérifiez le statut du nœud sur la page Properties.
Scénario 3 : Le journal de la tâche indique une réussite, mais le statut de l'instance indique un échec
Le journal d'exécution de la tâche affiche « Shell run successfully », mais le statut de l'instance indique un échec d'exécution. Ce scénario est généralement causé par une règle DQC (Data Quality Check) dont la validation a échoué.
DQC effectue des contrôles de qualité sur les données de sortie une fois la tâche terminée. Si une règle de qualité est configurée avec une politique de blocage et que le contrôle échoue, le système marque l'instance comme ayant échoué, même si la tâche elle-même s'est exécutée avec succès.
Étapes de dépannage :
Accédez à .
Recherchez la règle de surveillance de la qualité liée à la table de sortie.
Consultez l'historique d'exécution de la règle pour confirmer si le contrôle a réussi. En cas d'échec du contrôle, corrigez le problème de données ou ajustez la règle DQC, puis réexécutez l'instance.