4. 计算成本优化：资源弹性伸缩、任务调度优化、Shuffle优化、数据倾斜处理

计算成本，说白了就是你的作业跑起来花了多少钱。很多团队一上来就盯着存储砍，其实计算才是真正的吞金兽。我见过一个数仓，每天跑批要花掉好几万，结果一查，一半的资源都在空转。

这一章，我们聊聊怎么把计算成本降下来。核心就四个方向：资源弹性伸缩、任务调度优化、Shuffle优化、数据倾斜处理。每个方向都有实战经验，咱们一个一个说。

核心观点：计算成本优化的本质，是让每一份资源都产生价值。不是一味地砍资源，而是让资源在正确的时间、以正确的形态、服务于正确的任务。

4.1 资源弹性伸缩：别让资源等你，要让资源追着你跑

资源弹性伸缩，就是让集群的规模跟着业务量走。业务高峰期多开节点，低谷期缩回去。这个道理谁都懂，但落地的时候坑特别多。

我个人习惯把弹性策略分成两类：

  • 预测式弹性：基于历史规律，提前扩缩。比如每天凌晨2点是ETL高峰，那就提前30分钟把资源拉起来。
  • 反应式弹性：基于实时指标，动态调整。比如CPU使用率超过80%就扩容，低于30%就缩容。

我建议你优先用预测式弹性。为什么？因为反应式弹性有延迟。从触发扩容到节点就绪，少说也要3-5分钟。这期间作业可能已经排队了。

实战技巧：在YARN或Kubernetes上，可以设置一个"预热池"。比如预留20%的节点作为缓冲，平时跑低优先级任务。一旦需要扩容，直接把这部分节点提升优先级，秒级生效。

嗯，这里要注意一个细节：缩容的时候，别把正在跑任务的节点给缩了。我见过有人把缩容策略设得太激进，结果任务跑到一半，节点没了，整个作业失败重跑，反而更贵。

正确的做法是：先让节点进入"不可调度"状态，等上面的任务跑完，再回收节点。

4.2 任务调度优化：把时间轴上的资源利用率拉满

任务调度优化，说白了就是让不同的任务错峰跑，别挤在一起抢资源。你想想看，如果所有任务都在凌晨2点启动，那集群就得按峰值来配。但如果把它们分散开，集群规模就能降下来。

我总结了一套"三阶调度法"：

  1. 优先级分层：把任务分成P0、P1、P2三级。P0任务必须按时跑完，P1可以延迟，P2有空就跑。
  2. 时间窗口错峰：给每个任务分配一个"启动窗口"。比如P0任务在0:00-1:00启动，P1在1:00-2:00，P2在2:00之后。
  3. 动态资源分配：P0任务可以抢占P2的资源，但P2不能抢占P0。

这套方法我在一个日处理量10TB的平台上用过，效果很明显。集群规模没变，但任务完成率从85%提升到了99%。

优先级 任务类型 启动窗口 资源保障
P0 实时报表、核心ETL 0:00 - 1:00 独占50%资源
P1 离线分析、数据同步 1:00 - 2:00 共享30%资源
P2 历史归档、数据清理 2:00之后 使用剩余资源

避坑指南：我曾经把一个P2任务设成了"永远不超时"，结果它占着资源跑了三天三夜。后来我加了一个硬性限制：任何任务最多跑4小时，超时自动kill。这个规则救了我很多次。

4.3 Shuffle优化：别让数据在节点间"裸奔"

Shuffle，是Spark和MapReduce里最耗时的环节。数据要在节点间重新分区，涉及大量的网络传输和磁盘读写。优化得好，作业快一倍；优化得不好，作业直接挂掉。

我常用的Shuffle优化手段有这几个：

  • 减少Shuffle数据量：在Shuffle之前做一次过滤或聚合。比如先filter掉不需要的数据，再group by。
  • 调整Shuffle分区数：分区数太少，单个分区数据量太大，容易OOM；分区数太多，小文件太多，调度开销大。一般建议分区大小控制在200MB-1GB之间。
  • 使用广播变量：如果一个小表要join一个大表，把小表广播到每个节点上，避免Shuffle。
  • 开启Shuffle压缩：压缩Shuffle中间结果，减少网络传输。我一般用snappy或lz4，压缩和解压速度都快。

举个例子，一个join操作，如果两个表都很大，Shuffle的数据量可能是原始数据的2-3倍。但如果你先对每个表做一次聚合，把数据量降下来，Shuffle的压力就小很多。

-- 优化前：直接join
SELECT a.id, b.name
FROM table_a a
JOIN table_b b ON a.id = b.id

-- 优化后：先聚合再join
WITH a_agg AS (
  SELECT id, COUNT(*) AS cnt
  FROM table_a
  GROUP BY id
),
b_agg AS (
  SELECT id, MAX(name) AS name
  FROM table_b
  GROUP BY id
)
SELECT a_agg.id, b_agg.name
FROM a_agg
JOIN b_agg ON a_agg.id = b_agg.id

一个小技巧：在Spark里，可以设置spark.shuffle.file.buffer参数，增大Shuffle写缓冲区。默认是32KB，我一般调到64KB或128KB。这样能减少磁盘I/O次数，提升Shuffle速度。

4.4 数据倾斜处理：别让一个节点扛下所有

数据倾斜，就是某个分区的数据量特别大，其他分区很小。结果就是，一个节点累死，其他节点闲死。整个作业的进度，被最慢的那个节点拖死。

为什么会这样？最常见的原因是join或group by的key分布不均匀。比如按城市分组，北京的数据量是其他城市的100倍。

我处理数据倾斜，一般分三步走：

  1. 定位倾斜：看Spark UI或MapReduce的stage耗时。如果某个stage的某个task耗时特别长，大概率是倾斜了。
  2. 分析原因：看倾斜的key是什么。如果是某个热点key，比如"北京"，那就针对这个key做特殊处理。
  3. 对症下药：根据原因选择解决方案。

常用的解决方案有这些：

  • 加盐：给热点key加一个随机前缀，把数据分散到多个分区。处理完后再去掉前缀。
  • 两阶段聚合：先做一次局部聚合，再做一次全局聚合。这样能大幅减少Shuffle的数据量。
  • 调整并行度：增大分区数，让数据更分散。但要注意，分区数不是越大越好。
  • 使用Skew Join：Spark 3.0+支持自动检测和处理倾斜join。开启spark.sql.adaptive.skewJoin.enabled即可。

我记得有一次，一个join作业跑了2小时还没跑完。我一看，其中一个表有80%的数据key都是"null"。null值全分到了同一个分区。解决方案很简单：把null值替换成一个随机值，问题就解决了。

避坑指南：加盐的时候，注意随机前缀的粒度。太粗了，数据还是倾斜；太细了，分区数太多，反而增加调度开销。我一般控制在10-100个随机前缀之间。

4.5 本章小结：计算成本优化的核心逻辑

计算成本优化，不是一锤子买卖，而是一个持续迭代的过程。我建议你建立一个"成本监控-问题定位-优化实施-效果评估"的闭环。

最后，送你一张我总结的计算成本优化框架图。这张图涵盖了本章的所有核心知识点，你可以把它贴在工位上，每次做优化的时候看一眼。

计算成本优化框架图 计算成本优化框架 资源弹性伸缩 任务调度优化 Shuffle优化 数据倾斜处理 降低计算成本，提升资源利用率 实施手段：监控 → 定位 → 优化 → 评估（持续迭代） 预测式弹性 反应式弹性 预热池 优先级分层 时间窗口错峰 动态资源分配 减少Shuffle数据 调整分区数 广播变量/压缩 加盐/两阶段聚合 调整并行度 Skew Join 核心原则：让每一份资源都产生价值 不是一味砍资源，而是让资源在正确的时间、以正确的形态、服务于正确的任务

好了，这一章的内容就到这里。记住，计算成本优化没有银弹，只有持续地观察、分析、调整。希望这些经验能帮你少走一些弯路。

← 上一章 📖 返回目录 下一章 →