Airflow 2.1.4 K8s部署下动态生成DAG重复查询数据库问题咨询

问题根因 #

你遇到的重复查询问题本质是Airflow的DAG解析机制导致的：Airflow集群中所有节点（scheduler、webserver、每个KubernetesExecutor拉起的worker Pod）都会定期扫描并解析dags/目录下的所有Python文件，你将客户列表查询逻辑放在了DAG文件的顶层作用域，每次解析都会触发一次数据库查询，自然会产生远超预期的调用量。

问题1 解决方案：避免DAG解析阶段重复查询数据库 #

你可以从以下几个方案中按需选择：

• 开启DAG序列化（最适配你当前版本的方案）
  Airflow 2.x原生支持DAG Serialization特性，开启后scheduler会将解析完成的DAG序列化后存储到元数据库，webserver、worker无需再重新解析DAG源文件，直接从元数据库读取序列化后的DAG结构即可。
  配置方式：修改airflow.cfg中对应配置项：

  [core]
  dag_serialization = True
  store_serialized_dags = True
  

  开启后可以直接避免worker执行任务阶段的DAG解析请求，查询量至少可以降低90%以上。
• 缓存客户列表查询结果
  给客户列表查询逻辑加上TTL缓存，避免每次解析都查库：
  • 可以用functools.lru_cache做内存缓存，配合固定TTL（比如12小时），同进程内的重复解析会直接读缓存
  • 也可以单独跑一个定时DAG，每天1-2次同步客户列表到Airflow Variable或者本地JSON文件，DAG生成逻辑直接读缓存结果，完全解除DAG解析对业务数据库的依赖
• 静态化生成DAG文件
  写一个专门的同步DAG，每天按照客户列表生成每个客户的静态DAG文件写入dags/目录，原有动态生成DAG的逻辑从DAG目录下移走，这样所有DAG解析都只会读静态Python文件，不会触发业务库查询。

问题2 多租户场景设计优化建议 #

你当前的单客户单DAG设计适合客户逻辑差异大、需要单独做调度配置、权限隔离的场景，但2000个DAG的规模会给scheduler带来较大调度压力，可以根据业务需求做以下优化：

• 如果客户的DAG逻辑高度一致，优先用单DAG多租户模式
  不需要每个客户生成独立DAG，仅保留一个通用DAG，通过动态任务映射（如果可以升级到Airflow 2.3+版本，原生支持动态映射，2.1.4版本可以用BranchPythonOperator结合客户参数生成多组任务实例）的方式同时跑所有客户的任务，DAG总数直接从2000降到1，调度压力会大幅降低。
• 如果必须保留单客户单DAG模式，做以下优化
  • 拆分DAG目录：将不同类型的客户DAG拆分到不同子目录，调整scheduler.dag_dir_list_interval配置（默认30s，可适当拉长到5-10min），降低scheduler扫描频率
  • 开启DAG自动清理：对于注销的客户，自动删除对应DAG文件，避免无效DAG占用调度资源
  • 资源隔离：KubernetesExecutor配置多队列，不同优先级的客户任务分配到不同的NodePool或者Namespace，避免单客户任务异常占满集群资源影响其他租户
  • 权限隔离：开启Airflow RBAC能力，给不同租户的账号分配对应DAG的查看、操作权限，做到租户间数据隔离

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