DataWorks:Orquestração de workflows agendados

Etapa 1: Preparar o mecanismo de computação e os dados

1. No workspace de destino, bind a MaxCompute compute engine.

2. No MaxCompute, crie a tabela a seguir para armazenar os resultados.

   -- Create a simple result table
   CREATE TABLE IF NOT EXISTS dw_order_count_test (
       order_date STRING,
       total_count BIGINT
   ) 
   PARTITIONED BY (ds STRING); -- Partitioned by ds to store daily aggregation results

Etapa 2: Criar um workflow agendado

1. Acesse a página Workspaces no console do DataWorks. Na barra de navegação superior, selecione a região desejada. Localize o workspace desejado e escolha Shortcuts > Data Studio na coluna Actions.

   Se o botão estiver identificado como Data Development, ele abre o Data Studio legado. Não clique nele.

2. Clique no ícone na barra de navegação à esquerda e, à direita de Project Directory, clique em > Create Workflow para abrir a página Create Workflow.

3. Na caixa de diálogo Create Workflow, defina Scheduling Type como Periodic Scheduling, insira as informações necessárias (por exemplo, defina Name como minimal_daily_demo) e conclua a criação.

Etapa 3: Orquestrar o workflow — arrastar nós e conectar dependências

1. No canvas do workflow, arraste um nó Zero-Load Node a partir do painel de componentes à esquerda e nomeie-o como start_node.

   Zero-Load Node serve apenas para definir o ponto de partida de um processo de negócio e não é executado de fato.

2. Arraste um nó MaxCompute SQL e nomeie-o como count_orders.

3. Clique no círculo na parte inferior de start_node e arraste uma linha até a parte superior de count_orders para construir um pipeline de processamento simples.

Etapa 4: Desenvolver o código do nó

1. Dê um duplo clique no nó count_orders para abrir o editor de código do nó.

2. Escreva o código de lógica de negócio do nó (dados estatísticos simulados são usados aqui).

   -- bizdate is a defined scheduling variable whose meaning needs to be specified in the scheduling configuration
   INSERT OVERWRITE TABLE dw_order_count_test PARTITION (ds='${bizdate}')
   SELECT 
       '${bizdate}' as order_date,
       COUNT(*) as total_count
   FROM (SELECT 1 as id UNION ALL SELECT 2 as id) t; -- Simulated data

   Para mais informações sobre o desenvolvimento de nós, consulte Develop a MaxCompute SQL node .

3. Clique no botão Save na parte superior do editor de nó para salvar a configuração.

Etapa 5: Configurar agendamento e parâmetros

1. Volte ao workflow. No lado direito do canvas do workflow, clique em Scheduling Settings > aba Scheduling time:

   1. Defina Scheduling Frequency como Day.

   2. Defina Scheduling time como 00:05 (ou seja, 00:05 todos os dias).

2. No lado direito do editor do nó count_orders, configure Scheduling Settings > Scheduling Parameters. Adicione um parâmetro com Parameter name definido como bizdate e Parameter Value definido como $[yyyymmdd-1] (isso representa a data atual menos um dia, ou seja, o dia anterior).

Etapa 6: Depurar um nó individual e o workflow completo

1. Depuração do nó count_orders:

   1. Configurar parâmetros de depuração: clique em Debug Configuration no lado direito da página de edição do nó.

      1. Em Compute Resource, selecione o recurso de computação MaxCompute preparado na Etapa 1.

      2. Em Script Parameters, insira o Value Used in This Run. O valor padrão é o dia anterior à data atual.

   2. Executar a tarefa de depuração: clique no botão Run na barra de ferramentas. O nó é executado com os parâmetros de depuração configurados em Debug Configuration.

   3. Após os resultados atenderem às expectativas, clique em Sync to Scheduling no canto superior direito para sincronizar a configuração de execução com as configurações de agendamento.

2. Depuração do workflow:

   1. Volte ao canvas do workflow e clique no ícone na barra de ferramentas superior.

   2. Na caixa de diálogo exibida, insira o Value Used in This Run para o workflow (por exemplo, se hoje é 20260120, bizdate deve ser substituído por 20260119).

Etapa 7: Implantar em produção

1. Volte ao workflow e clique no botão na barra de ferramentas superior.

2. No painel de implantação, o sistema realiza verificações de dependências e configuração. Após confirmar que tudo está correto, clique em Start Release Production e defina o método de implantação como Full Publishing.

3. Após uma implantação bem-sucedida, acesse o Operation and Maintenance Center para verificar se o workflow aparece na lista de tarefas agendadas.

Orquestração de nós/workflows

Orquestração complexa: controle de fluxo

Nota

Os nós de ramificação/junção e os nós for-each/do-while estão disponíveis apenas no DataWorks Standard Edition e versões posteriores.

Os nós de controle de fluxo elevam o desenvolvimento de dados de uma simples integração de tarefas para uma verdadeira orquestração de negócios. Eles vão além do modelo de dependência linear única dos DAGs tradicionais, adicionando lógica avançada por meio de um conjunto preciso de nós de controle.

Nome do nó	Descrição do nó
Virtual node	Um nó virtual não executa computações reais. Ele gerencia centralmente múltiplas subtarefas e funciona como o nó inicial de um workflow. Por exemplo, em um workflow de análise de pedidos de produtos, um nó virtual chamado workshop pode conectar duas tarefas de sincronização em lote, tornando o caminho do fluxo de dados mais claro. Nota No desenvolvimento de nós standalone, utilize o nó raiz do workspace como nó de dependência inicial.
Branch node	Direciona para lógicas downstream diferentes com base nos resultados upstream. Por exemplo, se o total diário de pedidos for 0, um nó de alerta é acionado e as computações subsequentes são interrompidas; se o total for maior que 0, o fluxo segue para o nó de geração de relatórios.
Join node	Mescla os resultados de execução de múltiplas ramificações para resolver problemas de dependência downstream. Por exemplo, uma tarefa de liquidação financeira depende de duas ramificações: "liquidação normal" e "lógica de ajuste". O nó de junção garante que o arquivamento do relatório final seja disparado assim que qualquer uma das ramificações for concluída com sucesso.
For-each node	Itera sobre o conjunto de resultados de um nó de atribuição e executa operações downstream para cada elemento. Por exemplo, para 31 nomes de províncias obtidos por um nó de atribuição, o nó for-each executa uma tarefa de limpeza de dados 31 vezes, processando a partição de dados de uma província a cada iteração.
Do-while node	Repete a execução até que uma condição seja atendida. Por exemplo, a cada 10 minutos uma API externa é chamada para consultar o status de sincronização de dados. Se o valor retornado for "Processing", o loop continua. Se o valor retornado for "Completed", o loop é encerrado e o processamento subsequente é iniciado.

Para mais informações, consulte Common nodes in Data Studio .

Orquestração complexa: percepção de estado e integração externa

Nota

Os nós de verificação estão disponíveis apenas no DataWorks Professional Edition e versões posteriores. Os demais nós estão disponíveis apenas no DataWorks Enterprise Edition.

Esses nós avaliam se os recursos físicos necessários ou as tarefas anteriores estão prontos e integram-se a sistemas de terceiros para conectar plataformas de dados a sistemas de negócios.

Nome do nó	Descrição do nó
HTTP trigger	Recebe requisições HTTP de sistemas externos para disparar tarefas do DataWorks. Por exemplo, após o sistema de negócios upstream concluir o fechamento diário, ele chama uma API HTTP para iniciar o pipeline de processamento de dados T+1 do DataWorks.
Check node	Monitora se recursos externos (como arquivos no OSS ou partições do MaxCompute) estão prontos e dispara as tarefas downstream assim que ficam disponíveis. Por exemplo, um nó de verificação aguarda o arquivo de log do dia aparecer no OSS e então inicia a tarefa de parsing de logs.
Dependency check node	Utiliza polling ativo, combinações lógicas e verificações de prontidão de dependências entre ciclos ou entre workspaces para disparar tarefas downstream após todas as condições serem atendidas. Por exemplo, um nó agendado diariamente aguarda a conclusão de todas as 24 tarefas horárias do dia anterior.

Para mais informações, consulte Common nodes in Data Studio .

Encapsular sub-workflows para reutilização de lógica

Você pode encapsular um pipeline de subtarefas estável e reutilizável em um sub-workflow por meio de um nó SUB_PROCESS, permitindo que outros workflows o referenciem. Por exemplo, linhas de negócio de e-commerce, publicidade e IoT podem compartilhar um pipeline padronizado de limpeza de dados, estatísticas resumidas e verificações de Data Quality.

Procedimento:

1. No workflow child_workflow que você pretende referenciar, defina a propriedade General do workflow como Can be cited. Isso converte o workflow em um sub-workflow.

2. No workflow principal, arraste um nó SUB_PROCESS e defina o workflow referenciado como child_workflow.

Sub-workflows possuem as seguintes restrições:

• Internalidade: O workflow e todos os seus nós internos não podem ter dependências de tarefas externas.

• Isolamento: O workflow não pode ser configurado diretamente como dependência por nenhuma tarefa externa.

• Disparo passivo: Após a implantação, o workflow não gera automaticamente instâncias agendadas. Ele é executado apenas quando chamado por um nó SUB_PROCESS em outro workflow.

  Para mais informações, consulte Create a sub-workflow .

Configurações de dependência de agendamento

As dependências de agendamento conectam tarefas isoladas em um pipeline de produção de dados ordenado por meio de duas condições: cumprimento do horário agendado e sucesso do upstream. Ao orquestrar nós dentro de um workflow, as dependências de agendamento são estabelecidas automaticamente. Também é possível configurar dependências mais complexas por meio das configurações de dependência de agendamento.

Para mais informações, consulte Configure scheduling dependencies .

Design e fluxo de parâmetros

Parâmetros de workflow, variáveis de workflow e parâmetros no nível do workspace são suportados apenas ao utilizar um grupo de recursos serverless.

O DataWorks Data Studio oferece suporte a quatro níveis de passagem de parâmetros e permite a transferência dinâmica de dados entre nós por meio de parâmetros de contexto. Listados do menor para o maior escopo:

Configurações de agendamento

Os agendamentos são definidos no nível do workflow. Os nós internos podem apenas definir um tempo de atraso de execução, calculado adicionando o atraso ao horário agendado do workflow.

Depuração de nó individual

A depuração de nó individual verifica a lógica do código dentro de um único nó — por exemplo, validar uma instrução SQL, um script Python ou uma tarefa de sincronização do Data Integration. Esse modo executa apenas o nó atual, sem acionar dependências upstream ou downstream.

1. No painel Debug Configuration à direita do nó, configure os seguintes parâmetros:

   Nome do parâmetro	Descrição
   Compute resource	Selecione o recurso de computação associado. Se nenhum recurso de computação estiver disponível, selecione Create Compute Resource na lista suspensa. Importante Certifique-se de que o recurso de computação e o grupo de recursos estejam conectados. Para mais informações, consulte Network connectivity.
   Resource group	Selecione um grupo de recursos que tenha passado no teste de conectividade durante a associação do recurso de computação. Alguns nós permitem configurar dependency packages no grupo de recursos para estender o ambiente de execução.
   (Opcional) Dataset	Alguns nós (como Shell e Python) suportam mounting datasets para acessar dados não estruturados armazenados no OSS ou NAS.
   (Opcional) Script parameters	Ao configurar o conteúdo do nó e definir variáveis no formato ${parameter_name}, é necessário configurar Parameter name e Parameter Value em Script Parameters. Durante a execução, as variáveis são substituídas dinamicamente pelos valores reais. Para mais informações, consulte Configure scheduling parameters.
   (Opcional) Associated role	Alguns nós (como Shell e Python) suportam configuring associated roles para acessar recursos de outros serviços da Alibaba Cloud.

2. Na barra de ferramentas acima do nó, clique em Save e, em seguida, execute a tarefa do nó clicando em Run.

3. Visualize o log de execução e os resultados na parte inferior do nó.

Depuração de workflow

A depuração de workflow verifica se as dependências de dados, a passagem de parâmetros e a ordem de execução entre os diversos nós do pipeline estão corretas. Após a depuração de nós individuais, você pode depurar parte do pipeline ou o workflow completo.

1. Na página do canvas DAG do workflow, clique em Run na barra de ferramentas superior. Também é possível selecionar um nó, clicar com o botão direito e escolha Run to this node ou Run from this node para realizar uma verificação parcial.

2. Na caixa de diálogo exibida, atribua valores temporários para todas as variáveis dos nós no workflow (como ${bizdate}) para esta execução de depuração.

3. O sistema executa os nós rigorosamente de cima para baixo, conforme as relações de dependência definidas no DAG. Acompanhe o status dos nós em tempo real no canvas e clique em qualquer nó para visualizar o log de execução.

4. Clique em Return no lado esquerdo do canvas para retornar ao estado de desenvolvimento do workflow.

   O histórico de execuções no lado direito exibe todos os registros de depuração do workflow.

Gerenciar nós do workflow

O DataWorks permite importar nós standalone existentes para um workflow, remover nós de um workflow ou mover nós entre workflows, promovendo reutilização eficiente e gerenciamento modular.

Importar nós existentes para um workflow

Adicione nós standalone existentes — que não pertencem a nenhum workflow — ao canvas do workflow atual por meio de Import Node para reutilização.

1. Dê um duplo clique no workflow desejado para abrir a página de edição do canvas.

2. No painel de componentes à esquerda, alterne para a aba Import Node.

3. O painel lista todos os nós standalone disponíveis para adição. Filtre e pesquise por Node Type, Path ou Node Name para localizar rapidamente o nó desejado.

4. Após encontrar o nó, arraste-o para o canvas para concluir a importação.

Remover nós de um workflow

Você pode remover um nó de um workflow para transformá-lo em um nó standalone ou movê-lo diretamente para outro workflow.

• Remover do workflow como nó standalone

  Utilize este recurso quando precisar desacoplar um nó de um workflow para que ele deixe de fazer parte desse workflow.

  1. Na árvore de diretórios do projeto ou no canvas do workflow, clique com o botão direito no nó desejado.

  2. No menu de contexto, selecione Remove from workflow.

  3. Na caixa de diálogo de confirmação, selecione o caminho de destino onde o nó será armazenado após a remoção e confirme.

• Mover para outro workflow

  Utilize este recurso quando for necessário reestruturar um processo de negócios e migrar um nó do workflow atual para outro.

  1. Na árvore de diretórios do projeto ou no canvas do workflow, clique com o botão direito no nó desejado.

  2. No menu de contexto, selecione Move to another workflow.

  3. Na lista exibida, selecione o workflow de destino e confirme.

     Também é possível selecionar e arrastar um nó diretamente para o workflow de destino para movê-lo.

Clonar um workflow

A clonagem copia um workflow existente — incluindo todos os seus nós internos, código e dependências — para gerar um workflow independente. Para clonar, acesse Project Directory, clique com o botão direito no workflow desejado e selecione Cloning.

A clonagem copia praticamente todas as configurações, o que pode introduzir riscos. Antes de implantar o workflow clonado, verifique os itens a seguir (checagem de "isolamento de ambiente"):

1. Tabelas de saída e data sources de destino: O código do workflow clonado grava nas mesmas tabelas de destino do workflow original. Modifique os nomes das tabelas de destino no código (por exemplo, altere ods_user_table para dev_ods_user_table) ou ajuste a configuração de saída do nó para evitar que múltiplas tarefas operem na mesma tabela, o que causaria conflitos de dados.

2. Dependências upstream: Verifique a configuração de dependências upstream do workflow. O workflow clonado ainda depende das tarefas upstream originais por padrão. Confirme se isso atende às suas expectativas; caso contrário, pode haver confusão no pipeline de dados ou execuções secas de tarefas.

3. Configuração de parâmetros: Verifique os parâmetros personalizados do workflow e de seus nós internos, especialmente parâmetros relacionados a partições de data (como ${bizdate}), caminhos de entrada/saída e outros parâmetros. Certifique-se de que estejam corretos no novo ambiente.

Além de clonar workflows, também é possível clonar nós dentro de um workflow, porém a cópia de nós entre workflows diferentes não é suportada.

Gerenciamento de versões

O gerenciamento de versões registra automaticamente cada alteração no workflow, permite visualizar e comparar versões históricas e possibilita o rollback para qualquer estado anterior quando necessário.

No lado direito do canvas do workflow, o painel Version exibe dois tipos de registros:

• Registro de desenvolvimento: Gerado toda vez que você clica em Save no canvas. Esse snapshot evita a perda acidental de código durante o desenvolvimento e não afeta tarefas em execução na produção.

• Registro de implantação: Gerado após o workflow ser implantado no ambiente de produção. Esta é a versão executada pelo agendador de produção. Quando tarefas de produção apresentarem problemas, concentre-se nos registros de implantação para o rollback.

Casos de uso típicos

• Rollback rápido em caso de falha: Quando uma tarefa de produção falha devido a alterações no código, use Restore para reverter o workflow à última versão de implantação estável com um clique, minimizando o tempo de inatividade.

• Auditoria e rastreamento de alterações: Para investigar quando uma lógica foi alterada e por quem, utilize a lista de versões e os recursos de Diff para rastrear cada mudança no código.

• Recuperação de código: Se você excluir acidentalmente uma lógica de código sem salvar, restaure a partir do registro de desenvolvimento mais recente.

Considerações importantes

• A restauração sobrescreve a área de desenvolvimento atual: A opção Restore utiliza a versão histórica selecionada para sobrescrever todo o código e todas as configurações no canvas atual. Antes de restaurar, faça backup de quaisquer alterações não confirmadas copiando-as para um editor de texto local.

• É necessário reimplantar após a restauração: A opção Restore apenas restaura o código para o estado de desenvolvimento. Você deve implantá-lo manualmente para que o rollback entre em vigor na produção.

Implantação e operações

• Implantação de nó/workflow: Após concluir o desenvolvimento do workflow, implante os nós/workflows no ambiente de produção. Nesse momento, os nós do ambiente de desenvolvimento geram tarefas agendadas correspondentes no ambiente de produção. Para mais informações, consulte Deploy nodes and workflows.

• Operações de nó/workflow: Os workflows no ambiente de produção são agendados periodicamente com base nas configurações de agendamento. Acesse Operation and Maintenance Center para visualizar o status de agendamento dos workflows e realizar as operações relacionadas. Para mais informações, consulte Scheduled tasks e Scheduled instances.

Mecanismo de execução de tarefas

Em cenários de agendamento, o sucesso geral de um workflow depende do status de execução de suas tarefas internas.

O sucesso geral de um workflow é determinado pelo status final de seus nós internos:

• Falha: Se qualquer nó crítico falhar, a instância inteira do workflow normalmente é marcada como falha.

• Congelar/Pausar: Se um nó do workflow for congelado ou pausado manualmente e esse nó for upstream de nós subsequentes, o pipeline é interrompido e o workflow inteiro também é marcado como falha.

• Nó join: Se o workflow utiliza um nó join, mesmo que um nó em uma branch upstream falhe, o workflow inteiro pode retornar "sucesso" desde que a lógica própria do nó join determine sucesso. Portanto, projete cuidadosamente as verificações upstream dos nós join para evitar que tarefas prossigam com erros não detectados.

Cenários especiais:

• Ao congelar uma instância de backfill de dados de uma tarefa de workflow, a instância do workflow é definida com o status sucesso.

• Em cenários de backfill de dados, se o sistema determinar que uma tarefa não pode ser executada, o workflow é definido com o status falha.