1. HDFS前言

l 设计思想

　　分而治之：将大文件、大批量文件，分布式存放在大量服务器上，以便于采取分而治之的方式对海量数据进行运算分析；

l 在大数据系统中作用：

　　为各类分布式运算框架（如：mapreduce，spark，……）提供数据存储服务

l 重点概念：文件切块，副本存放，元数据

2. HDFS的概念和特性

首先，它是一个文件系统，用于存储文件，通过统一的命名空间——目录树来定位文件

其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色；

重要特性如下：

（1）HDFS中的文件在物理上是分块存储（block），块的大小可以通过配置参数( dfs.blocksize)来规定，默认大小在hadoop2.x版本中是128M，老版本中是64M

（2）HDFS文件系统会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data

（3）目录结构及文件分块信息(元数据)的管理由namenode节点承担

　　——namenode是HDFS集群主节点，负责维护整个hdfs文件系统的目录树，以及每一个路径（文件）所对应的block块信息（block的id，及所在的datanode服务器）

（4）文件的各个block的存储管理由datanode节点承担

　　---- datanode是HDFS集群从节点，每一个block都可以在多个datanode上存储多个副本（副本数量也可以通过参数设置dfs.replication）

（5）HDFS是设计成适应一次写入，多次读出的场景，且不支持文件的修改

(注：适合用来做数据分析，并不适合用来做网盘应用，因为，不便修改，延迟大，网络开销大，成本太高)

3. hdfs的工作机制

3.1. 概述

HDFS集群分为两大角色：NameNode、DataNode (Secondary Namenode)
NameNode负责管理整个文件系统的元数据
DataNode 负责管理用户的文件数据块
文件会按照固定的大小（blocksize）切成若干块后分布式存储在若干台datanode上
每一个文件块可以有多个副本，并存放在不同的datanode上
Datanode会定期向Namenode汇报自身所保存的文件block信息，而namenode则会负责保持文件的副本数量
HDFS的内部工作机制对客户端保持透明，客户端请求访问HDFS都是通过向namenode申请来进行

3.2. HDFS写数据流程

3.2.1. 概述

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

3.2.2. 详细步骤图

HDFS存放策略

1 1、如果该节点为写入节点，那么在该节点会保留一个副本。
2 2、尽量将一个块不同的副本分布到其他机架上【跨机架】，以便集群能够在整个机架损失中生存。
3 3、其中一个副本通常放置在与向文件写入节点相同的机架上，以便减少跨机架网络I/O。
4 4、将HDFS数据统一分布在集群中的DataNodes中。

3.3. HDFS读数据流程

3.3.1. 概述

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

3.3.2. 详细步骤图

4. NAMENODE工作机制　　

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

4.1. NAMENODE职责

NAMENODE职责：

　　负责客户端请求的响应

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

4.2. 元数据管理

namenode对数据的管理采用了三种存储形式：

　　内存元数据(NameSystem)

　　磁盘元数据镜像文件

　　数据操作日志文件（可通过日志运算出元数据）

4.2.1. 元数据存储机制

　　A、内存中有一份完整的元数据(内存meta data)

　　B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)

　　C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits文件）

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

4.2.2. 元数据手动查看

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

4.2.3. 元数据的checkpoint

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

checkpoint的详细过程如下：

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

1 dfs.namenode.checkpoint.check.period=60  #检查触发条件是否满足的频率，60秒
2 dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary
3 #以上两个参数做checkpoint操作时，secondary namenode的本地工作目录
4 dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}
5 
6 dfs.namenode.checkpoint.max-retries=3  #最大重试次数
7 dfs.namenode.checkpoint.period=3600  #两次checkpoint之间的时间间隔3600秒
8 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.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>/app/hadoop/tmp</value>
  <description>A base for other temporary directories.</description>
</property>

dfs.namenode.name.dir属性可以配置多个目录，

如file://{hadoop.tmp.dir}/dfs/name,file://{hadoop.tmp.dir}/dfs/name1,file://

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

1 #Mon Jun 18 10:40:00 CST 2018
2 namespaceID=41528730
3 clusterID=CID-72e356f5-7723-4960-885a-72e522e19be1
4 cTime=0
5 storageType=NAME_NODE
6 blockpoolID=BP-925531343-10.0.0.11-1528537498201
7 layoutVersion=-63

其中　　（1）、namespaceID是文件系统的唯一标识符，在文件系统首次格式化之后生成的；　　（2）、storageType说明这个文件存储的是什么进程的数据结构信息（如果是DataNode，storageType=DATA_NODE）；　　（3）、cTime表示NameNode存储时间的创建时间，由于我的NameNode没有更新过，所以这里的记录值为0，以后对NameNode升级之后，cTime将会记录更新时间戳；　　（4）、layoutVersion表示HDFS永久性数据结构的版本信息，只要数据结构变更，版本号也要递减，此时的HDFS也需要升级，否则磁盘仍旧是使用旧版本的数据结构，这会导致新版本的NameNode无法使用；　　（5）、blockpoolID：是针对每一个Namespace所对应的blockpool的ID，上面的这个BP-925531343-10.0.0.11-1528537498201就是在我的ns1的namespace下的存储块池的ID，这个ID包括了其对应的NameNode节点的ip地址。　　（6）、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。

2、$dfs.namenode.name.dir/current/seen_txid非常重要，是存放transactionId的文件，format之后是0，它代表的是当前namenode里面的edits_inprogress_*文件的尾数，namenode重启的时候，会检查seen_txid的数字。

seen_txid 包含最后一个checkpoint 的最后一个事务ID(合并edits 到一个fsimage)或者edit log roll(定稿当前的edits_inprogress并且创建一个新的)。这不是NameNode接受的最后一个事务ID。这个文件不会在每个事物上更新，只有在checkpoint 或edit log roll时才更新。

此文件的目的是试图确定在启动期间是否缺少edits 。

可以配置NameNode，对fsimage和edits文件使用单独的目录。如果edits目录意外地被删除，那么自最近一次checkpoint之后的所有事物都会丢失，并且NameNode启动只能使用fsimage并维持在一个旧状态。

为了防止这种情况，NameNode启动时也会检查seen_txid ，去验证它至少可以通过该数字加载事务。如果无法验证加载事务，它将中止启动。

具体启动过程如下：

 1 [yun@mini01 current]$ pwd
 2 /app/hadoop/tmp/dfs/name/current
 3 [yun@mini01 current]$ ll -h   # 启动前 
 4 ………………
 5 -rw-rw-r-- 1 yun yun   42 Jun 18 20:17 edits_0000000000000003236-0000000000000003237
 6 -rw-rw-r-- 1 yun yun   42 Jun 18 21:17 edits_0000000000000003238-0000000000000003239
 7 -rw-rw-r-- 1 yun yun 1.0M Jun 18 21:17 edits_0000000000000003240-0000000000000003240
 8 -rw-rw-r-- 1 yun yun 1.0M Jun 19 11:04 edits_0000000000000003241-0000000000000003241
 9 -rw-rw-r-- 1 yun yun 1.0M Jun 19 11:36 edits_0000000000000003242-0000000000000003585
10 -rw-rw-r-- 1 yun yun 1.0M Jun 19 11:37 edits_inprogress_0000000000000003586
11 -rw-rw-r-- 1 yun yun  30K Jun 18 21:17 fsimage_0000000000000003239
12 -rw-rw-r-- 1 yun yun   62 Jun 18 21:17 fsimage_0000000000000003239.md5
13 -rw-rw-r-- 1 yun yun  30K Jun 19 11:04 fsimage_0000000000000003240
14 -rw-rw-r-- 1 yun yun   62 Jun 19 11:04 fsimage_0000000000000003240.md5
15 -rw-rw-r-- 1 yun yun    5 Jun 19 11:37 seen_txid
16 -rw-rw-r-- 1 yun yun  199 Jun 19 11:04 VERSION
17 [yun@mini01 current]$ cat seen_txid 
18 3586
19 
20 #########################################
21 ### 启动过程中的日志
22 …….common.Storage: Lock on /app/hadoop/tmp/dfs/name/in_use.lock acquired by nodename 10011@mini01
23 …….FileJournalManager: Recovering unfinalized segments in /app/hadoop/tmp/dfs/name/current
24 …….FileJournalManager: Finalizing edits file /app/hadoop/tmp/dfs/name/current/edits_inprogress_0000000000000003586 -> /app/hadoop/tmp/dfs/name/current/edits_0000000000000003586-0000000000000003596
25 …….FSImage: Planning to load image: FSImageFile(file=/app/hadoop/tmp/dfs/name/current/fsimage_0000000000000003240, cpktTxId=0000000000000003240)
26 …….FSImageFormatPBINode: Loading 347 INodes.
27 …….FSImageFormatProtobuf: Loaded FSImage in 0 seconds.
28 …….FSImage: Loaded image for txid 3240 from /app/hadoop/tmp/dfs/name/current/fsimage_0000000000000003240
29 …….FSImage: Reading org.apache.hadoop.hdfs.server.namenode.RedundantEditLogInputStream@7be58f16 expecting start txid #3241
30 …….FSImage: Start loading edits file /app/hadoop/tmp/dfs/name/current/edits_0000000000000003241-0000000000000003241
31 …….EditLogInputStream: Fast-forwarding stream '/app/hadoop/tmp/dfs/name/current/edits_0000000000000003241-0000000000000003241' to transaction ID 3241
32 …….FSImage: Edits file /app/hadoop/tmp/dfs/name/current/edits_0000000000000003241-0000000000000003241 of size 1048576 edits # 1 loaded in 0 seconds
33 …….FSImage: Reading org.apache.hadoop.hdfs.server.namenode.RedundantEditLogInputStream@242aa8d9 expecting start txid #3242
34 …….FSImage: Start loading edits file /app/hadoop/tmp/dfs/name/current/edits_0000000000000003242-0000000000000003585
35 …….EditLogInputStream: Fast-forwarding stream '/app/hadoop/tmp/dfs/name/current/edits_0000000000000003242-0000000000000003585' to transaction ID 3241
36 …….FSImage: Edits file /app/hadoop/tmp/dfs/name/current/edits_0000000000000003242-0000000000000003585 of size 1048576 edits # 344 loaded in 0 seconds
37 …….FSImage: Reading org.apache.hadoop.hdfs.server.namenode.RedundantEditLogInputStream@5b11a194 expecting start txid #3586
38 …….FSImage: Start loading edits file /app/hadoop/tmp/dfs/name/current/edits_0000000000000003586-0000000000000003596
39 …….EditLogInputStream: Fast-forwarding stream '/app/hadoop/tmp/dfs/name/current/edits_0000000000000003586-0000000000000003596' to transaction ID 3241
40 …….FSImage: Edits file /app/hadoop/tmp/dfs/name/current/edits_0000000000000003586-0000000000000003596 of size 1048576 edits # 1 loaded in 0 seconds
41 …….FSImage: Initializing quota with 4 thread(s)
42 …….FSImage: Quota initialization completed in 22 milliseconds
43 ……………………
44 …….FSEditLog: Starting log segment at 3597
45 ########################################
46 
47 [yun@mini01 current]$ ll -h   # 启动后 
48 ………………
49 -rw-rw-r-- 1 yun yun   42 Jun 18 20:17 edits_0000000000000003236-0000000000000003237
50 -rw-rw-r-- 1 yun yun   42 Jun 18 21:17 edits_0000000000000003238-0000000000000003239
51 -rw-rw-r-- 1 yun yun 1.0M Jun 18 21:17 edits_0000000000000003240-0000000000000003240
52 -rw-rw-r-- 1 yun yun 1.0M Jun 19 11:04 edits_0000000000000003241-0000000000000003241
53 -rw-rw-r-- 1 yun yun 1.0M Jun 19 11:36 edits_0000000000000003242-0000000000000003585
54 -rw-rw-r-- 1 yun yun 1.0M Jun 19 11:37 edits_0000000000000003586-0000000000000003596
55 -rw-rw-r-- 1 yun yun 1.0M Jun 19 11:40 edits_inprogress_0000000000000003597
56 -rw-rw-r-- 1 yun yun  30K Jun 18 21:17 fsimage_0000000000000003239
57 -rw-rw-r-- 1 yun yun   62 Jun 18 21:17 fsimage_0000000000000003239.md5
58 -rw-rw-r-- 1 yun yun  30K Jun 19 11:04 fsimage_0000000000000003240
59 -rw-rw-r-- 1 yun yun   62 Jun 19 11:04 fsimage_0000000000000003240.md5
60 -rw-rw-r-- 1 yun yun    5 Jun 19 11:40 seen_txid
61 -rw-rw-r-- 1 yun yun  199 Jun 19 11:04 VERSION
62 [yun@mini01 current]$ cat seen_txid 
63 3597

　　说明如下：

　　1、对当前的 edits_inprogress_0000000000000003586 日志定稿；

　　2、加载最近的fsimage镜像 fsimage_0000000000000003240；

　　3、循环加载edits日志从事物ID编号 3241开始到 3586【启动前的 seen_txid 数字】；那么要加载的edits日志有如下几个：

　　【edits_0000000000000003241-0000000000000003241,edits_0000000000000003242-0000000000000003585,edits_0000000000000003586-0000000000000003596】

　　　　这样就能保证所有edits日志加载完毕。意味着已完成HDFS元数据的加载。

　　4、开始一个新的日志 edits_inprogress_0000000000000003597 ，并更新 seen_txid 信息，改为 3597。

3、$dfs.namenode.name.dir/current目录下在format的同时也会生成fsimage和edits文件，及其对应的md5校验文件。

补充：seen_txid

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

5. DATANODE的工作机制

5.1. 概述

1、Datanode工作职责：

　　存储管理用户的文件块数据

　　定期向namenode汇报自身所持有的block信息（通过心跳信息上报）

　　（这点很重要，因为，当集群中发生某些block副本失效时，集群如何恢复block初始副本数量的问题）

1 <property>
2     <name>dfs.blockreport.intervalMsec</name>
3     <value>3600000</value>
4     <description>Determines block reporting interval in milliseconds.</description>
5 </property>

2、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秒。

1 <property>
2         <name>heartbeat.recheck.interval</name>
3         <value>2000</value>
4 </property>
5 <property>
6         <name>dfs.heartbeat.interval</name>
7         <value>1</value>
8 </property>

5.2. 观察验证DATANODE功能

　　上传一个文件，观察文件的block具体的物理存放情况：

1 ### 在每一台datanode机器上的这个目录中能找到文件的切块：
2 [yun@mini04 finalized]$ pwd
3 /app/hadoop/tmp/dfs/data/current/BP-925531343-10.0.0.11-1528537498201/current/finalized

Hadoop2.7.6_03_HDFS原理

1. HDFS前言

2. HDFS的概念和特性

3. hdfs的工作机制

3.1. 概述

3.2. HDFS写数据流程

3.2.1. 概述

3.2.2. 详细步骤图

3.3. HDFS读数据流程

3.3.1. 概述

3.3.2. 详细步骤图

4. NAMENODE工作机制

4.1. NAMENODE职责

4.2. 元数据管理

4.2.1. 元数据存储机制

4.2.2. 元数据手动查看

4.2.3. 元数据的checkpoint

4.2.4. 元数据目录说明

5. DATANODE的工作机制

5.1. 概述

5.2. 观察验证DATANODE功能

4. NAMENODE工作机制　　