Hadoop基础-Hdfs各个组件的运行原理介绍
作者:尹正杰
版权声明:原创作品,谢绝转载!否则将追究法律责任。
一.NameNode工作原理(默认端口号:50070)
1>.什么是NameNode
NameNode管理文件系统的命名空间。它维护着文件系统树及整棵树内所有的文件和目录。这些信息以两个文件形式永久保存在本地磁盘上:命名空间镜像文件和编辑日志文件。NameNode也记录着每个文件中各个块所在的数据节点信息,但它并不永久保存块的位置信息,因为这些信息在系统启动时由数据节点重建。
2>.Name启动流程
NameNode职责: 1>.负责客户端请求的响应 2>.元数据的管理(查询,修改) NameNode对数据的管理采用了三种存储形式: 1>.内存元数据(NameSystem) 2>.磁盘元数据镜像文件 3>.数据操作日志文件(可通过日志运算出元数据) 元数据存储机制: 1>.内存中有一份完整的元数据(内存meta data) 2>.磁盘有一个“准完整”的元数据镜像(fsimage)文件(在namenode的工作目录中) 3>.用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志(edits文件) NameNode启动流程概述: 1>.第一次启动NameNode格式化后,创建fsimage和edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。 2>.客户端对元数据进行增删改的请求 3>.NameNode记录操作日志,更新滚动日志。 4>.namenode在内存中对数据进行增删改查 在NameNode端的工作流程如下: 1>.Namenode始终在内存中保存metedata,用于处理“读请求” 到有“写请求”到来时,namenode会首先写edits到磁盘,即向edits文件中写日志,当客户端操作成功后,相应的元数据会更新到内存matedata中,并且向客户端返回. 2>.Hadoop会维护一个fsimage文件,也就是namenode中metedata的镜像,但是fsimage不会随时与namenode内存中的metedata保持一致,而是每隔一段时间通过合并edits文件来更新内容。 查看namenode版本号 1>.在/home/yinzhengjie/data/hadoop/hdfs/ha/dfs/name1/current这个目录下查看VERSION文件, [yinzhengjie@s101 ~]$ cat /home/yinzhengjie/data/hadoop/hdfs/ha/dfs/name1/current/VERSION #Mon Aug 13 14:45:15 EDT 2018 namespaceID=1555352651 clusterID=CID-58730c19-c019-4f4c-97f1-0eb80eab6071 cTime=0 storageType=NAME_NODE blockpoolID=BP-1140132172-172.30.1.101-1534178655035 layoutVersion=-63 [yinzhengjie@s101 ~]$ 2>.namenode版本号具体解释 2.1>.namespaceID在HDFS上,会有多个Namenode,所以不同Namenode的namespaceID是不同的,分别管理一组blockpoolID。 2.2>.clusterID集群id,全局唯一 2.3>.cTime属性标记了namenode存储系统的创建时间,对于刚刚格式化的存储系统,这个属性为0;但是在文件系统升级之后,该值会更新到新的时间戳。 2.4>.storageType属性说明该存储目录包含的是namenode的数据结构。 2.5>.blockpoolID:一个block pool id标识一个block pool,并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中,在后续的启动过程中,会再次load并使用。 2.6>.layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。 namenode的本地目录可以配置成多个,且每个目录存放内容相同,增加了可靠性。具体配置如下: [hdfs-site.xml] <property> <name>dfs.namenode.name.dir</name> <value>file:///${hadoop.tmp.dir}/dfs/name1,file:///${hadoop.tmp.dir}/dfs/name2</value> <--注意,这个值咱们也可以写绝对路径,我测试过好使!--> </property>
3>.NameNode注意事项
第一:如下图所示,第一次启动namenode格式化后,创建fsimage和edits文件
第二:重启hdfs分布式文件系统时,默认会自动滚动编辑日志,如下图所示:
第三:如果不是第一次启动,直接加载编辑日志和镜像文件到内存,如下图所示:
想要了解更多关于镜像文件和编辑日志信息,可参考:https://www.cnblogs.com/yinzhengjie/p/9098092.html。
二.SecondaryNameNode工作原理(默认端口号:50090)
1>.什么是SecondaryNameNode
它是辅助namenode的进程,Secondary NameNode,为主namenode内存中的文件系统元数据创建检查点,Secondary NameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份。
2>.SecondaryNameNode有两个作用
2.1>.镜像备份,即备份fsimage(fsimage是元数据发送检查点时写入文件);
2.2>.日志与镜像的定期合并。简单的说是将Namenode中edits日志和fsimage合并,防止如果Namenode节点故障,namenode下次启动的时候,会把fsimage加载到内存中,应用edits log,edits log往往很大,导致操作往往很耗时。(这也是namenode容错的一套机制)
以上两个过程同时进行,称为checkpoint(检查点)。
3>.NameNode+SecondaryNameNode的工作原理
第一阶段:NameNode启动 1>.第一次启动NameNode格式化后,创建fsimage和edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。 2>.客户端对元数据进行增删改的请求 3>.NameNode记录操作日志,更新滚动日志。 4>.NameNode在内存中对数据进行增删改查 第二阶段:Secondary NameNode工作 1>.Secondary NameNode询问NameNode是否需要checkpoint。直接带回NameNode是否检查结果。 2>.Secondary NameNode请求执行checkpoint。 3>.NameNode滚动正在写的edits日志 4>.将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode 5>.Secondary NameNode加载编辑日志和镜像文件到内存,并合并。 6>.生成新的镜像文件fsimage.chkpoint 7>.拷贝fsimage.chkpoint到NameNode 8>.NameNode将fsimage.chkpoint重新命名成fsimage
检查点和编辑日志存放位置:
chkpoint检查时间参数设置 1>.通常情况下,SecondaryNameNode每隔一小时执行一次。 [hdfs-default.xml] <property> <name>dfs.namenode.checkpoint.period</name> <value>3600</value> </property> 2>.一分钟检查一次操作次数,当操作次数达到1百万时,SecondaryNameNode执行一次。 <property> <name>dfs.namenode.checkpoint.txns</name> <value>1000000</value> <description>操作动作次数</description> </property> <property> <name>dfs.namenode.checkpoint.check.period</name> <value>60</value> <description> 1分钟检查一次操作次数</description> </property> SecondaryNameNode目录结构 Secondary NameNode用来监控HDFS状态的辅助后台程序,每隔一段时间获取HDFS元数据的快照。 在/home/yinzhengjie/hadoop-2.7.3/data/hdfs/dfs/namesecondary/current这个目录中查看SecondaryNameNode目录结构。 edits_0000000000000000001-0000000000000000002 fsimage_0000000000000000002 fsimage_0000000000000000002.md5 VERSION SecondaryNameNode的namesecondary/current目录和主namenode的current目录的布局相同。 好处:在主namenode发生故障时(假设没有及时备份数据),可以从SecondaryNameNode恢复数据。 方法一:将SecondaryNameNode中数据拷贝到namenode存储数据的目录; 方法二:使用-importCheckpoint选项启动namenode守护进程,从而将SecondaryNameNode中数据拷贝到namenode目录中。
三.DataNode工作原理
1>.什么是DataNode
用大白话来说,NameNode用来存储一些元数据信息的,而DataNode却是用来存放真实数据的。
2>.DataNode的工作机制
如上图所示,DataNode和NameNode的通信机制如下:
1>.一个数据块在datanode上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳。
2>.DataNode启动后向namenode注册,通过后,周期性(1小时)的向namenode上报所有的块信息。
3>.心跳是每3秒一次,心跳返回结果带有namenode给该datanode的命令如复制块数据到另一台机器,或删除某个数据块。如果超过10分钟没有收到某个datanode的心跳,则认为该节点不可用。
集群运行中可以安全加入和退出一些机器。这种专业术语叫做集群的服役和退役。关于如何服役和退役详情请参考我之前分享的笔记:https://www.cnblogs.com/yinzhengjie/p/9101070.html
DataNode的校验和是为了保证数据的完整性: 1>.当DataNode读取block的时候,它会计算checksum; 2>.如果计算后的checksum,与block创建时值不一样,说明block已经损坏; 3>.client此时会读取其他DataNode上的block; 4>.datanode在其文件创建后周期验证checksum; 5>.不论数据是否发生改变,DataNode都会定期(默认是一小时)上报数据; 掉线时限参数设置 datanode进程死亡或者网络故障造成datanode无法与namenode通信,namenode不会立即把该节点判定为死亡,要经过一段时间,这段时间暂称作超时时长。HDFS默认的超时时长为10分钟+30秒。如果定义超时时间为timeout,则超时时长的计算公式为:timeout = 2 * dfs.namenode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval。 而默认的dfs.namenode.heartbeat.recheck-interval 大小为5分钟,dfs.heartbeat.interval默认为3秒。需要注意的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒,dfs.heartbeat.interval的单位为秒。 [hdfs-site.xml] <property> <name>dfs.namenode.heartbeat.recheck-interval</name> <value>300000</value> </property> <property> <name> dfs.heartbeat.interval </name> <value>3</value> </property> datanode也可以配置成多个目录,每个目录存储的数据不一样。即:数据不是副本。具体配置如下: [hdfs-site.xml] <property> <name>dfs.datanode.data.dir</name> <value>file:///${hadoop.tmp.dir}/dfs/data1,file:///${hadoop.tmp.dir}/dfs/data2</value> </property>
四.HDFS扫盲(跟你们小伙伴聊天别被他这些简单问题问到了)
1>.请列出正常工作的Hadoop集群中Hadoop都分别需要启动哪些进程,它们的作用分别是什么?
1>.NameNode它是hadoop中的主服务器,管理文件系统名称空间和对集群中存储的文件的访问,保存有metadate。 2>.SecondaryNameNode它不是namenode的冗余守护进程,而是提供周期检查点和清理任务。帮助NN合并editslog,减少NN启动时间。 3>.DataNode它负责管理连接到节点的存储(一个集群中可以有多个节点)。每个存储数据的节点运行一个datanode守护进程。 4>.ResourceManager(JobTracker)JobTracker负责调度DataNode上的工作。每个DataNode有一个TaskTracker,它们执行实际工作。 5>.NodeManager(TaskTracker)执行任务。 6>.DFSZKFailoverController高可用时它负责监控NN的状态,并及时的把状态信息写入ZK。它通过一个独立线程周期性的调用NN上的一个特定接口来获取NN的健康状态。FC也有选择谁作为Active NN的权利,因为最多只有两个节点,目前选择策略还比较简单(先到先得,轮换)。 7>.JournalNode 高可用情况下存放namenode的editlog文件。
2>.
3>.