单Python文件生成数千DAG时Airflow 1.x任务执行变慢问题咨询

一、调度变慢的核心原因（Airflow侧） #

• Airflow 1.x 调度器为单进程架构，每轮调度周期需要完成全量DAG解析、所有DAG运行状态巡检、待执行任务筛选三步操作，DAG总量线性增长时，每轮调度的耗时也会线性上升：
  • 你使用的单文件动态生成DAG的方式，每次DAG解析进程扫描该文件时，都要循环生成所有DAG对象并存入全局变量，3000个DAG的解析开销会远高于单个DAG，直接拉长调度器获取最新DAG状态的周期
  • 调度器每轮需要遍历所有DAG的所有待调度任务，检查任务依赖、执行条件，DAG越多遍历开销越大
  • 元数据库压力随DAG数量上升暴涨：Airflow 1.x 对DAGRun、TaskInstance表的大量查询没有做针对性优化，DAG越多对应表的数据量越大，元数据查询耗时会显著增加
• 你观察到的「前置任务完成后等待数分钟才启动下一个任务」，本质是调度器还没跑完上一轮调度周期，还没扫描到该任务已经满足执行条件。

二、缩短调度间隔的优化手段 #

1. 调度器配置优化 #

• 调大min_file_process_interval参数：将该DAG生成文件的解析间隔拉长到300s以上，避免调度器频繁重复解析生成数千个DAG，浪费资源
• 开启DAG序列化（Airflow 1.10.10及以上版本支持）：将解析后的DAG对象序列化存储在元数据库，调度器无需每次都解析Python文件即可获取DAG结构
• 调整并发相关参数：适当调大parallelism（全局任务并发数）、dag_concurrency（单DAG任务并发数）、worker_concurrency（单Worker进程并发数），同时调小scheduler_heartbeat_sec参数，让调度器更频繁地触发调度

2. 元数据库优化 #

• 给元数据库的dag_run、task_instance表的常用查询字段（dag_id、execution_date、state）添加索引，降低查询耗时
• 升级元数据库配置，使用高性能的PostgreSQL/MySQL实例，避免数据库成为性能瓶颈

3. Cloud Composer 配置优化 #

• 将调度器调度到独立的高配置节点，避免和Worker、WebServer抢占计算资源
• 适当增加Worker节点数量，避免任务调度后无可用资源执行

三、现有方案的合理性评估及优化方向 #

你当前的单文件生成数千个DAG的方案属于典型的不良设计模式，核心问题是为了「单独触发每个表的加载任务」就拆分出数千个独立DAG，完全没有必要，属于对Airflow能力的误用。

更高效的实现方案 #

1. 替换为单通用DAG方案：仅开发一个通用的表加载DAG，通过REST API触发DAG时传入表名、表类型等运行参数，DAG执行时根据传入参数动态选择对应的加载逻辑。这种方案仅需要1个DAG即可承载所有3000张表的加载需求，完全避免了大量DAG带来的调度压力，同时可以满足按表单独触发的需求。
2. 如果必须拆分独立DAG（比如需要单独配置调度周期、权限隔离），不要用单文件生成所有DAG，改为用模板批量生成独立的小DAG文件，每个DAG对应一个单独的Python文件，这样DAG解析进程仅会在对应文件修改时重新解析该DAG，不会每次都生成全量3000个DAG。

你提供的简化示例代码的核心问题就是单文件循环生成数千个DAG存入全局变量，每次解析该文件都要执行完整的5000次循环，解析开销极高，是典型的反模式。

内容的提问来源于stack exchange，提问作者elaspog