Jonathan Carlos Carletti; Gabriel Rangel

DOI: 10.22167/2675-6528-202600983

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

A crescente adoção de arquiteturas “multi-cloud” por organizações corporativas introduz desafios significativos relacionados à consistência de dados e orquestração de processos entre provedores heterogêneos. Para endereçar o problema da fragilidade dos pipelines de integração em arquiteturas multi-cloud, caracterizada pela ausência de resiliência nativa, observabilidade limitada e tratamento inadequado de erros, realizou-se uma análise comparativa entre Azure Data Factory e Apache Airflow. O objetivo foi avaliar comparativamente as ferramentas quanto à resiliência, observabilidade e tratamento de erros na integração de dados entre AWS S3 e Azure Blob Storage. Através de uma Prova de Conceito experimental, conduziram-se testes de resiliência, observabilidade e tratamento de erros utilizando datasets sintéticos gerados com a biblioteca Python Faker, incluindo anomalias intencionais para simulação de cenários reais de falha. Os resultados demonstraram que o Azure Data Factory ofereceu uma interface visual intuitiva, adequada para usuários não técnicos, mas exigiu configuração manual de políticas de “retry”. Em contraste, o Apache Airflow implementou “retry” automático nativo através de DAGs programáticos, proporcionando maior resiliência por padrão. A análise revelou “trade-offs” fundamentais entre facilidade de uso e flexibilidade operacional, evidenciando que a escolha da ferramenta deve considerar o perfil técnico da equipe, os requisitos de resiliência e a complexidade dos pipelines de dados. Este estudo contribuiu para a tomada de decisão arquitetural em projetos de integração multi-cloud empresariais.

Palavras-chave: Apache Airflow; Azure Data Factory; Integração de Dados; Orquestração; Resiliência.

1. Introdução

A transformação digital impulsionou a migração de infraestruturas tecnológicas para ambientes de computação em nuvem, buscando escalabilidade e otimização de custos (Armbrust et al., 2010). A estratégia “multi-cloud”, utilizando múltiplos provedores como Amazon Web Services (AWS), Microsoft Azure e Google Cloud Platform, emergiu para mitigar riscos de “vendor lock-in”, otimizar custos e garantir alta disponibilidade (Synergy Research Group, 2025). O mercado de infraestrutura de nuvem cresce exponencialmente (Gartner, 2025), mas essa complexidade introduz desafios técnicos significativos na orquestração e consistência de dados entre ambientes heterogêneos.

A implementação de arquiteturas multi-cloud acarreta complexidades na gestão de dados distribuídos. A consistência de dados, definida como o grau de uniformidade e precisão das informações replicadas entre múltiplos sistemas, torna-se um desafio crítico (Campêlo et al., 2020). Provedores de nuvem frequentemente não compartilham protocolos nativos, e suas APIs públicas podem oferecer diferentes garantias de atomicidade, dificultando a sincronização e a integridade dos dados (Vogels, 2009). A ausência de um padrão unificado pode levar a inconsistências e atrasos, exigindo soluções robustas para garantir dados consistentes e confiáveis no ecossistema multi-cloud (Kozina et al., 2024; Ferreira et al., 2024).

A orquestração de *workflows* de dados é fundamental para a viabilidade operacional de estratégias multi-cloud, coordenando o agendamento e monitoramento de processos de extração, transformação e carregamento (ETL) entre sistemas distribuídos (de Bas et al., 2019). Duas abordagens predominam. Ferramentas gerenciadas e de baixo código (low-code), como o Azure Data Factory da Microsoft (Microsoft, 2025; Patel, 2025), oferecem interfaces visuais intuitivas para construção de *pipelines*. Em contraste, plataformas *open-source* baseadas em “Configuration as Code”, como o Apache Airflow (Apache Software Foundation, 2025; Narayanan, 2024), permitem a definição programática de *workflows* como “Directed Acyclic Graphs” (DAGs), oferecendo alta flexibilidade e controle granular.

A escolha entre essas abordagens exige que as organizações ponderem requisitos técnicos cruciais: resiliência, observabilidade e tratamento de erros, em conjunto com considerações pragmáticas como curva de aprendizado, custos operacionais e adequação ao perfil técnico das equipes (Troyer, 2023). Resiliência refere-se à capacidade de um sistema de orquestração de dados de se recuperar de falhas transientes e continuar a operação sem intervenção manual. Observabilidade diz respeito à capacidade de entender o estado interno de um *pipeline* a partir de seus logs e métricas. Tratamento de erros envolve a forma como a ferramenta lida com exceções e falhas, incluindo mecanismos de *retry* e alertas, essenciais para manter a integridade dos dados (Gilbert & Lynch, 2002).

A literatura acadêmica tem se concentrado em análises teóricas de arquiteturas multi-cloud ou em estudos de caso isolados, carecendo de comparações empíricas diretas entre abordagens de orquestração “low-code” proprietárias e “code-first” *open-source* em cenários reais de integração inter-cloud (Yasmin et al., 2024). Essa lacuna é significativa, pois a escolha da ferramenta de orquestração impacta diretamente a manutenibilidade, os custos e a confiabilidade dos sistemas de dados empresariais. A relevância deste estudo manifesta-se em três dimensões: acadêmica, ao preencher uma lacuna com análise comparativa empírica; profissional, ao fornecer subsídios para arquitetos e engenheiros em decisões tecnológicas; e organizacional, ao auxiliar na prevenção de *pipelines* frágeis e incidentes operacionais com impactos financeiros e reputacionais.

Diante deste panorama, identifica-se como problema central a fragilidade dos *pipelines* de integração em arquiteturas multi-cloud, caracterizada pela ausência de resiliência nativa, observabilidade limitada e tratamento inadequado de erros, resultando em inconsistências de dados e elevada dependência de intervenção manual em ambientes de produção. A necessidade de endereçar essa fragilidade é premente, visto que a integridade dos dados é crucial para a operação empresarial moderna. Assim, o presente trabalho justifica-se pela busca de uma compreensão aprofundada das capacidades das ferramentas de orquestração de dados para mitigar esses desafios. O objetivo deste estudo é avaliar comparativamente o Azure Data Factory e o Apache Airflow quanto à resiliência, observabilidade e tratamento de erros na integração de dados entre AWS S3 e Azure Blob Storage.

2. Material e Métodos

Esta pesquisa caracterizou-se como experimental aplicada, com abordagem quantitativa e qualitativa, fundamentada na implementação de uma Prova de Conceito para comparação empírica de ferramentas de orquestração “multi-cloud”. A metodologia adotada seguiu o paradigma de engenharia experimental, conforme proposto por Wohlin et al. (2012), envolvendo a definição de objetivos mensuráveis, a implementação controlada de artefatos tecnológicos, a execução de experimentos reproduzíveis e a análise comparativa de resultados. O método de Prova de Conceito foi selecionado por permitir a validação prática da viabilidade técnica e do comportamento operacional de tecnologias em cenários aproximados de uso real, sem demandar investimentos de produção completa.

O ambiente experimental foi estruturado utilizando três provedores de infraestrutura cloud e local, compondo uma arquitetura “multi-cloud” representativa de cenários corporativos reais. Para a prova de conceito comparativa, definiu-se uma arquitetura de referência que priorizou baixo custo e alta reprodutibilidade. Esta arquitetura experimental foi organizada para refletir um cenário real de integração entre múltiplos ambientes, incluindo recursos da Amazon Web Services para armazenamento de origem, Microsoft Azure para destino e um ambiente local Docker para execução de Apache Airflow. Os componentes principais desta arquitetura experimental são detalhados na Tabela 1.

Tabela 1. Arquitetura do Ambiente Experimental

Ambiente	Serviço / Componente	Identificação	Finalidade
AWS (Origem)	Bucket S3	tcc-jonathan-origem-dados	Armazenamento do arquivo JSON de origem
AWS (Origem)	Região	US East N. Virginia	Localização geográfica do serviço
AWS (Origem)	Criptografia	SSE-S3	Proteção dos dados armazenados
AWS (Origem)	Credenciais	Access Keys (IAM)	Autenticação e controle de acesso
Azure (Destino)	Storage Account	tccjonathandestino	Armazenamento dos dados processados
Azure (Destino)	Container	tcc-destino-dados	Destino do arquivo copiado
Azure (Orquestração)	Azure Data Factory	tcc-adf-scheduler	Orquestração e execução do “pipeline”
Azure (Orquestração)	Linked Services	AWS S3 / Azure Blob Storage	Integração entre provedores
Ambiente Local	Orquestrador	Apache Airflow 2.10.4	Orquestração alternativa baseada em código
Ambiente Local	Contêineres	Docker Compose	Provisionamento do ambiente
Ambiente Local	Banco de dados	PostgreSQL	Metadados do Airflow
Ambiente Local	Mensageria	Redis	Gerenciamento de filas
Ambiente Local	Interface Web	localhost:8080	Monitoramento das execuções
Ambiente Local	Usuário padrão	airflow/airflow	Acesso administrativo
AWS (Origem)	Bucket S3	tcc-jonathan-origem-dados	Armazenamento do arquivo JSON de origem

Fonte: Elaborado pelo autor (2026)

A unidade de análise deste estudo consistiu nas ferramentas de orquestração de dados Azure Data Factory e Apache Airflow, selecionadas por representarem abordagens distintas e predominantes no mercado de integração multi-cloud. O Azure Data Factory foi escolhido como exemplo de ferramenta gerenciada e de baixo código (low-code), oferecida por um provedor de nuvem. Em contraste, o Apache Airflow representou uma plataforma de código aberto (open-source) baseada em “Configuration as Code”, executada em ambiente containerizado Docker, proporcionando flexibilidade e controle granular.

Para viabilizar os testes de resiliência e consistência sem comprometer dados reais ou incorrer em custos elevados de infraestrutura, optou-se pela geração sintética de datasets. Utilizou-se a biblioteca Python Faker, versão 28.1.0, para a criação automatizada de dados fictícios, porém realistas, mantendo a estrutura e características esperadas em cenários de integração. O script de geração produziu um dataset de 1.000 transações de vendas fictícias, com um esquema JSON contendo campos como id, cliente, produto, valor, data_transacao e status.

O dataset sintético foi enriquecido com a inserção controlada de anomalias em aproximadamente cinco por cento dos registros, permitindo a simulação de cenários reais de inconsistência de dados que demandam tratamento especial pelos sistemas de orquestração. As anomalias incluíram identificadores nulos, datas futuras inverossímeis e valores negativos, replicando padrões de dados sujos frequentemente encontrados em sistemas legados corporativos. Esta abordagem garantiu a representatividade dos dados para os testes de tratamento de erros e resiliência.

A infraestrutura AWS S3 foi provisionada através do console web AWS em 22 de janeiro de 2026, utilizando um “bucket” denominado tcc-jonathan-origem-dados com acesso privado e criptografia “server-side” padrão. Credenciais de acesso foram geradas via IAM com permissões restritas a operações “GetObject” e “ListBucket”, seguindo o princípio de least privilege. No ambiente Azure, um Resource Group rg-tcc-jonathan foi criado para isolamento lógico de recursos, contendo uma Storage Account tccjonathandestino com um “container” tcc-destino-dados e uma instância de Azure Data Factory tcc-adf-scheduler.

No Azure Data Factory Studio, acessado por meio do portal Azure, foram criados dois Linked Services essenciais para estabelecer conectividade com os datastores externos. Um Linked Service foi direcionado ao “bucket” S3 de origem, autenticado via credenciais IAM, e o outro ao Azure Blob Storage de destino. A validação nativa da conectividade confirmou que ambas as integrações estavam operacionais antes da construção do “pipeline”, assegurando a conectividade adequada para os procedimentos subsequentes.

Após a configuração dos Linked Services, construiu-se um pipeline denominado Pipeline_Copia_S3_para_Azure no canvas visual do ADF. O pipeline continha uma atividade Copy Data configurada com um “dataset” source referenciando o arquivo vendas_1769047075.json no “bucket” S3 e um “dataset” sink apontando para o container Azure Blob. As propriedades de “retry” não foram explicitamente configuradas, mantendo o comportamento padrão da ferramenta para observação da estratégia de tratamento de erros “out-of-the-box”.

O ambiente Apache Airflow foi provisionado localmente via Docker Compose, utilizando a configuração oficial da versão 2.10.4. Esta configuração incluiu os componentes necessários para orquestração distribuída: um banco de metadados PostgreSQL, um gerenciador de filas Redis e executores de tarefas. Esta abordagem garantiu a reprodutibilidade do experimento sem custos de infraestrutura em nuvem, com a interface web acessível em localhost:8080, utilizando credenciais padrão airflow/airflow.

Desenvolveu-se um Directed Acyclic Graph (DAG) em Python, denominado tcc_teste_resiliencia_s3, com o objetivo de simular o mesmo cenário de leitura de arquivo do AWS S3 testado no Azure Data Factory. O DAG continha duas tasks sequenciais: `ler_arquivo_s3`, responsável por autenticar com AWS via biblioteca boto3 e realizar a leitura do objeto S3, e `processar_dados`, uma task “downstream” dependente que processaria o conteúdo do arquivo em caso de sucesso. A task `ler_arquivo_s3` foi configurada com parâmetros `retries` igual a três e `retry_delay` igual a 30 segundos.

A execução da pesquisa envolveu a realização de testes controlados em cenários de sucesso e falha para ambas as ferramentas. Para o Azure Data Factory, uma primeira execução do pipeline foi realizada com o arquivo presente no S3 para validar o cenário de sucesso. Em seguida, o arquivo foi manualmente deletado do S3, e uma segunda execução foi iniciada para observar o comportamento da ferramenta em um cenário de falha. Para o Apache Airflow, o DAG foi executado com a task `ler_arquivo_s3` configurada para lançar propositadamente uma exceção `ValueError`, simulando um erro de arquivo não encontrado ou credencial inválida.

Quatro critérios quantitativos e qualitativos foram estabelecidos para a comparação sistemática das ferramentas: resiliência, tempo de falha, observabilidade e complexidade de configuração. A resiliência foi definida como o número de tentativas automáticas de “retry” executadas sem intervenção manual, medido através da contagem de execuções registradas em logs e interfaces de monitoramento. O tempo de falha correspondeu à duração total desde o início da execução até a declaração final de falha, incluindo intervalos entre retries, medido em segundos através de “timestamps” de início e fim.

A observabilidade foi caracterizada pela qualidade e granularidade das informações de erro disponibilizadas em logs e interfaces, avaliada qualitativamente quanto à presença de “stack traces”, códigos HTTP, mensagens descritivas e contexto de falha. A complexidade de configuração representou o esforço necessário para configurar pipelines e políticas de “retry”, avaliado através da contagem de passos de configuração e linhas de código ou configuração JSON requeridas. Estes critérios foram selecionados por representarem aspectos operacionais críticos em ambientes de produção, onde a resiliência impacta a disponibilidade de dados e o tempo de falha afeta os Acordos de Nível de Serviço (SLAs).

3. Resultados e Discussão

A análise dos resultados obtidos na Prova de Conceito revelou distinções significativas no comportamento e nas capacidades das ferramentas Azure Data Factory (ADF) e Apache Airflow, especialmente no que tange à resiliência, observabilidade, tempo de falha e complexidade de configuração em um cenário de integração de dados multi-cloud. Estes achados fornecem uma base empírica para a tomada de decisão arquitetural, alinhando-se com a necessidade de estudos comparativos diretos entre abordagens “low-code” proprietárias e “code-first” open-source, conforme destacado por Yasmin et al. (2024).

A configuração dos Linked Services no Azure Data Factory Studio, conforme ilustrado na Figura 1 e Figura 2, demonstrou a facilidade de estabelecimento de conectividade com datastores externos. A interface visual intuitiva do ADF, baseada em formulários estruturados, eliminou a necessidade de codificação manual de arquivos JSON de configuração, o que corrobora a sua adequação para usuários com menor proficiência técnica em programação. Este aspecto é particularmente relevante em equipes com perfis mais voltados à análise de negócios ou operações de dados, onde a curva de aprendizado para ferramentas “low-code” é significativamente menor (Patel, 2025). A validação nativa da conectividade, um recurso intrínseco da plataforma, assegurou que as integrações com o AWS S3 de origem e o Azure Blob Storage de destino estavam operacionais antes da construção do pipeline, minimizando potenciais erros de configuração em etapas posteriores.

Figura 1. LinkedService_AWS_S3 configurado no Azure Data Factory

Fonte: Elaborado pelo autor (2026).

Figura 2. LinkedService_Azure_Blob configurado no Azure Data Factory

Fonte: Elaborado pelo autor (2026).

A construção do pipeline denominado Pipeline_Copia_S3_para_Azure no canvas visual do ADF, conforme apresentado na Figura 3, foi realizada em aproximadamente 15 minutos. Este tempo reduzido de desenvolvimento é um indicativo da eficiência que ferramentas “drag-and-drop” podem oferecer para a criação de fluxos de trabalho de integração de dados relativamente simples. A atividade Copy Data, configurada para referenciar o arquivo JSON no bucket S3 de origem e o container Azure Blob de destino, representa um padrão comum em cenários de migração ou replicação de dados entre nuvens. A ausência de configuração explícita das propriedades de “retry” no ADF, mantendo o comportamento padrão da ferramenta, foi uma decisão metodológica crucial para observar a estratégia de tratamento de erros “out-of-the-box”. Este ponto se revelaria um diferencial crítico na comparação com o Apache Airflow.

Figura 3. Pipeline no Canvas do Azure Data Factory

Fonte: Elaborado pelo autor (2026).

A primeira execução do pipeline no Azure Data Factory, validando o cenário de sucesso com o arquivo presente no S3, foi concluída em 18 segundos, conforme registrado nos logs do Azure Data Factory Monitor (Figura 4). Este tempo incluiu a inicialização do Integration Runtime AutoResolve, autenticação com AWS S3, transferência de dados e finalização da escrita de metadados. A eficiência na transferência inter-cloud, mesmo para um dataset de 529KB, é um ponto forte do ADF, que se beneficia da infraestrutura otimizada e da rede global da Microsoft Azure. A integridade do conteúdo foi confirmada pela comparação de hash MD5, um procedimento essencial para garantir a consistência dos dados em ambientes distribuídos, conforme discutido por Campêlo et al. (2020) e Kozina et al. (2024). A rastreabilidade completa da execução, com timestamps precisos e acesso detalhado ao log de cada atividade, conforme evidenciado na Figura 4, é um fator que favorece o diagnóstico rápido em ambientes de produção, impactando positivamente o Mean Time To Resolution (MTTR) de incidentes. A verificação no Azure Portal, que confirmou a presença do arquivo transferido no container de destino (Figura 5), validou o sucesso completo da operação de cópia inter-cloud.

Figura 4. Execução bem-sucedida do pipeline no Azure Data Factory

Fonte: Elaborado pelo autor (2026).

Figura 5. Arquivo vendas_copiadas.json no Azure Blob Storage

Fonte: Elaborado pelo autor (2026).

Em contraste, o cenário de falha no Azure Data Factory, provocado pela deleção manual do arquivo de origem no bucket S3, resultou em uma execução falha em aproximadamente 17 segundos, com o status “FAILED” e o código de erro UserErrorFileNotFound (Figura 6). A mensagem de erro detalhada, incluindo o código HTTP 404 Not Found, o caminho completo do arquivo, o nome do Linked Service e um “stack trace” completo da exceção Java subjacente, demonstrou um alto nível de observabilidade. Esta granularidade é crucial para identificar a causa raiz de problemas rapidamente, o que é um aspecto positivo para a manutenibilidade operacional. No entanto, o aspecto mais crítico observado foi a ausência de tentativas automáticas de “retry”. O pipeline foi imediatamente marcado como “FAILED” após a primeira falha, sem aguardar uma possível recuperação transiente.

Figura 6. Execução falhada e detalhes do erro no Azure Data Factory

Fonte: Elaborado pelo autor (2026).

Esta estratégia “fail-fast” padrão do ADF, onde `maxRetries` é igual a zero por configuração padrão, pode ser vantajosa em cenários onde as falhas são estruturais e não transientes, exigindo intervenção humana imediata. Por exemplo, um erro de configuração de credenciais ou um caminho de arquivo incorreto são falhas definitivas que não se resolveriam com retries. No entanto, para falhas transientes, como “throttling” de API, timeouts temporários de rede ou indisponibilidade momentânea de recursos, que são comuns em ambientes multi-cloud (Vogels, 2009; Gilbert & Lynch, 2002), a ausência de retry automático por padrão é uma limitação significativa. Isso implica que, para garantir a resiliência em produção, os usuários do ADF devem configurar explicitamente as políticas de retry, o que demanda conhecimento técnico específico e pode ser um ponto de falha se negligenciado. A necessidade de configuração manual para resiliência contrasta com a expectativa de que ferramentas gerenciadas ofereçam um comportamento mais robusto por padrão, especialmente em um contexto de integração de dados onde a consistência e a disponibilidade são primordiais (Ferreira et al., 2024).

Passando para o Apache Airflow, o ambiente foi provisionado localmente via Docker Compose, utilizando a configuração oficial da versão 2.10.4, conforme ilustrado na Figura 7. Esta abordagem garantiu a reprodutibilidade do experimento sem custos de infraestrutura em nuvem, um benefício inerente a soluções open-source. A acessibilidade da interface web em localhost:8080 com credenciais padrão facilitou o monitoramento e a interação com os DAGs. A escolha do Airflow para este estudo reflete sua crescente popularidade como plataforma de orquestração “code-first”, especialmente em cenários que demandam alta flexibilidade e controle granular sobre os fluxos de trabalho (de Bas et al., 2019; Narayanan, 2024).

Figura 7. Interface inicial do Apache Airflow

Fonte: Elaborado pelo autor (2026).

O desenvolvimento de um Directed Acyclic Graph (DAG) em Python, denominado tcc_teste_resiliencia_s3, simulou o mesmo cenário de leitura de arquivo do AWS S3. O DAG continha duas tasks sequenciais: `ler_arquivo_s3` e `processar_dados`. A task `ler_arquivo_s3` foi configurada explicitamente com `retries` igual a 3 e `retry_delay` igual a 30 segundos, demonstrando a abordagem “Configuration as Code” do Airflow (Figura 8). Esta configuração explícita no código Python contrasta diretamente com a abordagem visual do ADF e destaca a flexibilidade e o poder que a programação oferece para definir comportamentos complexos de fluxo de trabalho. A capacidade de versionar, testar e reutilizar código Python para DAGs é uma vantagem significativa para equipes de engenharia de dados que já possuem proficiência na linguagem (Yasmin et al., 2024).

Figura 8. Graph View mostrando as duas tasks do DAG

Fonte: Elaborado pelo autor (2026).

A execução do DAG tcc_teste_resiliencia_s3, com a task `ler_arquivo_s3` configurada para lançar propositadamente uma exceção `ValueError`, simulou um erro de arquivo não encontrado ou credencial inválida. O Scheduler do Airflow executou automaticamente três tentativas, respeitando o intervalo de 30 segundos configurado em `retry_delay`, totalizando 116 segundos até a marcação final como “FAILED”. Este comportamento evidencia a resiliência nativa da ferramenta frente a falhas transientes, sem qualquer intervenção manual. A terceira e última tentativa falhou às 22:31:09, esgotando o “budget” de 3 retries e resultando na marcação final como “FAILED” às 22:31:39. A visualização na interface Grid View (Figura 9) deixou evidente que a task `ler_arquivo_s3` apresentou falha, sinalizada por um indicador visual vermelho, enquanto a task “downstream” `processar_dados` foi automaticamente pulada (“skipped”) devido à dependência não satisfeita, um comportamento esperado em DAGs com dependências encadeadas. Os logs completos de cada tentativa, incluindo “stack traces”, ficaram disponíveis através da interface Grid View, permitindo uma análise detalhada do comportamento de “retry”.

Figura 9. Logs mostrando “stack trace” e tentativas de “retry” no Airflow

Fonte: Elaborado pelo autor (2026).

A duração total do processo de falha no Airflow, incluindo os retries, foi de 1 minuto e 56 segundos, significativamente superior aos 17 segundos do ADF. No entanto, esta duração estendida proporcionou 3 oportunidades de recuperação automática de erros transientes sem intervenção humana. Em cenários de produção com falhas realmente transientes, como “throttling” momentâneo de API ou timeouts de rede recuperáveis, a estratégia de “retry” automático do Airflow pode evitar incidentes operacionais que demandariam intervenção manual em sistemas baseados em ADF sem “retry” configurado. Este “trade-off” fundamental entre a velocidade de falha e as oportunidades de recuperação automática é um diferencial decisório crucial. Cenários com falhas predominantemente definitivas se beneficiam do “fail-fast” do ADF para uma reexecução manual rápida, enquanto cenários com falhas transientes frequentes se beneficiam do “retry” automático do Airflow para redução da intervenção humana e, consequentemente, dos custos operacionais associados.

Tabela 2. Critérios de Avaliação Comparativa

Critério	Azure Data Factory	Apache Airflow
Paradigma	Visual (Drag-and-Drop)	Código (Python)
Curva de Aprendizado	Baixa	Média-Alta
“retry” Automático	Não (padrão)	Sim (padrão)
Tentativas Observadas	1 tentativa	3 tentativas
Intervalo entre Retries	N/A	30 segundos
Tempo até Falha Final	~17 segundos	~1min 56seg
Clareza do Erro	Excelente (“HTTP 404”)	Excelente (Stack Python)
Observabilidade	Boa	Excelente
Versionamento	Git (opcional)	Nativo (arquivos Python)
Custo de Operação	Pago (execuções)	Gratuito (infra própria)
Escalabilidade	Automática (Azure)	Manual (“workers”)
Cenário Ideal	Não-técnicos, “”low-code””	Desenvolvedores, complexo

Fonte: Elaborado pelo autor (2026).

A Tabela 2 sumariza os critérios de avaliação comparativa, destacando as diferenças entre as ferramentas. Em termos de resiliência, o Apache Airflow demonstrou superioridade ao oferecer “retry” automático como comportamento padrão, enquanto o Azure Data Factory exigiu configuração explícita. Esta diferença é crucial para a robustez de pipelines de dados em ambientes multi-cloud, onde a imprevisibilidade da rede e dos serviços pode levar a falhas transientes. A capacidade do Airflow de lidar com essas falhas automaticamente reduz a carga sobre as equipes de operações e melhora a disponibilidade geral dos dados, impactando diretamente os Acordos de Nível de Serviço (SLAs).

Quanto à observabilidade, ambas as ferramentas apresentaram qualidade elevada de logs, com “stack traces” completos e mensagens descritivas. No entanto, o Airflow ofereceu uma diversidade superior de visualizações, incluindo “Grid View”, “Graph View” e “Gantt Chart”, facilitando uma análise multidimensional das execuções. Essa riqueza de visualizações é particularmente útil para depuração de DAGs complexos e para a compreensão do fluxo de trabalho em diferentes granularidades, o que pode acelerar o diagnóstico e a resolução de problemas em ambientes de produção. A capacidade de inspecionar o estado de cada task, suas dependências e os logs de cada tentativa de retry é um diferencial para engenheiros de dados que precisam de controle e visibilidade profundos.

A complexidade de configuração favoreceu o Azure Data Factory para pipelines simples, devido à sua interface “drag-and-drop” que permite a construção rápida através de cliques visuais. Isso se alinha com a proposta de ferramentas “low-code” de democratizar o desenvolvimento e permitir que usuários não-técnicos criem soluções. Em contrapartida, o Apache Airflow demandou conhecimento de Python e dos conceitos de “Directed Acyclic Graph” (DAGs) e Operators. Embora a curva de aprendizado inicial do Airflow seja superior, desenvolvedores experientes em Python podem alcançar produtividade elevada através da expressividade completa da linguagem, reutilização de código e testes automatizados. A abordagem “code-first” do Airflow permite a implementação de lógica de negócios complexa e a integração com sistemas de controle de versão, o que é fundamental para a manutenção e escalabilidade de pipelines em ambientes corporativos (de Bas et al., 2019).

O modelo de custos também se diferencia fundamentalmente. O Azure Data Factory opera em um modelo “serverless”, com cobrança por execução de atividade, resultando em custos variáveis que se ajustam ao volume de uso. Isso pode ser vantajoso para cargas de trabalho intermitentes ou de baixo volume, onde os custos fixos de infraestrutura seriam desproporcionais. Por outro lado, o Apache Airflow, sendo “self-hosted”, incorre em custos fixos de infraestrutura (servidores, contêineres, banco de dados de metadados) independentemente do volume de execuções. Embora o custo inicial de configuração e manutenção possa ser maior, o Airflow pode se tornar mais econômico para cargas de trabalho de alto volume e contínuas, onde os custos variáveis do ADF poderiam escalar rapidamente. A escolha entre os modelos de custo deve considerar o perfil de uso esperado e a capacidade da equipe de gerenciar a infraestrutura.

Em suma, os resultados demonstram que a escolha da ferramenta de orquestração em arquiteturas multi-cloud envolve um “trade-off” entre facilidade de uso e flexibilidade operacional, bem como entre resiliência nativa e controle explícito. O Azure Data Factory é ideal para equipes com menor proficiência em programação e para pipelines de integração mais simples, onde a velocidade de desenvolvimento e a integração nativa com o ecossistema Azure são prioridades. No entanto, exige atenção à configuração explícita de políticas de retry para garantir a resiliência em falhas transientes. O Apache Airflow, por sua vez, é mais adequado para equipes de engenharia de dados com forte conhecimento em Python, que necessitam de alta flexibilidade, controle granular e resiliência nativa para lidar com a complexidade de workflows de dados e falhas transientes. A sua abordagem “code-first” facilita a manutenção, o versionamento e a automação de testes, aspectos cruciais para pipelines de dados complexos e de missão crítica.

Esta pesquisa contribui para o corpo de conhecimento em engenharia de software “multi-cloud” ao fornecer evidências empíricas quantitativas e qualitativas das diferenças comportamentais entre abordagens “low-code” e “code-first” em cenários reais de falha. Complementa a literatura existente, que muitas vezes se concentra em análises teóricas ou estudos de caso isolados, oferecendo um framework experimental reproduzível para comparação de ferramentas de orquestração baseado em critérios objetivos de resiliência, observabilidade e complexidade. As implicações práticas são significativas para arquitetos de soluções e engenheiros de dados que enfrentam decisões críticas de seleção tecnológica, auxiliando na escolha de orquestradores que melhor se alinham ao perfil técnico organizacional, aos requisitos de resiliência e à complexidade dos pipelines de dados em ambientes de transição para “multi-cloud”. A compreensão desses “trade-offs” é vital para evitar “pipelines” frágeis, dados inconsistentes e incidentes operacionais com impactos financeiros e reputacionais significativos.

4. Conclusão

Conclui-se que o objetivo foi atingido, avaliando comparativamente o Azure Data Factory e o Apache Airflow quanto à resiliência, observabilidade e tratamento de erros na integração de dados entre AWS S3 e Azure Blob Storage. A pesquisa demonstrou que o Azure Data Factory oferece uma interface visual intuitiva, ideal para usuários com menor proficiência técnica, mas exige configuração explícita de políticas de “retry” para garantir resiliência. Em contraste, o Apache Airflow, com sua abordagem “code-first”, proporciona resiliência nativa através de “retry” automático e maior flexibilidade, embora demande maior conhecimento em Python e conceitos de orquestração. Os resultados evidenciam um “trade-off” fundamental entre facilidade de uso e controle granular, e entre velocidade de falha e oportunidades de recuperação automática, fornecendo subsídios para decisões arquiteturais em ambientes multi-cloud.

Este estudo, contudo, possui limitações inerentes à sua natureza de Prova de Conceito. A análise foi realizada com um volume de dados específico de 529KB e focou em cenários de falha como arquivo não encontrado ou erro simulado, não abrangendo a totalidade de falhas transientes ou definitivas que podem ocorrer em ambientes de produção. Além disso, o ambiente Apache Airflow foi provisionado localmente via Docker, o que pode diferir de implementações gerenciadas em nuvem. Para estudos futuros, sugere-se expandir a comparação para outros provedores de nuvem, como Google Cloud Platform, realizar testes de escalabilidade com volumes de dados significativamente maiores e investigar uma matriz mais completa de cenários de falha, incluindo “throttling” de API e corrupção de dados. Adicionalmente, o desenvolvimento de um framework de Custo Total de Propriedade (TCO) seria valioso para uma análise econômica mais abrangente.

Referências Bibliográficas

Apache Software Foundation. Apache Airflow Documentation. 2025. Disponível em <https://airflow.apache.org/docs/>. Acesso em: 14 abr. 2026.

Armbrust, M.; Fox, A.; Griffith, R.; Joseph, A.D.; Katz, R.; Konwinski, A.; Lee, G.; Patterson, D.; Rabkin, A.; Stoica, I.; Zaharia, M. A view of cloud computing. Communications of the ACM 53(4): 50-58, 2010.

Campêlo, R.A.; Casanova, M.A.; Guedes, D.O.; Laender, A.H. A brief survey on replica consistency in cloud environments. Journal of Internet Services and Applications 11: 1-13, 2020.

de Bas, B.; Harenslak, J.; de Ruiter, J. Data Pipelines with Apache Airflow. Manning Publications, 2019.

Ferreira, S.; Mendonça, J.; Nogueira, B.; Tiengo, W.; Andrade, E. Impacts of data consistency levels in cloud-based NoSQL for data-intensive applications. Journal of Cloud Computing 13(1): 158, 2024.

Gartner. Magic Quadrant for Cloud Infrastructure and Platform Services. 2025. Disponível em: <https://www.gartner.com/en/documents/magic-quadrant-cloud>. Acesso em: 14 abr. 2026.

Gilbert, S.; Lynch, N. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News 33(2): 51-59, 2002.

Kozina, O.A.; Panchenko, V.I.; Kolomiitsev, O.V.; Usik, V.V.; Stratiienko, N.K.; Safoshkina, L.V.; Kucherenko, Y.F. Data consistency protocol for multicloud systems. International Journal of Cloud Computing 13(1): 42-61, 2024.

Microsoft. Azure Data Factory Documentation. 2025. Disponível em: <https://docs.microsoft.com/azure/data-factory/>. Acesso em: 14 abr. 2026.

Narayanan, P.K. Orchestrating Data Engineering Pipelines using Apache Airflow. In: Data Engineering for Machine Learning Pipelines. Apress, Berkeley, CA, 2024. p. 289-315.

Patel, R. Enhancing Enterprise Data Orchestration Using Azure Data Factory. International Scientific Journal of Engineering and Management 5(11): 1-12, 2025.

Synergy Research Group. Cloud Infrastructure Services Market Share Q4 2025. 2025. Disponível em: <https://www.srgresearch.com/cloud-market-share>. Acesso em: 14 abr. 2026.

Troyer, J. Azure Data Factory’s orchestration problem – why we need Airflow. Medium, 2023. Disponível em: <https://medium.com/glitni/azure-data-factorys-orchestration-problem-why-we-need-airflow-643e97a847d4>. Acesso em: 14 abr. 2026.

Vogels, W. Eventually consistent. Communications of the ACM 52(1): 40-44, 2009.

Wohlin, C.; Runeson, P.; Höst, M.; Ohlsson, M.C.; Regnell, B.; Wesslén, A. Experimentation in Software Engineering. Springer Science & Business Media, 2012.

Yasmin, J.; Jassim, S.A.; Jiang, Z.M.; Hassan, A.E. An Empirical Study of Developers’ Challenges in Implementing Workflows as Code: A Case Study on Apache Airflow. arXiv preprint arXiv:2406.00180, 2024.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy