大数据教程（7.3）namenode管理元数据的机制&datanode工做机制介绍

时间 2019-11-10

标签数据教程 7.3 namenode 管理机制 datanode 介绍繁體版

原文原文链接

前面两篇博客介绍了HDFS客户端读写数据流程，本篇博主将带给小伙伴们namenode和datanode的工做机制的分享。node

1、目标mysql

理解namenode的工做机制尤为是元数据管理机制，以加强对HDFS工做原理的理解，及培养hadoop集群运营中“性能调优”、“namenode”故障问题的分析解决能力。web

问题场景：redis

一、集群启动后，能够查看文件，可是上传文件时报错，打开web页面能够看到namenode正处于safemode状态，怎么处理？sql

二、Namenode服务器的磁盘故障致使namenode宕机，如何挽救集群及数据？数据库

三、Namenode是否能够有多个？namenode内存要配置多大？namenode跟集群数据存储能力有关系吗？缓存

四、文件的blocksize究竟调大好仍是调小好？服务器

....网络

诸如此类问题的回答，都须要基于对namenode自身的工做原理的深入理解数据结构

2、namenode的职责

负责HDFS客户端请求的响应，元数据的管理（查询，修改）

3、namenode元数据管理

namenode对数据的管理采用了三种存储形式：内存元数据(NameSystem)、磁盘元数据镜像文件、数据操做日志文件（可经过日志运算出元数据）

1.元数据存储机制：

                A、内存中有一份完整的元数据(内存meta data)
                B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工做目录中)
                C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操做日志（edits文件）

注：当客户端对hdfs中的文件进行新增或者修改操做，操做记录首先被记入edits日志文件中，当客户端操做成功后，相应的元数据会更新到内存meta.data中。

2.元数据手动查看

能够经过hdfs的一个工具来查看edits中的信息
bin/hdfs oev -i edits -o edits.xml
bin/hdfs oiv -i fsimage_0000000000000000087 -p XML -o fsimage.xml

3.元数据的checkpoint

每隔一段时间，会由secondary namenode将namenode上积累的全部edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程称为checkpoint）

checkpoint的详细过程：

checkpoint操做的触发条件配置参数：

dfs.namenode.checkpoint.check.period=60  #检查触发条件是否知足的频率，60秒
dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary
#以上两个参数作checkpoint操做时，secondary namenode的本地工做目录
dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}

dfs.namenode.checkpoint.max-retries=3  #最大重试次数
dfs.namenode.checkpoint.period=3600  #两次checkpoint之间的时间间隔3600秒
dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操做记录

checkpoint的附带做用：namenode和secondary namenode的工做目录存储结构彻底相同，因此，当namenode故障退出须要从新恢复时，能够从secondary namenode的工做目录中将fsimage拷贝到namenode的工做目录，以恢复namenode的元数据，secondNameNode没法替代namenode,它只作数据合并、备份。

4.元数据目录说明

在第一次部署好Hadoop集群的时候，咱们须要在NameNode（NN）节点上格式化磁盘：

#执行格式化，若是已经配置了hadoop环境则不须要带全路径执行
$HADOOP_HOME/bin/hdfs namenode -format

格式化完成以后，将会在$dfs.namenode.name.dir/current目录下以下的文件结构

current/
|-- VERSION
|-- edits_*
|-- fsimage_0000000000008547077
|-- fsimage_0000000000008547077.md5
`-- seen_txid

其中的dfs.name.dir是在hdfs-site.xml文件中配置的，默认值以下：

<property>
  <name>dfs.name.dir</name>
  <value>file://${hadoop.tmp.dir}/dfs/name</value>
</property>

hadoop.tmp.dir是在core-site.xml中配置的，默认值以下
<property>
  <name>hadoop.tmp.dir</name>
  <value>/tmp/hadoop-${user.name}</value>
  <description>A base for other temporary directories.</description>
</property>

dfs.namenode.name.dir属性能够配置多个目录，如/data1/dfs/name,/data2/dfs/name,/data3/dfs/name,....。各个目录存储的文件结构和内容都彻底同样，至关于备份，这样作的好处是当其中一个目录损坏了，也不会影响到Hadoop的元数据，特别是当其中一个目录是NFS（网络文件系统Network File System，NFS）之上，即便你这台机器损坏了，元数据也获得保存。
下面对$dfs.namenode.name.dir/current/目录下的文件进行解释：

(1)、VERSION文件是Java属性文件，内容大体以下：

#Fri Nov 15 19:47:46 CST 2013
namespaceID=934548976
clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196
cTime=0
storageType=NAME_NODE
blockpoolID=BP-893790215-192.168.24.72-1383809616115
layoutVersion=-47

                   （a）、namespaceID是文件系统的惟一标识符，在文件系统首次格式化以后生成的
（b）、storageType说明这个文件存储的是什么进程的数据结构信息（若是是DataNode，storageType=DATA_NODE）
     （c）、cTime表示NameNode存储时间的建立时间，因为个人NameNode没有更新过，因此这里的记录值为0，之后对NameNode升级以后，cTime将会记录更新时间戳
                   （d）、layoutVersion表示HDFS永久性数据结构的版本信息，只要数据结构变动，版本号也要递减，此时的HDFS也须要升级，不然磁盘仍旧是使用旧版本的数据结构，这会致使新版本的NameNode没法使用

（e）、clusterID是系统生成或手动指定的集群ID，在-clusterid选项中可使用它，以下说明

a、使用以下命令格式化一个Namenode：$HADOOP_HOME/bin/hdfs namenode -format [-clusterId <cluster_id>]选择一个惟一的cluster_id，而且这个cluster_id不能与环境中其余集群有冲突。若是没有提供cluster_id，则会自动生成一个惟一的ClusterID。
b、使用以下命令格式化其余Namenode：$HADOOP_HOME/bin/hdfs namenode -format -clusterId <cluster_id>
c、升级集群至最新版本。在升级过程当中须要提供一个ClusterID，例如：$HADOOP_PREFIX_HOME/bin/hdfs start namenode --config $HADOOP_CONF_DIR  -upgrade -clusterId <cluster_ID>若是没有提供ClusterID，则会自动生成一个ClusterID。

（f）、blockpoolID：是针对每个Namespace所对应的blockpool的ID，上面的这个BP-893790215-192.168.24.72-1383809616115就是在个人ns1的namespace下的存储块池的ID，这个ID包括了其对应的NameNode节点的ip地址。

二、$dfs.namenode.name.dir/current/seen_txid很是重要，是存放transactionId的文件，format以后是0，它表明的是namenode里面的edits_*文件的尾数，namenode重启的时候，会按照seen_txid的数字，循序从头跑edits_0000001~到seen_txid的数字。因此当你的hdfs发生异常重启的时候，必定要比对seen_txid内的数字是否是你edits最后的尾数，否则会发生建置namenode时metaData的资料有缺乏，致使误删Datanode上多余Block的资讯。
三、$dfs.namenode.name.dir/current目录下在format的同时也会生成fsimage和edits文件，及其对应的md5校验文件。

补充：seen_txid文件中记录的是edits滚动的序号，每次重启namenode时，namenode就知道要将哪些edits进行加载edits

4、datanode的工做机制

               问题场景：
          一、集群容量不够，怎么扩容？
                    二、若是有一些datanode宕机，该怎么办？
                    三、datanode明明已启动，可是集群中的可用datanode列表中就是没有，怎么办？

以上这类问题的解答，有赖于对datanode工做机制的深入理解

一、Datanode工做职责：存储管理用户的文件块数据、按期向namenode汇报自身所持有的block信息（经过心跳信息上报）（这点很重要，由于，当集群中发生某些block副本失效时，集群如何恢复block初始副本数量的问题）

<!--配置上报时间间隔3600s-->
<property>
	<name>dfs.blockreport.intervalMsec</name>
	<value>3600000</value>
	<description>Determines block reporting interval in milliseconds.</description>
</property>

二、Datanode掉线判断时限参数
datanode进程死亡或者网络故障形成datanode没法与namenode通讯，namenode不会当即把该节点断定为死亡，要通过一段时间，这段时间暂称做超时时长。HDFS默认的超时时长为10分钟+30秒。若是定义超时时间为timeout，则超时时长的计算公式为：

timeout  = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval。

而默认的heartbeat.recheck.interval 大小为5分钟，dfs.heartbeat.interval默认为3秒。须要注意的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒，dfs.heartbeat.interval的单位为秒。因此，举个例子，若是heartbeat.recheck.interval设置为5000（毫秒），dfs.heartbeat.interval设置为3（秒，默认），则总的超时时间为40秒。

<property>
    <name>heartbeat.recheck.interval</name>
    <value>2000</value>
</property>
<property>
    <name>dfs.heartbeat.interval</name>
    <value>1</value>
</property>

三、观察验证datanode功能

上传一个文件，观察文件的block具体的物理存放状况：在每一台datanode机器上的这个目录中能找到文件的切块：

/home/hadoop/app/hadoop-2.4.1/tmp/dfs/data/current/BP-193442119-192.168.2.120-1432457733977/current/finalized

四、datanode一样能够配置多个目录,不过它不会在同一个datanode存多份相同的数据，而是将几个目录当作是统一的工做空间，至关于扩容

5、最后总结：

本节难点主要在于对namenode和secodarynamenode工做机制的理解，它们的数据合并其实并不新奇；若是你了解开源数据库mysql和nosql缓存数据库redis，那应该知道mysql的日志记录机制也是记录的sql操做命令，且每次启动mysql，bin日志就会滚动出来一个新的，而从库配置的是上一次启动时最后的那个pos，因此直接读取新的就能够咯；redis的aof数据操做记录，一样是采起相同的方式，过一段时间、或者操做的数据达到多少许时就把数据合并到rdb文件去以此来实现高可靠、可恢复。

最后寄语，以上是博主本次文章的所有内容，若是你们以为博主的文章还不错，请点赞；若是您对博主其它服务器大数据技术或者博主本人感兴趣，请关注博主博客，而且欢迎随时跟博主沟通交流。