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. 我们会开辟一个新的系列介绍,敬请关注。

原文发布于微信公众号 - 包子铺里聊IT(baozitraining)

原文发表时间:2015-10-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏木可大大

大数据是什么?

大数据是指海量数据或巨量数据,其规模巨大到无法通过目前主流的计算机系统在合理时间内获取、存储、管理、处理并提炼以帮助使用者决策。

18230
来自专栏王小雷

Hadoop YARN学习之Hadoop框架演进历史简述

Hadoop YARN学习之Hadoop框架演进历史简述(1) 1. Hadoop在其发展的过程中经历了多个阶段: 阶段0:Ad Hoc集群时代 标志着H...

21070
来自专栏奇点大数据

我学习的Spark都在学些什么

---- 最近工作中,接触到最有用的“玩具”就是Spark了,在cpu密集型业务驱动下,提升CPU处理效率,高效的利用内存是最优先的事务,所以有个好的计算工具...

57550
来自专栏华章科技

教你读懂大数据的技术生态圈

大数据本身是个很宽泛的概念,Hadoop生态圈(或者泛生态圈)基本上都是为了处理超过单机尺度的数据处理而诞生的。你可以把它比作一个厨房所需要的各种工具:锅碗瓢盆...

11130
来自专栏开源优测

大数据测试学习笔记之hadoop家族

前言 在进行大数据测试之前,我们必须了解下大数据处理的的相关技术体系,今天主要学习和了解了hadoop家族,这里记录下来分享给大家。 hadoop家族产品 ha...

31960
来自专栏杨建荣的学习笔记

浅谈Hadoop (r4笔记第81天)

大数据的概念炒了好多年了,很显然这项技术经受住了时间的考验,不是有些人想的那样华而不实,多年来总是伴随着Hadoop的身影越发壮大。 这些年来数据的增长量真是发...

38060
来自专栏CSDN技术头条

浅谈Apache Spark的6个发光点

【编者按】Spark是一个基于内存计算的开源集群计算系统,目的是更快速的进行数据分析。Spark由加州伯克利大学AMP实验室Matei为主的小团队使用Scala...

19990
来自专栏Albert陈凯

《Hadoop大数据技术体系:原理、内幕与项目实践》课程体系

《Hadoop大数据技术体系:原理、内幕与项目实践》课程体系 课程特色: 本课程以 “互联网日志分析系统”这一大数据应用案例为主线,依次介绍相关的大数据技...

43650
来自专栏PPV课数据科学社区

【学习】Hadoop大数据学习线路图

入门知识 对于我们新手入门学习hadoop的朋友来说,首先了解一下云计算和云计算技术是有必要的。下面先是介绍云计算和云计算技术的: 云计算,是...

39960
来自专栏云计算D1net

为什么不改进MapReduce,而要取代它?

MapReduce的高延迟已经成为Hadoop发展的瓶颈,为当前的MapReduce寻找性能更高的替代品已成为Hadoop社区的一个共识。 MapReduce ...

44560

扫码关注云+社区

领取腾讯云代金券