Tecnologia
Consultoria e implementação de Apache Airflow
A empresa trocou um punhado de crontabs por Airflow e ganhou uma tela onde enxerga as rotinas. A troca resolveu a visibilidade e não mudou o desenho: as tarefas continuam sendo scripts que só sabem rodar uma vez, no horário certo. O problema aparece no dia em que a fonte chegou errada e alguém precisa reprocessar o período anterior. Aí ninguém sabe dizer se rodar de novo corrige o número ou duplica ele.
Como a gente encara.
Antes de escrever DAG nova, olhamos o que já roda. De cada tarefa vem uma pergunta: executá-la de novo muda o resultado? O que não sobrevive a ela é reescrito para regravar a partição que produz. Idempotência é o que torna reprocessagem uma rotina, e não uma operação de risco. Dependência entre rotinas passa a ser declarada no código, nunca deduzida do relógio. O arquivo de DAG fica só com a declaração; a lógica pesada sai para módulo importado e testável. E a rotina ganha onde rodar antes de produção.
Onde costuma quebrar
Os erros que aparecem sempre, e que ninguém conta na demonstração.
- 01
Tarefa que só sabe inserir. Rodar de novo soma linha em vez de substituir a janela processada, e aí o retry automático — que existe para salvar a sua madrugada — vira o mecanismo que corrompe o histórico.
- 02
Lógica pesada no corpo do arquivo de DAG: consulta a banco, chamada de API ou varredura de diretório na hora de montar as tarefas. O DAG processor — componente separado do scheduler — reanalisa esse arquivo em intervalo curto, então você paga esse custo de novo o tempo todo e o agendamento atrasa sem causa aparente.
- 03
Dependência entre DAGs resolvida por horário: a segunda começa mais tarde na esperança de que a primeira já tenha terminado. No dia em que a primeira atrasa, a segunda lê dado velho e termina em verde — entrega número errado sem falhar.
- 04
XCom usado para transportar o dado em vez da referência a ele. O banco de metadados do Airflow vira armazenamento de resultado, incha, e a lentidão aparece para todas as rotinas ao mesmo tempo.
- 05
Tarefa escrita para o dia em que ela roda, e não para o período que ela processa. Funciona no agendamento normal e produz o dado errado em toda reprocessagem, que é exatamente quando ninguém está olhando o resultado com calma.
O que custa mais do que parece
- Airflow é software que alguém precisa manter em pé: banco de metadados, atualização de versão e dependências de Python que brigam entre si dentro do mesmo ambiente. Esse tempo é permanente e costuma ficar de fora quando você compara o custo com o de um orquestrador gerenciado.
- Reprocessar histórico sai caro quando ninguém desenhou janela nem limite de execuções simultâneas. O backfill dispara tudo o que couber, pressiona o banco de origem ou o armazém, e alguém interrompe no meio deixando o período pela metade — pior do que não ter reprocessado.
- O alerta que ninguém lê. Retry automático esconde a falha intermitente até ela virar permanente, e a enxurrada de aviso treina o time a ignorar justamente a notificação que importava.
O que você recebe
- Inventário das rotinas com dono nomeado, janela de execução e o que para de funcionar a jusante quando cada uma falha.
- DAGs com tarefas idempotentes e o procedimento de reprocessagem escrito: qual comando se roda, qual janela se escolhe e qual o limite de execuções simultâneas.
- Dependência entre rotinas declarada no código, sem espera por horário.
- Ambiente para rodar e testar a rotina antes do merge, com a suíte executando no pipeline de integração.
- Alerta com destinatário nomeado e critério de disparo, separando a falha que acorda alguém da falha que espera o horário comercial.
O que fazemos com Apache Airflow
Open source ou enterprise, a frente é a mesma.
Implantar
Do zero, com a arquitetura decidida no diagnóstico e não pelo catálogo do fornecedor.
Migrar
De outra ferramenta, ou de uma versão antiga, com o que já roda continuando a rodar.
Desenvolver em cima
Aplicação, integração e automação construídas sobre Apache Airflow, incluindo o que a ferramenta não faz sozinha.
Sustentar
Operação, custo sob controle e correção de rota depois que entra em produção.
Perguntas diretas.
- Airflow serve para qualquer automação da empresa?
- Não. Airflow é bom em rotina de dado que roda em lote, tem dependência entre etapas e precisa ser reprocessada por período. Ele é a peça errada para fluxo que reage a evento com resposta imediata e para processamento contínuo: você acaba com uma tarefa de pé perguntando se já pode seguir, cada uma ocupando um slot de execução enquanto espera. Operador deferrable existe justamente para isso e devolve o slot ao triggerer durante a espera, mas devolve só o slot: a retomada continua presa ao ciclo do agendador, e a latência sai pior do que a de uma fila. Aprovação humana no meio o Airflow já sabe fazer, com operador próprio para isso, mas continua sendo uma escolha discutível: a execução fica aberta pelo tempo que a pessoa levar para responder, e o seu pipeline passa a ser medido pela agenda dela.
- Vale manter um Airflow próprio, ou é melhor um gerenciado — ou nenhum?
- Se você tem poucas rotinas, sem dependência entre elas e sem necessidade de reprocessar período, cron com log e alerta resolve, e o Airflow só acrescenta um banco, um scheduler e um componente a atualizar. Quando existe dependência, calendário compartilhado e reprocessagem, um orquestrador se justifica — e aí a pergunta seguinte é se há alguém no time para mantê-lo em pé. Se não há, um gerenciado, ou o agendador que já vem com a sua nuvem ou com o seu armazém, custa mais na fatura e muito menos em gente. Vale dizer isso antes de propor a implantação.
- Por que a rotina falha ou entrega número diferente quando roda de novo, se o código não mudou?
- Quase sempre por um de dois motivos. O primeiro é a tarefa que usa a data de hoje em vez da janela da execução: reprocessar um período antigo vai buscar o dado do período errado. O segundo é a tarefa que só insere: a segunda execução acrescenta o que a primeira já havia gravado, e o total dobra sem que nada apareça como erro. Os dois se resolvem no desenho da tarefa, não no ajuste do agendamento.
Ferramentas vizinhas
Apache Airflow raramente decide sozinho.
Antes de escolher a ferramenta
A ferramenta é consequência da arquitetura. Nunca a premissa.
Esta página existe porque alguém procura por esse nome. Mas a escolha certa sai do diagnóstico do seu cenário, não do catálogo de quem vende. Se a resposta for outra ferramenta, ou nenhuma, é isso que você vai ouvir.
Não está na lista? Não é impedimento, é conversa. O que decide não é o nome do produto, é o problema que ele precisa resolver.