为了理解 MapReduce 克制使用内存、细粒度重试的设计原因，我们需要回顾下 MapReduce 的诞生历程 。当时谷歌内部的数据中心很多都是共享使用的——集群中的同一个机器上，既有在线的生产服务，也有离线的批处理任务 。每个任务使用容器（虚拟化）的方式进行（CPU、RAM、Disk Space）资源预留 。不同任务之间存在优先级，如果某个高优先级的任务需要更多资源，则该任务所在机器上的低优先级任务可能就会被干掉以让出资源 。当然，优先级是和计算资源的价格挂钩的：团队需要为用到的资源付费，高优先级的资源要更贵 。
这种架构设计的好处是，可以面向非线上服务超发（overcommitted）资源（这也是云计算赚钱的理由之一） 。因为系统通过优先级跟用户约定了，在必要时这些超发的资源都可以被回收 。相比在线离线服务分开部署，这种混合部署、超发资源的方式能够更加充分的利用机器资源 。当然代价就是，以低优先级运行的 MapReduce 的任务可能会随时被抢占 。通过这种方式，批处理任务能够充分地利用在线任务等高优先级任务留下的资源碎片 。
统计来说，在谷歌当时集群中，为了让位给高优先级任务，持续一小时左右 MapReduce 子任务大约有 5% 的概率被中止 。这个概率大概比由于硬件问题、机器重启和其他原因造成的子任务重启要高一个数量级 。在这种抢占率下，对于一个包含 100 个子任务、每个子任务持续 10 分钟的 MapReduce 任务来说，在运行过程中，有超过一半的概率会发生至少一个子任务被中止 。
这就是为什么 MapReduce 面向频繁异常中止设计的原因：不是为了解决硬件的故障问题，而是给了系统随意中止子任务的自由，进而在总体上提高计算集群的资源利用率 。
但在开源的集群调度系统中，可抢占调度并不普遍 。YARN 的 CapacityScheduler 支持抢占以在不同队列间进行资源的均衡，但到本书写作时，YARN、Mesos、Kube.NETes 都不支持更为通用的按优先级抢占调度 。在抢占不频繁的系统中，MapReduce 这种设计取舍就不太有价值了 。在下一节 ， 我们会考察一些做出不同取舍的 MapReduce 的替代品 。
参考资料[1]DDIA 读书分享会: https://ddia.qtmuniao.com/
推荐阅读
- 使用旧域名创建新站点获取快速收录和排名的实践心得
- 办公风水技巧
- 为什么我每天睡够了8小时,黑眼圈和眼袋还是很重啊?
- 怎么区分土鸡蛋和饲料蛋，粮食鸡蛋和饲料鸡蛋的区别
- 防爆单反相机和防爆卡片相机有哪些区别呢
- 杨紫琼办婚宴，吕克贝松和何超琼到场，85岁母亲看着比女婿还年轻
- excel表格如何设置自动和
- “四川火锅”和“重庆火锅”区别大！别再以为是同一种了
- 如若一个女人和你分享这四种私人话题，暗示她已经爱上你了
- 57岁叶子楣复出！和男友未婚没有遗产，粉丝合影要红包