Artigo

05 de agosto de 2026

Estratégias de Agendamento “multi-cloud” para Redução de Inconsistência de Dados em Sistemas Heterogêneos

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

Você também pode gostar

17 de setembro de 2026

Heterogeneidade Territorial do Bolsa Família: uma Análise por Clusters e Efeitos Fixos

O Programa Bolsa Família (PBF) representa uma das políticas de proteção social mais relevantes globalmente, o que justifica a investigação de seus efeitos diante das acentuadas e heterogêneas desigualdades regionais brasileiras. O estudo avaliou os reflexos socioeconômicos dos repasses do programa sobre a saúde, a educação e o mercado de trabalho nos municípios brasileiros, no período de 2004 a 2019. Para isso, aplicou-se a técnica de agrupamento K-means para segmentação territorial e estimaram-se modelos econométricos de dados em painel com efeitos fixos, tanto a nível nacional quanto segregados por clusters. Os resultados revelaram a natureza anticíclica do PBF no mercado de trabalho, com uma relação negativa entre repasses e vínculos empregatícios formais em quatro dos cinco clusters, sugerindo que os recursos foram mais intensos onde o mercado formal falhou. Na saúde, o programa associou-se à redução significante da mortalidade infantil evitável em municípios com maior equilíbrio socioeconômico, mas não apresentou efeito detectável em agrupamentos de maior precariedade estrutural, indicando que a transferência de renda é necessária, porém insuficiente sem infraestrutura de saúde funcional. Na educação, a análise por subperíodos mostrou atenuação progressiva do coeficiente nacional, refletindo a convergência das taxas de matrícula para um patamar de alta inércia temporal. Concluiu-se que o PBF cumpriu seu objetivo de proteção social de forma anticíclica e territorialmente focalizada, mas sua capacidade de transformar indicadores estruturais dependeu da sinergia com investimentos em infraestrutura pública.

Palavras-chave: Bolsa Família; Mortalidade Infantil; Municípios Brasileiros; Painel de Dados; Política Pública.

Gestão Tributária

17 de setembro de 2026

Limites Jurídicos e Práticos da Dedutibilidade Retroativa dos Juros sobre Capital Próprio

A gestão tributária adequada é crucial para a saúde financeira das empresas, especialmente no complexo sistema tributário brasileiro. Os Juros sobre Capital Próprio (JCP) constituem um mecanismo jurídico relevante para a remuneração do capital próprio, utilizado para otimizar a carga tributária. O estudo investigou a controvérsia sobre a dedutibilidade de JCP referentes a exercícios anteriores à deliberação societária que autoriza seu pagamento. Aplicou-se a metodologia de pesquisa e análise documental empírica, baseada em “Normative Systems”, para identificar cinco propriedades representativas dos argumentos jurídicos na jurisprudência administrativa e judicial. Analisaram-se acórdãos do Conselho Administrativo de Recursos Fiscais (CARF), revelando padrões decisórios predominantes, divergências interpretativas, incoerências argumentativas e significativa insegurança jurídica. Os resultados indicaram forte tendência de invalidação dos planejamentos envolvendo JCP extemporâneos na esfera administrativa. Contudo, o julgamento do Tema 1319 pelo Superior Tribunal de Justiça (STJ) seguiu direção oposta, consagrando tese favorável à dedutibilidade e estabelecendo um precedente paradigmático que pode influenciar a jurisprudência administrativa e redefinir os critérios decisórios.

Palavras-chave: CARF; gestão tributária; limitação temporal; lucro real; planejamento tributário.

17 de setembro de 2026

Símbolos da Moda Esportiva: Consumo, Identidade e Status entre Consumidores Brasileiros

A moda esportiva consolidou-se como linguagem simbólica de distinção social nas últimas décadas, impulsionada pela expansão do mercado de wellness e pela reconfiguração dos padrões de prestígio nas sociedades de consumo contemporâneas. O estudo objetivou compreender como os símbolos da moda esportiva influenciaram a construção de identidade e pertencimento e sua associação ao prestígio social entre consumidores brasileiros que adquiriram produtos do setor nos últimos 12 meses. Desenvolveu-se a pesquisa por meio de levantamento bibliográfico e pesquisa descritiva, com levantamento do tipo survey aplicado a uma amostra não probabilística por conveniência de 445 consumidores brasileiros de moda esportiva. Os principais resultados indicaram que a maioria dos respondentes associou marcas esportivas a percepções de status social; mais da metade reconheceu o wellness como novo símbolo de prestígio; e parcela expressiva percebeu o sportstyle como mais aceito em ambientes formais de trabalho. Em contrapartida, formas ostensivas de sinalização, como preferência por logotipos visíveis, influência de redes sociais e disposição a pagar sobrepreço, foram amplamente rejeitadas, revelando uma dissociação entre a atribuição simbólica de status e o comportamento de sinalização ostensiva. O consumidor brasileiro de moda esportiva com elevado capital cultural operou por meio de sinais simbólicos sutis e não ostensivos, compatíveis com o fenômeno do consumo inconspícuo, no qual a distinção social se manifestou de forma internalizada.

Palavras-chave: Consumo inconspícuo; Distinção; Prestígio social; Sportstyle; Wellness.

17 de setembro de 2026

Modelo Validado de Formação de Competência Técnica e Habilidades Não Técnicas em Indústrias Químicas Complexas

Analisou-se a implementação de um processo sistemático para o desenvolvimento e a atualização de competências técnicas e habilidades não técnicas em Operações Industriais e Segurança de Processo em uma indústria química de alta complexidade, pertencente a uma multinacional localizada no Polo Petroquímico de Camaçari, Bahia. O estudo objetivou implementar um processo mensurável e sustentável que assegurou a competência técnica e não técnica de 100% dos operadores, em conformidade com a legislação estadual da Bahia, diretrizes de institutos internacionais e políticas corporativas. A pesquisa caracterizou-se como um estudo de caso de abordagem mista, que envolveu diagnóstico documental, entrevistas semiestruturadas com 85 operadores experientes, análise de tarefas críticas e o desenvolvimento e aplicação piloto de um programa modular de treinamento. Este processo evidenciou a necessidade de alinhamento e atualização sistemática das competências requeridas. Os resultados obtidos indicaram a eficácia do modelo proposto, com 100% dos operadores concluindo os módulos teóricos e práticos e alcançando uma taxa de aprovação superior a 80%, além de conformidade operacional em campo. O trabalho contribuiu com um modelo estruturado de formação, incluindo matriz de competências, programas modulares de treinamento e diretrizes para certificação e recertificação, demonstrando potencial de replicação em outras unidades industriais de elevada complexidade e risco, e fortalecendo a segurança de processo e a sustentabilidade operacional.

Palavras-chave: Capacitação; Competência; Habilidades não técnicas; Segurança de processo; Treinamento.

Compliance E Esg

17 de setembro de 2026

Governança Pública Climática e Enchentes de 2024 no Rio Grande do Sul

As enchentes de 2024 no Rio Grande do Sul evidenciaram fragilidades estruturais na governança pública em um contexto federativo submetido a risco climático extremo. Este trabalho analisou, no recorte temporal de maio de 2024 a maio de 2025, como a atuação federal, estadual e municipal se estruturou diante da crise e em que medida a comparação com os Países Baixos ofereceu parâmetros úteis para o fortalecimento da resiliência institucional. A pesquisa adotou abordagem qualitativa, aplicada, exploratória e comparativa, com análise documental e análise de conteúdo de fontes oficiais, relatórios técnicos internacionais, atos normativos e pronunciamentos institucionais, organizados por categorias temáticas e interpretados com apoio do Modelo das Três Linhas do IIA. Os resultados mostraram que, embora os três níveis de governo tenham criado ou reestruturado instrumentos relevantes de coordenação e reconstrução após o desastre, prevaleceu uma institucionalidade reativa, posterior ao evento, com lacunas de continuidade administrativa, integração preventiva, monitoramento e accountability. Na comparação internacional, o modelo neerlandês destacou-se por combinar autoridade operacional permanente, base territorial clara, financiamento próprio e mecanismos mais robustos de monitoramento e responsabilização. Concluiu-se que os impactos das enchentes foram agravados menos pela ausência formal de normas e mais pela insuficiente articulação entre operação, gestão de riscos e controle. O fortalecimento da governança climática, no caso gaúcho, depende de institucionalizar coordenação, dados, financiamento e accountability em bases permanentes.

Palavras-chave: accountability; adaptação climática; gestão de riscos; governança multinível.

Digital Business

17 de setembro de 2026

Dados e Automação Utilizados em uma Campanha de Marketing na Engenharia Civil

A crescente utilização de dados no marketing digital impulsionou a adoção de estratégias mais orientadas por métricas e desempenho, com o Inbound Marketing em destaque. O uso de ferramentas de Business Intelligence (BI) mostrou-se fundamental para transformar dados em informações estratégicas, apoiando a tomada de decisão e a construção de bases de contatos qualificadas. Analisou-se como a ausência de integração entre sistemas de BI e plataformas de automação de marketing impactou a eficiência operacional e a efetividade das estratégias de Inbound Marketing em uma empresa de engenharia. Para isso, adotou-se uma abordagem descritiva de natureza qualitativa, baseada na análise dos processos operacionais envolvidos, desde a leitura de relatórios extraídos do BI e sua posterior transformação em mailings, até a preparação para importação no RD Station. Os resultados indicaram que o processo atual dependia de etapas manuais e empíricas, demandando tempo significativo. Identificaram-se limitações relacionadas à ausência de integração entre os sistemas, o que impactou diretamente a eficiência operacional e aumentou a dependência de atividades repetitivas. Concluiu-se que a estruturação adequada do processo de gestão de mailings e a integração entre BI e ferramentas de automação de marketing representam uma oportunidade para otimizar fluxos, melhorar a qualidade dos dados e fortalecer as estratégias de Inbound Marketing.

Palavras-chave: Automação de Marketing; Business Intelligence; Inbound Marketing; Integração de Sistemas; RD Station.

17 de setembro de 2026

Detecção de Anomalias no Monitoramento de Saúde de Pontes Usando Redes Neurais

O monitoramento da saúde estrutural de pontes tornou-se cada vez mais relevante diante do envelhecimento das infraestruturas e da intensificação de eventos extremos associados às mudanças climáticas. Nesse contexto, abordagens baseadas em dados destacaram-se como alternativas promissoras para o reconhecimento de anomalias. O estudo objetivou desenvolver e avaliar uma abordagem baseada em aprendizado de máquina para o reconhecimento de anomalias em séries temporais de aceleração estrutural. A metodologia adotada consistiu no uso de autoencoders treinados exclusivamente com dados representativos da condição íntegra, permitindo ao modelo aprender padrões associados ao estado saudável da estrutura; em seguida, o erro de reconstrução, quantificado por meio do erro quadrático médio (MSE), foi utilizado como critério para identificação de desvios em relação a essa condição. O conjunto de dados analisado foi composto por 1767 séries temporais de 1000 pontos cada, pertencentes a duas classes: íntegra (normal) e anômala (danificada). Os resultados obtidos demonstraram que o modelo proposto apresentou elevada capacidade de reconhecimento da classe anômala, com taxa de detecção superior a 90%, e desempenho global satisfatório, com área sob a curva ROC (AUC) próxima de 0,78, indicando boa capacidade discriminativa e reforçando o potencial da abordagem para aplicações em monitoramento estrutural.

Palavras-chave: Autoencoders; Detecção de Anomalias; Monitoramento de Pontes; Redes Neurais.

17 de setembro de 2026

Gestão Escolar Integrada: o Papel da Direção Administrativa na Capacitação da Equipe de Gestão Pedagógica para a Compreensão do Orçamento Escolar

A administração escolar foi abordada sob a perspectiva da integração entre gestores administrativos e pedagógicos, com foco na participação democrática, capacitação e qualificação dos atores. O objetivo geral consistiu na elaboração de um Guia de Orientações para Orçamento, direcionado à equipe de gestão pedagógica e mediado pela direção administrativa, visando instrumentalizar esses profissionais para a compreensão e participação nos processos financeiros e decisórios da instituição. Para tanto, o estudo desenvolveu-se em uma instituição particular privada, adotando uma abordagem qualitativa, descritiva e aplicada, com procedimento metodológico de estudo de caso. A pesquisa mapeou desafios práticos e dificuldades de comunicação entre os setores, analisou referenciais teóricos da gestão escolar e estruturou o instrumento formativo proposto. Os resultados demonstraram que a ausência de integração entre as áreas administrativa e pedagógica pode comprometer a efetividade da gestão escolar, evidenciando a necessidade de processos formativos contínuos que promovam entendimento mútuo, cooperação e construção coletiva de soluções. O Guia proposto fortaleceu a gestão democrática, elevou a qualificação da equipe pedagógica e melhorou os processos decisórios institucionais, destacando o papel formativo e estratégico do diretor administrativo.

Palavras-chave: Comunicação escolar; Gestão escolar participativa; Orçamento escolar.

Inscreva-se em nossa newsletter!

Receba conteúdos e fique sempre atualizado sobre as novidades em gestão, liderança e carreira com a Revista E&S.

Ao preencher o formulário você está ciente de que podemos enviar comunicações e conteúdos da Revista E&S. Confira nossa Política de Privacidade