6.2 性能优化

6.2 性能优化

本节摘要：Airflow 变慢很少是因为 Python 函数少写了两行。更常见的是解析循环太重、Scheduler 与元数据库锁竞争、XCom 表膨胀、短任务在容器里付冷启动税。优化顺序是减账本与解析负担，再调并发，最后才加机器。盲目加大 Worker 会把外部系统先打挂。打挂之后的重试会变成自激。自激要用池和暂停拧住，不要再用重启加油。加油只会让更多 Worker 去打已经 5xx 的下游。下游需要的是限流，不是炮灰。

学习目标

阅读完本节，你应当能够：

1. 用四段生命周期定位延迟：解析、状态推演、排队、执行
2. 给出 XCom 与动态映射的体积与行数上限直觉
3. 解释短任务不适合一任务一 Pod 的成本结构
4. 用池和 max_active_runs 保护下游，而不是只追求高并发

一、先分段，再动手

原文把性能写成调度确定性与执行不确定性之间的契约。一次任务的墙钟时间包含：等到窗口、等到依赖、等到槽位、进程启动、真正计算、写回状态。只优化计算，可能只动了 10%。轻任务上冷启动能占很大比例——原文引用过生产统计里短作业冷启动占比很高的现象，用来提醒：执行器选型本身就是性能决策。

解析：文件多、顶层 IO、动态生成复杂图，会拉高每次扫描成本。表现是调度心跳变老、新窗口创建推迟，任务函数其实很快。对策：拆文件、禁顶层 IO、限制工厂规模、序列化 DAG 减少重复解析负担（按你使用的版本启用官方推荐的序列化，不编造开关名）。

状态推演：Scheduler 要问依赖、规则、池。实例行数乘深度。映射把行数放大。库里 task_instance 表无维护、索引缺失、XCom 联查，会把循环变成 SQL 展览。对策：定期清理旧运行、限制保留天数、XCom 不进大对象、映射有上限。

二、并发旋钮会反噬

max_active_runs、max_active_tasks、池大小、Worker 数，四个数字要匹配最弱的下游。只加大 Airflow 并发，数仓连接先尽。性能优化包含故意限速。回填单独池，避免和日报抢。

Celery 预取过大，Worker 会囤积任务然后死掉造成大量幽灵。预取调小，让失败更快回到队列。K8s 短任务合并：把五个五秒任务合成一个函数，或改回常驻 Worker。

数据库：连接泄漏来自 Hook 未关闭、回调里查库。给库足够的规格，但先用查询看是不是全表扫 XCom。清理策略要先于加盘。

图 优化顺序不要颠倒

三、可延迟、下推、测量

可延迟把等待移出 Worker，提高槽位利用率，这是性能工具不只是高级调度玩具。计算下推：Spark 作业一次提交，不要把行循环写成几千个 Python 任务。Airflow 擅长编排，不擅长成为计算引擎。

测量：给关键 DAG 记录从窗口闭合到成功的时长，画占比相对 schedule。靠近 1 就是时序债务。不要用平均值掩盖长尾，看分位。

⚠️ 常见坑：把 parallelism 调到极大，数据库 max_connections 被占光，连 UI 登录都失败，于是所有人开始重启，雪上加霜。
💡 关键直觉：性能是配额艺术。先决定谁准快，再决定机器数。

清理：过期日志、过期 Run。保留期按合规，不是无限。无限历史会把“可审计”变成“不可查询”。

版本升级带来的调度器改进（更聪明的查询、更好的序列化）值得跟，但不要把升级当当天的救火手段。救火先限流、清 XCom、停回填。

四、一次变慢投诉的记录模板

记录：哪个 dag_id、哪个窗口、从闭合到成功多久、Local 对照多久、当时 queued 多久、解析心跳年龄、库锁等待、XCom 大小、是否回填高峰、执行器类型。没有对照时间的投诉，先补测再优化。有对照且 Local 也慢，去看 SQL 与外部 API。有对照且只有集群慢，去看镜像、槽位、队列。模板迫使分段，分段才能避免“优化”成加机器。

保留期：运行历史与日志按合规留 N 天，过期清理。清理本身用低优先级，避开业务高峰，监控清理是否追上写入。留太久不是更可审计，是查询变慢到无法审计。XCom 尤其要短，对象存储里的业务数据按数据生命周期管，不要跟调度账本绑死。

parallelism 一类全局上限是保险丝。调大前看数据库 max_connections 与下游限流。保险丝不是性能旋钮，是保护。把保险丝调到最大，等于宣布不要保护。池才是按类限流的旋钮。全局上限应略高于所有池之和的合理值，留下余量给调度自己的查询。

测量时序债务：关键 DAG 每天把时长占比写入指标。连续超阈进入性能债列表，与功能需求一起排期。不进列表的“感觉慢”不排期。性能优化没有债列表，就会永远让给新 DAG。

问题：序列化 DAG 开了是不是解析就不再是问题？

会减轻重复解析，但顶层副作用在第一次解析仍会执行，文件数量仍影响处理器。序列化不是许可证。仍然禁顶层 IO，仍然限制工厂。把它当加速，不当豁免。

问题：短任务合并会不会让失败粒度变粗？

会。这是明确的取舍：付更少冷启动税，付出失败要重跑一小段胶水。对无副作用或强幂等的五秒级任务，合并划算。对昂贵外部写操作，保持分离并接受税，或改常驻 Worker。用数字比：税占墙钟百分之四十就该认真讨论合并，占百分之二就别折腾。

五、回填期间的性能隔离清单

回填前：确认在线池与回填池分开、非关键 DAG 可暂停、XCom 清理追上、数据库有余量、下游限流已知。回填中：盯锁等待与关键 DAG 时长占比，超阈立刻拧回填并发。回填后：看 XCom 与日志盘是否留下尖峰，补清理。把回填当性能实验可以，当无计划的三年全量不可以。原文统计里锁竞争是大规模延迟主因，回填是主动制造大规模的行为。隔离清单是对调度器的礼貌，也是对在线 SLA 的合同。礼貌写进操作单，不写进感想。没有清单的回填，等于用生产集群做压测还不告诉值班。

六、对照实验记录格式

日期、dag_id、窗口、执行器、入队等待、执行时长、重试次数、镜像大小或 Worker 版本、备注。一张表用到来年。没有表，口耳相传的“K8s 慢”无法证伪。证伪能力是性能工作的科学部分。优化建议必须指向表里的某一列。指向不了列的建议，是感受。感受可以听，不能排期。排期只接受列。列会随形态切换而增加，例如加上 Pod 调度等待。增加列时不要丢掉 Local 基线列。基线是所有新列的减法对象。减法得到税。税大于收益，回退形态或合并短任务。回退不是丢脸。丢脸的是没有表还在加机器。加机器会让表更难解释，因为同时变了太多列。一次只变执行器或只变池，是 4.1 说的二分。性能章把二分用在延迟上。延迟比可用性更需要二分，因为它不是 0 或 1，谎言更顺滑。

七、一次只变一列

对照表有多列。优化实验一次只改执行器或只改池或只改是否 deferrable。多列同变，无法归因。无法归因的优化会变成巫术。巫术会进周会。周会会通过加机器。加机器会再变一列。列越来越多，表越来越不能减法。不能减法就失去科学。科学是 6.2 相对感觉的优势。优势要靠一次一列保护。保护写进实验纪律。纪律比算法重要。算法再好，同变三列，也说不清。说不清就不能进债列表的“已还”状态。不能已还，债会重复还。重复还是浪费。浪费来自不二分。二分在 4.1 对变更说，在 6.2 对延迟说。延迟更需要二分，因为它连续。连续的谎言更顺滑。顺滑要用一次一列打断。打断后，税才看得见。看得见才能决定合并短任务或回退形态。回退不是丢脸。丢脸是巫术。巫术在没有表的口耳相传里。口耳相传在本节被对照表替代。替代要执行。执行是每次优化附一张只变一列的表行。表行进记录。记录进周会。周会只接受表行。不接受感受。感受可以会下说。会下说不算排期。排期只认列。列来自一次一列。一次一列结束本节的科学部分。科学部分结束 6.2 的牙齿。牙齿咬住加机器的手。手要先减负担。负担在解析与 XCom。XCom 在 2.3。解析在 3.3。6.2 把它们连成顺序。顺序一次走一刀。一刀一列。一列一结论。结论才还债。还债才算优化。优化结束。加机器若仍需要，那时才是奖励。奖励给做完减法并且一次一列证明过的人。人在记录上。记录在表里。表在本节。本节让表成为唯一语言。语言结束感觉。感觉结束加错层。错层结束。性能开始成为纪律。纪律结束 6.2。

八、周会只收表行

优化建议不带对照表行，不排期。不排期不是冷淡，是科学。科学结束巫术进周会。巫术结束加机器。加机器结束无法减法的表。表结束于一次一列。一次一列结束多列同变。同变结束无法归因。无法归因结束重复还债。重复结束浪费。浪费结束不二分。二分结束谎言顺滑。顺滑结束感受排期。感受会下说。会下结束。会内只认列。列结束 6.2 的语言。语言结束感觉。感觉结束加错层。错层结束。减法在前。前结束奖励。奖励结束最后加机器。机器结束于证明过的人。人在记录。记录在表。表在周会。周会结束本节的执行面。执行面结束科学部分的落地。落地结束 6.2。

九、基线列禁止删除

对照表可以加列，不许删 Local 秒数。删除结束减法。减法结束税。税结束科学。科学结束于基线仍在。仍在结束本节。本节结束。

要点串联

• 延迟要分段：解析、推演、排队、执行、冷启动
• XCom 与实例行数直接打库
• 并发数字对齐最弱下游
• 短任务避免容器税，用对照测量
• 可延迟与下推计算是正道
• 加机器放在减负担之后

下一节把这些约束写成测试与 CI，让违规进不了生产目录。