Hey there, let's break down your problem step by step—you're hitting classic scaling pain points with Airflow when dealing with a massive 100k+ task DAG, and I've helped teams work through similar bottlenecks before.

你是否触达了Web服务器或调度器的限制？ #

绝对是的。Airflow的默认配置是针对中小规模DAG设计的，当单个DAG的任务数突破上万级时，调度器和Web服务器都会遇到明显的性能瓶颈：

• 调度器需要解析、调度和跟踪数十万任务实例，默认的解析和调度线程/进程根本扛不住，会导致调度器挂起或卡顿。
• Web服务器在渲染Graph View、Tree View时，需要从数据库拉取大量任务实例数据，默认的同步worker和有限的进程数会导致UI加载极慢甚至崩溃。

处理Airflow大量任务的核心策略与配置建议 #

1. 拆分超大DAG，避免单DAG过载 #

这是最关键的一步：不要把10万+任务塞进一个DAG。按以下维度拆分：

• 按业务域：比如把用户数据处理、订单数据处理拆成独立DAG。
• 按时间窗口：比如按天生成DAG（用DAG动态生成），每个DAG只处理当天的任务。
• 按逻辑模块：把数据提取、转换、加载拆成不同DAG，用ExternalTaskSensor做跨DAG依赖。

目标是让每个DAG的任务数控制在1000-5000以内，这样调度器和UI都能轻松处理。

2. 用Task Groups替代SubDagOperator #

别用SubDagOperator！ 它已经被Airflow官方弃用（从2.x版本开始），而且存在诸多性能问题：

• SubDag会启动额外的调度器子进程，反而增加调度器负载。
• 调试和监控SubDag内的任务非常麻烦。

取而代之的是Task Groups，它能让你把相关任务分组展示在UI中，同时不会引入额外的性能开销，完全兼容现有任务依赖逻辑。

3. 优化调度器配置 #

你已经调整了部分参数，这里补充几个关键配置（修改airflow.cfg）：

• max_active_tasks_per_dag: 限制单个DAG的并发任务数，建议设为500-1000（根据集群资源调整），避免一个DAG占满所有调度资源。
• parsing_processes: 增加调度器的DAG解析进程数，比如设为4-8（对应CPU核心数的一半），加快DAG文件解析速度。
• dag_dir_list_interval: 调大DAG目录扫描间隔，比如从默认的300秒改为3600秒，减少调度器的重复扫描开销。
• scheduler_heartbeat_sec: 适当调大心跳间隔，比如从5秒改为10-15秒，降低调度器的心跳频率。
• 切换分布式执行器：如果还在用默认的SequentialExecutor，立刻换成CeleryExecutor或KubernetesExecutor：
  • CeleryExecutor：需要配置Redis/RabbitMQ作为消息队列，同时增加足够多的Celery Worker节点横向扩展。
  • KubernetesExecutor：适合云原生环境，能自动根据任务负载伸缩Pod，无需手动管理Worker。

4. 优化Web服务器配置 #

解决UI缓慢问题，重点调整Web服务器参数：

• workers: 增加Web服务器的worker进程数，建议设为4-6。
• worker_class: 使用异步worker，比如gevent，替换默认的sync模式，提升UI并发处理能力。
• web_server_worker_timeout: 调大超时时间，比如设为120秒，避免UI请求因处理慢被中断。
• 关闭不必要的UI功能：比如禁用DAG视图的自动刷新，或者在UI设置中限制显示的历史任务实例数量（比如只保留最近7天）。

5. 数据库优化（重中之重） #

Airflow的性能严重依赖后端数据库（禁止用SQLite，必须用PostgreSQL或MySQL）：

• 给数据库分配足够的CPU、内存和IO资源：10万任务会产生大量任务实例、日志和XCom数据，数据库IO很容易成为瓶颈。
• 定期清理历史数据：执行airflow db clean --clean-before-timestamp $(date -d "-30 days" +%Y-%m-%dT%H:%M:%S)清理30天前的任务实例、日志和XCom，减少数据库存储和查询压力。
• 添加索引：给task_instance表的dag_id、execution_date、state字段添加联合索引，加速UI和调度器的数据库查询。

6. 其他实用优化 #

• 启用DAG序列化：设置dag_serialization_enabled = True，将DAG元数据序列化到数据库，调度器无需每次解析DAG文件，大幅提升调度性能。
• 用Dynamic Task Mapping：如果你的任务是重复参数化的（比如处理10万条数据），用Airflow 2.3+支持的动态任务映射，比手动生成10万任务更高效，调度器处理更轻松。
• 简化DAG文件：不要在DAG文件中做耗时的计算或数据库查询，DAG会被调度器频繁解析，任何冗余操作都会拖慢调度器。

总结 #

你的核心问题是单DAG规模远超Airflow默认配置的处理能力，通过拆分DAG、切换分布式执行器、优化调度器和数据库配置、用Task Groups替代SubDag，完全可以解决调度器挂起和UI缓慢的问题。从小规模DAG开始验证优化效果，逐步推广到整个任务体系，会更稳妥。

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