hdfs各个节点工作机制-09

（1）Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件idnode的序列化信息。 

（2）Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。 

（3）seen_txid文件保存的是一个数字，就是最后一个edits_的数字

（4）每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成Namenode启动的时候就将fsimage和edits文件进行了合并。

(5)edits_inprogress 它是正在工作的日志缓存文件,其它的edits是已经落实的日志文件

使用下面两个命令就可以把那些二进制文件转换为xml看它里面具体的实现过程

hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径

hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径

强制滚动编辑日志  hdfs dfsadmin -rollEdits

工作机制

正常服务器内存大小为128G , 1024Byte(字节)=1KB 每个block在内存中占150byte大小.

1）第一阶段：namenode启动

（1）第一次启动namenode格式化后，创建fsimage(镜像文件)和edits(编辑日志)文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。

（2）客户端对元数据进行增删改的请求,查询不会记录到日志中去.

（3）namenode记录操作日志，更新滚动日志。

（4）namenode在内存中对数据进行增删改查

2）第二阶段：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.

Secondary NameNode是否需要checkpoint的条件,两者成立一条都执行.

1.默认每隔一小时执行一次

2.操作次数达到一百万时执行一次

namenode版本号

1）namespaceID在HDFS上，会有多个Namenode，所以不同Namenode的namespaceID是不同的，分别管理一组blockpoolID。

（2）clusterID集群id，全局唯一

（3）cTime属性标记了namenode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。

（4）storageType属性说明该存储目录包含的是namenode的数据结构。

（5）blockpoolID：一个block pool id标识一个block pool，并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中，在后续的启动过程中，会再次load并使用。

（6）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。

datanode工作机制

1）一个数据块在datanode上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳。

2）DataNode启动后向namenode注册，通过后，周期性（1小时）的向namenode上报所有的块信息。

3）心跳是每3秒一次，心跳返回结果带有namenode给该datanode的命令如复制块数据到另一台机器，或删除某个数据块。如果超过10分30秒没有收到某个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的单位为秒。这两个参数可以自己设置.

<property>     <name>dfs.namenode.heartbeat.recheck-interval</name>     <value>300000</value> </property> <property>     <name> dfs.heartbeat.interval </name>     <value>3</value> </property>

数据完整性

1）当DataNode读取block的时候，它会计算checksum

2）如果计算后的checksum，与block创建时值不一样，说明block已经损坏。

3）client读取其他DataNode上的block.

4）datanode在其文件创建后周期验证checksum

DataNode的目录结构

和namenode不同的是，datanode的存储目录是初始阶段自动创建的，不需要额外格式化。

1）在/opt/module/hadoop-2.7.2/data/tmp/dfs/data/current这个目录下查看版本号

[atguigu@hadoop102 current]$ cat VERSION

storageID=DS-1b998a1d-71a3-43d5-82dc-c0ff3294921b

clusterID=CID-1f2bf8d1-5ad2-4202-af1c-6713ab381175

cTime=0

datanodeUuid=970b2daf-63b8-4e17-a514-d81741392165

storageType=DATA_NODE

layoutVersion=-56

2）具体解释

       （1）storageID：存储id号

       （2）clusterID集群id，全局唯一

       （3）cTime属性标记了datanode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。

       （4）datanodeUuid：datanode的唯一识别码

       （5）storageType：存储类型

       （6）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。

3）在/opt/module/hadoop-2.7.2/data/tmp/dfs/data/current/BP-97847618-192.168.10.102-1493726072779/current这个目录下查看该数据块的版本号

[atguigu@hadoop102 current]$ cat VERSION

#Mon May 08 16:30:19 CST 2017

namespaceID=1933630176

cTime=0

blockpoolID=BP-97847618-192.168.10.102-1493726072779

layoutVersion=-56

4）具体解释

（1）namespaceID：是datanode首次访问namenode的时候从namenode处获取的storageID对每个datanode来说是唯一的（但对于单个datanode中所有存储目录来说则是相同的），namenode可用这个属性来区分不同datanode。

（2）cTime属性标记了datanode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。

（3）blockpoolID：一个block pool id标识一个block pool，并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中，在后续的启动过程中，会再次load并使用。

（4）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。