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.
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.