O que faz uma DAG do Airflow ser bem projetada, e quais erros você procura em revisão?

Uma boa DAG tem tasks pequenas e idempotentes com dependências claras, deriva a janela de tempo do data interval e não do relógio, e mantém a lógica pesada fora do arquivo da DAG, já que esse arquivo é parseado constantemente. Evite passar dados grandes pelo XCom, evite sensores bloqueantes longos que ocupam slots de worker, e configure retentativas, timeouts e alertas sensatos nas tasks que importam.

As duas coisas com que eu mais me importo são granularidade das tasks e idempotência. As tasks devem ser pequenas o bastante para que uma falha seja barata de repetir e específicas o bastante para que a falha diga o que quebrou, e cada uma delas deve ser segura de reexecutar. Depois, a janela de tempo tem que vir do data interval que o Airflow passa, nunca de um datetime.now dentro da task, senão uma reexecução da terça passada processa os dados de hoje e você recebe uma resposta sutilmente errada em vez de um erro. Em revisão, o que eu mais aponto é código caro no nível superior do arquivo da DAG. Esse arquivo é parseado em intervalos curtos, então uma chamada de API ou uma consulta a banco fora da função da task roda o tempo todo e degrada o scheduler inteiro; eu já vi só isso adicionar minutos de latência de agendamento em um deployment inteiro. Eu também checo o uso de XCom, já que ele é uma tabela de metadados e não um transporte de dados, então passe um caminho no S3 em vez de um dataframe.