08. Apache Airflow — configuração e pools

Um fluxo de engenharia pode envolver várias tarefas Python com dependências e horários próprios. O Apache Airflow organiza essa execução por grafos, enquanto seu ambiente computacional fornece os workers que realizam as tarefas. O grafo e o pool resolvem problemas diferentes e precisam ser dimensionados em conjunto.

DAG e execução de tarefas

Um DAG é um grafo direcionado sem ciclos que descreve tarefas e suas dependências. Se carregar depende de extrair, disponibilizar mais workers não autoriza inverter a ordem. O escalonador identifica tarefas prontas; workers executam trabalho elegível. A concorrência possível nasce primeiro da estrutura do grafo e depois dos limites operacionais.

Conexões e identidades das tarefas continuam necessárias. Um DAG pode falhar em autenticação enquanto outros executam normalmente no mesmo pool. Esse padrão sugere investigar a tarefa ou sua conexão, em vez de recriar todo o ambiente. A disponibilidade do runtime é condição para executar, não garantia de que cada operação será bem-sucedida.

Um DAG com quatro extrações independentes e uma consolidação tem duas fases lógicas: as extrações podem coexistir, e a consolidação aguarda todas. Aumentar workers pode reduzir a primeira fase se as fontes suportarem a concorrência; não elimina a segunda. Já um DAG com quatro tarefas em cadeia tem um limite de paralelismo imposto pelas dependências. Desenhar essa relação antes do dimensionamento permite estimar onde recursos adicionais podem produzir benefício e onde apenas ficariam ociosos aguardando a etapa anterior.

Starter pool e pool personalizado

O starter pool atende ao início do trabalho e pode encerrar após inatividade. Uma nova utilização pode exigir retomada e preparação. Isso é aceitável para desenvolvimento ocasional, mas precisa ser considerado quando a primeira tarefa do dia tem uma janela de execução curta. Inicialização rápida em um teste não prova disponibilidade contínua.

O pool personalizado atende ao padrão always-on quando mantido ativo. Sua criação registra a configuração, mas ele precisa ser iniciado para disponibilizar o runtime. Pausar suspende essa disponibilidade; a retomada deve ocorrer com antecedência suficiente para preparar o ambiente antes de um DAG crítico. A escolha envolve o padrão operacional, não apenas a duração de uma tarefa.