Spark 性能调优之 Shuffle Partition Number

在工作中，我的团队遇到了一个问题，某些 Spark Jobs 的运行时间远远超过了 SLA（Service-Level Agreement，即与用户约定好的服务协议）。因此，我们需要找出这些 Spark Jobs 速度慢的原因并进行修复。

具体修复流程如下：

1. 查看历史数据，判断这是长期问题还是短期偶尔的性能问题。结论是长期存在的问题。
2. 访问 Spark Job 主页，观察到底是哪一部分成为了瓶颈（Bottleneck）。结论是 Evaluation 部分耗时最长，其他部分如读取数据、Shuffle 数据和写入数据都还算正常。
3. 深入 Evaluation Stage，查看所有的 Task，观察具体问题。结论是 Shuffle Read Data Size 达到 2.2GB，远大于预期的 150MB - 200MB。过多的数据无法全部存储在 executor 的内存里，因此部分数据需要写入硬盘。于是我们看到 Memory Spill 和 Disk Spill 都有很大的值。这两个值表示相同的数据，但 Memory Spill 通常比 Disk Spill 大很多，因为数据在内存中是反序列化的，需要更大的存储空间。
4. 解决办法是将每个 Task 拆分成更多的小 Task，使 executor 可以将数据全部存储在内存中，从而极大地加快计算速度。最后我将 Shuffle Partition Number 提高了12倍（12 ~= 2.2GB / (150MB 到 200MB)）。这样每个 Task 处理的数据量是原来的十二分之一。

通过这种方式，我们成功地优化了 Spark Jobs 的性能，确保其运行时间在 SLA 之内。