5分钟深入 Hadoop 容错

通过之前几篇文章，我们对 Hadoop 的工作原理有了基本的了解，并且通过学习优化 Hadoop 性能，更深入的体会 Hadoop 处理数据的机制。今天我们聊聊另一个重要的话题：容错。

Why fault tolerant is necessary？

在公司内开发过分布式系统的朋友应该比较熟悉，在实践中，我们除了要实现业务的应用逻辑，并且提高系统性能之外，还要经常处理机器出错的问题。尤其是亚麻工作过的朋友，应该不少有半夜爬起来发现某机器 ping 不到，或者内存／硬盘爆掉的经验。

我们当今已经进入大数据时代，无论你使用什么 framework 处理海量数据，都要应用大量机器，处理复杂问题。机器数量越多，工作负荷越大，机器硬件就越容易出现问题；处理问题越复杂，机器出现故障对数据处理流程造成的负面影响就越大。

举个栗子

举此 Hadoop 系列一直使用的 word count 的实例为例：

我们假设在 Mapping 阶段，第二号机器（包括 Car Car River 的机器）出现故障（断电，网络故障等），无法与机器集群中其他机器联系。如果不对这个故障进行处理（怎么处理我们稍后便说），那么这个故障就会造成最终 word count 结果不对：Car 少了2个 count，River 少了一个。

这仅仅是一个最简单的例子啊，想想 Google 为了建立搜索索引要完成 web crawling，indexing，ranking 等工作，要用到几十到上百的 Hadoop job，如果某一些机器出错，那整个数据处理流程的结果就有问题。

此外，完成这些工作要使用上万台机器，引用我们在 HDFS 那篇文章里引用的机器故障率，这些机器出问题的概率和次数也大的吓人。所以任何数据处理架构必须有良好的容错机制！

什么是容错？

面对机器集群中出现机器故障的问题，我们有如下解决办法：

• 打电话骂硬件厂商
• 把运算重新算一次
• 手动把故障机器的运算搬到其他机器，并让运算使用你的修改结果
• 在数据处理架构中加入自动容错机制

有点开玩笑的意思哈？其实小编觉得在特定情况下4个都有必要：

• 你们订购的硬件／数据中心老出故障时，该换硬件／数据中心了；
• 真的可以，但你要盼望硬件不会再出问题，而且再次运算后可以赶上你需要数据的期限；
• 这就是容错的本质内容，但是手动调节（一天的 job，一年的，一辈子的……）太累了……
• 这才是业界说的容错！也是你拿到工作和升职的技能！

具体说来，以上面 word count 为例，如果那个 mapper function fail 了，那 Hadoop 可以自动检测到这个 function fail 的情况，重新算一次这个 function（而不是整个job），或者在另一台机器上重新算一次，然后使用新结果继续整个 job 的运算。

Hadoop如何做到容错？

Hadoop 容错的核心就是我们在《5分钟深入Hadoop内核》中介绍的心跳机制。这些心跳消息从 TaskTracker 发到 JobTracker；当 JobTracker 收到这些心跳以后，返还给 TaskTracker 一些回复，这些回复里包括一些命令，比如开始或结束一个 mapper／reducer 任务，或者让 TaskTracker 重启。

我们具体的看看 Hadoop 集群有可能有哪些故障，以及这些故障是如何一条一条被解决的。

运行 TaskTracker 的机器无法被别的机器联系

造成这种问题有可能是那台机器电源有问题，或者网络彻底断了。

这会造成 JobTracker 不能从这台机器收到心跳信息，如果超过一定时间（这是一个可以配置的值），JobTracker 就认为这台机器出现问题。那么 JobTracker 就把所有的本来要安排在那台机器上的所有任务转移到一台健康的机器上。即使在那台机器上已经完成了一些 mapper tasks，也要在别的机器上重新计算那些任务，因为出错机器上的中间结果（spill file）无法被读取。

TaskTracker 运行任务失败了

注意这个和机器本身出错是不同的。这里机器依然可以和 JobTracker 联系，只是运行的任务失败了。

造成的原因有可能是：

• 用户写的 mapper／reducer tasks 里有bug；
• 这台机器的网路暂时有问题造成任务失败，而不影响心跳消息的发布；
• 机器部分故障，比如硬盘写 spill file 有故障；

无论哪种情况，mapper／reducer function 都 throw 一个 unchecked exception 给 TaskTracker.

这种情况下，JobTracker 会尝试重新运行这个任务，叫做 TaskAttempt. 实际上，当任务第一次运行时，JobTracker 也会给这个任务分配一个 AttemptID；如果任务成功，那这个任务一个 attempt 就完成了运算；如果不成功，会有更多的 attempt 去计算。当失败的 attempt 超过一个界限（可以配置），那整个 Job 就 fail 了。

这种情况 Hadoop 就没办法容错了，因为错误不是硬件的问题，而很有可能是用户代码本身的问题。

TaskTracker的任务运行了好久啊

这种情况没有 trhow exception，但是 Task 运行了好久好久…… 有可能是 mapper function 的进程挂了…… 但是我们又不敢大胆的 kill 掉这个 task，因为不能排除这个任务真的很大，或者网络状况不好，导致任务里的代码运行的比较慢。

为了真正清楚的监视任务的进程，Hadoop 设计了一个 task report 机制。当 TaskTracker 需要运行一个任务时，它会创建一个新的进程运行用户写的任务代码。

TaskTracker 本身在一个进程中运行，现在创建一个新的，就是考虑到如果用户的代码有问题，不应影响 TaskTracker 自身运行。用户的代码，真的有可能有很多问题啊！

新进程称为 TaskInstance，它会负责 invoke mapper／reducer function （还记得我们说过 mapper／reducer 都是用户写的类，而不是让用户自己运行一个进程，这个 TaskInstance 就是负责运行用户类的的，也是 Hadoop Framework 的一部分）。那么这个 TaskInstance 会不断报给 TaskTracker 任务的运行进程。

那一个任务是挂了还是运行的慢需要等就看这个报告中的百分比了，如果长时间（可以配置）都没有进展，那么就宣告这个任务挂了，JobTracker 要杀掉这个正在运行的任务，并重新运行一下。

Hadoop 说，我们永远可以做得更好

那有的机器就是慢怎么办？明明我们通过输入优化平均了每个任务的负担，就是这几台机器慢，比别人时间长，我们就干等着？

Hadoop 有个机制叫 Speculative execution. 当绝大多数任务运行完了的时候，Hadoop 会复制还在运行的任务到其他空闲机器上，和正在运行的机器来个比赛。注意，复制的任务是一模一样的，输入和代码都一样，只有这样才能保证不会搞乱整个 job。无论哪个机器先完成这个任务，它的结果就被使用了，其他的机器上的任务就被杀掉了。

Single Point of Failure

到这里，我们一直在说 TaskTracker 的容错，可 JobTracker 也没有什么运气永远不出问题，而且是个 single point of failure：如果 JobTracker 挂了，无论是机器问题，还是它自己进程的问题，都无药可救……现在有很多研究提出了解决方案，有时间我们可以再一步学习。

结语

好了，到这里，我们终于把 Hadoop Framework 做个全面深入的介绍（公共号内回复“Hadoop” 查看全部六篇系列文章）。

话说高效并行处理海量数据，这里面的门道可真不少。好在 Hadoop 前辈已经帮我们解决了大部分常见问题，我们只需要处理业务逻辑，如果没了 Hadoop 让我们自己从头写起？？？那每个公司再多出几十个软工岗位吧……

正当 Hadoop 如日中天时，突然杀出了另一个架构，对 Hadoop 的老大地位形成了挑战，大有取而代之的趋势，它就是 Spark. 我们会开辟一个新的系列介绍，敬请关注。