DataWorks:Dépannage et gestion des problèmes de développement de nœuds

Choisir une méthode de vérification

• Erreurs de syntaxe lors de la saisie — Le diagnostic de syntaxe en temps réel (LSP) les signale en temps réel.

• Règles de gouvernance intégrées — Une analyse en direct applique des règles intégrées efficaces au nœud actif lorsque vous l'enregistrez.

• Couverture complète des règles — Déclenchez manuellement une vérification approfondie pour appliquer toutes les règles, y compris les règles IA personnalisées. Vous pouvez analyser un seul fichier ou un lot de fichiers ouverts.

Activer les éléments de configuration

Ajustez les paramètres de diagnostic des problèmes pour les adapter à votre flux de travail de développement. Tous les éléments de configuration prennent effet uniquement pour le compte Alibaba Cloud actuel.

DataStudio Governance Check Module Enablement contrôle la capacité de vérification du plug-in Data Asset Governance, et SyntaxErrorEnable contrôle le diagnostic de syntaxe en temps réel. Ces deux options vérifient la qualité du code à différents niveaux. Activez les deux pour obtenir une couverture complète du diagnostic des problèmes.

1. Accédez à la page de liste des espaces de travail DataWorks, sélectionnez l'espace de travail cible, puis choisissez Quick Start > DataStudio dans la colonne Actions.

2. Cliquez sur Setup en bas du volet de navigation de gauche, puis cliquez sur l'onglet User de la page Setup.

   Le tableau suivant décrit les éléments de configuration.

Gérer la bibliothèque de règles intégrée

Les bibliothèques de règles pilotent le comportement de vérification du plug-in Data Asset Governance et se composent de règles intégrées et de règles personnalisées. Activez ou désactivez une règle spécifique selon vos besoins.

La gestion de la bibliothèque de règles prend effet uniquement pour le compte Alibaba Cloud actuel.

1. Dans le volet de navigation de gauche de la page DataStudio, cliquez sur l'icône de gouvernance pour ouvrir la configuration du plug-in Data Asset Governance.

2. Dans la section Built-in Rule Library du panneau du plug-in Data Asset Governance, recherchez la règle de gouvernance cible et cliquez sur le commutateur à côté de celle-ci pour activer ou désactiver la règle.

   • Enabled (par défaut) : La règle est vérifiée lorsque vous enregistrez un nœud.

   • Disabled : La règle n'est plus vérifiée lorsque vous enregistrez un nœud.

Bibliothèque de règles personnalisée

Lorsque les règles intégrées ne peuvent pas couvrir la logique métier spécifique ou les normes de codage de votre équipe, utilisez la bibliothèque de règles personnalisée du plug-in Data Asset Governance pour définir de nouvelles règles de vérification. Décrivez chaque règle en langage naturel et fournissez des exemples corrects et incorrects.

Scénarios de règles personnalisées pris en charge

Procédure

1. Dans le volet de navigation de gauche de la page DataStudio, cliquez sur l'icône de gouvernance pour ouvrir la configuration du plug-in Data Asset Governance.

2. Dans la section Custom rule library du panneau du plug-in Data Asset Governance, cliquez sur + pour créer une règle.

   Pour générer une règle de gouvernance avec DataWorks Copilot, cliquez sur AI Generation.

3. Configurez les champs de la règle. Cet exemple crée la règle personnalisée suivante :

   • Rule Name : Fact table updates must include WHERE.

   • Severity : Le niveau d'avertissement vous invite uniquement pendant le développement, et le niveau d'erreur déclenche une alerte et bloque la publication avant le déploiement. Dans cet exemple, sélectionnez Warning.

   • Scope : Sélectionnez la portée des nœuds à laquelle la règle s'applique, telle que MaxCompute > MaxCompute SQL.

   • Effective scope : Les niveaux user level, workspace level et tenant level sont pris en charge. Seul un administrateur locataire peut voir le niveau locataire, seul un administrateur d'espace de travail peut voir le niveau espace de travail, et un membre régulier ne peut voir que l'option de niveau utilisateur.

   • Rule Description : Check UPDATE statements in MaxCompute SQL. If a statement updates a fact table whose name ends with _f but has no WHERE clause, flag it as a high-risk issue.

   • Valid example :

     • UPDATE my_project.order_detail_f SET status='shipped' WHERE order_id='123';

     • UPDATE my_project.order_detail_dim SET status='shipped';

   • Invalid example : UPDATE my_project.order_detail_f SET status='expired';

4. Cliquez sur Save. La règle prend effet dans deep check.

   Pour cesser d'utiliser une règle de gouvernance personnalisée, survolez-la et cliquez sur l'icône de désactivation qui apparaît.

deep check

Une vérification approfondie (deep check) est une vérification complète et longue que vous déclenchez manuellement. Elle applique toutes les règles de gouvernance, y compris les règles IA personnalisées. En revanche, l'analyse en direct qui s'exécute lorsque vous enregistrez un nœud s'applique uniquement aux règles intégrées efficaces. Pour vérifier votre code par rapport à l'ensemble complet de règles, exécutez une vérification approfondie.

Pour analyser un seul fichier

Pour analyser le fichier actuellement ouvert dans l'éditeur, cliquez sur deep check au-dessus de l'éditeur. L'éditeur analyse le fichier en profondeur et signale les problèmes restants.

Par exemple, dans le code d'exemple de Démarrage rapide, si vous corrigez uniquement le problème Partitioned table queries must include a partition, l'analyse signale le problème non résolu Creating tables in SQL is not allowed.

Pour analyser plusieurs fichiers par lot

Prenez note des limites suivantes avant de démarrer une analyse par lot :

• Une vérification par lot couvre uniquement les onglets de fichiers actuellement ouverts dans l'éditeur. Les fichiers qui ne sont pas ouverts ne peuvent pas être sélectionnés.

• Vous pouvez sélectionner jusqu'à 5 fichiers.

• Une seule vérification approfondie peut s'exécuter à la fois lors d'une vérification par lot.

1. Dans le volet de navigation de gauche de la page DataStudio, cliquez sur l'icône de gouvernance pour ouvrir la configuration du plug-in Data Asset Governance.

2. Dans la section deep check du panneau du plug-in Data Asset Governance, sélectionnez les fichiers et les règles pour la vérification par lot, puis démarrez la vérification approfondie.

   Une fois la vérification approfondie terminée, l'onglet deep check en bas affiche les résultats. Par exemple, la vérification du fichier testassetrule renvoie deux avertissements : Creating tables in SQL is not allowed [my_partitioned_table] (règle ForbidUseCreateTable, ligne 7, colonne 28) et Partitioned table queries must include a partition (règle MissPartitionKeyFilter, ligne 17, colonne 18). Cliquez sur un nom de règle pour afficher ses détails.

Dans le volet de résultats deep check, cliquez sur View Log dans le coin supérieur droit pour examiner comment le grand modèle de langage a raisonné sur chaque règle de vérification.

Les requêtes de tables partitionnées doivent inclure une partition

Risque : L'interrogation d'une table partitionnée MaxCompute sans spécifier de partition déclenche une analyse complète de la table, ce qui consomme de grandes quantités de ressources de calcul et génère des coûts de calcul élevés.

Exemple de code incorrect :

SELECT user_id, order_amount
FROM user_orders
WHERE status = 'paid';

Exemple de code correct :

SELECT user_id, order_amount
FROM user_orders
WHERE status = 'paid'
AND pt = '${bizdate}'; -- Add a partition filter

Logique de correction automatique : Quick Fix est pris en charge. Le système ajoute un filtre de partition à la clause WHERE, tel que AND pt = '${bizdate}'.

INSERT INTO avec la propriété de réexécution n'est pas autorisé

Risque : Si une tâche SQL contient uniquement la logique INSERT INTO et que sa configuration de planification autorise les réexécutions, chaque réexécution ajoute des données à la table cible. Cela provoque facilement des données en double et compromet la précision des données.

Exemple de code incorrect :

-- The task property is set to "rerunnable"
INSERT INTO target_table SELECT * FROM source_table;

Exemple de code correct :

-- The task property is set to "rerunnable"
INSERT OVERWRITE TABLE target_table SELECT * FROM source_table;

Logique de correction automatique : Quick Fix est pris en charge. Le système change INSERT INTO en INSERT OVERWRITE afin qu'une réexécution écrase les données au lieu de les ajouter.

Les types de champs JOIN doivent correspondre

Risque : Dans MaxCompute SQL, si les champs de clé étrangère d'une opération JOIN ont des types incohérents, une conversion de type implicite se produit. Cela peut provoquer des erreurs de calcul et une dégradation des performances, et affecter la qualité des données.

Exemple de code incorrect :

-- a.user_id is BIGINT, b.uid is STRING
SELECT * FROM table_a a JOIN table_b b ON a.user_id = b.uid;

Exemple de code correct :

-- a.user_id is BIGINT, b.uid is STRING
SELECT * FROM table_a a JOIN table_b b ON a.user_id = CAST(b.uid AS BIGINT);

Logique de correction automatique : Quick Fix est pris en charge. Le système détecte l'incompatibilité et applique la fonction CAST à l'un des champs pour convertir explicitement son type afin qu'il corresponde à l'autre champ.

INSERT dans une table qui n'appartient pas au projet actuel

Risque : L'écriture de données depuis une tâche du projet A vers une table du projet B est une opération à haut risque. Elle rompt l'isolation entre les projets et peut entraîner un accès non autorisé aux données et des fuites de données.

Exemple de code incorrect :

-- Run in a task of project_A
INSERT INTO project_B.some_table SELECT * FROM my_table;

Exemple de code correct :

-- Recommended approach: let a task in the project that owns the table (project_B) write the data.
-- Avoid this operation in project_A.

Logique de correction automatique : La correction automatique n'est pas prise en charge. Ajustez le lien de synchronisation des données en fonction de vos besoins métier afin que le projet cible écrive les données avec sa propre tâche.

Les tâches automatiquement déclenchées en ligne ne doivent pas écrire dans des tables de l'environnement de développement

Risque : Lorsqu'une tâche automatiquement déclenchée dans l'environnement de production écrit des données dans une table de l'environnement de développement, le niveau de protection des données diminue et des risques de sécurité des données apparaissent.

Exemple de code incorrect :

-- Run in a task of the production environment (PROD)
INSERT OVERWRITE TABLE user_dev.temp_data SELECT * FROM user_prod.source_data;

Exemple de code correct :

-- A production task must write to a table in the production environment
INSERT OVERWRITE TABLE user_prod.result_data SELECT * FROM user_prod.source_data;

Logique de correction automatique : La correction automatique n'est pas prise en charge. Modifiez manuellement la table cible afin que le flux de données soit conforme aux normes d'isolation des environnements.

La création de tables en SQL n'est pas autorisée

Risque : L'utilisation directe de CREATE TABLE dans une tâche SQL planifiée rend la propriété de la table peu claire, car la table appartient généralement au compte Alibaba Cloud ou au compte de planification. Cela augmente les coûts de gestion et crée un risque de suppression accidentelle des données.

Exemple de code incorrect :

CREATE TABLE my_temp_table (id INT);
INSERT INTO my_temp_table VALUES (1);

Exemple de code correct :

-- Create the table in the DataWorks table management module first, and then use it directly in the SQL task.
INSERT INTO my_temp_table VALUES (1);

Logique de correction automatique : La correction automatique n'est pas prise en charge. Créez la table dans la gestion des métadonnées DataWorks, ou utilisez CREATE TABLE IF NOT EXISTS pour éviter les erreurs dans certains scénarios.

Vérificateur de paramètre de planification manquant

Risque : Une tâche automatiquement déclenchée traite les données de manière incrémentielle par heure. Si la condition WHERE omet un paramètre de planification tel que ${bizdate}, la tâche pourrait traiter toutes les données chaque jour ou traiter une plage de dates incorrecte. Cela entraîne des données manquantes ou incorrectes et gaspille de grandes quantités de ressources.

Exemple de code incorrect :

-- Incorrect: the scheduling parameter is missing, so daily incremental processing is impossible
INSERT OVERWRITE TABLE users_active_today PARTITION (pt = '${bizdate}')
SELECT    user_id  FROM    login_log; -- WHERE pt = '...' is missing

Exemple de code correct :

-- Correct: use the scheduling parameter as a filter to process data incrementally every day
INSERT OVERWRITE TABLE users_active_today PARTITION (pt = '${bizdate}')
SELECT    user_id FROM    login_log
WHERE    pt = '${bizdate}';

Logique de correction automatique : La correction automatique est partiellement prise en charge. Le plug-in met en évidence l'endroit où un filtre de paramètre de planification pourrait manquer. Étant donné que la logique métier varie, ajoutez manuellement le filtre correct en fonction de vos besoins.

Ces vérifications affectent-elles les performances de l'éditeur ou le temps nécessaire pour enregistrer une tâche ?

Le diagnostic de syntaxe en temps réel (LSP) a un impact léger mais acceptable sur les performances de l'éditeur. Le plug-in Data Asset Governance s'exécute lorsque vous enregistrez un nœud, ce qui ajoute un petit laps de temps à l'opération d'enregistrement. La durée exacte dépend de la complexité du code et du nombre de règles. Si vous remarquez un ralentissement évident, vérifiez votre environnement réseau ou contactez le support technique.

Le diagnostic des problèmes est-il facturé séparément et DataWorks Copilot est-il requis ?

Le diagnostic des problèmes est une fonctionnalité de base de DataWorks et n'est pas facturé séparément. Cependant, si vous utilisez les suggestions de correction de DataWorks Copilot, les règles de facturation décrites dans Aperçu de Data Agent s'appliquent. Vous pouvez également corriger les problèmes manuellement sans Copilot.

J'ai activé la fonctionnalité, mais les problèmes dans mon code ne sont pas détectés. Pourquoi ?

Effectuez le dépannage comme suit :

• Vérifiez les interrupteurs principaux : Assurez-vous que DataStudio Governance Check Module Enablement et SyntaxErrorEnable sont activés dans Setup > User. Pour le chemin de navigation et les valeurs valides, consultez Activer les éléments de configuration.

• Vérifiez les interrupteurs de règles : Accédez à la Built-in Rule Library et assurez-vous que les règles que vous souhaitez appliquer sont activées. Pour les instructions, consultez Gérer la bibliothèque de règles intégrée.

• Confirmez le type de nœud : Vérifiez si le type de nœud actuel se trouve dans la portée de la règle cible.

• Vérifiez le réseau : Vérifiez si une requête réseau a échoué dans les outils de développement de votre navigateur. Le service LSP ou le service de gouvernance a pu ne pas se charger en raison de problèmes réseau.

Que se passe-t-il si le service LSP ou le service du plug-in de gouvernance n'est pas disponible ?

Si le service backend est temporairement indisponible, le diagnostic des problèmes échoue silencieusement. Vous ne verrez pas d'invites de syntaxe en temps réel ni de problèmes de gouvernance lors de l'enregistrement, mais l'édition et l'enregistrement du code fonctionnent toujours comme d'habitude. Actualisez la page et déclenchez à nouveau les vérifications.