漫谈分布式系统(16) -- 搞定 worker 的性能问题

---

这是《漫谈分布式系统》系列的第 16 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。  

MapReduce 的性能问题

上一篇，我们提到，分布式系统中，经常存在中心化的角色，随着集群规模的扩大，这些中心化的角色会达到性能瓶颈，使得系统不能持续横向扩展下去。

然后，我们通过 Federation 等方法解决了这些中心化的 master 的性能问题。

但这不由得提醒我们，除了 master 外，slave/worker 是不是也可能出现性能问题呢？哪怕算不上瓶颈，是不是还有性能提升的空间？

再次检视下我们之前提到最多的 HDFS 和 MapReduce，从架构上看，作为 master 的 NameNode 和 ResourceManager 也能扩展后，作为 slave/worker 的 DataNode 和 NodeManager 本来就能稳定横向扩展。至少架构上没有明显的性能瓶颈了。

架构太粗粒度，再从执行过程上看看，细粒度的个体会不会有性能问题。

下图是 MapReduce 的执行过程。

联想到我们在传统的 web 和数据库领域，经常排查分析后，得出的性能瓶颈大都在 IO 上。我们也重点关注下 MR 过程中的 IO 操作。

大致有这么几步涉及 IO：

• map 阶段，读取文件数据给 map function 处理，处理结果写到一个环形缓存，达到阈值后会以分区为单位拆分、排序，再 spill to disk。这里涉及磁盘 IO。

• map 阶段的每次 spill 操作都会产生一个文件，所以最后会通过几轮的 merge，来保证最后每个分区只有一个排序好的文件。这里涉及磁盘 IO。

• shuffle 阶段，需要从各个 mapper 把对应数据 copy 到对应 reducer。这里涉及网络 IO。

• 如果从 mapper 读到的数据很小，就会先放到缓存，达到阈值后再 merge 然后 spill to disk；如果从 mapper 读到的数据很大，就会直接存到磁盘。这里涉及磁盘 IO。

• reducer 从 mapper copy 数据的同时，会有独立的线程持续对拿到的数据做 merge。最后一轮 merge 做完后，把结果交给 reduce function 处理。这里涉及磁盘 IO。

程序执行时间往往都大量消耗在这些 IO 操作上，尤其是磁盘 IO，非常拖累性能。

MapReduce 框架想了很多办法来优化性能，比如对 map input 做 merge 和 split，比如 combiner，比如启用对 map output 的压缩等等。

但无论怎么优化，仍然会有大量的 IO 操作，尤其是磁盘 IO 操作。

另一方面，MapReduce 的编程模型比较简单和死板，稍微复杂点的处理逻辑，就需要多个 MR 任务顺序执行。比如，经典的 Word Count 例子可以算出每个单词出现的次数，但想要知道出现次数最多的单词，就需要再起一个 MR 任务了。

这样一来，一个业务逻辑被硬生生拆成一个个 MR 任务组成 workflow，每个 MR 任务都以前任的 output 作为 input，自己的 output 也将成为后继者的 input。这无疑又大大增加了 IO 操作，进一步拖累了性能。

于是，逐渐有了跳出 MapReduce 去解决问题的想法。

想统治计算世界的 Spark

怎么减轻磁盘 IO 对性能的拖累？放内存啊！几乎是脱口而出吧，在传统架构里随处可见的缓存，已经给了我们足够多的经验。

Apache Spark 最初正是打着「基于内存」的旗号，迅速赢得了口碑，并得到大量应用。