// stack.lumi
Dados

Airflow

Orquestracao robusta para pipelines de dados.

// o que é

Apache Airflow agenda, monitora e orquestra pipelines com dependencias complexas. Para a Lumi Data, e essencial quando a empresa precisa coordenar ingestao, transformacao, validacao e publicacao de dados com rastreabilidade.

Sistemas de gerenciamento de workflows são estudados desde os anos 1990 sob o modelo de redes de Petri e grafos acíclicos dirigidos (DAGs), que provam propriedades de ausência de deadlocks e ordenação causal de tarefas (van der Aalst, 1998). O Apache Airflow, lançado pelo Airbnb em 2014, formalizou esse modelo no contexto de pipelines de dados, introduzindo a noção de DAG como unidade de código Python versionável e auditável (Apache Software Foundation, 2015). Kleppmann (2017) trata processamento batch como a fundação histórica de sistemas de dados, e a orquestração confiável é o que garante que jobs batch sejam executados exatamente uma vez, na ordem correta, com capacidade de retry e alertas de falha. A influência do Borg do Google (Verma et al., 2015) no design de schedulers modernos se manifesta no Airflow pela separação entre scheduler, executor e workers, permitindo escalonamento horizontal.

Como a Lumi enxerga:A Lumi implementa DAGs idempotentes, alertas, SLAs e padroes de deploy para reduzir falhas silenciosas e retrabalho operacional.
// na prática

Como empresas usam Airflow

01

Operadora de saúde com integrações entre sistemas legados, APIs externas e data warehouse

DAGs do Airflow coordenam a ingestão diária de prontuários de sistemas HL7/FHIR, cruzamento com base de beneficiários da ANS, execução de modelos dbt e publicação em dashboards clínicos. A dependência entre tarefas garante que o dashboard de ocupação de leitos só atualiza quando todos os feeds de hospitais confirmaram envio — eliminando o problema de dados parciais que causavam alarmes falsos na diretoria médica.

02

Varejista com pipelines de inventário, precificação e sell-out integrados a ERP SAP

Airflow orquestra extração incremental do SAP, validação de qualidade via Great Expectations, transformação dbt e carga em Redshift, com alertas no Slack quando qualquer etapa falha. O scheduler garante que o relatório de ruptura de estoque esteja disponível às 7h toda manhã, antes da abertura das lojas, com rastreabilidade completa de qual job gerou cada linha do relatório.

03

Startup de crédito com modelos de score sendo retreinados semanalmente

DAGs coordenam feature engineering com Spark, treinamento de modelo em SageMaker, validação de métricas de performance (Gini, KS) e promoção automática do modelo se as métricas superam o baseline. O Airflow serve como orquestrador único de MLOps, com auditoria de qual versão de dado e código gerou cada modelo em produção — requisito regulatório do Banco Central para modelos de crédito.

// decisão técnica

Quando usar — e quando não usar

Use quando
  • Pipelines têm dependências complexas entre tarefas — ingestão deve concluir antes da transformação, que deve concluir antes da validação — e essas dependências precisam ser declaradas explicitamente e monitoradas.
  • O ambiente de dados envolve múltiplas fontes heterogêneas (APIs, bancos relacionais, object storage, cloud services) que precisam ser coordenadas com retry logic, timeouts e alertas de falha.
  • A equipe precisa de auditabilidade completa: saber exatamente quando cada job rodou, quanto tempo levou, quais parâmetros usou e o que produziu — para fins de debugging, SLA ou conformidade regulatória.
  • Há necessidade de pipelines parametrizados com backfill histórico, permitindo reprocessar datas passadas quando dados chegam atrasados ou quando lógica de negócio muda retroativamente.
  • O time já trabalha com Python e quer definir infraestrutura de orquestração como código, versionada em Git e revisada no mesmo processo de code review do restante do projeto.
Evite quando
  • O caso de uso é trigger de eventos em tempo real ou near-realtime com latência de segundos; Airflow é um scheduler batch e não substitui Kafka, Flink ou Cloud Functions para reações a eventos.
  • A organização tem apenas dois ou três pipelines simples e lineares; o overhead operacional de manter Airflow (scheduler, webserver, metadata DB, workers) não se justifica — um cron job ou Cloud Scheduler resolve com menos custo.
  • O time não tem familiaridade com Python e não tem capacidade de manter DAGs como código; soluções low-code como Fivetran ou Airbyte para ingestão podem ser mais adequadas para o perfil do time.
  • O ambiente é serverless e event-driven por natureza (ex: Cloud Functions acionadas por eventos de Pub/Sub); adicionar Airflow cria uma camada de orquestração desnecessária sobre um sistema já adequadamente coordenado.
// visão lumi

A Lumi usa Airflow quando a complexidade de dependências entre tarefas justifica o investimento operacional — não como padrão para qualquer pipeline. Em projetos menores, Cloud Scheduler com Cloud Functions ou Step Functions da AWS resolvem com zero overhead. Quando Airflow entra, a primeira decisão é onde rodar: Cloud Composer no GCP e MWAA na AWS eliminam o trabalho operacional de gerenciar a infra, o que para a maioria dos clientes faz mais sentido do que clusters Airflow próprios. Um sinal vermelho que encontramos frequentemente são DAGs com lógica de negócio embutida no operador — o Airflow deve orquestrar, não processar; quando ele começa a fazer transformações complexas, a arquitetura está errada.

Lumi escolhe quando

  • Quando pipelines têm mais de cinco etapas com dependências entre si e o cliente precisa de observabilidade centralizada e alertas de falha por tarefa.
  • Quando existe requisito de auditoria regulatória (LGPD, Banco Central, ANS) que exige rastreabilidade de quando e como cada dado foi gerado.
  • Quando o ambiente já usa GCP (Cloud Composer) ou AWS (MWAA) e a gestão da infra do Airflow pode ser delegada ao provedor cloud.
  • Quando o projeto envolve MLOps e o Airflow serve como orquestrador unificado de pipelines de dados e de treinamento de modelos.

Lumi não recomenda quando

  • Quando o pipeline é simples e linear e o overhead operacional do Airflow seria maior do que o problema que ele resolve.
  • Quando o time não tem maturidade para manter DAGs como código com testes e versionamento — DAGs sem disciplina viram debt técnico rapidamente.
  • Quando o caso de uso é orientado a eventos em tempo real; nesse caso indicamos Kafka + Flink ou serviços gerenciados de streaming cloud.
// aplicações

Onde essa tecnologia gera valor

01

DAGs de ETL e ELT

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

02

Carga incremental

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

03

Rotinas de qualidade

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

04

Integracao entre bancos, APIs e cloud

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

// fundamentos

Referências acadêmicas e técnicas

Apache Software Foundation. (2015). Apache Airflow Documentation. https://airflow.apache.org/docs/

Documentação oficial do Airflow, incluindo arquitetura de scheduler, executor e DAG lifecycle.

Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media.

Capítulo sobre processamento batch como fundação de sistemas de dados; contextualiza a necessidade de orquestração confiável.

Verma, A., Pedrosa, L., Korupolu, M., Oppenheimer, D., Tune, E., & Wilkes, J. (2015). Large-scale cluster management at Google with Borg. EuroSys Conference Proceedings.

Descreve o design de schedulers em larga escala que influenciou a separação de responsabilidades do Airflow.

van der Aalst, W. M. P. (1998). The Application of Petri Nets to Workflow Management. Journal of Circuits, Systems, and Computers, 8(1), 21–66.

Formalização matemática de workflows como DAGs e redes de Petri, base teórica dos sistemas de orquestração modernos.

Reis, J., & Huyen, C. (2022). Fundamentals of Data Engineering. O'Reilly Media.

Define orquestração como componente crítico do ciclo de vida de engenharia de dados e discute trade-offs entre ferramentas.

// tecnologias relacionadas

Dados

// próximo passo

Quer saber se esse stack faz sentido para você?

A Lumi avalia contexto, dados, equipe, custo e maturidade para recomendar a tecnologia certa e entregar com responsabilidade.