任务依赖与 DAG 优化：DAG 设计原则、并行度控制、关键路径识别与优化

聊到数据湖的任务调度，DAG（有向无环图）是绕不开的核心概念。说白了，你的任务编排好不好，直接决定了整个 pipeline 是跑得飞起还是卡成 PPT。我见过太多团队，明明资源给够了，但调度效率就是上不去——问题往往就出在 DAG 的设计上。

DAG 设计原则：别让依赖变成死结

先说说 DAG 的设计原则。很多人一上来就画图，画着画着就成了一团乱麻。我个人习惯，设计 DAG 之前先问自己三个问题：

• 这个任务真的需要依赖前一个任务吗？
• 能不能拆成更小的独立单元？
• 如果某个节点挂了，影响面有多大？

我在项目中遇到过这样一个案例：某团队把数据清洗、聚合、写入全部塞进一个节点，结果每次重跑都要从头来。后来我建议他们把清洗和聚合拆成两个独立节点，中间用临时表衔接。这样一来，清洗成功但聚合失败时，只需要重跑聚合节点就行——节省了将近 40% 的重跑时间。

并行度控制：不是越多越好

并行度控制是个技术活。你想想看，把并行度调高，资源占用就上去了；调低了，任务又跑得慢。这里有个常见的误区：很多人以为并行度等于并发数，其实不是。

并行度指的是一个任务内部能同时处理的数据分片数。而并发数，是调度系统同时运行的任务数。这两个概念搞混了，资源分配就容易出问题。

参数	含义	控制粒度	常见问题
并行度	单个任务内部的分片数	任务级别	分片过多导致小文件爆炸
并发数	同时运行的任务数量	调度系统级别	并发过高导致资源争抢
槽位数	每个节点能同时处理的任务数	计算引擎级别	槽位不足导致任务排队

我曾经在一个实时数仓项目里，把并行度从 10 调到 50，结果任务反而变慢了。为什么？因为分片太多，每个分片的数据量太小，调度和通信的开销反而超过了计算本身。后来我根据数据量动态计算并行度——每 100MB 数据分配一个分片，效果立竿见影。

关键路径识别：找到瓶颈，一击即中

关键路径，就是 DAG 中耗时最长的那个路径。它决定了整个 pipeline 的最短完成时间。你优化非关键路径上的节点，对整体耗时几乎没有影响——说白了，力气要用在刀刃上。

怎么识别关键路径？我一般用两种方法：

1. 正向计算最早开始时间：从起点开始，每个节点的最早开始时间等于所有前置节点完成时间的最大值。
2. 反向计算最晚开始时间：从终点开始，每个节点的最晚开始时间等于所有后置节点开始时间的最小值减去自身耗时。

关键路径上的节点，最早开始时间和最晚开始时间相等——它们一点都不能耽误。

下面这张图展示了一个典型的 DAG 关键路径：

关键路径优化：从理论到实战

识别出关键路径之后，怎么优化？我总结了四个方向：

• 拆分长节点：如果关键路径上有个节点耗时特别长，看看能不能拆成多个子节点并行执行。比如一个全量数据聚合，可以按时间分区拆成多个小聚合，最后再合并。
• 调整依赖关系：有些依赖其实是可以松绑的。我记得有个案例，A 任务需要 B 任务的 80% 数据就能开始，但设计者非要等 100%。后来改成 80% 触发，整体耗时缩短了 15%。
• 资源倾斜：给关键路径上的节点分配更多资源。比如在 YARN 或 Kubernetes 里，给关键节点设置更高的优先级或更多的 CPU/内存配额。
• 缓存中间结果：如果关键路径上的某个节点经常被重跑，把它的输出结果缓存起来。下次重跑时直接复用，不用重新计算。

DAG 优化的常见陷阱

嗯，这里要提醒几个容易踩的坑：

• 过度拆分：节点拆得太细，调度开销反而超过计算收益。一般来说，单个节点的处理时间不要低于 10 秒。
• 忽略数据倾斜：并行度调高了，但如果数据分布不均匀，大部分分片很快跑完，少数分片卡在那里——这就是数据倾斜。我一般用 Salting 或重新分区来解决。
• 依赖链过长：有些 DAG 的依赖深度达到十几层，任何一个节点出问题都会导致大面积重跑。建议控制依赖深度在 5 层以内，超过的考虑用事件驱动或消息队列解耦。

最后说一句：DAG 优化不是一锤子买卖。业务数据在变，资源环境在变，你的 DAG 也需要持续调整。我每个季度都会 review 一次关键路径，看看有没有新的瓶颈出现。毕竟，性能调优这件事，永远在路上。