DataWorks:Deploy Center

Introdução ao recurso

No Deploy Center, uma operação de publicação trata objetos como nós, funções, recursos e widgets como as unidades mínimas de execução. Os fluxos de negócios associados e as dependências de nós são implantados no workspace de destino ao mesmo tempo. Para mais informações, consulte Publishing logic.

Com base nos diferentes ambientes de publicação, o Deploy Center no DataWorks oferece suporte a same-workspace publishing, cross-workspace publishing e cross-cloud publishing.

• Same-workspace publishing

  Este recurso está disponível apenas para workspaces que utilizam o standard mode with the new Data Studio. Ele permite publicar em lote objetos como nós, funções, recursos e widgets do ambiente de desenvolvimento para o ambiente de produção dentro do mesmo workspace.

• Cross-workspace publishing

  A implantação entre workspaces é usada principalmente para implantar objetos como nós, funções, recursos e componentes de um workspace no modo básico para outro workspace na mesma região e sob a mesma conta da Alibaba Cloud. Esse recurso também pode ser usado para isolar os ambientes de desenvolvimento e produção de workspaces no modo básico. Para mais informações, consulte Appendix: How to isolate development from production in basic mode.

• Cross-cloud publishing

  Este recurso oferece suporte à implantação de objetos — como nós, funções, recursos e componentes — entre contas, regiões ou plataformas cloud distintas. Está disponível apenas para workspaces que utilizam o legacy DataStudio. Em essência, esse recurso migra e implanta nós de um workspace de origem para um workspace de destino em uma região, conta ou plataforma cloud diferente.

Lógica de alterações na publicação

Se um nó possui dependências, seus nós ancestrais devem ser publicados no workspace de destino antes que o nó descendente possa ser publicado. As alterações em um nó publicado são as seguintes:

• Ao publicar um nó, o sistema substitui o prefixo do nome do workspace de origem pelo nome do workspace de destino nas entradas e saídas de todos os nós relacionados. Se o nó tiver dependências entre workspaces, configure também o parâmetro Dependency Mappings para o ambiente de publicação. As dependências ancestrais, as dependências descendentes e os nomes de entrada e saída do nó se alteram após a publicação conforme a configuração definida. Para mais informações, consulte:

  • No cross-workspace dependencies

  • Cross-workspace dependencies exist, but no cross-workspace dependency mapping is set

  • Cross-workspace dependencies exist, and cross-workspace dependency mapping is set

• Ao publicar uma tarefa que utiliza o engine do MaxCompute, o sistema modifica o código da tarefa, substituindo qualquer referência ao nome do workspace de origem pelo nome do workspace de destino. Para mais informações, consulte Code changes for tasks that use a MaxCompute engine.

Sem dependências entre workspaces

Os nós em project1 não possuem dependências entre workspaces. Todos os nós de project1 são publicados em project2.

Após a publicação, o prefixo project1 em todos os nomes de entrada e saída dos nós é alterado para project2. Por exemplo:

• O nome de entrada de task_A muda de project1_root para project2_root.

• O nome de saída de task_A muda de project1.task_A para project2.task_A.

Dependências entre workspaces existem, mas nenhum mapeamento de dependência entre workspaces foi definido

project1.task_A tem uma dependência entre workspaces em relação a project2.task_A. Todos os nós de project1 são publicados em project3.

Após a publicação, as alterações nos nós são as seguintes:

• Entradas e saídas dos nós: o prefixo project1 em todos os nomes de entrada e saída dos nós é alterado para project3.

• Dependências entre workspaces dos nós: project1.task_A originalmente tinha uma dependência entre workspaces em relação a project2.task_A. Após a publicação, project3.task_A mantém a dependência entre workspaces em relação a project2.task_A.

Dependências entre workspaces existem e o mapeamento de dependência entre workspaces foi definido

project1.task_A tem uma dependência entre workspaces em relação a project2.task_A. Todos os nós de project1 são publicados em project4, e um mapeamento de dependência é definido de project2 para project3.

Após a publicação, as alterações nos nós são as seguintes:

• Entradas e saídas dos nós: o prefixo project1 em todos os nomes de entrada e saída dos nós é alterado para project4.

• Dependências entre workspaces dos nós: project1.task_A originalmente tinha uma dependência entre workspaces em relação a project2.task_A. Após a publicação, a dependência entre workspaces de project4.task_A passa a apontar para project3.task_A.

Importante

Se um nó no workspace de origem usar um nome de saída do sistema para uma dependência entre workspaces, a operação de publicação poderá falhar. Isso ocorre quando a lista Scheduling > Output Name of Ancestor Node na configuração do nó inclui um nome de saída do sistema proveniente de outro workspace. Para resolver o problema, modifique a dependência para usar um nome de saída que não seja do sistema.

• Não referencie nomes de saída gerados pelo sistema:

  Em workspaces onde a opção Use Data Studio (New Version) não está ativada, o nome de saída do sistema segue o formato Workspace Name.File ID_out, como por exemplo shanghai_simple02.504822000_out.

• Referencie nomes de saída nos seguintes formatos:

  • Workspace Name.Output Table Name (Recomendado)

  • Workspace Name.Node Name

Alterações de código para tarefas que utilizam o engine do MaxCompute

Ao publicar uma tarefa que utiliza o engine do MaxCompute — como um nó ODPS SQL ou ODPS Spark — no workspace de destino, o sistema substitui o nome do workspace de origem pelo nome do workspace de destino no código da tarefa durante a execução.

Por exemplo, task_A é um nó ODPS SQL ou MaxCompute SQL. Em project1, o código para consultar table_A é SELECT * FROM project1.tableA. Em seguida, todos os nós de project1 são publicados em project2.

Após a publicação do nó em project2, o código para consultar table_A é alterado para SELECT * FROM project2.tableA.