Hadoop原理详细解析.docx_第1页
Hadoop原理详细解析.docx_第2页
Hadoop原理详细解析.docx_第3页
Hadoop原理详细解析.docx_第4页
Hadoop原理详细解析.docx_第5页
已阅读5页,还剩4页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

HadoopHDFS设计原则 硬件错误是常态而不是异常 流式数据访问 大规模数据集 简单的一致性模型 “移动计算比移动数据更划算” 异构软硬件平台间的可移植性 特性 容灾 大容量/大吞吐量(水平扩展能力) 为mapreduce计算设计的数据本地化能力 系统结构名称节点(NameNode)管理元数据和文件块管理元数据指管理元数据信息。元数据信息包括名字空间、文件到文件块的映射、文件块到数据节点的映射三部分。管理文件块包括创建新文件块、文件复制、移除无效文件块以及回收孤立文件块等内容。(1)字空间或者文件到文件快的映射的任何修改,HDFS都会通过EditLog记录下来。保存到本地磁盘中。通过这种方式可以提高系统的可靠性,并凭借EditLog日志,误中恢复而不必担心数据的一致性问题。(2)块存放的位置信息并不固定而是经常发生变化,因此系统并没有将其持久化到本地中。NameNode启动后并不需要对DataNode进行维护,DataNode会周期性地向NameNode发生心跳响应汇报其文件块信息。(3)所有信息都保存在内存中,所以NameNode可以周期性快速地扫描元数据的状态,然后确定出哪些文件块由于DataNode宕机而需要重新复制,哪些件块需要被回收,哪些文件块需要在DataNode间进行迁移来保证系统的负载均衡等元数据元数据一般有三种类型,都会被保存在NameNode内存中(1) 文件(包括目录)的名称空间,如:/user/hongzhen.lm/search4tag/full/(2) 文件到文件块的映射,如:那个文件由几个文件块(Block)组成(3) 文件块的位置信息,组成Block的文件块持久化在那几个DataNode中。EditLog主要保存了元数据更改的历史信息(执行写操作,如新建文件或移动文件),因此具有非常重要的作用。EditLog不仅持久化记录了元数据信息,也记录了元数据修改顺序的逻辑时间线,而逻辑时间是对文件和文件块进行查找确认的唯一标识。因此,必须保证EditLog存储的安全性与可靠性。为了防止丢失整个文件系统或者客户端最近的几次操作记录,系统应保证在客户端对元数据的修改操作还没记录到EditLog之前,使该操作对其是不可见的。FsImageFsImage 文件是文件系统元数据的持久化检查点,磁盘上的元数据信息。当NameNode出现问题,是可以根据FsImage和EditLog 快速从错误中进行数据恢复,从而保存数据一致性fsImage文件不会更新文件系统的每个写操作,但是不影响系统的弹性,因为如果名称节点失败,其元数据的最新状态可以被重建,具体方式是从磁盘中将FsImage加载到内存,然后将此应用于编辑日志(EditLog)中的每个操作Secondary NameNode如前所述,editLog文件会无限增大,虽然在名称节点运行期间不会对系统产生影响,但如果名称节点发生重新启动,会发很长时间来运行editLog中的每个操作,所以将导致NameNode启动过慢情况。解决方案:并不是NameNode出现问题时候的备用节点,它和NameNode负责不同时期,主要功能是周期性将NameNode的元数据信息FsImage和EditLog合并,防止日志文件EditLog过大。合并后FsImage会在NameNode保存一份,保证NameNode失败可以进行恢复。二级NameNode通知NameNode生成新的EditLog,以后的日志都写到新的日志文件中,然后二级NameNode用那http get从NameNode获得FsImage以及旧的EditLog,然后二级NameNode将FsImage加载到内存中,并执行日志文件中的操作,然后生成新的FsImage.ckpt 再次二级NameNode将旧的FsImage以及旧的EditLog换为新的FsImage和新的EditLog,更新Fstime写入此次检查点发生的时间。这样NameNode中的FsImage保持了最新的checkPoint的元数据信息,日志文件也重新开始写入,保证了大小。管理员可以手工使用命令:hadoop dfsadmin saveNamespace;大型集群。二级节点是需要专用机器的,因为需要将fsimage加载到内存中。内存成为瓶颈管理命名空间NameNode管理文件系统的命名空间。任何对文件系统元数据产生修改的操作,NameNode都会使用事务日志记录(下称EditLog)来表示;同样地,修改文件的副本系数也将往Editlog插入一条记录,NameNode将Editlog存储在本地操作系统的文件系统中。同时,文件系统的命名空间被存储在一个称为Fslmage的文件中,包括文件的属性、文件块到文件的映射以及文件块到数据节点的映射等内容,FsImage文件也是放在NameNode所在的本地文件系统中。监听请求和处理请求监听请求指监听客户端事件和DataNode事件。客户端事件包含名字空间的创建和删除,文件的创建、读写、重命名和删除,文件列表信息获取等信息。DataNode事件主要包括文件块信息、心跳响应、出错信息等。处理请求指处理上面的监听请求事件并返回结果。心跳检测数据节点会定期将自己的负载情况通过心跳信息向名称节点汇报,名称节点才能掌握数据节点的数据块的实际情况。故障恢复数据节点(DataNode)数据读写NameNode对文件块进行创建,删除,复制等操作进行指挥和调度,而实际对数据进行客户端直接对DataNode进行读写操作。报告状态每个DataNode节点会周期性地向NameNode发送心跳信号和文件块状态报告,以便NameNode获取到工作集群中DataNode节点状态的全局视图,从而掌握它们的状态。数据流水线复制由第一个DataNode向第二个DataNode节点复制,如此反复进行下去,直到完成文件块及其块副本的流水线复制。数据数据结构HDFS中存储数据最小单位是一个数据块Block,HDFS默认的数据块大小为64M。一个文件对应的数据块按照一定的部署策略存在于数据节点中。客户端和NameNode交互的需求,对于同一块的读写只需要向NameNode发送一个获取块位置信息的初始请求即可,这极大程度的降低了系统的负荷;其次,因为块足够大,客户端基本可以在一个给定的块上进行多次操作,这也降低了网络交互方面的困难,使其可以在一个时间段内与块服务器之间保持个持久的TCP连接;最后,这种设计方式可以减少在NameNode上存储的元数据的大小。数据交互读数据网络拓扑计算机架感知HDFS读取数据过程如下:(1) client调用get方法得到HDFS文件系统的一个实例(Distributed FileSystem),然后调用它的open方法。(2) DistributedFileSystem通过RPC远程调用NameNode决定文件的block的位置信息。对于每一个bolck,NameNode返回block所在的DataNode(包括副本)的地址,DistributedFileSystem返回FSDatalnputStream给client用来读取数据,FSDatalnputStream封装了DFSlnputStream用于管理NameNode和DataNode的IO。(3) client调用FSDatalnputStream的read方法。(4) DFSInputStream保存了block块所在的DataNode的地址信息,DFSInputStream连接第一个block的DataNode,read block数据,传回给client。(5) 当第一个block读完,DFSInputStream关掉与这个DataNode的连接,然后开第二个block。(6) 当client读结束,调用FSDatalnputStream的close方法。在读的过程中,如果client和一个DataNode通讯时出错,它会连接副本所在的DataNode。这种cliem直接连接DataNode读取数据的设计方法使HDFS可以同时响应很多client的同时并发,因为数据流量均匀的分布在所有的DataNode上,NameNode只需负责block的位置信息请求即可。下图是读数据块时,客户端发送过来的信息写数据(1)客户端调用create()来创建文件。(2)DistributedFileSystem用RPC调用名称节点,在文件系统的命名空间中创建一个新的文件。名称节点首先确定文件原来不存在,并且客户端有创建文件的权限,然后创建新文件,DistributedFileSystem返回FSDataOutputStream,客户端用于写数据。(3)客户端开始写入数据,DFSOutputStream将数据分成块,写入data queue。Data queue由Data Streamer读取,Data Streamer通知NameNode通过分配DataNode,用来存储数据块(每块默认复制3块),分配的DataNode列表形成一个管道(pipeline)。(4)Data Streamer将数据块写入pipeline中的第一个DataNode,第一个DataNode将数据块发送给第二个DataNode,第二个DataNode将数据发送给第三DataNode。(5)同时,DFSOutputStream管理ack queue,ack queue里存储着等待NameNode识别的数据块,只有当管道里所有数据节点都返回写入成功,这个packet才算写成功,才会离开ack queue,开始下一个packet。如果某个数据节点写失败,会产生如下步骤,但是这些对client是透明的。(1)管道关闭。(2)正常的DataNode上正在写的block会有一个新ID(需要和NameNode通信),而失败的DataNode上的那个不完整的block在上报心跳的时候会被删掉。(3)失败的DataNode会被移出管道,block中剩余的packet继续写入管道的其他两个DataNode。(4)NameNode会标记这个block的副本个数少于指定值,block的副本会稍后在另一个DataNode创建。(5)有些时候多个DataNode会失败,只要dfsreplicationmin(缺省是1)个DataNode成功了,整个写入过程就算成功,缺少的副本会进行异步的恢复。(6)当客户端结束写入数据,则调用stream的close函数,此操作将所有的数据块写入pipeline中的数据节点,并等待ack queue返回成功。(7)最后通知NameNode写入完毕。多副本写入写入机制数据管理维护数据的可用性(Availability)和一致性(Consistent,或称可靠性Reliability)既是系统最基本的要求,又是系统最重要的功能。一般来说,系统通过数据复制、节点故障、数据校验、垃圾回收机制来维护数据的可用性和一致性。数据复制(1) 复制块位置复制块放置位置的选择非常重要,因为它将极大地影响HDFS的性能和可靠性。HDFS的这个特征有别于其他的分布式文件系统,复制块放置位置的选择需要很多的调节和经验。通常情况下,HDFS运行在跨越许多机架的集群机器之上,两个不同机架上的节点通过交换机来通信,机架的复制布局是为了提高数据的可用性,可靠性以及带宽利用率。通常情况下,在相同机架上的节点比在不同机架上的节点的网络带宽具有优势。如果都在一个节点,不会损失带宽,但是并没有实现冗余(节点Down机,导致数据丢失)但是跨机架或者跨机房读取,将有很大的读写带宽消耗,所以需要在可靠性和写入带宽和读入带宽之间做出权衡目前副本放置规则:是将第一个放在本地节点,将第二个复制放到本地机架上的另外一个节点而将第三个复制放到不同机架上的节点。因为文件块被保存在两个不同的机架上,而不是三个,这就在保证数据的可靠性和可用性的前提下,减少了读操作的网络聚合带宽(2) 复制块的选择出于全局带宽消耗和读取延迟等因素考虑,HDFS会使用离读请求的发起者最近处的复制块内容去响应。读请求所在机架上的复制块会被优先用于响应,如果一个HDFS集群跨越多个数据中心,则本地数据中心的复制块内容会被优先考虑数据节点故障恢复所有的DataNode都会周期性地向NameNode发送“心跳”响应消息,如果发生网络赦障,将会导致部分DataNode与NameNode服务失去连接而不能发送“心跳”响应。NameNode将会通过没有接收到“心跳”响应而检测到DataNode所发生的故障。NameNode将停止发送“心跳”响应的DataNode标记为“死亡”,并且停止将任何新的IO请求转发给它们。对于HDFS来说,标记为“死亡”的DataNode服务器上的数据是不可用的,DataNode的死亡还会引起部分数据块的复制因子下降到低于指定值。NameNode会定时追踪这些数据块,并在需要时进行复制操作。当发生如下几种情况时,会引发复制操作的进行:一个DataNode变为不可用状态,一个复制操作失败,DataNode上的硬盘故障,一个文件的复制因子变大等。数据校验当软件错误,网络故障,存储设备故障等问题发生时,将可能会造成数据块的损坏。HDFS客户端软件将会对HDFS文件中的内容进行校验。当一个客户端在创建一个HDFS文件的时候,会计算这个文件中每个数据块内容的校验和,同时将这些校验和存储在一个单独的隐藏文件中,并将其存储在同样的HDFS命名空间中。当一个客户端获取到一个文件时会自动校验这个文件的校验和是否正确。如果出现校验失败,则会选择从其他的DataNode获取该文件的拷贝。文件删除和恢复第一,文件的删除和恢复。用户或者应用程序删除文件时,文件并没有立刻被删除。其执行过程是HDFS首先重命名该文件,然后将该文件保存为trash目录下的一个文件中。系统可以把文件在trash目录中保存一段时间,同时被删除

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论