hadoop源代码分析毕业设计.docx
《hadoop源代码分析毕业设计.docx》由会员分享,可在线阅读,更多相关《hadoop源代码分析毕业设计.docx(46页珍藏版)》请在冰豆网上搜索。
hadoop源代码分析毕业设计
黄冈师范学院
本科生毕业论文
题目:
HDFS源代码分析与云存储环境搭建
专业班级:
网络工程2010级01班
学号:
201026340109
学生姓名:
王婷
指导教师:
崔一辉
论文完成日期:
2014年5月
郑重声明
本人的毕业论文是在指导老师崔一辉的指导下独立撰写并完成的。
毕业论文没有剽窃、抄袭、造假等违反学术道德、学术规范和侵权行为,如果有此现象发生,本人愿意承担由此产生的各种后果,直至法律责任;并可通过网络接受公众的查询。
特此郑重声明。
毕业论文作者(签名):
年月 日
HDFS源代码分析与云存储环境搭建
专业:
网络工程班级:
201001班作者:
王婷指导老师:
崔一辉
摘要
HDFS是HadoopDistributeFileSystem的简称,也就是Hadoop的一个分布式文件系统。
它已经在各种大型在线服务和大型存储系统中得到广泛应用,已经成为各大网站等在线服务公司的海量存储事实标准,多年来为网站客户提供了可靠高效的服务。
Hadoop系统在处理各种数据处理问题时,采用了分布式存储方式,提高了读写速度,并扩大了存储容量。
采用MapReduce来整合分布式文件系统上的数据,可保证分析和处理数据的高效。
与此同时,Hadoop还采用存储冗余数据的方式保证了数据的安全性。
Hadoop中HDFS的高容错特性,以及它是基于Java语言开发的,这使得Hadoop可以部署在低廉的计算机集群中,同时不限于某个操作系统。
在本次设计中,我们首先搭建虚拟机下ubuntu中的云计算环境,在本机安装eclipse并进行配置使得本机可以与ubuntu下的云计算进行通讯。
后逐次对源代码进行分析和实践,了解hdfs各个功能和实现原理,并可以通过自编程序实现hdfs的基本功能。
关键词:
Hadoop;HDFS;MapReduce;java;云计算;分布式文件系统;云存储环境搭建
HDFSSourceCodeAnalysisandCloudStorageEnvironmentBuilding
Speciality:
NetworkEngineeringClass:
1001
Author:
WangTingTutor:
CuiYi-hui
Abstract
HDFSHadoopDistributeFileSystemabbreviation,adistributedfilesystemisHadoop.Ithasbeenwidelyusedinvariouslargeonlineservicesandlargestoragesystem,hasbecomeeachbigwebsite,onlinecompanies'smassstoragestandardinfact,overtheyearsforthecustomerprovideareliableandefficientservice.
Hadoopsystemintheprocessingofvariousdataprocessingproblems,adoptsthedistributedstorage,improvethespeedofreadingandwriting,andtoexpandthestoragecapacity.UsingMapReducetointegratedistributedfilesystemdata,canguaranteetheefficientdataanalysisandprocessing.Atthesametime,Hadoopalsousesthestorageredundancydatainamannertoensuredatasecurity.HighfaulttolerancepropertiesinHadoopHDFS,anditisbasedontheJavalanguagedevelopment,whichmakesHadoopcanbedeployedonacomputerclusterlow,butnotlimitedtoanoperatingsystem.
Inthisdesign,wefirstbuildavirtualmachineUbuntuinthecloudcomputingenvironment,installedinthismachineeclipseandconfigurethemachinecanbeusedwiththeUbuntuunderthecloudcomputingcommunication.Aftersuccessiveanalysesthesourcecodeandthepractice,understandingofHDFSfunctionandtherealizationprinciple,andthroughthebasicfunctionsofprogramhdfs.
Keywords:
Hadoop;HDFS;MapReduce;Java;cloudcomputing;distributedfilesystem;cloudstorageenvironment
1绪论
1.1研究目的和意义
众所周知,现代社会的信息量增长速度极快,这些信息里又积累着大量的数据,其中包括个人数据和工业数据。
预计到2020年,每年产生的数字信息将会有超过1/3的内容驻留在云平台中或借助云平台处理。
我们需要对这些数据进行分析和处理,以获取更多有价值的信息。
那么我们如何高效地存储和管理这些数据,如何分析这些数据呢?
这时可以选用Hadoop系统,它在处理这类问题时,采用了分布式存储方式,提高了读写速度,并扩大了存储容量。
采用MapReduce来整合分布式文件系统上的数据,可保证分析和处理数据的高效。
与此同时,Hadoop还采用存储冗余数据的方式保证了数据的安全性。
HDFS是HadoopDistributeFileSystem的简称,也就是Hadoop的一个分布式文件系统。
它是运行在通用硬件上的分布式文件系统。
HDFS提供了一个高度容错性和高吞吐量的海量数据存储解决方案。
HDFS已经在各种大型在线服务和大型存储系统中得到广泛应用,已经成为各大网站等在线服务公司的海量存储事实标准,多年来为网站客户提供了可靠高效的服务。
随着信息系统的快速发展,海量的信息需要可靠存储的同时,还能被大量的使用者快速地访问。
传统的存储方案已经从构架上越来越难以适应近几年来的信息系统业务的飞速发展,成为了业务发展的瓶颈和障碍。
HDFS通过一个高效的分布式算法,将数据的访问和存储分布在大量服务器之中,在可靠地多备份存储的同时还能将访问分布在集群中的各个服务器之上,是传统存储构架的一个颠覆性的发展[1]。
1.2研究内容
HDFS的每个数据块分布在不同机架的一组服务器之上,在用户访问时,HDFS将会计算使用网络最近的和访问量最小的服务器给用户提供访问。
由于数据块的每个复制拷贝都能提供给用户访问,而不是从单数据源读取,HDFS对于单数据块的访问将是传统存储方案的数倍。
HDFS是一个的主从结构,一个HDFS集群是由一个名字节点,它是一个管理文件命名空间和调节客户端访问文件的主服务器,当然还有一些数据节点,通常是一个节点一个机器,它来管理对应节点的存储。
HDFS对外开放文件命名空间并允许用户数据以文件形式存储。
内部机制是将一个文件分割成一个或多个块,这些块被存储在一组数据节点中。
名字节点用来操作文件命名空间的文件或目录操作,如打开,关闭,重命名等等。
它同时确定块与数据节点的映射。
数据节点来负责来自文件系统客户的读写请求。
数据节点同时还要执行块的创建,删除,和来自名字节点的块复制指令。
名字节点和数据节点都是运行在普通的机器之上的软件,机器典型的都是GNU/Linux,HDFS是用java编写的,任何支持java的机器都可以运行名字节点或数据节点,利用java语言的超轻便型,很容易将HDFS部署到大范围的机器上。
典型的部署是由一个专门的机器来运行名字节点软件,集群中的其他每台机器运行一个数据节点实例。
体系结构不排斥在一个机器上运行多个数据节点的实例,但是实际的部署不会有这种情况。
集群中只有一个名字节点极大地简单化了系统的体系结构。
名字节点是仲裁者和所有HDFS元数据的仓库,用户的实际数据不经过名字节点[2]。
1.3研究方法和技术路线
设计首先搭建虚拟机下ubuntu中的云计算环境,在本机安装eclipse并进行配置使得本机可以与ubuntu下的云计算进行通讯。
逐次对源代码进行分析和实践,了解hdfs各个功能和实现原理。
大部分的HDFS程序对文件操作需要的是一次写多次读取的操作模式。
一个文件一旦创建、写入、关闭之后就不需要修改了。
在靠近计算数据所存储的位置来进行计算是最理想的状态,尤其是在数据集特别巨大的时候。
这样消除了网络的拥堵,提高了系统的整体吞吐量[3]。
1.4预期的研究目标
在本次设计中,我们首先搭建虚拟机下ubuntu中的云计算环境,在本机安装eclipse并进行配置使得本机可以与ubuntu下的云计算进行通讯。
后逐次对源代码进行分析和实践,了解hdfs各个功能和实现原理,并可以通过自编程序实现hdfs的基本功能。
2HDFS简介
2.1分布式文件系统HDFS特性
2.1.1高吞吐量访问
HDFS的每个数据块分布在不同机架的一组服务器之上,在用户访问时,HDFS将会计算使用网络最近的和访问量最小的服务器给用户提供访问。
由于数据块的每个复制拷贝都能提供给用户访问,而不是从单数据源读取,HDFS对于单数据块的访问是传统存储方案的数倍[4]。
HDFS通过分布式计算的算法,将数据访问均摊到服务器阵列中的每个服务器的多个数据拷贝之上,单个硬盘或服务器的吞吐量限制都可以数倍甚至数百倍的突破,提供了极高的数据吞吐量。
2.1.2无缝容量扩充
HDFS将文件的数据块分配信息存放在NameNode服务器之上,文件数据块的信息分布地存放在DataNode服务器上。
当整个系统容量需要扩充时,只需要增加DataNode的数量,系统会自动地实时将新的服务器匹配进整体阵列之中。
之后,文件的分布算法会将数据块搬迁到新的DataNode之中,不需任何系统宕机维护或人工干预。
通过以上实现,HDFS可以做到在不停止服务的情况下实时地加入新的服务器作为分布式文件系统的容量升级,不需要人工干预文件的重新分布[5]。
2.1.3高度容错
HDFS文件系统假设系统故障(服务器、网络、存储故障等)是常态,而不是异常。
因此通过多方面保证数据的可靠性。
数据在写入时被复制多份,并且可以通过用户自定义的复制策略分布到物理位置不同的服务器上;数据在读写时将自动进行数据的校验,一旦发现数据校验错误将重新进行复制;HDFS系统在后台自动连续的检测数据的一致性,并维持数据的副本数量在指定的复制水平上[6]。
2.2HDFS基本概念
2.2.1数据块
HDFS默认的最基本的存储单位是64M的数据块block。
大文件会被分割成多个block进行存储,每一个block会在多个datanode上存储多份副本,默认是3份。
2.2.2元数据节点和数据节点
元数据节点用来管理文件系统的命名空间
Ø其将所有的文件和文件夹的元数据保存在一个文件系统树中。
Ø这些信息也会在硬盘上保存成以下文件:
命名空间镜像(namespaceimage)及修改日志(editlog)
Ø其还保存了一个文件包括哪些数据块,分布在哪些数据节点上。
然而这些信息并不存储在硬盘上,而是在系统启动的时候从数据节点收集而成的。
数据节点是文件系统中真正存储数据的地方。
Ø客户端(client)或者元数据信息(namenode)可以向数据节点请求写入或者读出数据块。
Ø其周期性的向元数据节点回报其存储的数据块信息。
从元数据节点(secondarynamenode)
Ø从元数据节点并不是元数据节点出现问题时候的备用节点,它和元数据节点负责不同的事情。
Ø其主要功能就是周期性将元数据节点的命名空间镜像文件和修改日志合并,以防日志文件过大。
这点在下面会相信叙述。
合并过后的命名空间镜像文件也在从元数据节点保存了一份,以防元数据节点失败的时候,可以恢复[7]。
图2-1元数据节点的目录结构
${dfs.name.dir}/current/VERSION
/edits
/fsimage
/fstime
图2-2从元数据节点的目录结构
${fs.checkpoint.dir}/current/VERSION
/edits
/feimage
/fstime
/previous.checkpoint/VERSION
/edits
/fsimage
/fstime
图2-3数据节点的目录结构
${dfs.data.dir}/current/VERSION
/blk_
/blk_.meta
/blk_
/blk_.meta
/…
/blk_
/blk_.meta
/subdir0/
/subdir1/
/…
/subdir63/
2.2.3文件系统命名空间映像文件及修改日志
当文件系统客户端(client)进行写操作时,首先把它记录在修改日志中(editlog)
元数据节点在内存中保存了文件系统的元数据信息。
在记录了修改日志后,元数据节点则修改内存中的数据结构。
每次的写操作成功之前,修改日志都会同步(sync)到文件系统。
fsimage文件,也即命名空间映像文件,是内存中的元数据在硬盘上的checkpoint,它是一种序列化的格式,并不能够在硬盘上直接修改。
同数据的机制相似,当元数据节点失败时,则最新checkpoint的元数据信息从fsimage加载到内存中,然后逐一重新执行修改日志中的操作。
从元数据节点就是用来帮助元数据节点将内存中的元数据信息checkpoint到硬盘上的
checkpoint的过程如下:
从元数据节点通知元数据节点生成新的日志文件,以后的日志都写到新的日志文件中。
从元数据节点用httpget从元数据节点获得fsimage文件及旧的日志文件。
从元数据节点将fsimage文件加载到内存中,并执行日志文件中的操作,然后生成新的fsimage文件。
从元数据节点奖新的fsimage文件用httppost传回元数据节点
元数据节点可以将旧的fsimage文件及旧的日志文件,换为新的fsimage文件和新的日志文件(第一步生成的),然后更新fstime文件,写入此次checkpoint的时间。
这样元数据节点中的fsimage文件保存了最新的checkpoint的元数据信息,日志文件也重新开始,不会变的很大了[8]。
如图是Namenode与secondarynamenode之间的进行checkpoint的过程。
图2-4checkpoint的过程
2.2.4HDFS中的数据流
读文件
*客户端(client)用FileSystem的open()函数打开文件
*DistributedFileSystem用RPC调用元数据节点,得到文件的数据块信息。
*对于每一个数据块,元数据节点返回保存数据块的数据节点的地址。
*DistributedFileSystem返回FSDataInputStream给客户端,用来读取数据。
*客户端调用stream的read()函数开始读取数据。
*DFSInputStream连接保存此文件第一个数据块的最近的数据节点。
*Data从数据节点读到客户端(client)
*当此数据块读取完毕时,DFSInputStream关闭和此数据节点的连接,然后连接此文件下一个数据块的最近的数据节点。
*当客户端读取完毕数据的时候,调用FSDataInputStream的close函数。
*在读取数据的过程中,如果客户端在与数据节点通信出现错误,则尝试连接包含此数据块的下一个数据节点。
*失败的数据节点将被记录,以后不再连接[9]。
整个过程就是如图所示:
图2-5读文件的过程
写文件
*客户端调用create()来创建文件
*DistributedFileSystem用RPC调用元数据节点,在文件系统的命名空间中创建一个新的文件。
*元数据节点首先确定文件原来不存在,并且客户端有创建文件的权限,然后创建新文件。
*DistributedFileSystem返回DFSOutputStream,客户端用于写数据。
*客户端开始写入数据,DFSOutputStream将数据分成块,写入dataqueue。
*Dataqueue由DataStreamer读取,并通知元数据节点分配数据节点,用来存储数据块(每块默认复制3块)。
分配的数据节点放在一个pipeline里。
*DataStreamer将数据块写入pipeline中的第一个数据节点。
第一个数据节点将数据块发送给第二个数据节点。
第二个数据节点将数据发送给第三个数据节点。
*DFSOutputStream为发出去的数据块保存了ackqueue,等待pipeline中的数据节点告知数据已经写入成功。
*如果数据节点在写入的过程中失败:
(1)关闭pipeline,将ackqueue中的数据块放入dataqueue的开始。
(2)当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示,则错误节点重启后能够察觉其数据块是过时的,会被删除。
(3)失败的数据节点从pipeline中移除,另外的数据块则写入pipeline中的另外两个数据节点。
(4)元数据节点则被通知此数据块是复制块数不足,将来会再创建第三份备份。
(5)当客户端结束写入数据,则调用stream的close函数。
此操作将所有的数据块写入pipeline中的数据节点,并等待ackqueue返回成功。
最后通知元数据节点写入完毕[10]。
整个过程如图所示:
图2-6写文件的过程
2.3HDFS构架与设计
Hadoop也是一个能够分布式处理大规模海量数据的软件框架,这一切都是在可靠、高效、可扩展的基础上。
Hadoop的可靠性——因为Hadoop假设计算元素和存储会出现故障,因为它维护多个工作数据副本,在出现故障时可以对失败的节点重新分布处理。
Hadoop的高效性——在MapReduce的思想下,Hadoop是并行工作的,以加快任务处理速度。
Hadoop的可扩展——依赖于部署Hadoop软件框架计算集群的规模,Hadoop的运算是可扩展的,具有处理PB级数据的能力。
Hadoop主要由HDFS(HadoopDistributedFileSystem)和MapReduce引擎两部分组成。
最底部是HDFS,它存储Hadoop集群中所有存储节点上的文件。
HDFS的上一层是MapReduce引擎,该引擎由JobTrackers和TaskTrackers组成。
HDFS可以执行的操作有创建、删除、移动或重命名文件等,架构类似于传统的分级文件系统。
需要注意的是,HDFS的架构基于一组特定的节点而构建(参见图2),这是它自身的特点。
HDFS包括唯一的NameNode,它在HDFS内部提供元数据服务;DataNode为HDFS提供存储块。
由于NameNode是唯一的,这也是HDFS的一个弱点(单点失败)。
一旦NameNode故障,后果可想而知[11]。
2.3.1HDFS构架(如图所示)
图2-7HDFS构架
2.3.2HDFS的设计
1)错误检测和快速、自动的恢复是HDFS的核心架构目标。
2)比之关注数据访问的低延迟问题,更关键的在于数据访问的高吞吐量。
3)HDFS应用对文件要求的是write-one-read-many访问模型。
4)移动计算的代价比之移动数据的代价低。
2.3.3文件系统的namespace
Namenode维护文件系统的namespace,一切对namespace和文件属性进行修改的都会被namenode记录下来,连文件副本的数目称为replication因子,这个也是由namenode记录的[12]。
2.3.4数据复制
Namenode全权管理block的复制,它周期性地从集群中的每个Datanode接收心跳包和一个Blockreport。
心跳包的接收表示该Datanode节点正常工作,而Blockreport包括了该Datanode上所有的block组成的列表。
HDFS采用一种称为rack-aware的策略来改进数据的可靠性、有效性和网络带宽的利用。
完成对副本的存放[13]。
2.3.5文件系统元数据的持久化
Namenode在内存中保存着整个文件系统namespace和文件Blockmap的映像。
这个关键的元数据设计得很紧凑,因而一个带有4G内存的Namenode足够支撑海量的文件和目录。
当Namenode启动时,它从硬盘中读取Editlog和FsImage,将所有Editlog中的事务作用(apply)在内存中的FsImage,并将这个新版本的FsImage从内存中flush到硬盘上,然后再truncate这个旧的Editlog,因为这个旧的Editlog的事务都已经作用在FsImage上了。
这个过程称为checkpoint[15]。
2.3.6通信协议
所有的HDFS通讯协议都是构建在TCP/IP协议上。
客户端通过一个可配置的端口连接到Namenode,通过ClientProtocol与Namenode交互。
而Datanode是使用DatanodeProtocol与Namenode交互。
从ClientProtocol和Datanodeprotocol抽象出一个远程调用(RPC),在设计上,Namenode不会主动发起RPC,而是是响应来自客户端和Datanode的RPC请求[16]。
2.4HDFS的主要设计理念
2.4.1存储超大文件
这里的“超大文件”是指几百MB、GB甚至TB级别的文件。
2.4.2最高效的访问模式是一次写入、多次读取(流式数据访问)
HDFS存储的数据集作为hadoop的分析对象。
在数据集生成后,长时间在此数据集上进行各种分析。
每次分析都将设计该数据集的大部分数据甚至全部数据,因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更