¿Qué hace que un DAG de Airflow esté bien diseñado y qué errores buscas al revisarlo?

Un buen DAG tiene tareas pequeñas e idempotentes con dependencias claras, deriva su ventana temporal del data interval en vez del reloj, y mantiene la lógica pesada fuera del fichero del DAG porque ese fichero se parsea constantemente. Evita pasar datos grandes por XCom, evita sensores bloqueantes largos que ocupan slots de worker, y configura reintentos, timeouts y alertas sensatas en las tareas que importan.

Las dos cosas que más me importan son la granularidad de las tareas y la idempotencia. Las tareas deben ser lo bastante pequeñas para que un fallo sea barato de reintentar y lo bastante específicas para que el fallo te diga qué se rompió, y todas deben ser seguras de reejecutar. Luego, la ventana temporal tiene que venir del data interval que pasa Airflow, nunca de un datetime.now dentro de la tarea, o si no una reejecución del martes pasado procesa los datos de hoy y obtienes una respuesta sutilmente equivocada en lugar de un error. En revisión, lo que más señalo es código caro en el nivel superior del fichero del DAG. Ese fichero se parsea a intervalos cortos, así que una llamada a una API o una consulta a base de datos fuera de la función de la tarea corre constantemente y degrada todo el scheduler; he visto que eso solo añadía minutos de latencia de planificación en todo un despliegue. También reviso el uso de XCom, ya que es una tabla de metadatos y no un transporte de datos, así que pasa una ruta de S3 y no un dataframe.