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 seguinte tabela 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: Crie 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 rotulado como Data Development, ele abre o Data Studio legado. Não clique em nele.

2. Clique em 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. Na tela do workflow, arraste um Zero-Load Node do painel de componentes à esquerda e nomeie-o como start_node.

   O Zero-Load Node serve apenas para definir o ponto inicial de um processo de negócios e não executa de fato.

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

3. Clique em no círculo na parte inferior de start_node e arraste uma linha até o topo de count_orders para criar um pipeline de processamento simples.

Etapa 4: Desenvolver o código do nó

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

2. Escreva o código da lógica de negócios para o 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 em no botão Save na parte superior do editor de nós para salve a configuração.

Etapa 5: Configure agendamento e parâmetros

1. Retorne ao workflow. No lado direito da tela do workflow, clique em na aba Scheduling Settings > 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 único nó e todo o workflow

1. Depuração do nó count_orders:

   1. Configure 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. Execute a tarefa de depuração: Clique em no botão Run na barra de ferramentas. O nó executa com os parâmetros de depuração configurados em Debug Configuration.

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

2. Depuração do workflow:

   1. Retorne à tela do workflow e clique em 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 for 20260120, substitua bizdate por 20260119).

Etapa 7: Implantar em produção

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

2. No painel de implantação, o sistema realiza verificações de dependência e configuração. Após confirme 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 verifique 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 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 da integração de tarefas para a orquestração de negócios. Eles vão além do modelo de dependência linear única dos DAGs tradicionais ao adicionar lógica avançada por meio de um conjunto de nós de controle precisos.

Nome do nó	Descrição do nó
Nó virtual	Um nó virtual não realiza computações reais. Ele gerencie centralmente múltiplas subtarefas e serve 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 Para o desenvolvimento de nós independentes, use o nó raiz do workspace como o nó de dependência inicial.
Nó de ramificação	Direciona para diferentes lógicas downstream com base nos resultados upstream. Por exemplo, se o total diário de pedidos for 0, acione um nó de alerta e interrompa as computações subsequentes; se o total for maior que 0, continue para o nó de geração de relatórios.
Nó de junção	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 final do relatório seja acionado desde que qualquer uma das ramificações seja concluída com sucesso.
Nó For-each	Itera sobre o conjunto de resultados de um nó de atribuição e executa operações downstream em 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 vez.
Nó Do-while	Repete a execução até que uma condição seja atendida. Por exemplo, chame uma API externa a cada 10 minutos 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 começa.

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

Orquestração complexa: Consciência 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. Outros 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 fazer a ponte entre plataformas de dados e sistemas de negócios.

Nome do nó	Descrição do nó
Gatilho HTTP	Recebe solicitações HTTP de sistemas externos para acionar tarefas do dataworks. Por exemplo, após um sistema de negócios upstream concluir o fechamento diário, ele chama uma API HTTP para acionar o pipeline de processamento de dados T+1 do dataworks.
Nó de verificação	Monitora se recursos externos (como arquivos OSS ou partições MaxCompute) estão prontos e aciona tarefas downstream assim que eles ficarem disponíveis. Por exemplo, um nó de verificação aguarda o arquivo de log do dia aparecer no OSS e, em seguida, inicia a tarefa de análise de log.
Nó de verificação de dependência	Usa polling ativo, combinações lógicas e verificações de prontidão de dependência entre ciclos ou entre workspaces para acionar 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

É possível encapsular um pipeline de subtarefas estável e reutilizável em um sub-workflow por meio de um nó SUB_PROCESS, que outros workflows podem então referenciar. Por exemplo, linhas de negócios de e-commerce, publicidade e IoT podem compartilhar um pipeline padronizado para limpeza de dados, estatísticas resumidas e verificações de Qualidade de Dados.

Procedimento:

1. No workflow child_workflow que você planeja 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.

Os 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 definido diretamente como dependência por nenhuma tarefa externa.

• Acionamento passivo: Após a implantação, o workflow não gera automaticamente instâncias agendadas. Ele execute 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 ordenado de produção de dados por meio de duas condições: cumprimento do horário agendado e sucesso upstream. Ao orquestrar nós dentro de um workflow, as dependências de agendamento são estabelecidas automaticamente. Também é possível configure dependências mais complexas pelas configurações de dependência de agendamento.

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

Design e fluxo de parâmetros

O dataworks Data Studio suporta quatro níveis de passagem de parâmetros e permite a transferência flexível de dados dinâmicos entre nós por meio de parâmetros de contexto de nó. 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 só podem definir um tempo de execução atrasado, calculado adicionando o atraso ao horário agendado definido pelo workflow.

Depuração de nó único

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

1. No painel Debug Configuration no lado direito do nó, configure os seguintes parâmetros:

   Nome do parâmetro	Descrição
   Recurso de computação	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.
   Grupo de recursos	Selecione um grupo de recursos que tenha passado no teste de conectividade quando o recurso de computação foi associado. Alguns nós suportam configure 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) Parâmetros de script	Ao configure o conteúdo do nó e definir variáveis usando o formato ${parameter_name}, configure 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) Função associada	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 depois em Run para execute a tarefa do nó.

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 em múltiplos nós do pipeline estão corretas. Após a depuração de nó único, você pode depurar um pipeline parcial ou todo o workflow.

1. Na página da tela DAG do workflow, clique em no botão Run na barra de ferramentas superior. Você também pode selecione um nó, clique em 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 de nó no workflow (como ${bizdate}) para esta execução de depuração.

3. O sistema executa estritamente os nós de cima para baixo, seguindo as relações de dependência definidas no DAG. Monitore o status dos nós em tempo real na tela e clique em qualquer nó para visualize o log de execução.

4. Clique em no botão Return no lado esquerdo da tela para retornar ao estado de desenvolvimento do workflow.

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

Gerencie nós de workflow

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

Importar nós existentes para um workflow

Adicione nós independentes existentes que não pertencem a nenhum workflow à tela do workflow atual por meio de Import Node para reutilização.

1. Dê um clique duplo no workflow de destino para abrir a página de edição da tela.

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

3. O painel lista todos os nós independentes que podem ser adicionados. Filtre e pesquise por Node Type, Path ou Node Name para localizar rapidamente o nó de destino.

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

Remover nós de um workflow

Remova um nó de um workflow para torná-lo um nó independente ou mova-o diretamente para outro workflow.

• Remover de um workflow como nó independente

  Use este recurso quando precisar desacoplar um nó de um workflow para que ele não faça mais parte dele.

  1. Na árvore de diretórios do projeto ou na tela do workflow, clique em com o botão direito no nó de destino.

  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 precisar reestruturar um processo de negócios e migrar um nó do workflow atual para outro workflow.

  1. Na árvore de diretórios do projeto ou na tela do workflow, clique em com o botão direito no nó de destino.

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

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

     Você também pode selecione 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 em com o botão direito no workflow de destino e selecione Cloning.

A clonagem copia quase todas as configurações, o que pode introduzir riscos. Antes de implantar o workflow clonado, verifique o seguinte (verificação de "isolamento de ambiente"):

1. Tabelas de saída e fontes de dados de destino: O código do workflow clonado grava nas mesmas tabelas de destino que o workflow original. Modifique os nomes das tabelas de destino no código (por exemplo, altere ods_user_table para dev_ods_user_table) ou modifique 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ência 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 causar confusão no pipeline de dados ou execução simulada 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, você também pode clonar nós dentro de um workflow, mas a cópia de nós entre workflows não é suportada.

Gerenciamento de versões

O gerenciamento de versões registra automaticamente cada alteração no workflow, suporta a visualize e comparação de versões históricas e permite a restauração para qualquer estado histórico quando necessário.

No lado direito da tela do workflow, o painel Version mostra dois tipos de registros:

• Registro de desenvolvimento: Gerado cada vez que você clique em Save na tela. Este snapshot previne perda acidental de código durante o desenvolvimento e não afeta tarefas em execução em produção.

• Registro de implantação: Gerado após um workflow ser implantado no ambiente de produção. Esta é a versão que o agendador de produção executa. Quando tarefas de produção encontrarem problemas, foque nos registros de implantação para restauração.

Casos de uso típicos

• Restauração rápida em caso de falha: Quando uma tarefa de produção falha devido a alterações de código, use Restore para reverter o workflow para a ú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 a lógica foi alterada e por quem, use os recursos de lista de versões e Diff para rastrear cada mudança de código.

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

Considerações importantes

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

• Nova implantação é necessária após a restauração: Restore apenas restaura o código para o estado de desenvolvimento. Você deve implantá-lo manualmente para que a restauração tenha efeito em 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. Neste ponto, os nós no 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: Workflows no ambiente de produção são agendados periodicamente com base nas configurações de agendamento. Acesse o Operation and Maintenance Center para visualize o status de agendamento dos workflows agendados e realizar 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, toda a instância do workflow é tipicamente marcada como falha.

• Congelamento/Pausa: Se um nó dentro do workflow for manualmente congelado ou pausado, e esse nó for upstream para nós subsequentes, o pipeline é interrompido e todo o workflow também é marcado como falha.

• Nó de junção: Se o workflow usar um nó de junção, mesmo que um nó em uma ramificação upstream falhe, todo o workflow pode retornar "sucesso" desde que a própria lógica do nó de junção determine o sucesso. Portanto, projete cuidadosamente as verificações upstream para nós de junção para evitar que tarefas sejam executadas com erros não detectados.

Cenários especiais:

• Quando você congela uma instância de backfill de dados de uma tarefa de workflow, a instância do workflow é definida com status de sucesso.

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