Orquestração de Workflows: Apache Airflow vs Prefect
Gabarito: letra B. O Prefect é a ferramenta mais adequada aos requisitos porque é nativamente cloud-native, suporta fluxos de trabalho dinâmicos e oferece monitoramento centralizado com tratamento de falhas em tempo real — características que se alinham diretamente com a necessidade de gerenciar fluxos complexos de coleta e análise de dados urbanos. A alternativa B descreve com precisão o modelo do Prefect, que combina agendamento baseado em tempo (time-based schedules) com gatilhos orientados a eventos (event-driven triggers), permitindo execução sob demanda.
O problema central desta questão é distinguir duas das principais ferramentas de orquestração de pipelines de dados: Apache Airflow e Prefect. Ambas são amplamente utilizadas, mas possuem filosofias e capacidades distintas. O Airflow, criado pela Airbnb, consolidou-se como o padrão da indústria para agendamento e monitoramento de workflows, utilizando o conceito de DAGs (Directed Acyclic Graphs) definidos em código Python. Sua interface web é robusta, mas sua arquitetura é mais tradicional, com um scheduler centralizado e execução baseada principalmente em agendamento periódico. O Prefect, por sua vez, foi projetado com uma abordagem mais moderna e cloud-native, priorizando a flexibilidade, a observabilidade e a resiliência. Ele permite a criação de fluxos dinâmicos que podem ser acionados por eventos, além de oferecer um painel de controle unificado para monitoramento e tratamento de falhas em tempo real.
A escolha entre as duas ferramentas depende dos requisitos específicos do projeto. Para o cenário descrito — que exige fluxos de trabalho dinâmicos, integração com serviços em nuvem e monitoramento centralizado com tratamento de falhas em tempo real — o Prefect se destaca. Sua natureza cloud-native facilita a integração com serviços como AWS, GCP e Azure, e seu modelo de execução orientado a eventos é ideal para workflows que precisam reagir a mudanças nos dados ou a condições específicas. O Airflow, embora poderoso, é mais adequado para pipelines com agendamento fixo e previsível, e sua configuração e manutenção podem ser mais complexas em ambientes distribuídos.
É importante notar que a alternativa B não apenas identifica a ferramenta correta, mas também descreve com precisão suas características fundamentais. A menção a "Cloud-Native Workflows" e "gerenciamento de fluxos dinâmicos" são termos diretamente associados ao Prefect. Além disso, a capacidade de executar workflows "quando necessário" através de time-based schedules e event-driven triggers é uma distinção crucial em relação ao Airflow, que tradicionalmente se baseia em agendamento periódico. Essa combinação de características torna o Prefect a escolha mais alinhada aos requisitos apresentados.
A pegadinha desta questão reside na tentação de escolher o Apache Airflow por ser a ferramenta mais conhecida e consolidada. No entanto, as alternativas que mencionam o Airflow contêm erros técnicos que as invalidam. A alternativa A, por exemplo, afirma que o Airflow é "ideal para processamento de dados em tempo real que exige baixa latência", o que não é verdade — o Airflow é um orquestrador de batch, não uma ferramenta de streaming. A alternativa C menciona uma "built-in query language" e "integração direta com APIs REST", características que não são centrais ou exclusivas do Airflow. A alternativa D, embora descreva corretamente a interface de monitoramento do Prefect, erra ao atribuir essa funcionalidade ao Prefect de forma genérica, sem destacar os diferenciais de dinamicidade e cloud-native. A alternativa E sugere usar ambas as ferramentas simultaneamente, o que seria uma solução desnecessariamente complexa e não otimizada para o cenário.
Critério | Apache Airflow | Prefect |
|---|
Abordagem | Orquestração de batch, agendamento periódico | Cloud-native, fluxos dinâmicos |
Gatilhos de execução | Baseados principalmente em tempo (schedules) | Time-based schedules e event-driven triggers |
Monitoramento e falhas | Interface web robusta, mas arquitetura tradicional | Painel centralizado com tratamento de falhas em tempo real |
Integração com nuvem | Possível, porém configuração mais complexa | Nativa (AWS, GCP, Azure) |
Adequação ao cenário | Pipelines previsíveis e estáticos | Fluxos dinâmicos que reagem a eventos |
Alternativa A — ❌ Incorreta
Esta alternativa atribui ao Apache Airflow a capacidade de ser "ideal para processamento de dados em tempo real que exige baixa latência". Isso é um erro conceitual grave. O Airflow é uma ferramenta de orquestração de batch, projetada para agendar e monitorar pipelines que processam dados em lotes, não para processamento de streaming em tempo real. Para baixa latência, seriam utilizadas ferramentas como Apache Kafka, Apache Flink ou Spark Streaming. A afirmação sobre "API Python" e "testar localmente" é verdadeira, mas não é suficiente para tornar a alternativa correta, pois o requisito central de tempo real não é atendido.
Alternativa B — ✅ Correta ⟵ GABARITO
A alternativa B descreve com precisão o Prefect. Ele é, de fato, uma plataforma cloud-native para orquestração de workflows, projetada para gerenciar fluxos dinâmicos. A capacidade de executar workflows "quando necessário" é suportada por dois mecanismos: agendamento baseado em tempo (time-based schedules) e gatilhos orientados a eventos (event-driven triggers). Isso permite que os pipelines sejam acionados não apenas em horários fixos, mas também em resposta a eventos externos, como a chegada de novos dados ou a conclusão de outro processo. Essa flexibilidade é essencial para o cenário de coleta e análise de dados urbanos, onde os fluxos podem precisar reagir a mudanças em tempo real.
Alternativa C — ❌ Incorreta
Esta alternativa afirma que o Apache Airflow oferece uma "built-in query language" e "suporte nativo a fluxos dinâmicos por meio de sua integração direta com APIs REST". Essas características não são precisas. O Airflow não possui uma linguagem de consulta embutida; ele utiliza Python para definir DAGs. Além disso, embora o Airflow possa ser integrado a APIs REST, isso não é uma característica "nativa" ou central de sua arquitetura, e o suporte a fluxos dinâmicos é limitado em comparação ao Prefect. A descrição é vaga e não reflete as capacidades reais da ferramenta.
Alternativa D — ❌ Incorreta
A alternativa D descreve corretamente a interface de monitoramento do Prefect, que exibe uma lista de DAGs com ícones, status e conexões entre nós. No entanto, ela falha ao não mencionar as características mais importantes que justificam a escolha do Prefect para este cenário: a natureza cloud-native, o suporte a fluxos dinâmicos e o tratamento de falhas em tempo real. A descrição é superficial e não aborda os requisitos específicos do enunciado, tornando a alternativa incompleta e, portanto, incorreta.
Alternativa E — ❌ Incorreta
A alternativa E sugere utilizar o Apache Airflow e o Prefect simultaneamente, aproveitando o primeiro para fluxos estáticos e o segundo para fluxos dinâmicos. Embora seja tecnicamente possível, essa abordagem é desnecessariamente complexa e não otimizada. O Prefect já é capaz de lidar com ambos os tipos de fluxos, estáticos e dinâmicos, de forma unificada. Introduzir duas ferramentas de orquestração diferentes aumentaria a complexidade operacional, o custo de manutenção e a curva de aprendizado, sem trazer benefícios significativos. A solução mais adequada é escolher uma única ferramenta que atenda a todos os requisitos, e o Prefect é a que melhor se encaixa.
Gabarito: letra B