Erros e execução condicional
APLICA-SE A:
Azure Data Factory Azure Synapse Analytics
Dica
Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange desde movimentação de dados até ciência de dados, análise em tempo real, business intelligence e relatórios. Saiba como iniciar uma avaliação gratuita!
Caminhos condicionais
A orquestração do pipeline do Synapse e do Azure Data Factory possibilita uma lógica condicional e permite que o usuário sigam caminhos diferentes com base nos resultados de uma atividade anterior. O uso de caminhos diferentes permite que os usuários criem pipelines robustos e incorporem o tratamento de erro na lógica ETL/ELT. No total, permitimos quatro caminhos condicionais:
| Nome | Explicação |
|---|---|
| Após o êxito | (Senha Padrão) Execute este caminho se a atividade atual tiver êxito |
| Após a falha | Execute este caminho se a atividade atual falhou |
| Após a conclusão | Execute esse caminho após a conclusão da atividade atual, independentemente de ter êxito ou não |
| Após ser ignorado | Execute esse caminho se a atividade em si não tiver sido executada |
Adicione vários branches seguindo uma atividade, com uma exceção: o caminho após a conclusão não pode coexistir com o caminho Após o êxito ou após a falha. Para cada execução de pipeline, no máximo um caminho é ativado, com base no resultado da execução da atividade.
Tratamento de erros
Mecanismo comum de tratamento de erro
Bloco Try Catch
Nessa abordagem, o cliente define a lógica de negócios e define apenas o caminho Após a falha para capturar qualquer erro da atividade anterior. Essa abordagem faz o pipeline ser bem-sucedido se o caminho Após a falha é bem-sucedido.
Bloco Do If Else
Nessa abordagem, o cliente define a lógica de negócios e os caminhos Após a falha e Após o êxito. Essa abordagem faz o pipeline falhar mesmo se o caminho Após a falha é bem-sucedido.
Bloco Do If Skip Else
Nessa abordagem, o cliente define a lógica de negócios e o caminho Após a falha e Após o êxito, com uma atividade Após ser ignorado fictícia anexada. Essa abordagem faz o pipeline ser bem-sucedido se o caminho Após a falha é bem-sucedido.
Tabela de resumo
| Abordagem | Define | Quando a atividade é bem-sucedida, o pipeline geral mostra | Quando a atividade falha, o pipeline geral mostra |
|---|---|---|---|
| Try-Catch | Somente o caminho Após a falha | Êxito | Êxito |
| Do-If-Else | Caminho Após a falha + caminho Após o êxito | Sucesso | Falha |
| Do-If-Skip-Else | Caminho Após a falha + caminho Após o êxito (com um Após ser ignorado fictício no fim) | Êxito | Êxito |
Como a falha do pipeline é determinada
Mecanismos diferentes de tratamento de erro produzem um status diferente para o pipeline: enquanto alguns pipelines falham, outros são bem-sucedidos. Determinamos o êxito e as falhas do pipeline da seguinte forma:
- Avaliar o resultado de todas as atividades folha. Se uma atividade folha tiver sido ignorada, vamos avaliar a atividade pai dela.
- O resultado do pipeline será bem-sucedido se e somente se todos os nós avaliados forem bem-sucedidos
Supondo que as atividades Após a falha e Após ser ignorado fictícia sejam bem-sucedidas,
Na abordagem Try-Catch,
- Quando a atividade anterior é bem-sucedida: o nó Após a falha é ignorado e o nó pai dele é bem-sucedido; o pipeline geral é bem-sucedido
- Quando a atividade anterior falha: o nó Após a falha é acionado; o pipeline geral é bem-sucedido
Na abordagem Do-If-Else,
- Quando a atividade anterior é bem-sucedida: o nó Após o êxito e o nó Após a falha são ignorados (e o nó pai dele é bem-sucedido); o pipeline geral é bem-sucedido
- Quando a atividade anterior falha: o nó Após o êxito é ignorado e o nó pai dele falha; o pipeline geral falha
Na abordagem Do-If-Skip-Else,
- Quando a atividade anterior é bem-sucedida: o nó Após ser ignorado fictício e o nó pai dele Após o êxito são bem-sucedidos; a outra atividade de nó, Após a falha, é ignorada e o nó pai dela é bem-sucedido; o pipeline geral é bem-sucedido
- Quando a atividade anterior falha: o nó Após a falha é bem-sucedido e o nó Após ser ignorado fictício é bem-sucedido; o pipeline geral é bem-sucedido
Execução condicional
À medida que desenvolvemos pipelines mais complicados e resilientes, às vezes é necessário introduzir execuções condicionais à nossa lógica: executar uma determinada atividade somente se determinadas condições forem atendidas. Os casos de uso são suficientes, por exemplo:
- executar uma atividade de acompanhamento, como enviar uma notificação por email, se os trabalhos de cópia anteriores tiverem êxito
- executar um trabalho de tratamento de erros, se alguma das atividades anteriores falhou
- prossiga para a próxima etapa se a atividade em si ou sua atividade de tratamento de erros correspondente tiver êxito
- etc.
Aqui explicamos algumas lógicas comuns e como implementá-las no ADF.
Atividade única
Aqui estão alguns padrões comuns após uma única atividade. Podemos usar esses padrões como blocos de construção para construir fluxos de trabalho complicados.
Tratamento de erros
O padrão é a lógica de condição mais comum no ADF. Uma atividade de tratamento de erro é definida para o caminho "Após falha" e será invocada se a atividade principal falhar. Ele deve ser incorporado como prática recomendada para todas as etapas críticas que precisam de alternativas de fall-back ou registro em log.
Melhores etapas de esforço
Determinadas etapas, como o registro em log informativo, são menos críticas e suas falhas não devem bloquear todo o pipeline. Nesses casos, devemos adotar as melhores estratégias de esforço: adicionar as próximas etapas ao caminho "Após a conclusão", para desbloquear o fluxo de trabalho.
And
Os primeiros e mais comuns cenários são "e" condicionais: continue o pipeline se e somente se as atividades anteriores tiverem êxito. Por exemplo, você pode ter várias atividades de cópia que precisam ter êxito primeiro antes de passar para o próximo estágio de processamento de dados. No ADF, o comportamento pode ser obtido facilmente: declarar várias dependências para a próxima etapa. Graficamente, isso significa várias linhas apontando para a próxima atividade. Você pode escolher o caminho "Após o Sucesso" para garantir que a dependência tenha sido bem-sucedida ou o caminho "Após a conclusão" para permitir a melhor execução do esforço.
Aqui, a atividade de espera de acompanhamento só será executada quando ambas as atividades da Web tiverem sido bem-sucedidas.
E aqui, a atividade de espera de acompanhamento é executada quando ActivitySucceeded for aprovado e ActivityFailed for concluído. Observação, com o caminho "Após o sucesso" ActivitySucceeded tem que ser bem-sucedido, enquanto ActivityFailed no caminho "Após a conclusão" é executado com o melhor esforço, ou seja, pode falhar.
Ou
Os segundos cenários comuns são "ou" condicionais: execute uma atividade se qualquer uma das dependências tiver êxito ou falhar. Aqui, precisamos usar caminhos "Após a conclusão", se atividade if Condition elinguagem de expressão.
Antes de nos aprofundarmos no código, precisamos entender mais uma coisa. Depois que uma atividade for executada e concluída, você poderá referenciar seu status com @activity("ActivityName"). Status. É "Êxito" ou "Falha". Usamos essa propriedade para criar uma lógica ou condicional.
Etapa de registro em log de tratamento de erros compartilhados
Em alguns casos, talvez você queira invocar uma etapa de registro em log ou tratamento de erro compartilhado, se alguma das atividades anteriores falhou. Você pode criar seu pipeline da seguinte maneira:
- executar várias atividades em paralelo
- adicionar uma condição if para conter as etapas de tratamento de erro, no branch True
- conectar atividades à atividade de condição usando o caminho "Após a conclusão"
- expressão lógica para leituras de atividade de condição
@or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded').Status, 'Failed'))
- Anotação: você precisa concatenar ou se tiver mais de duas atividades de dependência, por exemplo,
@or(or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded1').Status, 'Failed')),equals(activity('ActivitySucceeded1').Status, 'Failed'))
Luz verde se alguma atividade tiver sido bem-sucedida
Quando todas as atividades forem de melhor esforço, convém prosseguir para a próxima etapa se alguma das atividades anteriores tiver sido bem-sucedida. Você pode criar seu pipeline da seguinte maneira:
- executar várias atividades em paralelo
- adicionar uma condição if para conter as próximas etapas, no branch True
- conectar atividades à atividade de condição usando o caminho "Após a conclusão"
- expressão lógica para leituras de atividade de condição
@or(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
- Observação: o grafo será exatamente semelhante ao cenário anterior. A única diferença é a linguagem de expressão usada
Cenários complexos
Todas as atividades precisam ter êxito para continuar
O padrão é uma combinação de dois: tratamento condicional e + erro. O pipeline prossegue para as próximas etapas se todas as atividades em andamento forem bem-sucedidas ou então executar uma etapa de registro em log de erros compartilhado. Você pode criar o pipeline da seguinte maneira:
- executar várias atividades em paralelo
- adicionar uma condição if. Adicione as próximas etapas no branch True e adicione o código de tratamento de erro no branch False
- conectar atividades à atividade de condição usando o caminho "Após a conclusão"
- expressão lógica para leituras de atividade de condição
@and(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
Padrões comuns
Try-Catch-Proceed
O padrão é equivalente a tentar capturar bloco na codificação. Uma atividade pode falhar em um pipeline. Quando falha, o cliente precisa executar um trabalho de tratamento de erro para lidar com isso. No entanto, a falha de atividade única não deve bloquear as próximas atividades no pipeline. Por exemplo, tento executar um trabalho de cópia, movendo arquivos para o armazenamento. No entanto, pode falhar no meio do caminho. E, nesse caso, quero excluir os arquivos parcialmente copiados e não confiáveis da conta de armazenamento (minha etapa de tratamento de erro). Mas estou pronto para prosseguir com outras atividades depois.
Para configurar o padrão:
- Adicionar primeira atividade
- Adicionar tratamento de erro ao caminho UponFailure
- Adicionar segunda atividade, mas não se conectar à primeira atividade
- Conectar os caminhos UponFailure e UponSkip da atividade de tratamento de erros à segunda atividade
Observação
Cada caminho (UponSuccess, UponFailure e UponSkip) pode apontar para qualquer atividade. Vários caminhos podem apontar para a mesma atividade. Por exemplo, UponSuccess e UponSkip podem apontar para uma atividade, enquanto UponFailure aponta para outra.
O trabalho de Tratamento de Erro é executado somente quando a Primeira Atividade falha. A Próxima Atividade será executada independentemente de a Primeira Atividade ter êxito ou não.
Tratamento de erro genérico
Normalmente, temos várias atividades sendo executadas sequencialmente no pipeline. Se houver falha, preciso executar um trabalho de tratamento de erros para limpar o estado e/ou registrar o erro no log. Por exemplo, tenho atividades de cópia sequenciais no pipeline. Se algum deles falhar, preciso executar um trabalho de script para registrar a falha do pipeline.
Para configurar o padrão:
- Crie um pipeline de processamento de dados sequencial
- Adicionar etapa de tratamento de erro genérico ao final do pipeline
- Conecte os caminhos UponFailure e UponSkip da última atividade à atividade de tratamento de erros
A última etapa, Tratamento de Erro Genérico, só será executada se alguma das atividades anteriores falhar. Não será executada se todos funcionarem.
Você pode adicionar várias atividades para tratamento de erros.
