Hadoop由三个模块组成:分布式存储HDFS、分布式计算MapReduce、资源调度引擎Yarn
NameNode负责:文件元数据信息的操作以及处理客户端的请求
NameNode管理:HDFS文件系统的命名空间NameSpace。
NameNode维护:文件系统树(FileSystem)以及文件树中所有的文件和文件夹的元数据信息(matedata)维护文件到块的对应关系和块到节点的对应关系
NameNode文件:namespace镜像文件(fsimage),操作日志文件(edit log)这些信息被Cache在RAM中,当然这两个文件也会被持久化存储在本地硬盘。
NameNode记录:每个文件中各个块所在的数据节点的位置信息。但它并不永久保存块的位置信息,因为这些信息在系统启动时由数据节点重建。从数据节点重建:在nameNode启动时,DataNode向NameNode进行注册时发送给NameNode
文件名,文件目录结构,文件属性(生成时间,副本数,权限)每个文件的块列表。以及列表中的块与块所在的DataNode之间的地址映射关系 在内存中加载文件系统中每个文件和每个数据块的引用关系(文件、block、datanode之间的映射信息) 数据会定期保存到本地磁盘,但不保存block的位置信息而是由DataNode注册时上报和在运行时维护
NameNode负责文件元数据的操作 ,DataNode负责处理文件内容的读写请求,数据流不经过NameNode,会询问它跟那个DataNode联系
文件数据块到底存放到哪些DataNode上,是由NameNode决定的,NN根据全局情况做出放置副本的决定读取文件的时候,NN尽量让client读取离它最近的datanode上的副本,降低带宽消耗和读取时延
全权管理数据块的复制,周期性的接受心跳和块的状态报告信息(包含该DataNode上所有数据块的列表)
若接受到心跳信息,NN认为DN工作正常,如果在10分钟后还接受到不到DN的心跳,那么NN认为DN已经宕机 这时候NN准备要把DN上的数据块进行重新的复制。 块的状态报告包含了一个DN上所有数据块的列表,blocks report 每个1小时发送一次
没有Namenode,HDFS就不能工作。事实上,如果运行namenode的机器坏掉的话,系统中的文件将会完全丢失,因为没有其他方法能够将位于不同datanode上的文件块(blocks)重建文件。因此,namenode的容错机制非常重要,Hadoop提供了两种机制。
第一种方式是将持久化存储在本地硬盘的文件系统元数据备份。Hadoop可以通过配置来让Namenode将他的持久化状态文件写到不同的文件系统中。这种写操作是同步并且是原子化的。比较常见的配置是在将持久化状态写到本地硬盘的同时,也写入到一个远程挂载的网络文件系统(NFS)。
第二种方式是运行一个辅助的Namenode(SecondaryNamenode)。 事实上SecondaryNamenode并不能被用作Namenode它的主要作用是定期的将Namespace镜像与操作日志文件(edit log)合并,以防止操作日志文件(edit log)变得过大。通常,SecondaryNamenode 运行在一个单独的物理机上,因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份,万一哪天Namenode宕机了,这个备份就可以用上了。
但是辅助Namenode总是落后于主Namenode,所以在Namenode宕机时,数据丢失是不可避免的。在这种情况下,一般的,要结合第一种方式中提到的远程挂载的网络文件系统(NFS)中的Namenode的元数据文件来使用,把NFS中的Namenode元数据文件,拷贝到辅助Namenode,并把辅助Namenode作为主Namenode来运行。
一个集群可能包含上千个DataNode节点,这些DataNode定时和NameNode进行通信,接受NameNode的指令 为了减轻NameNode的负担,NameNode上并不永久保存哪个DataNode上有哪些数据块的信息,而是通过DataNode启动时的上报来更新NameNode上的映射表。
根据客户端或者是namenode的调度存储和检索数据,并且定期向namenode发送所存储的块(block)的列表,数据块在DataNode进程所在的节点上以文件的形式存储在本地磁盘上 ,一个是数据本身 ,一个是元数据(数据块的长度,块数据的校验和,以及时间戳),维护blockid与DataNode之间的映射信息(元信息)
datanode启动时,每个datanode对本地磁盘进行扫描,将本datanode上保存的block信息汇报给namenode namenode在接收到的block信息以及该block所在的datanode信息等保存在内存中。
DataNode启动后向NameNode注册,通过后周期性(1小时)的向NameNode上报所有的块信息.
(1)通过向NameNode发送心跳保持与其联系(3秒一次),心跳返回结果带有NN的命令 ,返回的命令为:如块的复制,删除某个数据块……
(2)如果10分钟没有收到DataNode的心跳,则认为其已经lost,并copy其上的block到其它DataNode
(3)DN在其文件创建后三周进行验证其checkSum的值是否和文件创建时的checkSum值一致
集群中的每个服务器都运行一个DataNode后台程序,这个后台程序负责把HDFS数据块读写到本地的文件系统。 当需要通过客户端读/写某个数据时,先由NameNode告诉客户端去哪个DataNode进行具体的读/写操作 然后,客户端直接与这个DataNode服务器上的后台程序进行通信,并且对相关的数据块进行读/写操作。
SecondaryNameNode是HDFS架构中的一个组成部分,但是经常由于名字而被人误解它真正的用途,其实它真正的用途,是用来保存namenode中对HDFS metadata的信息的备份,并减少namenode重启的时间。对于hadoop进程中,要配置好并正确的使用snn,还是需要做一些工作的。hadoop的默认配置中让snn进程默认运行在了namenode的那台机器上,但是这样的话,如果这台机器出错,宕机,对恢复HDFS文件系统是很大的灾难,更好的方式是:将snn的进程配置在另外一台机器上运行。
在hadoop中,namenode负责对HDFS的metadata的持久化存储,并且处理来自客户端的对HDFS的各种操作的交互反馈。为了保证交互速度,HDFS文件系统的metadata是被load到namenode机器的内存中的,并且会将内存中的这些数据保存到磁盘进行持久化存储。为了保证这个持久化过程不会成为HDFS操作的瓶颈,hadoop采取的方式是:没有对任何一次的当前文件系统的snapshot进行持久化,对HDFS最近一段时间的操作list会被保存到namenode中的一个叫Editlog的文件中去。当重启namenode时,除了load fslmage意外,还会对这个Editlog文件中记录的HDFS操作进行replay,以恢复HDFS重启之前的最终状态。
而SecondaryNameNode,会周期性的将Editlog中记录的对HDFS的操作合并到一个checkpoint中,然后清空Editlog。所以namenode的重启就会Load最新的一个checkpoint,并重现Editlog中记录的hdfs操作,由于Editlog中记录的是从上一次checkpoint以后到现在的操作列表,所以就会比较小。如果没有SecondaryNameNode的这个周期性的合并过程,那么当每次重启namenode的时候,就会花费很长的时间。而这样周期性的合并就能减少重启的时间。同时也能保证HDFS系统的完整性。
这就是SecondaryNameNode所做的事情。所以snn并不能分担namenode上对HDFS交互性操作的压力。尽管如此,当namenode机器宕机或者namenode进程出问题时,namenode的daemon进程可以通过人工的方式从snn上拷贝一份metadata来恢复HDFS文件系统。
至于为什么要将snn进程运行在一台非NameNode的机器上,这主要出于两点考虑:
1、可扩展性:创建一个新的HDFS的snapshot(快照)需要将namenode中load到内存的metadata信息全部拷贝一遍,这样的操作需要的内存和namenode占用的内存一样,由于分配给namenode进程的内存其实是对HDFS文件系统的限制,如果分布式文件系统非常的大,那么namenode那台机器的内存就可能会被namenode进程全部占据。
2、容错性:当snn创建一个checkpoint的时候,它会将checkpoint拷贝成metadata的几个拷贝。将这个操作运行到另外一台机器,还可以提供分布式文件系统的容错性。
SECONDARYNAMENODE工作原理
日志与镜像的定期合并总共分五步:
1、SecondaryNameNode通知NameNode准备提交edits文件,此时主节点产生edits.new
2、SecondaryNameNode通过http get方式获取NameNode的fsimage与edits文件(在SecondaryNameNode的current同级目录下可见到 temp.check-point或者previous-checkpoint目录,这些目录中存储着从namenode拷贝来的镜像文件)
3、SecondaryNameNode开始合并获取的上述两个文件,产生一个新的fsimage文件fsimage.ckpt
4、SecondaryNameNode用http post方式发送fsimage.ckpt至NameNode
5、NameNode将fsimage.ckpt与edits.new文件分别重命名为fsimage与edits,然后更新fstime,整个checkpoint过程到此结束。 在新版本的hadoop中(hadoop0.21.0),SecondaryNameNode两个作用被两个节点替换, checkpoint node与backup node. SecondaryNameNode备份由三个参数控制fs.checkpoint.period控制周期,fs.checkpoint.size控制日志文件超过多少大小时合并, dfs.http.address表示http地址,这个参数在SecondaryNameNode为单独节点时需要设置。
工作原理:
Hadoop的HDFS集群非常容易出现机器与机器之间磁盘利用率不平衡的情况,例如:当集群内新增、删除节点,或者某个节点机器内硬盘存储达到饱和值。当数据不平衡时,Map任务可能会分配到没有存储数据的机器,这将导致网络带宽的消耗,也无法很好的进行本地计算。
当HDFS负载不均衡时,需要对HDFS进行数据的负载均衡调整,即对各节点机器上数据的存储分布进行调整。从而,让数据均匀的分布在各个DataNode上,均衡IO性能,防止热点的发生。进行数据的负载均衡调整,必须要满足如下原则:
c(1)数据平衡不能导致数据块减少,数据块备份丢失
(2)管理员可以中止数据平衡进程
(3)每次移动的数据量以及占用的网络资源,必须是可控的
(4)数据均衡过程,不能影响namenode的正常工作
负载均衡原理如下:
在了解读写过程之前先了了解基本的概念:
在DFSClient写HDFS的过程中,有三个需要搞清楚的单位:block、packet与chunk;
block是最大的一个单位,它是最终存储于DataNode上的数据粒度,由dfs.block.size参数决定,默认是64M;注:这个参数由客户端配置决定;
packet是中等的一个单位,它是数据由DFSClient流向DataNode的粒度,以dfs.write.packet.size参数为参考值,默认是64K;注:这个参数为参考值,是指真正在进行数据传输时,会以它为基准进行调整,调整的原因是一个packet有特定的结构,调整的目标是这个packet的大小刚好包含结构中的所有成员,同时也保证写到DataNode后当前block的大小不超过设定值;
chunk是最小的一个单位,它是DFSClient到DataNode数据传输中进行数据校验的粒度,由io.bytes.per.checksum参数决定,默认是512B;
注:事实上一个chunk还包含4B的校验值,因而chunk写入packet时是516B;数据与检验值的比值为128:1,所以对于一个128M的block会有一个1M的校验文件与之对应;
联系客服