HDFS元数据管理机制

HDFS元数据管理机制

1、 HDFS元数据

HDFS的元数据分为内存元数据和元数据文件两类:分别存储在内存和磁盘上

元数据概念:

1. 文件、目录自身的数据,例如文件名字,目录名,修改信息等等。
2. 文件记录的信息的存储相关的新,例如存储块信息,分块信息,副本个数等。
3. 用来记录HDFS的Datanode的信息,用于管理Datanode。

       fsimage 镜像文件：是元数据的一个持久化的检查点，包含Hadoop文件系统中的所有目录和文件元数据信息，但不包含文件块位置的信息。文件块位置信息只存储在内存中，是在 datanode加入集群的时候，namenode询问datanode得到的，并且间断的更新。

       Edits 编辑日志：存放的是Hadoop文件系统的所有更改操作（文件创建，删除或修改）的日志，文件系统客户端执行的更改操作首先会被记录到edits文件中。

       当NameNode启动的时候,会先将fsimage的内存加载到内存中,然后去执行edits中的各项操作,使得内存中的元数据和实际的同步,而内存中的元数据会支持客户端的读写操作,所有说内存中的元数据是最完整的元数据。

       当客户端对hdfs进行读写操作的时候,首先会计入到hdfs的edits日志中,当操作成功后,相对应的元数据会加载到内存元数据中,因此导致fsimage的文件会非常的大,如果所有的更新操作都往fsimage文件中添加，这样会导致系统运行的十分缓慢。

       hdfs的这种设计模型:

1. 在内存中进行数据的更新,查询快,极大的缩短了操作响应的实际;
2. 在内存中元数据丢失风险颇高(断点,宕机等),因此会有一个secondaryname去进行数据的备份来保证元数据的安全性,从而降低风险。

2、HDFS元数据在集群中相应的位置

       此处的格式化是指集群搭建完毕后并不能马上启动,首先的对集群进行格式化操作,此处的格式化并不是指传统意义上的本地磁盘格式化，而是一些清除与准备工作。

       格式化:namenode:$HADOOP_HOME$/bin/hdfs namenode –format

注意:如果是已经运行的集群,千万不要随便的进行格式化,因为会把以前运行产生的元数据全部清空,相当于重新整了一个集群

       首先的需要找到hdfs元数据存放位置的配置信息($HADOOP_HOME$/etc/hadoop/core-site.xml)

       当集群格式化完毕后,会在hadoop.tmp.dir配置的路径下自动的生成dfs/name/current目录,由于笔者的集群已经跑了不少时间,所有产生的文件相对而言比较多。

fsimage
       fsimage文件其实是Hadoop文件系统元数据的一个永久性的检查点，其中包含Hadoop文件系统中的所有目录和文件idnode的序列化信息；

       fsimage包含Hadoop文件系统中的所有目录和文件idnode的序列化信息；对于文件来说，包含的信息有修改时间、访问时间、块大小和组成一个文件块信息等；而对于目录来说，包含的信息主要有修改时间、访问控制权限等信息。

edits
       edits文件存放的是hadoop文件系统的所有操作的路径,文件操作端的所有操作都会被记录到edits文件中,其实edits文件的存在就是为了解决所有的操作都直接的给fsimage中写入,从而导致fsimage越来越大,系统运行越来越慢的缺点,同时edits文件也会定时的同步更新,从而保证数据的一致性。

.md5
       用来对fsimage进行校验的文件

seen_txid
       seen_txid文件非常之重要,当进行namenode格式化操作的时候是0.它代表的是namenode文件中的edits_*的尾数,当集群启动的时候,会按照seen_txid的值从头跑edits_00000001~seen_txid的数字,所以当你的hdfs发生异常重启的时候,一定要对比seen_txid的数字和edits最后的尾数所吻合。

**VERSION **

#Tue Sep 24 12:01:15 CST 2019
namespaceID=1621074170
clusterID=CID-f1fe55eb-03e5-49f9-90c3-05da8c2647a3
cTime=0
storageType=NAME_NODE
blockpoolID=BP-831398103-192.168.216.150-1568503571432
layoutVersion=-60

       namespaceID/clusterID/blockpoolID :这些都是HDFS集群的唯一标识符。标识符被用来防止DataNodes意外注册到另一个集群中的namenode上。这些标识在联邦（federation）部署中特别重要。

       storageType:说明这个文件存储的是什么进程的数据结构信息（如果是DataNode，storageType=DATA_NODE）；

       cTime NameNode:存储系统创建时间，首次格式化文件系统这个属性是0，当文件系统升级之后，该值会更新到升级之后的时间戳；

       ayoutVersion:表示HDFS永久性数据结构的版本信息，是一个负整数。

3、 secondary namenode

        NameNode职责是管理元数据信息，DataNode的职责是负责数据具体存储，那么SecondaryNameNode的作用是什么？对很多初学者来说是非常迷惑的。它为什么会出现在HDFS中。从它的名字上看，它给人的感觉就像是NameNode的备份。但它实际上却不是。

当hdfs集群运行一段时候后,肯定会出现一些问题,导致集群中出故障。

       例如namenode在运行期间突然宕机,又或者断电,或者各种外在的因数都会使得我们失去最新的fsimage信息,当重新启动之后,此时的fsimage文件非常的旧极好

       随着时间的推移,edits给fsimage写入的数据越来越大,而集群启动的时候,会加载fsimage信息到内存中,当fsimage的信息越来越大,就会导致集群的启动时间也会越来越长,这与我们所想象的有点不符合。

       为了解决这些问题,我们需要一个易于管理的机制来帮助我们去减少edits log文件的大小和得到一个最新的fsimage文件,这样也会减少namenode的压力,当我们遇到发生意想不到的情况时,可以fsimage回滚到最新的上一次恢复点上,减少我们的损失。

       而secondaryNameNode 就是为了解决上述问题的,它的职责是用来合并NameNode的edit log到fsimage中,并不是NameNode的备份,等待NameNode挂掉后secondaryNameNode去上位。
       

4、 secondary namenode合并文件的过程

我们将secondary namenode合并文件的过程称为checkpoint(检查点)

1) checkpoint的触发条件:
       
checkpoint操作受两个参数的限制,可以通过core-site.xml来配置

• 两次执行checkpoint间隔一小时
• 在一小时内执行100万此操作,将强制执行紧急checkpoint

<property>
	<name> dfs.namenode.checkpoint.period</name>
   	<value>3600</value>
</property>
<property>
  	<name>dfs.namenode.checkpoint.txns</name>
 	 <value>1000000</value>
</property>

从上面的描述我们可以看出，SecondaryNamenode根本就不是Namenode的一个热备，其只是将fsimage和edits合并。其拥有的fsimage不是最新的，因为在他从NameNode下载fsimage和edits文件时候，新的更新操作已经写到edit.new文件中去了。而这些更新在SecondaryNamenode是没有同步到的！当然，如果NameNode中的fsimage真的出问题了，还是可以用SecondaryNamenode中的fsimage替换一下NameNode上的fsimage，虽然已经不是最新的fsimage，但是我们可以将损失减小到最少！
2) secondary namenode的执行流程:

1. 在开机的时候name会立刻创建一个空的fismage和空的edits
2. 运行一段时间后，edits记录了用户操作（有数据！）
3. （第一次执行）一小时后 Secondary namenode 会将fismage和edits 拿走 并且在namenode中创建一个新的edits（记录合并过程的增量修改）在secondary namenode中 合并成new fismage（存：一小时之前的内存状态和用户进行的操作）
   （第n次执行）： Secondry namenode只拉取一小时的增量（edits） 去合并fismage得到新的newfismage
4. 合并完毕后 Secondary namenode 将newfismage 给namenode 并替代namenode中的fismage和edits
5. 在将newfismage与newedits（合并过程增量修改）合并成一个全新的fismage

5、 HDFS的安全模式

1. namenode启动的时候，首先将映像文件fsimgae加载到内存，并执行编辑日志（edits）中的各项操作
   一旦在内存中成功建立文件系统元数据的映射，则创建一个新的fsimage文件（这个操作不在secodarynamenode中进行，）和一个空的编辑日志

2. 此刻的namenode运行处在安全模式，即namenode的文件系统对于客户端来说是只读的，其他操作都会失效

3. 此阶段的namenode在收集各个datanode的报告，当数据块达到最小副本数以上，会被认为是”安全的,“默认为0.999f。当小于这个比例，那就将系统切换成安全模式，对数据块进行复制；当大于该比例时，就离开安全模式，说明系统有足够的数据块副本数，可以对外提供服务。小于等于0意味不进入安全模式，大于1意味一直处于安全模式。

4. 当检测副本数不足的数据块的时候，该块会默认的复制直到达到最小副本数，系统中数据块的位置并不是namenode维护的，而是以块的列表形式存储在datanode中

手动进入安全模式

hdfs dfsadmin -safemode enter

手动退出安全模式

hdfs dfsadmin -safemode leave