二次学习（节外生枝篇）一、初探Hadoop（4）

blovekyo

　　回忆一下Google的计算环境，由很多廉价的机器组成的集群，硬件不可靠，网络带宽一般。前面我们介绍了MapReduce的并行计算模型，但是，针对特定的计算环境，仍然有一些设计上的问题要考虑。
　　首先必须考虑机器故障的容错处理。主要有两种故障，一种是运行worker程序的机器发生故障，一种是运行master程序的机器发生故障。在google的计算环境中，只有一个master，相对来说，worker的故障要常见得多。
　　要应对worker的故障，需要master的帮助。所以，我们先来看看master上维护的几个数据结构。在master上的数据结构中，保存了每一个map和reduce任务的状态（空闲，处理中，已完成），以及worker（对于非空闲的任务状态）的标识。
　　master就像map任务与reduce任务之间的一个管道，它传递中间文件区块的位置（从map到reduce），因此，对于每一个完成的map任务，master会保存由这个map任务产生的R个中间文件区域块的位置和大小。当map任务完成时，master会接收到对位置和大小信息的更新。然后，这个信息被master增量推到正在进行reduce任务（状态是处理中）的worker上去。
　　那么，如果worker发生故障怎么办？为了解决这个问题，master会定期ping每一个 worker机器（包括处理map或reduce的机器）。如果在一定的时间内没有响应，master就认为这个worker失效了。这个worker完成的map任务（状态是已完成）的状态被复位成空闲。而这些被复位的map任务又被master调度给其他的worker。类似的，正在处理的map任务和reduce任务 （状态是处理中，注意，这里包含reduce任务了），也被复位成空闲，然后重新调度。
　　已经完成的map任务也要被重新执行，其原因是中间结果被存放在这台失效的wroker机器上，这些中间结果无法被使用了。而已经完成的reduce任务不需要被重新执行，因为其结果被保存在了全局的文件系统 上了。这个全局的文件系统是怎么回事，要等待后续的学习（看看hadoop的实现）去了解了。
　　这里还有一个通知的机制。当原来在workerA上做map任务，后来workerA失败了，转到workerB上去做map任务，中间结果的位置信息发生了变化，所有执行reduce任务的worker都会得到通知，那些还没来得及从workerA上读取数据的reduce worker会从workerB上去读取。蛮有兴趣看看这个机制的实现细节。
　　那么，如果master发生故障了怎么办？解决方案很简单，master会把上面介绍的数据结构写入周期性的checkpoint中，如果master机器失效了，会从最后一次checkpoint开始启动一个新的进程。不过，由于目前的计算模型中，只有一个master，所以，当前的实现是退出mapreduce计算。客户端可以检测到这个问题，如果愿意，它们可以再次尝试mapreduce操作。
　　容错处理对用户来说是透明的，mapreduce计算模型通过对map任务和reduce任务的输出结果进行原子提交来做到这一点，也就是说，在计算环境中一些机器发生了故障，可是在用户看来，就像从来没有故障发生过。原子提交是怎么回事呢？
　　每一个正在处理中的任务（map任务或reduce任务）都会把输出结果写到私有的临时文件中，一个Reduce任务会产生一个这样的文件，而一个map任务产生R个这样的文件。当一个map任务完成后，worker会发送一个消息给master，这个消息中包含了R个临时文件的名字。如果master收到了一个已经完成的map任务发出的完成消息，它会忽略这个消息（因为已经处理过了。为什么还会再次发出？ ），否则，它会把R个文件的名字，记入master的数据结构中去。
　　当一个reduce任务完成了，reduce worker会自动地把它的临时输出文件改名为正式的输出文件。如果一个相同的reduce任务在多个机器上执行，就会为相同的正式输出文件执行多次更名调用。他们通过底层的文件系统提供的原子化的更名操作，来保证正式文件系统的状态仅仅包含这次reduce任务执行产生的数据。（需要再次理解和验证）
　　在mapreduce计算模型的语义中，map和reduce操作大多是确定性的（确定性的意思是，在任何时候，确定的输入总是得到确定的结果 ），在这种情况下，map和reduce操作在并发执行和顺序执行是等同的（结果一致）。在非确定性的情况下，这种计算模型也提供了一个稍弱一些的语义。
　　这个稍弱一些的语义是，特定reduce任务R1的输出，与 【非确定性程序经顺序执行产生的R1】 的输出是等价的，而另一个reduce任务R2的输出，可能与 【这个非确定性程序经另一个顺序执行产生的R2】 的输出是对应的。
　　我的理解，语义是一种约束性的逻辑。在满足这个逻辑的基础上，或者说，前提下，我们来考虑实现。
　　关于这个稍弱的语义，来看个例子。现在有map任务M和reduce任务R1和R2。假设，e(Ri )是已经提交的Ri 的执行（有且仅有一个这样的执行）。当e（R1）读取的是M的一次执行产生的输出，而e（R2）读取的是M的另一次执行产生的输出，这时候，稍弱的语义就成立了。