全方位揭秘！大数据从0到1的完美落地之HDFS的工作机制

HDFS的工作机制

开机启动Namenode过程

非第一次启动集群的启动流程

我们应该知道，在启动namenode之前，内存里是没有任何有关于元数据的信息的。那么启动集群的过程是怎样的呢？下面来叙述一下：

第一步：
Namenode在启动时，会先加载name目录下最近的fsimage文件.
将fsimage里保存的元数据加载到内存当中，这样内存里就有了之前检查点里存储的所有元数据。但是还少了从最近一次检查时间点到关闭系统时的部分数据，也就是edit日志文件里存储的数据。

第二步：
加载剩下的edit日志文件
将从最近一次检查点到目前为止的所有的日志文件加载到内存里，重演一次客户端的操作，这样，内存里就是最新的文件系统的所有元数据了。

第三步：
进行检查点设置（满足条件会进行）
namenode会终止之前正在使用的edit文件,创建一个空的edit日志文件。然后将所有的未合并过的edit日志文件和fsimage文件进行合并，产生一个新的fsimage.

第四步：
处于安全模式下，等待datanode节点的心跳反馈，当收到99.9%的块的至少一个副本后，退出安全模式，开始转为正常状态。

不是第一次启动,直接加载编辑日志和edits文件的情况展示:

执行流程

第一次启动集群的启动流程

第一次启动namenode格式化后的情况展示:

注意：格式化集群后，第一次启动集群的特点，参考下图

小知识

(1) 滚动编辑日志（前提必须启动集群）
1.可以强制滚动
[bigdata@hadoop102 current]$ hdfs dfsadmin -rollEdits
2.可以等到edits.inprogress满64m生成edits文件
3.可以等操作数量达到100万次
4.时间到了,默认1小时
注意:在2,3,4时发生滚动,会进行checkpoint
(2) 镜像文件什么时候产生
可以在namenode启动时加载镜像文件和编辑日志
也可以在secondarynamenode生成的fsimage.chkpoint文件重新替换namenode原来的fsimage文件时
(3) namenode目录说明

安全模式介绍

Namenode启动时，首先要加载fsimage文件到内存，并逐条执行editlog文件里的事务操作，在这个期间一但在内存中成功建立文件系统元数据的映像，就会新创建一个fsimage文件(该操作不需要SecondaryNamenode)和一个空的editlog文件。在这个过程中，namenode是运行在安全模式下的，Namenode的文件系统对于客户端来说是只读的，文件修改操作如写，删除，重命名等均会失败。

系统中的数据块的位置并不是由namenode维护的，而是以块列表的形式存储在datanode中。在系统的正常操作期间，namenode会在内存中保留所有块位置的映射信息。在安全模式下，各个datanode会向namenode发送最新的块列表信息，如果满足“最小副本条件”，namenode会在30秒钟之后就退出安全模式,开始高效运行文件系统.所谓的最小副本条件指的是在整个文件系统中99.9%的块满足最小副本级别（默认值：dfs.replication.min=1）。

PS:启动一个刚刚格式化完的集群时，HDFS还没有任何操作呢，因此Namenode不会进入安全模式。

系统离开安全模式，需要满足哪些条件？
当namenode收到来自datanode的状态报告后，namenode根据配置确定
1. 可用的block占总数的比例
2. 可用的数据节点数量符合要求之后，离开安全模式。
1、2两个条件满足后维持的时间达到配置的要求。

注意: 如果有必要，也可以通过命令强制离开安全模式。
与安全模式相关的主要配置在hdfs-site.xml文件中，主要有下面几个属性
1. dfs.namenode.replication.min:
  最小的文件block副本数量，默认为1
2. dfs.namenode.safemode.threshold-pct:
  副本数达到最小要求的block占系统总block数的百分比，当实际比例超过该配置后，才能离开安全模式（但是还需要其他条件也满足）。默认为0.999f，也就是说符合最小副本数要求的block占比超过99.9%时，并且其他条件也满足才能离开安全模式。如果为小于等于0，则不会等待任何副本达到要求即可离开。如果大于1，则永远处于安全模式。
3. dfs.namenode.safemode.min.datanodes:
  离开安全模式的最小可用（alive）datanode数量要求，默认为0.也就是即使所有datanode都不可用，仍然可以离开安全模式。
4. dfs.namenode.safemode.extension:
  当集群可用block比例，可用datanode都达到要求之后，如果在extension配置的时间段之后依然能满足要求，此时集群才离开安全模式。单位为毫秒，默认为1。也就是当满足条件并且能够维持1毫秒之后，离开安全模式。这个配置主要是对集群的稳定程度做进一步的确认。避免达到要求后马上又不符合安全标准。

相关命令

查看namenode是否处于安全模式

  [root@qianfeng01 current]# hdfs dfsadmin -safemode get  Safe mode is ON

管理员可以随时让Namenode进入或离开安全模式，这项功能在维护和升级集群时非常关键

  [root@qianfeng01 current]# hdfs dfsadmin -safemode enterSafe mode is ON[root@qianfeng01 current]# hdfs dfsadmin -safemode leaveSafe mode is OFF

将下面的属性的值设置为大于1，将永远不会离开安全模式

<property><name>dfs.namenode.safemode.threshold-pct</name><value>0.999f</value>
</property>

有时，在安全模式下，用户想要执行某条命令，特别是在脚本中，此时可以先让安全模式进入等待状态
```
[root@qianfeng01 current]# hdfs dfsadmin -safemode wait
# command to read or write a file
```

DataNode与NameNode通信(心跳机制)

hdfs是qianfeng01/slave结构，qianfeng01包括namenode和resourcemanager，slave包括datanode和nodemanager

qianfeng01启动时会开启一个IPC服务，等待slave连接

slave启动后，会主动连接IPC服务，并且每隔3秒链接一次，这个时间是可以调整的，设置heartbeat，这个每隔一段时间连接一次的机制，称为心跳机制。Slave通过心跳给qianfeng01汇报自己信息，qianfeng01通过心跳下达命令。

Namenode通过心跳得知datanode状态。Resourcemanager通过心跳得知nodemanager状态

当qianfeng01长时间没有收到slave信息时，就认为slave挂掉了。

注意：超长时间计算结果：默认为10分钟30秒

属性：dfs.namenode.heartbeat.recheck-interval 的默认值为5分钟 #Recheck的时间单位为毫秒
属性：dfs.heartbeat.interval 的默认值时3秒 #heartbeat的时间单位为秒

计算公式:2recheck+10heartbeat

SecondayNamenode的工作机制(检查点机制)

SecondaryNamenode，是HDFS集群中的重要组成部分，它可以辅助Namenode进行fsimage和editlog的合并工作，减小editlog文件大小，以便缩短下次Namenode的重启时间，能尽快退出安全模式。

两个文件的合并周期，称之为检查点机制（checkpoint），是可以通过hdfs-default.xml配置文件进行修改的：

<property><name>dfs.namenode.checkpoint.period</name><value>3600</value><description>两次检查点间隔的秒数，默认是1个小时</description>
</property>
<property><name>dfs.namenode.checkpoint.txns</name><value>1000000</value><description>txid执行的次数达到100w次，也执行checkpoint</description>
</property>
<property><name>dfs.namenode.checkpoint.check.period</name><value>60</value><description>60秒一检查txid的执行次数</description>
</property>

通过上图，可以总结如下：

SecondaryNamenode请求Namenode停止使用正在编辑的editlog文件，Namenode会创建新的editlog文件，同时更新seed_txid文件。

SecondaryNamenode通过HTTP协议获取Namenode上的fsimage和editlog文件。

SecondaryNamenode将fsimage读进内存当中，并逐步分析editlog文件里的数据，进行合并操作，然后写入新文件fsimage_x.ckpt文件中。

SecondaryNamenode将新文件fsimage_x.ckpt通过HTTP协议发送回Namenode。

Namenode再进行更名操作。

HDFS 管理命令

全方位揭秘！大数据从0到1的完美落地之HDFS的工作机制相关推荐

全方位揭秘！大数据从0到1的完美落地之HDFS块详解
HDFS块详解传统型分布式文件系统的缺点现在想象一下这种情况:有四个文件 0.5TB的file1,1.2TB的file2,50GB的file3,100GB的file4:有7个服务器,每个服务器上有 ...
全方位揭秘！大数据从0到1的完美落地之HDFS的体系结构
HDFS的体系结构体系结构解析 HDFS采用的是master/slaves这种主从的结构模型来管理数据,这种结构模型主要由四个部分组成,分别是Client(客户端).Namenode(名称节点).D ...
全方位揭秘！大数据从0到1的完美落地之HDFS读写流程
数据流读流程的详解读操作: hdfs dfs -get /file02 ./file02 hdfs dfs -copyToLocal /file02 ./file02 FSDataInputStr ...
全方位揭秘！大数据从0到1的完美落地之Hive自定义函数
自定义函数自定义函数介绍 hive的内置函数满足不了所有的业务需求.hive提供很多的模块可以自定义功能,比如:自定义函数.serde.输入输出格式等.而自定义函数可以分为以下三类: 1)UDF:u ...
全方位揭秘！大数据从0到1的完美落地之大数据简介
大数据简介什么是大数据最近几年,IT行业最火的名词中,少不了"大数据"."人工智能"."云计算"."物联网".& ...
全方位揭秘！大数据从0到1的完美落地之MapReduce实战案例(1)
案例一: MR实战之小文件合并(自定义inputFormat) 项目准备需求无论hdfs还是MapReduce,对于小文件都有损效率,实践中,又难免面临处理大量小文件的场景,此时,就需要有相应解决 ...
全方位揭秘！大数据从0到1的完美落地之Shuffle和调优
MapReduce高级 shuffle阶段概述 MapReduce会确保每个reducer的输入都是按键排序的.从map方法输出数据开始.到作为输入数据传给reduce方法的过程称为shuffle. ...
全方位揭秘！大数据从0到1的完美落地之Mysql介绍
导读在大数据中,我们需要处理的数据来自不同的渠道,其中有一个很重要的渠道就是关系型数据库中存储的数据.在企业中,会把业务数据存储在关系型数据库中,一般以 MySQL 居多.另外,我们在后续的学习中需 ...
全方位揭秘！大数据从0到1的完美落地之Hive介绍
Hive定义 Hive是一个基于Hadoop的数据仓库工具,可以将结构化的数据文件映射成一张数据表,并可以使用类似SQL的方式来对数据文件进行读写以及管理.这套Hive SQL 简称HQL.Hive的 ...