添加count动作后Spark CDC合并作业运行速度大幅提升的原因是什么？

• DAG执行计划拆分优化
  原作业无中间action时，所有逻辑会被拼接成一个超大DAG，Catalyst优化器处理复杂DAG时容易生成冗余执行路径，比如不必要的嵌套shuffle、重复扫描大表，甚至错误触发笛卡尔积计算。新增的count(*)相当于把大DAG切割为多个独立的小执行段，每个阶段的逻辑更简单，优化器可以生成更精准的最优执行计划，抵消了count本身的执行开销。
• 高负载集群下的内存释放收益
  你提到集群长期处于高负载状态，原单一大作业会持续持有所有中间计算结果的内存占用，直到作业全部结束才释放，很容易触发内存溢写磁盘，甚至和其他运行中的作业争抢资源导致频繁Full GC。每个count执行完成后，对应阶段的非复用中间数据会被Spark自动回收，大幅降低作业生命周期的内存峰值，减少GC耗时和资源争抢等待时间，这个收益在高负载场景下远高于count算子的开销。
• shuffle IO开销降低
  无中间action的大作业跨多个shuffle阶段时，前序阶段生成的shuffle数据可能因为后续stage等待资源时间过长，被节点shuffle清理机制误删，或者已经被交换到远端磁盘，后续阶段拉取数据需要跨节点走网络IO。拆分执行后每个阶段的shuffle数据生成后会被立刻消费，大概率还保留在内存或者本地磁盘，无需跨节点拉取，大幅降低shuffle的网络和磁盘IO开销。
• 广播join的正确触发
  你用到的100万条服务商表、400万条会员表的大小均符合Spark默认的广播join阈值，但原大DAG中join逻辑嵌套在多层算子之后时，优化器无法精准判断关联表的实际大小，会默认走开销更高的shuffle join。count执行后会精准统计每个阶段的数据集大小，优化器可以正确识别小表，自动触发广播join，避免了大量不必要的shuffle操作。

注意：这是高负载集群、复杂DAG场景下的特例，不符合通用Spark优化规范。如果集群负载正常、作业逻辑简单，新增不必要的action仍然会带来额外的执行开销，不建议作为常规优化手段使用。

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