O extract que “já funciona” quase sempre é um script na máquina de alguém. Roda na sexta. Às vezes no domingo, se a pessoa lembrar. Quando falha, a reunião de segunda começa com “o número ainda não atualizou”.
Isso não é engenharia de dados. É um ponto único de falha com nome e sobrenome.
O que o script do fulano esconde
Três coisas que só aparecem quando a pessoa tira férias:
- a senha do legado, ou o jeito certo de “não travar o sistema de produção”;
- o recorte — tira cancelado, ou não tira; fuso; o que conta como nulo;
- a ordem: primeiro esse arquivo, depois aquele join, senão o total muda.
Ninguém documentou porque “está na cabeça”. O painel, se existir, espera esse arquivo. A planilha é o backup informal. Os dois mentem no mesmo dia em que o script não roda.
O que o orquestrador muda de verdade
Airflow (ou equivalente) não é moda. É o lugar onde o ritmo da fonte vira agenda: lote noturno, janela quase em tempo real, reprocessamento quando falha. O alerta chega antes da reunião, não durante.
Cada sistema legado tem o próprio ritmo, e o pipeline respeita esse ritmo em vez de depender de alguém rodando script manual quando algo trava. No ForBarber, o transacional sai do Firebase para um PostgreSQL analítico no mesmo espírito: extração agendada, não “quando o fulano puder”.
Modular, testado, com contrato entre passos. Se o schema da fonte muda, a validação para antes de gravar lixo no destino. Isso é o oposto de um .py solto numa pasta do Desktop.
O que não prometemos
Não vamos listar tempo de DAG nem economia de nuvem. Isso só vale no ambiente do cliente. Também não trocamos um script por um Airflow se o negócio ainda cabe numa aba e uma pessoa — isso é teatro.
A troca faz sentido quando o extract já é decisão de gestão e já quebrou mais de uma vez. Aí o trabalho é orquestrar de verdade e apontar o consumo para o resultado, não para o arquivo da sexta.
Se o número da segunda depende de alguém ter lembrado de rodar, escreve.