Erros e execução condicional

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Gorjeta

Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange tudo, desde a movimentação de dados até ciência de dados, análises em tempo real, business intelligence e relatórios. Saiba como iniciar uma nova avaliação gratuitamente!

Caminhos condicionais

A orquestração do Azure Data Factory e do Synapse Pipeline permite a lógica condicional e permite que o usuário siga um caminho diferente com base nos resultados de uma atividade anterior. O uso de caminhos diferentes permite que os usuários criem pipelines robustos e incorpora o tratamento de erros na lógica ETL/ELT. No total, permitimos quatro caminhos condicionais,

Nome	Explicação
Após Êxito	(Passe padrão) Execute este caminho se a atividade em curso tiver sucesso
Em Caso de Falha	Execute este caminho se a atividade em curso falhar
Após a Conclusão	Execute este caminho após a conclusão da atividade atual, independentemente de ter sido bem-sucedida ou não
Após o Skip	Execute esse caminho se a atividade em si não tiver sido executada

Você pode adicionar várias ramificações após uma atividade, com uma exceção: o caminho Após a conclusão não pode coexistir com o caminho Após o sucesso 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.

Processamento de Erros

Mecanismo comum de tratamento de erros

Experimente o bloco Catch

Nessa abordagem, o cliente define a lógica de negócios e apenas especifica o caminho Em Caso de Falha para detetar qualquer erro da atividade anterior. Esta abordagem executa o pipeline com êxito, se o caminho Upon Failure for bem-sucedido.

Bloquear Do If Else

Nesta abordagem, o cliente define a lógica de negócios e também define os caminhos de "Em Caso de Falha" e "Em Caso de Sucesso". Esta abordagem faz com que a pipeline falhe, mesmo que o percurso Upon Failure seja bem-sucedido.

Bloco Fazer Se Omitir Senão

Nessa abordagem, o cliente define a lógica de negócios, assim como os caminhos Em Caso de Falha e Em Caso de Sucesso, com uma atividade fictícia Em Caso de Omissão anexada. Esta abordagem faz com que o pipeline funcione com sucesso, se o caminho Upon Failure tiver êxito.

Quadro-resumo

Abordagem	Define	Quando a atividade é bem-sucedida, o pipeline geral é exibido	Quando a atividade falha, o fluxo de trabalho geral aparece
Try-Catch	Somente em caso de falha	Com êxito	Com êxito
Do-If-Else	Caminho do Fracasso + Caminho do Sucesso	Com êxito	Falha
Do-If-Skip-Else	Caminho do Fracasso + Caminho do Sucesso (com um Dummy Upon Skip no final)	Com êxito	Com êxito

Como as falhas do pipeline são determinadas

Diferentes mecanismos de tratamento de erros levam a um status diferente para o pipeline: enquanto alguns pipelines falham, outros são bem-sucedidos. Determinamos o sucesso e as falhas do pipeline da seguinte forma:

• Avalie o desfecho de todas as atividades relacionadas a folhas. Se uma atividade folha foi ignorada, avaliamos a sua atividade principal.
• O resultado do pipeline é bem-sucedido se e somente se todos os nós avaliados forem bem-sucedidos

Assumindo que a atividade Upon Failure e a atividade Dummy Upon Failure tiverem sucesso,

• Na abordagem de Try-Catch,

  • Quando a atividade anterior é bem-sucedida: o nó Upon Failure é ignorado e o nó pai tem sucesso; todo o pipeline é bem-sucedido.
  • Quando a atividade anterior falha: o nó Upon Failure é acionado; o pipeline geral é bem-sucedido

• Na abordagem Do-If-Else ,

  • Quando a atividade anterior é bem-sucedida: o nó Upon Success também é bem-sucedido, e o nó Upon Failure é ignorado (e o seu nó pai é bem-sucedido); no geral, o pipeline é bem-sucedido.
  • Quando a atividade anterior falha: o nó Upon Success é ignorado, o nó pai falha e toda a pipeline falha.

• Na abordagem Do-If-Skip-Else,

  • Quando a atividade anterior é bem-sucedida: o nó Dummy Upon Skip é ignorado e seu nó pai, Upon Success, é bem-sucedido; a atividade do outro nó, Upon Failure, é ignorada e seu nó pai também é bem-sucedido; o pipeline global é bem-sucedido.
  • Quando a atividade anterior falha: o nó Upon Failure é bem-sucedido e Dummy Upon Skip é bem-sucedido; no geral, o pipeline é bem-sucedido.

Execução condicional

À medida que desenvolvemos pipelines mais complicados e resilientes, às vezes é necessário introduzir execuções condicionais na nossa lógica: executar uma determinada atividade somente se certas condições forem atendidas. Os casos de uso são muitos, por exemplo:

• executar uma atividade de acompanhamento, como enviar uma notificação por e-mail, se trabalhos de cópia anteriores forem bem-sucedidos
• Executar um trabalho de tratamento de erros, se alguma das atividades anteriores falhar
• Prossiga para a próxima etapa se a atividade em si ou sua atividade de tratamento de erros correspondente for bem-sucedida
• 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.

Processamento de erros

O padrão é a lógica de condição mais comum no ADF. Uma atividade de tratamento de erros é definida para o caminho "Upon Failure" e será invocada se a atividade principal falhar. Deve ser incorporado como prática recomendada para todas as etapas de missão crítica que necessitem de alternativas alternativas de recurso ou registro.

Melhores passos de esforço

Certas etapas, como o registo informativo, são menos críticas, e as suas falhas não devem bloquear a totalidade do pipeline. Nesses casos, devemos adotar as melhores estratégias de esforço: adicionar os próximos passos ao caminho "Após a conclusão", para desbloquear o fluxo de trabalho.

And

Os primeiros e mais comuns cenários são condicionais “e”: continuar o pipeline se e somente se as atividades anteriores forem bem-sucedidas. Por exemplo, você pode ter várias atividades de cópia que precisam ser bem-sucedidas primeiro antes de passar para o próximo estágio de processamento de dados. No ADF, o comportamento pode ser alcançado 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 web forem bem-sucedidas.

E aqui, a atividade de espera de acompanhamento é executada quando ActivitySucceeded passa e ActivityFailed é concluída. Note que com o caminho "Upon Success" ActivitySucceeded tem de ser bem-sucedido, enquanto ActivityFailed no caminho "Upon Completion" é executado com o melhor esforço, isto é, pode falhar.

Ou

Um segundo cenário comum é o condicional "ou": execute uma atividade se qualquer uma das dependências for bem-sucedida ou falhar. Aqui precisamos usar os caminhos "Após a conclusão", atividade "If Condition" e a linguagem de expressões.

Antes de nos aprofundarmos no código, precisamos entender mais uma coisa. Depois que uma atividade for executada e concluída, você poderá fazer referência ao seu status com @activity('ActivityName'). Estado. É "Sucesso"_ ou "Falhou". Usamos esta propriedade para construir estruturas condicionais ou lógicas.

Etapa de registro de tratamento de erros compartilhados

Em alguns casos, convém invocar uma etapa de tratamento de erros ou registro em log compartilhada, se alguma das atividades anteriores falhar. Pode construir o seu pipeline desta forma:

• executar várias atividades em paralelo
• adicionar uma condição if para conter as etapas de tratamento de erros, na ramificação 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'))

• Nota: você precisa concatenar ou, se tiver mais de duas atividades com dependências, por exemplo,

@or(or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded1').Status, 'Failed')),equals(activity('ActivitySucceeded1').Status, 'Failed'))

Luz verde se alguma atividade for bem-sucedida

Quando todas as suas atividades forem o melhor esforço, você pode querer prosseguir para a próxima etapa se alguma das atividades anteriores tiver sido bem-sucedida. Você pode construir o seu pipeline assim:

• executar várias atividades em paralelo
• adicionar uma condição if para conter as próximas etapas, na ramificação 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'))

• Nota: o gráfico se parece exatamente com o cenário anterior. A única diferença é a linguagem de expressão utilizada

Cenários complexos

Todas as atividades precisam ser bem-sucedidas para prosseguir

O padrão é uma combinação de dois: condicional e tratamento de erros. O pipeline prossegue para as próximas etapas se todas as atividades anteriores forem bem-sucedidas, ou então executa uma etapa de registo de erros partilhada. Você pode construir o pipeline assim:

• executar várias atividades em paralelo
• Adicione uma condição if. Adicione as próximas etapas na ramificação True e adicione o código de tratamento de erros na ramificação 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

Tenta-Captura-Prossegue (Try-Catch-Proceed)

O padrão é equivalente a tentar catch block na codificação. Uma atividade pode falhar num pipeline. Quando falha, o cliente precisa executar um trabalho de tratamento de erros para lidar com isso. No entanto, a falha de uma única atividade não deve impedir as próximas atividades no pipeline. Por exemplo, tento executar um trabalho de cópia, movendo arquivos para o armazenamento. No entanto, pode falhar a 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 erros). Mas não tenho problema em prosseguir com outras atividades depois.

Para configurar o padrão:

• Adicionar primeira atividade
• Adicionar tratamento de erros ao caminho UponFailure
• Adicionar segunda atividade, mas não conectar à primeira atividade
• Conecte os caminhos UponFailure e UponSkip da atividade de tratamento de erros à segunda atividade

Nota

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 uma diferente.

O trabalho de Tratamento de Erros é executado somente quando a Primeira Atividade falha. A próxima atividade será executada independentemente de a primeira atividade ser bem-sucedida ou não.

Tratamento genérico de erros

Comumente, temos várias atividades em execução sequencialmente no pipeline. Se algum falhar, preciso executar um trabalho de tratamento de erros para limpar o estado e/ou registrar o erro. Por exemplo, tenho atividades de cópia sequencial no fluxo de trabalho. 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 genérica de tratamento de erros ao final do pipeline
• Conecte os caminhos UponFailure e UponSkip da última atividade à atividade de tratamento de erros

A última etapa, Tratamento Genérico de Erros, só será executada se alguma das atividades anteriores falhar. Não funcionará se todos tiverem sucesso.

Você pode adicionar várias atividades para tratamento de erros.

Conteúdos relacionados

Métricas e alertas do Data Factory

Monitorizar Visualmente