猛设计-完成摘要

1、性本人郑重：所呈交的是本人在导师的指导下独立进行取得的研究成果。除了文中特别加以标注的内容外，本不包括任何其他个人或集体已经或撰写的成果作品。本人完全本的法律由本人承担。作者签名：年月日使用书本作者完全了解学校有关保障、使用的规定，同意学校保留并向有关管理部门或机构送交的复印件和，允许被查阅和借阅。本人省级优秀学士评选机构将本的全部或部分内容编入有关数据进行检索，可以采用影印、缩印或扫描等保存和汇编本学位。本属于 1、囗，在年后适用本书2、不囗。（请在以上相应方框内打“”）作者签名：年月日导师签名：年月日摘要随着大数据时代的到来，数据与容错成为热门的研究领域，如何在实现高容错的前提下提高效率和

2、恢复效率，是该领域主要的目标。而 Hadoop提供了一种非常好的分布式系统 HDFS，可以用于大数据的和分析。提出一种基于 Hadoop 的混合 Raid 容错机制，在总结已有方案的基础上，通过镜像备份和Raid 编码，实现容错性能和内的恢复，进一步提高恢复性能。效率的，并且通过Rack研究过通过修改 Hadoop 源码实现了 HRIR(Hybrid Raid In_rack Recover)系统，该系统采用混合Raid 编码提供容错。经过测试，发现其效率教Hadoop 自带的三备份有很大提高，容错性能相差不大，而恢复性能在一定条件下也有很大提高，达到了预期目标。：Hadoop；混合 RAID

3、；数据容错；数据恢复AbstractWith the arrival of Big Data, data storage and fault tolerancee a hot researchfield, how to achieve high fault tolerance under the premise of improving storageefficiency and recovery efficiency, is the main goalhe field. Hadoop provides a verygood distributed storage system called

4、HDFS, which can be used for Big Datas storageandtoleranysis. On the basis of the existing throry, we proe a hybrid Raid faultcheme based on Hadoop. Through Replication and Raid, we can improvefault tolerance and storage efficiency, and improve recovery performance through In_Rack recovery.We modify

5、the source code of Hadoop to achieve the HRIR (Hybrid Raid In_rackRecover) system, which uses a hybrid Raid to provide fault tolerance. After tested ,found its storage efficiency is bettern 3-way, which is the Hadoops original plan,and recovery performance under certain conditions also grey improved

6、. So the HRIR is pretty good and it achieve our desired goal.Keywords: Hadoop; hybrid RAID; data fault tolerance; data recovery目录摘要IAbstractII1绪论11.1课题背景11.2传统策略11.3混合RAID21.4预期目标21.5本文的内容与组织22相关技术42.1Hadoop42.2RAID52.3HDFS-RAID62.4本章小结93设计与实现103.1混合Raid 容错103.2容错恢复过程113.3Rack 内恢复Block173.4Parity 文件

7、恢复203.5优化Task 的分发策略203.6本章小结214实验与分析224.1测试环境搭建224.2网络带宽限制234.3恢复时间的计算244.4单Block 丢失恢复254.5Datanode 故障恢复314.6本章小结335总结与展望345.1全文总结345.2展望34致 谢35参考文献361绪论1.1 课题背景现代的发展极大方便了的日常生活，各种设备和服务无时无刻不在为提供着服务，随之带来的就是数据的增长，而且根据机构IDC 的预计，未来的数据总量增长率将在 50%左右，也就是说，到两年后的 2020年，全球的数据总量将会达到 40ZB(1ZB=270Byte)，这也就解释了为什么大

8、数据，云计算等会成为当下的热门研究领域。大数据对技术领域的首要考验是，Apache的 Hadoop 就是一个海量数据的，主要由 Hadoop 框架中的分布式文件系统 HDFS(HadoopDistributed File System)提供数据服务。但是光光并不能满足需求，因为Hadoop 大都是部署在相对廉价的机器上，而这些机器出故障的概率是很大的，尤其是在机器数目众多的情况下，必然会有某个机器出现故障，导致其的数据丢失，所以大数据的还需要考虑数据容错。容错的目标是，一旦发生故障，能够在最短的时间内恢复出故障节点的数据，保证整个系统中的数据安全。容错方案可以是副本，也可以是 RAID 容错，

9、不管采用那种容错，恢复速度都是非常重要的，同时还需要考虑在繁忙的数据下，网络带宽也会成为一个恢复的瓶颈。1.2 传统策略传统的 Hadoop 提供的是一种三备份的方案，这种方案可以有效提供数据容错，2 个块的丢失，且大多数情况下可以至少可以数据块的丢失，但是首先对于三备份来说，数据冗余过大，冗余度达到了 200%，在海量数据的时候，因为提供容错而浪费的资源过以大规模实施；其次，三备份方案 Block 的分发策略是将其中两个备份放置在一个 Rack 内的节点上，剩下的一个 Block 放置在另外的 Rack 内的节点上，所以三备份容错方案在进行数据恢复的时候，会出现的一定的概率要从其他机架(Ra

10、ck)内数据块，假设所有 Block所在节点损坏的可能性相同，那么需要跨 Rack进行恢复的概率是 1/3，这在Rack 的 IO 耗时比较长，并且 Rack 之间网络传输繁忙的时候会大大影响恢复性能。1.3 混合 RAID对于RAID 编码提供容错的方案，RAID1 的方案是一种简单的双备份，分别在两个 Rack 中建立备份，而 RAID5 则是将源数据进行编码生成编码块提供容错，这两种方案各有优缺点，Raid5 的效率高，并且可以进行 Rack 内的编码恢复，Raid1 的容错性好，其中一个备份损坏的时候，可以由镜像恢复出来，因此可以考虑采用混合 RAID 容错方案，即在 RAID1 实现

11、双备份的两个 Rack中，在每个 Rack 内进行编码，产生的两个编码块存放在各自的 Rack 内，与原数据的备份一起提供容错，如此一来，除了能够提供高容错性(的情况下能够三个Block 的丢失)，还有效提高了效率。1.4 预期目标根据之前提到的，在实际的集群系统中，Rack(In_rack)的数据传输速度要比 Rack 之间(across_rack)的快很多，所以就考虑能不能在实现了混合 Raid的系统上采用 Rack编码的方式进行数据恢复，减少对 Rack 间网络带宽的占用，恢复性能。因此，提出基于 Hadoop 的混合RAID 容错方案，建立基于 Hadoop，采用混合 RAID 实现R

12、ack 内数据恢复的系统 HRIR(Hybrid RaidIn_rack Recover)，测试其实际的恢复性能并与其他容错方案作比较。预期目标是：比起三副本策略，1.开销降低至少 10%；2.写入速度提高至少 20%；3.在 Block损坏的时候，采用 Rack以上。进行RAID 修复，可以比恢复的性能提高 20%1.5 本文的内容与组织本课题研究的是基于 Hadoop 的混合 RAID 容错方案，主要针对 Hadoop 三副本数据容错机制所存在的数据开销大，写入速度慢和跨机架恢复带宽消耗高等缺点，设计一种基于镜像和编码混合的容错机制，从而降低数据开销，提高写入速度，消除节点恢复所造成的跨机

13、架带宽消耗。研究方式是在Hadoop 源代码的基础上进行修改，实现混合 Raid 容错机制并对其进行优化，最后比较混合 Raid 和三副本两种容做机制，工作难点在于 Hadoop 源码的阅读和实验的搭建。本文的内容组织如下：第一章：绪论部分，介绍课题的背景，传统的容错策略和新混合 Raid 思想，以及本课题的预期目标。第二章：介绍相关的技术背景，主要设计到的是 Hadoop，Raid 和 HDFS-RAID 技术。第三章：详细介绍 HRIR 系统的设计与实现，包括源码的修改和相关优化策略。第四章：进行实验分析，检测 HRIR 系统实际的恢复效率，并与三备份进行比较。第五章：总结性工作，回顾整个

14、研究过程，对未来提出展望。2相关技术2.1 HadoopApach Hadoop 是一个支持分布式 计算和大数据处理的系统架构，其可以由廉价的设备组集群中心，通过高速网络进行相互之间的通信。它的设计是为了将单服务器扩展为数以千计的节点，每个节点都提供本地的数据和计算能力，这样可以避免单服务器所带来的巨大硬件开销，同时能够保证提供高可靠性的服务。Hadoop 的兴在 2005 年前后的三篇，分别介绍了 GFS，的技术。Hadoop 项目主要包括于MapReduce 和BigTable 三种大数据时代几个模块：Hadoop Common:通用模块，用于支撑其他模块的运行Hadoop Distrib

15、uted File System()HDFS:分布式文件系统，提供高效的文件读写，这是的混合Raid 方案需要重点研究的部分Hadoop YARN:Job 调度框架和集群资源管理Hadoop MapReduce:基于 YARN 系统，用于并行处理大数据Hadoop 最的部分是 HDFS 和 MapReduce，的实验系统 HRIR 采用的混合Raid 容错机制的设计就是基于 HDFS 的，而容错的实现，包括 Raid 编码过Decode机上去执行的。过程，提交的 Job 都是通过 MapReduce 计算框架提交到 Task正是因为 Hadoop 的设计中所体现出来的高可靠性(Hadoop 提

16、供了数据容错，计算任务失败再提交等机制)，高可扩展性(集群点个数可以动态增删)和高效性(MapReduce 的计算框架对于大数据的计算有着得天独厚的优势，计算效率可以大大提高，而且，分布式的也可以很方便地实现数据的并行，提高读写效率)，更为重要的是其开源的特性，技术可以在其基础上进行二次开发，后面的 Hadoop-就是公司在 Hadoop1.0 的基础上增加了 Raid方案而开发出的适合其公司特性的 Hadoop 系统，Hadoop 在当前这个大数据的时代得到了广泛的应用，Yahoo 作为著名的互联网门户，它使用了包含 4000个节点的 Hadoop 集群来支撑其搜索业务；国内的公司如也使用

17、Hadoop 系统进行搜索日志的分析和定点推送等服务；阿里巴巴的淘宝每天需要处理大量的网络订单，事关金钱交易，而且数据量又巨大，高可靠性的 Hadoop 系统在系统数据，作业调度，安全性方面都为其提供了巨大的支持，尤其是双十一期间，爆发式的交易订单增长并没有对阿里巴巴的业务造成破坏性影响。如今，Hadoop 还在不断发展之中，各个公司基于 Hadoop 开发的适合自己的分布式、计算系统正在不断补充 Hadoop 的内容，社区的也在解决代码中的Bug，优化方案，在大数据时代的推动下，Hadoop 框架将会越来越完善。2.2 RAID独立冗余磁盘阵列RAID(Redundant Array of

18、Independent Disk)技术是加州大学分校(University of California, Berkeley)在 1987 年提出，本质上的愿望是通过多块比较廉价的小磁盘组装成磁盘阵列，在效果上可以和昂贵的大磁盘相近，而且对在磁盘上的数据提供容错。RAID 的出现，可以作为计算机磁盘的替代，以其多硬盘的优势，实现并行，提高读写效率，并且组长而成的磁盘阵列可以极大提高设备的容量，同时，通过镜像备份或是编码，还可以提供较好的容错，在其中某一块磁盘出现问题之后，并不会影响整个磁盘阵列的数据读写。RAID 有多种工作模式，不同工作模式的效率，容错能力有一定差异，比较流行的工作模式有RAI

19、D0，RAID1，RAID5 和RAID10 这四种。RAID0RAID0 就是数据分条技术，在多块磁盘组成的磁盘阵列中，将数据分别存放到不同的磁盘上，因为每一块磁盘都有磁盘驱动可以同时进行数据的读写，所以采用 RAID0 工作模式，可以提高磁盘阵列的读写性能，且成本比较低廉，有两块磁盘即可以组成RAID0 磁盘阵列。但是 RAID0 工作模式并不提供容错，所以当数据损坏的时候不能进行修复，比较适合那些对数据安全性要求不高，成本比较小的情况。RAID1RAID1 提供了一种最直观的容错方案，即冗余备份，将磁盘上的所有数据作一个镜像备份到另一个磁盘上，因此 RAID1 又被称为磁盘镜像，两块磁盘

20、同时进行数据读写，所以读写的效率和普通磁盘几乎是一样的，不会因为存在备份而降低读写效率，但是 RAID1 所具有的数据容错能力是最强的，完全的数据备份可以保证系统的高可靠性和可修复性，在其中一块磁盘发生故障的时候，可以从镜像中数据，并不会影响数据，之后可以在空闲的时候进行磁盘恢复。但是 RAID1 高可靠性的代价就是较低的效率，只有 50%，在数据量巨大的情况为镜像设备的磁盘将会是一笔比较大的开销。比较适合那些要求数据高可靠性的场合，比如，RAID5，企业信息等。考虑到RAID0 高效率但不提供容错，RAID1 提供高容错但是较低的效率，RAID5 工作模式可以说是二者的折衷，即 Hybrid

21、，综合二者之长，减弱二者的短板。RAID5 的工作模式改变了 RAID1 的完全备份，而是采用奇偶校验信息作为容错方案，选取一定长度的源数据进行计算，将得出的奇偶校验信息一同以提供容错，并且奇偶校验信息不在同一个磁盘上以避免该磁盘出现故障所导致的整体失效。在写入的性能上会有一定程度的降低，因为需要计算奇偶校验块，效率上不会有很大的减弱，只是多了一个奇偶校验块而已。在发生磁盘故障的时候，可以用剩下的磁盘中的数据和奇偶校验信息计算得出丢失的数据，虽然数据容错能力不如 RAID1，但是其 RAID0 所不具有的容错能力，比较适合部署使用。RAID10RAID10 又写成 RADI0+1，称为镜像阵列

22、条带，和 RAID0 一样采用数据分条技术，又和 RAID1 一样采用 100%的完全备份，是一种高性能，同时也高开销的效率较高，而且提供了RAID 工作模式，在读的时候支持多磁盘并行，写入的时候和 RAID1 相同，都是写入两个镜像的磁盘中，而且容错能力更好，即使两个磁盘出现故障，如果不是相同的镜像磁盘的话，依然可以提供正常的数据服务。集合了 RAID0效率依然只有 50%。和RAID1 的优点，也完全继承了RAID1 的缺点，即2.3 HDFS-RAID对于用户总数超过 20 亿，占全球总1/3 强的公司，PB 级别的公司所拥有数据都已经不算什么，很早之前的一份数据显示，2011 年的压缩

23、数据已经达到了 25PB，还未压缩数据则有 150PB，这仅仅是 6 年前的数据，在移动网络飞速发展，全球数据增长的情况下，今天，所需要处理的数据或以称之为全球最大的大数据了。HDFS-RAID 是l 基于第一代的 Hadoop 分支所开发的 Raid 方案，对Hadoop 自带的 HDFS 修改不大，用设计者的话来说，就是“Hadoop 本身已经够复杂了，不想让它更复杂”，主要是在现有的 HDFS 上增加了一个包装contrib，并不是将修改的代码嵌入到 Hadoop 中。常用的编码方式有RS(Reed-Solomon)编码和 XOR 编码，本质上他们都是对 N额数据块进行运算，产生K 个校

24、验块，然后在 N+K 个块中，就可以最多K额块的丢失，丢失的块可以由剩下的块通过计算恢复出来，N 和 K 都是可以自由设定的，一般称N 为StripeLength，称K 为 ParityLength。数据的Raid 有几种不同的方案，对于不太冷的数据，需要保存比较多的备份，但是又不能是完全的三备份，这时候可以采用 XOR 编码，生成的 parity 块保留两个备份，源数据块从三备份减少为双备份，在StripeLenght 为 3，ParityLenght为 1 的情况下，理论上 replicate 系数可以从 3 减少到 2.67，但是容错能力并没有减弱，然而得到了一定程度的加强(在情况下，三

25、备份只能两个块的丢失，但是Raid 方案能够至少三个块的丢失)。对于非常冷的数据，则可以采用 RS 编码，StripeLength 设置为 10，ParityLength 设置为 4，这样子理论上的replicate 系数为 1.4，已经大大小于三备份方案了，而且依然提供容错，只是恢复的计算开销会比较大，所以适合比较冷的数据。HDFS-RAID 主要三个模块组成，分别是：DistributedRaidFileSystem这是包装了 DistributeFileSystem 的分布式文件系统类，提供了 HDFS-RAID 方HDFS 中 block 数据时发生 CorruptException

26、或案中的相关支持，当misRaidNodeEcception 时根据parity 文件对异常的block 进行修复。RaidNode 会启动RPC Server，接收通过RaidS发送过来的指令，进行编码或者恢复或者负载均衡等，这些操作是由各自的进程来完成的。RaidS一个 Cnt 端管理工具，提供了命令窗口，集群管理员通过 RaidS RaidNode 发送指令进行操作。HDFS-RAID 的整体结构如所示。给归档处理，减轻 NameNode 的负担。2.4 本章小结本章主要介绍了课题研究中所涉及到的三种主要技术，即 Hadoop，Raid 和HDFS-RAID，通过对相关技术的了解，方便后

27、续研究工作的展开。3设计与实现3.1 混合 Raid 容错HRIR 系统采用的是一种混合 Raid 容错机制，在两个机架之间使用镜像备份，每个机架则使用 Raid5 进行编码，生成编码块分别在 Rack，采用这种方案可以可以在较高的效率下提供非常好的容错性能。其拓扑结构如所示：比较如所示：表 3-1 混合Raid 与三备份的比较可以发现，混合 Raid 方案比起三备份有着较高的效率，一般情况下三备情况下，混合 Raid 能够份的容错性能会更好一些，但是的数据块丢失数目，而且，混合 Raid 可以完全实现Rack 内的数据恢复，三备份策略有 1/3的概率要进行跨Rack 的恢复。3.2 容错恢复

28、过程3.2.1Block 丢失Datanode会通过 DataBlockScanner 类定期检查本地的数据目录，当在Datanode 上手动删除 Block 的时候， Datanode 检测到文件丢失， 通过reportBadBlocks()函数经过一连串调用，将一系列 LocateBlock 对象(该对象了包含丢失的 Block 和其 DatanodeInfo 数 组 信 息 ) 传 递 给 NameNode 的reportBadBlocksernal()函数。在 NameNode 的reportBadBlocksernal()函数中，处理的逻辑就是循环处理传递过来的每一个 LocateB

29、lock 对象，通过 LocateBlock 对象的下列两个函数获得Block 信息和DatanodeInfo 数组信息：Block blk = locatedBlock.getBlock(); DatanodeInfo nodes = locatedBlock.getLocations();之后通过amesysstem 的 markBlockAsCorrupt()函数，在确认 node 非 null和 blk 所属的文件非 null 之后，将属于 nodes 数组上内每一个 node 上丢失的的该blk 标记为corrupt。标记为corrupt 后，通过调用updateNeededRepl

30、icationQueue()函数更新 neededReplications 对象，这是在恢复过非常重要的一个对象，其比较项目混合 Raid三备份效率(数据块个数)1012容错性能可以3 个 Block 丢失可以2 个 Block 丢失恢复性能可以进行跨 Rack恢复或者 Rack 内编码恢复1/3 的概率需要跨 Rack恢复，2/3 的概率在 Rack 内恢复定义类为 UnderReplicatedBlocks，用于保存需要进行备份的 Blocks 信息。在恢复的情况下，Block 的丢失到这儿也就可以了，但是因为要进行Raid 修复， 为了避免在修复过的分发阶段出现问题，需要在updateN

31、eededReplicationQueue()函数后面添加一段代码，即使用 invalidateBlock函数Block 丢失的 Datanode 上的该block 信息删除。原本invalidateBlock 函数是用于上还存有该Block 的信息，加上新恢复成功后，因为丢失 Block 的 Datanode生成的副本，该Block 的副本数就超过了所定义的需要的副本数，所以需要将此 Datanode 上的 Block 无效，也就是在invalidateBlock 函数内执行removeStoredBlock()函数，将该 Block 从 Datanode 上移除。但是现在需要进行 Raid

32、 恢复，因为节点有限，分发数据的时候如果恰好又选择到了丢失Block 的节点，那么发送的时候会出现报错，所以测到Block 丢失后，就使此 Datanode 上的 Block 无效。为此，还需要去修改 invalidateBlock()函数的判断条件，原本的策略是在在检有至少下两个副本的情况下才会 invalidateBlock 掉相应的 Block，实验中我们定义的副本数为 2，因此在只有一个副本的情况下也需要将该 Block 从Datanode 上移除。修改的代码如下：至此， 丢失 Block 的 report 任务修改完毕， 丢失信息成功保存到neededReplications 对象中

33、。其流程如所示：3.2.2关闭恢复在混合 Raid 的方案中，发生 Block 丢失的时候，由于在另一个 Rack 内一定有这个 Block 的备份，所以 Hadoop 默认采用的是跨 Rack 的恢复，为了实现 In_rack 的恢复，需要手动关闭其恢复功能。在进行源码的修改之后，可以使用命令：来进行功能的动态开启或者关闭。3.2.3Corrupt file 获取Hadoop 在启动 RaidNode 后，会开启一个 BlockegrityMonitor 线程检查系统中的文件，BlockegrityMonitor 有两个实现，在部署的分布式计算的Hadoop系统中，采用的是第二种 Dist

34、模式，其实现线程为DistBlockegrityMonitor，将计算任务分发到 Task 机上去执行，减少RaidNode 上的计算开销。DistBlockegrityMonitor 线程在运行的时候，通过 DFSck(Distribute File SystemCheck)命令检查系统中已经 Raid 化的数据，在丢失一个 Block 的情况下，默认并不会将其作为Corrupt File 返回，而是进行恢复。为了实现In_rack 的编码恢复，需要修改Corrupt file 的获取代码。 首先定位获取损坏文件的代码，在 DistBlockegrityMonitor 线，每隔一段时间就调用

35、一次 checkAndReconstructBlocks() ，而此函数则是调用了 CorruptionWorker 类中的 getLostFiles()来返回一个损坏文件名和其损坏 Block 数 目的 HashMap 对象。而最终要调用的，是位于amesystem 中的 listCorruptFilocks() 函数，在该函数中 通过迭代 之前 提到过的 neededReplications 对象中的所有损坏 block，根据优先级获取其中需要进行修复的 Block，然后返回一个 CorruptFilockInfo 的对象队列，CorruptFilockInfo保存了损坏的Block 和其

36、对应的文件Path 信息。 默认在进行 Raid 修复的时候只会返回优先级为 3 的损坏 Block，但是对于混合 Raid 容错机制下副本数为 2，且已经有一个 Block 损坏的情况下，该Block 的 优先级为 0，所以需要修改源码，使之在单Block 损坏的时候也提交给 Raid 进行修复。为了不影响正常恢复的过程，所以添加了一个判断，判断的条件hadoop dfsadmin blockReplication disable/enableblockReplicationEnabled 就是前文中进行动态设置的恢复开关。 与之对应，源码下方的判断条件也要进行相应的修改，同样需要设置判断条

37、件。在getLostFiles()函数中获得了相应的损坏文件信息后，但是这其中会包括一些已经移动到回收站的文件，参照源码中的说明，先打印出损坏文件的个数，然后过滤掉已经被删除的文件，再次打印文件个数。主要函数调用逻辑。3.2.4Job 提交过程在 checkAndReconstructBlocks()函数中获取到损坏和丢失的文件后，然后就要调用computePrioritiesAndStartJobs(fs, lostFiles, detectTime)进行修复了，传入的参数包括文件系统fs，丢失Block 的文件列表lostFiles 以及当前时间。首先会进行计算文件的优先级，副本数目越小，

38、发生 corrupt 的 Block 数目越大，优先级就越高。将计算好优先级的文件列表按优先级排序，作为参数构建修复 Job。 job 的输入是所有需要修复的文件 path 的 sequence file 。会根据 raid.blockfix.filespertask 配置的值进行 sync，即在 job 的 split 阶段会按照该值设置的进行split，默认是 20Job 的 Mapper 主要是通过Reconstruter 在task 机上完成响应文件的恢复。执行 Job 的 Map 任务的类为继承自 Mapper 类的 ReconstructionMapper 类，其map 函数是恢复

39、的主要过程，其调用了 BlockReconstruct 类中的 reconstructFile()函数，完成恢复过程并计算时间开销。3.3 Rack 内恢复 Block3.3.1Rack 内数据在进行文件恢复的时候，reconstructFile()函数根据其文件类型的不同分别进行恢复，通过新建的 Decode 对象，调用其中的恢复函数。恢复过需要源文件数据块或者是编码块，为了实现 In_rack 的恢复，必须是在 Rack 内进行读取，这样子在恢复性能上才可能会超过 across_rack 的block 的恢复。而过程比较复杂，先通过 lost block 获得其所属的文件地址，然后定位该

40、block 在文件中的偏移地址，之后建立该文件地址下的 FSDataInputStream 输入流，根据偏移地址对该block 进行，在恢复的时候实现多个Block 的并行。修改的策略是在 getBlockLocations()返回一系列 LocateBlocks 之后，因为的时候默认是从某个 Block 所对应的 DatanodeInfo 数组中的第一个之后Datanode 进行，所以在得到 LocateBlocks 后进行排序处理，将离当前执行Job 的 Datanode 比较近的节点前移，保证 In_rack 的恢复。Hadoop 本身有一定的优化，可以在一定程度上保证尽量从比较近的地方

41、进行，但是实验过发现在某些情况下还是经常会从比较远的另一个 Rack 内进行Block，这样一Block 所需要的传输时间已经和恢复相等了，那么 Raid 恢复来，本身的效率并没有提高，反而有所降低，也不再是真正意义上的 In_rack 恢复了。 排序的策略是，扫描所有节点数组，如果找到本地节点，即当前执行 Job 的节点，那么无疑这个的距离是最近的，将其放置到数组的第一的位置；如果有同一Rack 的节点，在没有本地节点的情况下这个是最近的，于是将其放置到第一(不存在本地节点)或者本地节点之后的位置，如果既没有本地节点，也没有同 Rack内节点，那么可以不改变数组顺序，原样返回就行，修改后的

42、sort 策略可以保证在存在 In_rack 节点的情况下，一定是从 Rack 内进行 Block In_rack 的恢复。修改后的pseudoSortByDistance 函数相关内容如下所示：，进而实现功能：根据与当前节点的距离，将包含 Block 的节点集合进行排序，寻找同一台机器上的local node 前移到数组头部，如果没有 local node 则寻找同一Rack 内的 local rack node，如果都没有，则不改变nodes 数组的顺序输入：当前执行Job 的节点reader，包含 Block 的节点集合nodes输出：完成排序的节点集合nodes其流程图如所示：3.3.

43、3生成块的分发在成功生成丢失Block 之后，需要进行数据分发，在实验中所搭建好的系统中，分发策略比较简单，只要避免分发到保存有该 Block 的 Datanode 上，将其列入 Advoiding Datanode，然后选取与该 Datanode 不同Rack，优先选择与最初损坏的 Datanode 同一Rack 的Datanode 进行Block 分发，方便再次出现故障的时候依然能够进行有效的In_rack 恢复。3.4 Parity 文件恢复与源文件不同，Parity 文件的恢复其实和Raid 的时候一样，都是编码生成编码块的过程，只是因为配置好的 Hadoop 在Raid 成功后莫名其

44、妙地会将Parity 文件移动到Trash 回收站中，而进行编码恢复的时候，在返回 corrupt file 之后会进行一次文件的过滤，导致实验过不能对 Parity file 进行Raid 恢复。所以需要找到删除Parity file 的源码位置，即 PurgeMonitor 类中的duPurge()函，先删除了 parity file 后，才进行判断是否源文件数，其判断逻辑有一定经历了修改，如果修改过了，则重新进行编码生成 parity file，实验中并没有去增删源文件，也不希望该进程删除 parity file，所以将删除函数 purgeCode()移动到判断之后，即先进行判断，是否进

45、行重新编码，然后决定是否删除该 sourcefile 的parity file。3.5 优化 Task 的分发策略以上 In_rack 的优化方案都是建立在执行 blockfixer 任务的 Task 机是在 Rack内的，否则若在另一个 Rack 的机器 进行了Raid 修复，生成的 Block 还是需要进行跨 Rack 的发送，白白多了一个 Raid 的过程，性能上得不到一点点的提高。所以需要优化 Hadoop 系统的 Job 分发策略，即进行 Raid 修复的时候，将blockfixer 任务发送到lost block 节点所在的 Rack该 Datanode 的话，甚至可以就是该节点)

46、。节点(实验中如果没有关闭但是因为 Hadoop 的 Job 分发策略并不是在生成 Job 的时候就选择该 Job 的执行Task 机，而是生成的 Job交由任务调度器，最主要使用的是 Hadoop 默认的 JobQueueTaskScheduleer FIFO(InOut)调度器，Datanode 上的进程tasktrakcer 会定期向 Jobtracker 发送心跳信息，Jobtracker 在接受到任意tasktracer的心跳信息后，综合考虑其内容，计算力等，为其分配相应的task，在的 HRIR 系统中，涉及到的只有两种Job，即Raid job 和 Reconstruct job

47、。需要在分发 Reconstruct job 的时候，掉其他 Rack 内的节点，为此，我们找到处理该逻辑的相关代码，修改Job 分发策略。源码中分发给tasktracker 的tasklist 由 assignTasks()函数分发。为此，在该函数中添加一个判断，因为只是为了满足实验要求， 判断 Job 类型是否为修复 block 的 blockfixer 以及当前需要分发 task 的 tasktracker 是否为发生 block 丢失的 datanode 所在 Rack 以外的 Rack，如果两个条件都满足，则不分发该 Task，然后继续执行相关代码。通过优化 Job 的分发策略，可以

48、保证每次进行恢复的时候都是 In_rack 的编码恢复。3.6 本章小结本章是课题研究的主体内容，主要介绍了混合 Raid 的容错方案并与三备份策略进行比较，还详细介绍了 In_Rack 编码恢复的恢复过程 以及相关的优化方案，主要的工作在代码的修改上。/modify by duroper2017-04-20 if(job.getJobConf().getJobName().contains(blockfixer)&taskTracker.getTracker Name().contains(Slave5)LOG.info(job.getJobConf().getJobName()+canno

49、tbeexecutat+ taskTracker.getTrackerName();continue;/end4实验与分析4.1 测试环境搭建4.1.1集群拓扑结构实验选用 Ubuntu14.04 系统进行 Hadoop 集群部署，使用 VMware 开启五台虚拟机，分别作为 NameNode 节点和四个 DataNode 节点，RaidNode 部署在NameNode 上。虚拟机的硬件配置和版本如所示。表 4-1 Hadoop 集群点机器配置信息(注：NameNode 的内存为 800MB，DataNode 的内存为 600MB)项目配置信息内存800MB/600MB硬盘20GBCPU(宿主

50、机)el Core i5-2450M 2.5GHz操作系统Ubunu 14.04kernelx86_64 Linux 3.13.0-32-genericGit 版本1.9.1Ant 版本1.9.3Jave 版本1.8.0_111架Rack2 内，NameNode/RaidNode 独立于两个 Rack，其拓扑结构如所示。4.1.2Datanode 故障模拟实际的集群系统中，运行 Datanode 的从节点机器发生的故障主要有两类，一类是由于断电，宕机等造成节点关闭，其硬盘上的数据全部丢失；还有一类是磁盘的部分扇区出现坏道等问题，导致部分数据 Block 不能，在实验总需要模拟这两种故障发生时，

51、测试 HRIR 系统的容错恢复能力。通过研究 Hadoop 的源码中对于两种情况处理过程的不同，可以发现，Datanode故障是通过 Namenode 检测 heartbeat 的丢失来完成的，因为检测的周期比较长，所以导致故障响应比较慢，而删除 Block 的话，Datanode 在本地数据检测的时候发现 Block 丢失，会立即调用 reportBadBlock()函数，该函数的具体功能中已经有完整叙述，总之，调用函数之后能够快速响应 Block 丢失。而在检测到相应故障的时候，两种情况下的最后的处理过程都是一样的，均是文调用了updateNeedReplicationQueue()函数将

52、该 Block 添加到待恢复的队列，唯一不同的是 Datanode 故障发生之后的响应过，有一步操作是将该 Datanode 上的 corrupt Block 移除(因为检测到 Datanode 故障，集群也就将该 node 移除了)。这并不会影响 的恢复过程，所以可以使用 rm 命令删除 Block 的方法来模拟单Block 的丢失。表 4-2 Datanode 故障与手动删除Block 的对比4.2 网络带宽限制HRIR 系统采用的是 In_rack 的 Raid 恢复，相比较于直接的恢复，所需要的 Block 个数一定是的，在最好的情况下，即 stripeLenghth(条带长度)为 2

53、，parityLength(编码块长度)为 1 的时候，至少需要2 个 Block 才能完成恢复。而 In_rack 恢复能达到更好的恢复效率，一个重要的原因是 Rack 内的Datanode 故障关闭rm 命令删除 Block触发机制lost heartbeatreportBadBlock()相应时间超过十分钟一分钟以内故障处理updateNeedReplicationQueue()updateNeedReplicationQueue()速度要远快于跨 Rack的速度，因此在实验过要模拟出实际 Rack 的拓扑结构，部署的时候 Rack2 内只有一个节点 Slave4，所以可以限制 Slav

54、e4 和其他Slaves 之间网络传输的带宽，Rack 内传输和跨Rack 传输的速率比参考相关资料得知，在 1:5 到 1:20 之间，更差一点的情况甚至可以达到 1:200。因此，首先确定在 VMware 虚拟机之间的最大网络带宽是多少，采用实验的方式，使用 恢复确定大小的Block，更改Slave4 的网络带宽，多次实验，实际传输Block 所花费的时间，得出相关的如下所示：表 4-3 网络带宽测试所以可以大致确定虚拟机之前的最大传输带宽在 350Mbps 左右，为了确保带宽限制的效果，设定虚拟机中逻辑 Rack 内的网络带宽为 300Mbps，并且按照 1:5 或者 1:10 的带宽比

55、，分别可以设置 Slave4 的网络带宽为 60Mbps 或者 30Mbps。设置方法为在 VMware 中点击虚拟机-设置-网络适配器-高级，分别设置传入带宽和传出带宽为相应的数值。4.3 恢复时间的计算比较In_rack 和across_rack 在恢复性能的差异，最主要的参数就是故障的恢复时间，对于 In_rack 的 Raid 恢复，分别计算其实际恢复的时间 DT(DecodeTime)和包含 Job Schedule 的时间 ST(Schedule Time)，结果通过该 Job 的 log 日志输出，恢复的时间也包括两部分，一个是发送请求开始到目标节点收到该Block 的时间TT(

56、Transfer Time)，还有一个是Block 源节点在与目标节点完Slave4 网络适配器带宽传输 64MB 的 Block 的实际发送时间(：ms)不受限MbpsMbpsMbpsMbps27832721成连接，实际传输过程所花费的时间 RT(Replicate Time)，这两个时间可以通过 NameNode 和 Datanode 的log 日志输出。在进行单 Block 恢复的时候，主要计算的是实际恢复的时间，即 DT 和TT，这样能够最直接反映处 In_rack 恢复在Rack内高速传输情况下的优势，而在 Datanode 故障的时候，计算的是所有时间的累加和，即包含所有时间的 S

57、T 和 RT，Raid 编码修复和 Replicate修复开始的时间一样，都是从 Namenode 检测到 lost heartbeat 开始，到完成最后一个 Block的修复为止。4.4 单 Block 丢失恢复单Block 丢失的主要实验步骤为：..9.10.上传测试文件到 Hadoop 系统启动RaidNode 进行编码设置Slave4 网络适配器的带宽关闭 Hadoop 系统的功能删除Slave2 上的Block等待In_rack 的恢复完成，测试出恢复时间开启 Hadoop 系统的功能删除Slave1 上的Block等待across_rack 的恢复完成，

58、测试出恢复时间修改Slave4 网络适配器的带宽，测试不同带宽限制下两种恢复的时间设置StripeLength 为 2，ParityLength 为 1，这样在实验中的 Block 分布比较直观。一般情况下实际 Hadoop 系统的Block 设置以 64MB 为主，并且进行多次实验，取平均值作为最后的实验数据。4.4.1单 Block 恢复实验数据 Block 大小 1MB限速 60Mbps表4-4 Block 为 1MB 限速 60Mbps 的恢复时间限速 30Mbps4-5 Block 为 1MB 限速 30Mbps 的恢复时间表 Block 大小 4MB限速

59、 60Mbps表 4-6 Block 为 4MB 限速 60Mbps 的恢复时间限速 30Mbps表 4-7 Block 为 4MB 限速 30Mbps 的恢复时间实验次数In_rack 编码恢复(ms)across_rack恢复(ms)93639811006平均值938960实验次数In_rack 编码恢复(ms)across_rack恢复(ms)1103847128825173827465平均值916484实验次数In_rack 编码恢复(ms)across_rack恢复(ms)1993554199平均值530204实验次数In_rack 编码恢复(ms)across_rack恢复(ms)

60、147267257048345197平均值4977 Block 大小 8MB限速 60Mbps表4-8 Block 为 8MB 限速 60Mbps 的恢复时间限速 30Mbps4-9 Block 为 8MB 限速 30Mbps 的恢复时间表 Block 大小 16MB限速 60Mbps表 4-10 Block 为 16MB 限速 60Mbps 的恢复时间限速 30Mbps表 4-11 Block 为 16MB 限速 30Mbps 的恢复时间实验次数In_rack 编码恢复(ms)across_rack恢复(ms)119764476218234451实验次数In_r