目标：
-
重点：HDFS的数据流（读写操作）
-
重点：NameNode和SecondaryNameNode
- NN和SNN工作机制
- Fsimage和Edits解析
- CheckPoint时间设置
- NN故障处理
- 集群安全模式
- NN多目录配置
-
重点：DataNode
- DataNode工作机制
- 数据完整性
- 掉线时限参数设置
-
HDFS2.x新特性
- 集群间数据拷贝
- 小文件存档
- 回收站
- 快照管理
-
HDFS高可用HA
1 HDFS的数据流
1.1 HDFS读数据流程
- 客户端通过Distributed FileSystem向NN请求下载文件，NN通过查询元数据，找到文件所在的DN地址
- 挑选一台DN（就近原则，然后随机）节点，请求读取数据
- DN开始传输数据给Client（从磁盘里面读取数据输入流，以packet为单位来做校验）
- 客户端以packet为单位来接收，先在本地缓存，然后写入目标文件
1.2 HDFS写数据流程
流程如下：
- 客户端通过Distributed FileSystem向NN请求上传文件，NN检查目标文件是否存在，父目录是否存在
- NN返回是否可以上传
- 客户端请求第一个block上传到哪几个DN节点上
- NN返回3个DN节点，分别为DN1，DN2，DN3
- 客户端FSDataOutputStream模块请求DN1上传数据，DN1收到请求会继续调用DN2，然后DN2调用DN3，将这个通信管道建立完成
- DN1，DN2，DN3逐级回复客户端
- 客户端开始往DN1上传第一个block，以packet为单位，DN1收到一个packet就会传给DN2，DN2传给DN3，DN1每传一个packet就会放入一个应答队列等待应答
- 当一个block传输完成之后，客户端再次请求NN上传第二个block的服务器
- 重复执行3-7的步骤
在HDFS写数据的时候，NN会选择距离待上传数据最近距离的DN接收数据。节点距离：两个节点到达最近的共同祖先的距离总和。
-
机架感知策略
2 NN和SNN
2.1 NN和SNN工作机制
FsImage：在磁盘中备份元数据信息。NN内存中元数据序列化后形成的文件。
Edits文件：每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。只进行追加操作，效率很高。
SNN：帮助NN进行FsImage和Edits的合并。如果这个操作由NN来完成，效率会低。
- 第一阶段
- 第一次启动NN格式化后，创建FsImage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
- 客户端对元数据进行增删改的请求
- NN记录操作日志，更新滚动日志
- NN在内存中对数据进行增删改
- 第二阶段
- SNN询问NN是否需要CheckPoint，直接带回NN是否检查结果
- SNN请求执行CheckPoint
- NN滚动正在写的Edits日志
- 将滚动前的编辑日志和镜像文件拷贝到SNN
- SNN加载编辑日志和镜像文件到内存，合并
- 生成新的镜像文件fsimage.chkpoint
- 拷贝fsimage.chkpoint到NN
- NN将fsimage.chkpoint重新命名为fsimage
2.2 FsImage和Edits详解
- FsImage：HDFS文件系统元数据的一个永久性的检查点，其中包括HDFS文件系统的所有目录和文件inode的序列化信息
- Edits：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到Edits文件中
- 每次NN启动时都会将FsImage文件读入内存中，加载Edits中的更新操作，保证内存中的元数据信息是最新的。可以看成是NN启动的时候将FsImage和Edits文件进行了合并。
2.3 NN故障处理
- 方法一：将SNN中数据拷贝到NN存储数据的目录
- kill -9 NN进程
- 删除NN存储的数据
- 拷贝SNN中数据到NN存储数据目录
- 重新启动NN
- 方法二：使用-importCheckpoint选项启动NN守护进程，从而将SNN中数据拷贝到NN中
- 修改hdfs-site.xml
- kill -9 NN进程
- 删除NN存储的数据
- 如果SNN和NN不在同一个节点上，需要将SNN存储数据的目录拷贝到NN存储数据的平级目录，并删除in_use.lock文件
- 导入检查点数据
- 重新启动NN
3 DN
3.1 DN工作机制
流程如下：
- 一个数据块在DN上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的长度、块数据的校验和，以及时间戳
- DN启动后向NN注册，通过后，周期性（1小时）的向NN上报所有的块信息
- 心跳是每3s一次，心跳返回结果带有NN给DN的命令如复制块数据到另一台机器，或删除某个数据块。如果超过10分钟没有收到某个DN的心跳，则认为该节点挂掉
3.2 数据完整性
-
DN节点保证数据完整性的方法：
- 当DN读取block数据时，会计算CheckSum
- 如果计算后的CheckSum与block创建时值不一样，说明block已经损坏
- client读取其他DN上的block
- DN在其文件创建后周期验证CheckSum
4 HDFS2.x新特性
4.1 小文件存档
-
小文件弊端
- 大量的小文件会耗尽NN中的大部分内存，但注意，存储小文件所需要的磁盘容量和数据块的大小无关。
- 一个1m的文件设置为128m的块存储，但实际使用的是1m的磁盘空间，而不是128m
-
解决方法
-
HDFS存档文件对内还是一个个独立文件，对NN来说却是一个整体，减少了NN的内存消耗
-
4.2 快照
- 快照相当于对目录做一个备份，但是不会立即复制所有文件，而是记录文件变化。
5 HDFS的HA（高可用）
5.1 HA概述
HA（High Available），即高可用（7*24小时不中断服务），实现高可用最关键的就是消除单点故障。HA严格来说应该分成各个组件的HA机制：HDFS的HA和YARN的HA。
-
NN主要在两个方面影响HDFS集群
- NN机器发生意外：宕机，集群无法使用，直到管理员重启
- NN机器需要升级，包括软件、硬件升级，此时集群也无法使用
HDFS的HA功能主要通过配置Active/StandBy两个NN实现在集群中对NN的热备来解决上述问题。如果出现故障，如机器崩溃或需要升级维护，可以通过此种方法将NN很快的切换到另外一台机器上。
5.2 HDFS-HA工作要点
- 元数据管理方式改变
- 内存中各自保存一份元数据
- Edits日志只有Active状态的NN可以做写操作
- 两个NN都可以读取Edits
- 共享的Edits放在一个共享存储中管理（QJM和NFS）
- 需要一个状态管理功能模块
- 实现了一个zkfailover，常驻在每一个NN节点上，每一个zkfailover负责监控自己所在NN节点，利用zk进行状态标识，当需要进行状态切换时，由zkfailover来负责切换，切换时需要防止brain split现象的发生
- 必须保证两个NN之间能够ssh无密码登录
- 隔离：即同一时刻只有一个NN对外提供服务
5.3 HDFS-HA自动故障转移机制
自动故障转移为HDFS增加了两个新组件：ZooKeeper和ZKFailoverController（ZKFC）进程。ZooKeeper是维护少量协调数据，通知客户端这些数据的改变和监视客户端故障的高可用服务。
HA的自动故障转移依赖于ZK的以下功能：
- 故障转移：集群中的每个NN都在ZK中维护了一个持久会话，如果机器崩溃，ZK中的会话将会终止，ZK通知另一个NN需要触发故障转移
- 现役NN选择：ZK提供了一个简单的机制用于唯一的选择一个节点为Active状态。如果现役NN崩溃，另一个节点可能从ZK获得特殊的排外锁以表名它应该成为现役的NN。
ZKFC是自动故障转移的另一个新组件，是ZK的客户端，也监视和管理NN的状态。每个运行NN的主机也运行了一个ZKFC进程。
- 健康检测：ZKFC使用一个健康检查命令定期的ping与之在相同主机的NN，只要该NN及时回复健康状态，ZKFC认为该节点健康。
- ZK会话管理：当本地的NN健康，ZKFC保持一个在ZK中的会话。如果本地NN是Active，那么ZKFC也会保持一个特殊的znode锁（临时节点），如果会话结束，临时节点自动删除
- 基于ZK的选择：如果本地NN健康，且ZKFC发现没有其他的NN持有znode锁，它将为自己获取该锁。如果成功，那么就负责运行故障转移进程以使它的本地NN为Active。
小结
好了，关于HDFS的高阶部分就总结到这里，实际工作中呢，还会有更多的操作，后续就具体场景具体分析吧。
