MapReduce针对频繁故障设计：源于Google混合数据中心的抢占式调度

MPP数据库遇到节点崩溃通常直接中止整个查询、让用户重新提交（因为查询本就只跑几秒到几分钟，重试代价不大，所以更愿意把数据尽量留在内存里、避免磁盘开销），MapReduce却反过来：容忍单个Map/Reduce任务失败而不影响整个作业，而且会更急切地把数据落盘。这个设计差异表面看是”作业越大、越可能中途出故障、粒度越细的重试就越划算”，但书中给出了更具体的历史原因：MapReduce最初设计时，Google的数据中心里在线生产服务和离线批处理作业混跑在同一批机器上，每个任务都有资源配给和优先级，优先级更高的任务可以随时抢占（终止）同机器上低优先级的任务以腾资源——这种”过量使用”策略能显著提高机器利用率，但代价是低优先级的MapReduce作业随时可能被打断，只能”捡面包屑”利用剩余资源。实测数据显示，谷歌里运行一小时的MapReduce任务大约有5%概率被为了让位高优先级进程而终止，这个概率比硬件故障高出一个数量级；按此计算，一个由100个10分钟任务组成的作业，至少有一个任务在完成前被终止的概率超过50%。也就是说，MapReduce对频繁故障的容忍设计，根源不是硬件不可靠，而是”随意终止低优先级进程”本身就是提高集群利用率的手段——这个假设在不支持通用优先级抢占的开源调度器（YARN/Mesos/Kubernetes）环境里就没那么必要了。