DataWorks:Deploy Center

Présentation de la fonctionnalité

Dans le Deploy Center, une opération de publication traite les objets (nœuds, fonctions, ressources et widgets) comme des unités d'exécution minimales. Les flux métier associés et les dépendances entre nœuds sont déployés simultanément vers le workspace cible. Pour plus d'informations, consultez la section Logique de publication.

Selon l'environnement de publication, le Deploy Center dans DataWorks prend en charge la publication au sein du même workspace, la publication inter-workspace et la publication inter-cloud.

• Publication au sein du même workspace

  Cette fonctionnalité est disponible uniquement pour les workspaces utilisant le mode standard avec le nouveau Data Studio. Elle permet de publier par lot des objets (nœuds, fonctions, ressources et widgets) de l'environnement de développement vers l'environnement de production au sein du même workspace.

• Publication inter-workspace

  Le déploiement inter-workspace sert principalement à déployer des objets (nœuds, fonctions, ressources et composants) d'un workspace en mode basique vers un autre workspace situé dans la même région et sous le même compte Alibaba Cloud. Vous pouvez également utiliser cette fonctionnalité pour isoler les environnements de développement et de production des workspaces en mode basique. Pour plus d'informations, consultez l'Annexe : Comment isoler le développement de la production en mode basique.

• Publication inter-cloud

  Cette fonctionnalité prend en charge le déploiement d'objets (nœuds, fonctions, ressources et composants) entre différents comptes, régions ou plateformes cloud. Elle est disponible uniquement pour les workspaces qui utilisent l'ancien DataStudio. Elle migre et déploie les nœuds d'un workspace source vers un workspace cible situé dans une région, un compte ou une plateforme cloud différent(e).

Logique des modifications lors de la publication

Si un nœud possède des dépendances, publiez ses nœuds ancêtres vers le workspace cible avant de publier le nœud descendant. Les modifications apportées à un nœud publié sont les suivantes :

• Lors de la publication d'un nœud, le système remplace le préfixe du nom du workspace source par le nom du workspace cible dans les entrées et les sorties de tous les nœuds associés. Si le nœud présente des dépendances inter-workspace, configurez également le paramètre Dependency Mappings pour l'environnement de publication. Les dépendances ancêtres, les dépendances descendantes ainsi que les noms d'entrée et de sortie du nœud changent après la publication en fonction de votre configuration. Pour plus d'informations, consultez :

  • Aucune dépendance inter-workspace

  • Des dépendances inter-workspace existent, mais aucun mappage de dépendance inter-workspace n'est défini

  • Des dépendances inter-workspace existent et un mappage de dépendance inter-workspace est défini

• Lors de la publication d'une tâche qui utilise un moteur MaxCompute, le système modifie le code de la tâche. Il remplace toute mention du nom du workspace source par le nom du workspace cible. Pour plus d'informations, consultez la section Modifications de code pour les tâches utilisant un moteur MaxCompute.

Aucune dépendance inter-workspace

Les nœuds dans project1 n'ont aucune dépendance inter-workspace. Tous les nœuds de project1 sont publiés vers project2.

Après la publication, le préfixe project1 dans tous les noms d'entrée et de sortie des nœuds est remplacé par project2. Par exemple :

• Le nom d'entrée de task_A passe de project1_root à project2_root.

• Le nom de sortie de task_A passe de project1.task_A à project2.task_A.

Des dépendances inter-workspace existent, mais aucun mappage de dépendance inter-workspace n'est défini

project1.task_A a une dépendance inter-workspace sur project2.task_A. Tous les nœuds de project1 sont publiés vers project3.

Après la publication, les modifications apportées aux nœuds sont les suivantes :

• Entrées et sorties des nœuds : Le préfixe project1 dans tous les noms d'entrée et de sortie des nœuds est remplacé par project3.

• Dépendances inter-workspace des nœuds : project1.task_A avait initialement une dépendance inter-workspace sur project2.task_A. Après la publication, project3.task_A conserve sa dépendance inter-workspace sur project2.task_A.

Des dépendances inter-workspace existent et un mappage de dépendance inter-workspace est défini

project1.task_A a une dépendance inter-workspace sur project2.task_A. Tous les nœuds de project1 sont publiés vers project4, et un mappage de dépendance est défini de project2 vers project3.

Après la publication, les modifications apportées aux nœuds sont les suivantes :

• Entrées et sorties des nœuds : Le préfixe project1 dans tous les noms d'entrée et de sortie des nœuds est remplacé par project4.

• Dépendances inter-workspace des nœuds : project1.task_A avait initialement une dépendance inter-workspace sur project2.task_A. Après la publication, la dépendance inter-workspace de project4.task_A pointe vers project3.task_A.

Important

Si un nœud du workspace source utilise un nom de sortie système pour une dépendance inter-workspace, l'opération de publication peut échouer. Cela se produit si la liste Scheduling > Output Name of Ancestor Node dans la configuration du nœud inclut un nom de sortie système provenant d'un autre workspace. Pour résoudre ce problème, modifiez la dépendance afin d'utiliser un nom de sortie non système.

• Ne faites pas référence aux noms de sortie générés par le système :

  Dans les workspaces où l'option Use Data Studio (New Version) n'est pas activée, le nom de sortie système est au format Workspace Name.File ID_out, par exemple shanghai_simple02.504822000_out.

• Faites référence aux noms de sortie dans les formats suivants :

  • Workspace Name.Output Table Name (Recommandé)

  • Workspace Name.Node Name

Modifications de code pour les tâches utilisant un moteur MaxCompute

Lors de la publication d'une tâche utilisant un moteur MaxCompute (telle qu'une tâche ODPS SQL ou ODPS Spark) vers le workspace cible, le système remplace le nom du workspace source dans le code de la tâche par le nom du workspace cible lors de l'exécution.

Par exemple, task_A est un nœud ODPS SQL ou MaxCompute SQL. Dans project1, le code pour interroger table_A est SELECT * FROM project1.tableA. Tous les nœuds de project1 sont ensuite publiés vers project2.

Après la publication du nœud vers project2, le code pour interroger table_A devient SELECT * FROM project2.tableA.