HDFS的工作机制

1.概述

1.1.HDFS集群两大角色：

NameNode、
DataNode

1.2.NameNode职责

NameNode负责管理整个文件系统的元数据

1.3.DataNode 职责

DataNode负责管理用户的文件数据块

1.4.文件存储

文件会按照固定的大小（blocksize）切成若干块后分布式存储在若干台datanode上

1.5.副本

每一个文件块可以有多个副本，并存放在不同的datanode上

1.6.block信息

Datanode会定期向Namenode汇报自身所保存的文件block信息，而namenode则会负责保持文件的副本数量

1.7.机制透明

HDFS的内部工作机制对客户端保持透明，客户端请求访问HDFS都是通过向namenode申请来进行

2.HDFS写数据流程（上传到HDFS）

2.1 概述

客户端要向HDFS写数据，首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode，然后，客户端按顺序将文件逐个block传递给相应datanode，并由接收到block的datanode负责向其他datanode复制block的副本

2.2 详细步骤图

也可以看这幅图：

2.3 详细步骤解析

2.3.1、根据namenode通信请求上传文件，namenode检查目标文件是否已存在，父目录是否存在

2.3.2、namenode返回是否可以上传

2.3.3、client请求第一个 block该传输到哪些datanode服务器上

2.3.4、namenode返回3个datanode服务器ABC

2.3.5、client请求3台dn中的一台A上传数据（本质上是一个RPC调用，建立pipeline），A收到请求会继续调用B，然后B调用C，将真个pipeline建立完成，逐级返回客户端

2.3.6、client开始往A上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位，A收到一个packet就会传给B，B传给C；A每传一个packet会放入一个应答队列等待应答

2.3.7、当一个block传输完成之后，client再次请求namenode上传第二个block的服务器。

3.HDFS读数据流程（从HDFS下载）

3.1 概述

客户端将要读取的文件路径发送给namenode，namenode获取文件的元信息（主要是block的存放位置信息）返回给客户端，客户端根据返回的信息找到相应datanode逐个获取文件的block并在客户端本地进行数据追加合并从而获得整个文件

3.2 详细步骤图

也看可以看这张图：

3.3 详细步骤解析

3.3.1、跟namenode通信查询元数据，找到文件块所在的datanode服务器

3.3.2、挑选一台datanode（就近原则，然后随机）服务器，请求建立socket流

3.3.3、datanode开始发送数据（从磁盘里面读取数据放入流，以packet为单位来做校验）

3.3.4、客户端以packet为单位接收，现在本地缓存，然后写入目标文件

4.NameNode工作机制

学习目标：理解namenode的工作机制尤其是元数据管理机制，以增强对HDFS工作原理的理解，及培养hadoop集群运营中“性能调优”、“namenode”故障问题的分析解决能力

问题场景：
1、集群启动后，可以查看文件，但是上传文件时报错，打开web页面可看到namenode正处于safemode状态，怎么处理？
当hadoop集群从新启动的时候，会进入安全模式，在这个转态下，拒绝一切外来的增删改
hadoop dfsadmin –safemode leave
2、Namenode服务器的磁盘故障导致namenode宕机，如何挽救集群及数据？ha高可用，解决单点故障
3、Namenode是否可以有多个？namenode内存要配置多大？namenode跟集群数据存储能力有关系吗？
4、文件的blocksize究竟调大好还是调小好？
……

诸如此类问题的回答，都需要基于对namenode自身的工作原理的深刻理解

4.1. NameNode职责

4.1.1、负责客户端请求的响应

4.1.2、元数据的管理（查询，修改）

4.1.3、SecondaryNameNode的流程

4.2. 元数据管理

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

4.2.1 、元数据存储机制

A、内存中有一份完整的元数据(内存meta data)
B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)
C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits文件）注：当客户端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存meta.data中

4.2.2、 元数据手动查看

可以通过hdfs的查看edits中的信息

cd /usr/local/hadoop-2.7.3/data/name/current

4.2.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的元数据

4.2.4、 元数据目录说明

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

$HADOOP_HOME/bin/hdfs namenode -format

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

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

dfs.namenode.name.dir属性可以配置多个目录，
各个目录存储的文件结构和内容都完全一样，相当于备份，这样做的好处是当其中一个目录损坏了，也不会影响到Hadoop的元数据，特别是当其中一个目录是NFS（网络文件系统Network File System，NFS）之上，即使你这台机器损坏了，元数据也得到保存。

下面对$dfs.namenode.name.dir/current/目录下的文件进行解释:
1、VERSION文件是Java属性文件，内容大致如下：

#Fri Nov 15 19:47:46 CST 20