Apache Airflow

Apache Airflow é uma plataforma open-source para criar, agendar e monitorar workflows como código. Pipelines são definidos como DAGs (Directed Acyclic Graphs) em Python, o que permite versionar, testar e reutilizar a lógica de orquestração.

É o orquestrador mais adotado na engenharia de dados: gerencia dependências entre tarefas, agenda execuções, lida com retries, e oferece uma interface web para monitoramento.

Arquitetura

graph TB
    subgraph Airflow["Apache Airflow"]
        WS[Webserver\nUI + API REST]
        SCH[Scheduler\nagendamento + trigger de tasks]
        META[(Metadata DB\nPostgreSQL)]
        EX[Executor]
        WK[Workers]
    end
    DAGs[DAG files\n.py] --> SCH
    SCH --> META
    SCH --> EX
    EX --> WK
    WS --> META
    WS --> WK

Componente	Responsabilidade
Webserver	Interface web (UI) e API REST para gerenciar DAGs, tasks e conexões
Scheduler	Lê os DAG files, avalia agendamento e dispara task instances
Executor	Define como as tasks são executadas (local, Celery, Kubernetes)
Workers	Processos que executam de fato o código das tasks
Metadata DB	PostgreSQL (ou MySQL) que armazena estado de DAGs, runs, tasks, conexões e variáveis
Triggerer	Componente opcional para sensores deferríveis (async I/O sem ocupar worker)

Fluxo de execução

sequenceDiagram
    Scheduler->>DAG file: parse (a cada ~30s)
    Scheduler->>Metadata DB: cria DagRun quando schedule bate
    Scheduler->>Executor: enfileira TaskInstance
    Executor->>Worker: executa task
    Worker->>Metadata DB: atualiza estado (running → success/failed)
    Webserver->>Metadata DB: lê estado para exibir na UI

Executores

O executor determina onde e como as tasks rodam. A escolha impacta escalabilidade, custo e complexidade.

Executor	Onde roda	Escalabilidade	Quando usar
SequentialExecutor	Processo local, 1 task por vez	Nenhuma	Desenvolvimento e testes simples
LocalExecutor	Subprocessos no mesmo host	Limitada ao host	Ambientes pequenos, single-node
CeleryExecutor	Workers remotos via fila (Redis/RabbitMQ)	Horizontal	Produção com múltiplos workers
KubernetesExecutor	Pod K8s por task	Elástica	Cloud-native, isolamento por task
CeleryKubernetesExecutor	Híbrido Celery + K8s	Elástica	Migração gradual para K8s

CeleryExecutor

graph LR
    SCH[Scheduler] --> Q[Fila - Redis/RabbitMQ]
    Q --> W1[Worker 1]
    Q --> W2[Worker 2]
    Q --> W3[Worker N]

Workers são processos persistentes que ficam consumindo a fila. Escala adicionando mais workers.

KubernetesExecutor

Cada task instance cria um Pod efêmero no Kubernetes. O pod é destruído ao fim da task. Isolamento total entre tasks, sem workers ociosos.

graph LR
    SCH[Scheduler] --> K8s[Kubernetes API]
    K8s --> P1[Pod: task A]
    K8s --> P2[Pod: task B]
    K8s --> P3[Pod: task C]

Quando usar Airflow

Use Airflow para:

Pipelines batch com dependências complexas entre steps
Orquestração de múltiplas ferramentas (Spark, dbt, BigQuery, Dataflow)
Workflows que precisam de retry, alertas e visibilidade centralizada
Agendamento baseado em cron ou evento externo

Considere alternativas quando:

Pipelines são simples e lineares → Cron + script pode ser suficiente
Foco em data assets com observabilidade → Dagster
Simplicidade operacional e Python-first → Prefect
Streaming em tempo real (Airflow é orientado a batch, mesmo com sensores)

Versões relevantes

Versão	Destaque
Airflow 2.0 (2021)	TaskFlow API (`@dag`, `@task`), scheduler reescrito, estabilidade
Airflow 2.4	DatasetScheduling: DAGs disparados por produção de datasets
Airflow 2.6	Sensores deferríveis estáveis, Triggerer component
Airflow 2.9	Deferrable operators nativos, melhorias de performance no scheduler
Airflow 3.0 (2025)	Novo scheduler distribuído, AIP-72 Assets unificado, UI redesenhada

Serviços gerenciados

Plataforma	Serviço	Nota
GCP	Cloud Composer	Airflow gerenciado sobre GKE/Serverless
AWS	Amazon MWAA	Managed Workflows for Apache Airflow
Astronomer	Astro	SaaS multi-cloud, versão enterprise do Airflow

Second Brain

Explorer