Hadoop—HDFS

Hadoop是什么

Hadoop是一个软件也是一个生态圈

Hadoop—HDFS 是什么

分布式文件系统——软件 HDFS

廉价磁盘存储海量数据实现存储计算

将多磁盘对外提供一个视图一一RAID

Hadoop-HDFS 工作流程

客户端 -> NameNode 一般最少俩台存储元数据（存储的文件名格式等） 不包扩数据存储的DataNode节点 多台NameNode根据Zookeeper进行选主当主节点宕机会自动切换，如果是因为网络延时Zookeeper没能监听到，会先杀死该线程再切换主节点

主节点才能写进QJM（日志存储系统） 至少启动三个节点（QJM自身选主，三个集群）

NameNode -> DataNode 一个块数据会在三个DataNode存储

DataNode->NameNode NameNode发起心跳机制，监听DataNode是否在正常运行 复制日志也在该命令中完成

客户端

1.分割过大的文件

2.询问NN文件上传或从哪下载

3.与DN建立关系进行读写

ANN Active NameNode（主节点服务器）

1,接收客户端的读写诗求

2.通过心跳汇报块与DN的映射关系

3.通过心跳汇报资游情况

DN DataNode（磁盘）

1.接收客户端的读写请求

2,存储文件与块的映射关系

3,收集块与DN的映射关系

Hadoop 模型

**Hadoop Common 基础型功能 Hadoop自己使用的系统文件 **

Hadoop Distributed File System 负责存放数据 （HDFS）

**Hadoop YARN 负责资源的调配 **

**Hadoop MapReduce 大数据的计算框架 **

HDFS 恢复存储数据的方式

1.edits文件用于存储元数据，默认2分钟生成一个

2.只有ANN才会生成edits文件

3.主备NN的edits都是不完整，但是QJM是完整的

4.fsimage是快照文件，用于压缩存储edits快速恢复元数据至内存

5.fsimage时间纬度：默认一小时生成一次，操作纬度：默认100W,时间纬度和操作纬度触发检查间隔时间：1分钟

6.ANN会使用fsimage加edits inprogress文件还有大于fsimage的edits文件即可完全恢复元数据

7.fsimage文件生成的工作由SNN完成并拷贝至ANN

Hadoop-HA

hadoop-HA集群运作机制介绍 所谓HA，即高可用，消除单点故障

设计思想

• hadoop2.x启用了主备节点切换模式（1主1备） hadoop1.x没有HA
• 当主节点出现异常的时候，集群直接将备用节点切换成主节点 - 要求备用节点马上就要工作- 主备节点内存几乎同步
• 有独立的线程对主备节点进行监控健康状态
• 需要有一定的选举机制，帮助我们确定主从关系
• 我们需要实时存储日志的中间件

ANN

• Active NameNode 的功能和原理的NN的功能是一样的

• 接受客户端请求，查询数据块DN信息

• 存储数据的元数据信息 - 数据文件：Block：DN的映射关系

• 工作 - 启动时：接受DN的block汇报- 运行时：和DN保持心跳(3s,10m30s)

• 存储介质 - 完全基于内存- 优点：数据处理效率高- 缺点：数据的持久化(日志edits+快照fsimage)

SNN

• Standby NameNode：NN的备用节点
• 他和主节点做同样的工作，但是它不会发出任何指令
• 存储：数据的元数据信息 - 数据文件：Block：DN的映射关系- 它的内存数据和主节点内存数据几乎是一致的
• 工作： - 启动时： 接受DN的block汇报- 运行时： 和DN保持心跳(3s,10m30s)
• 存储介质 - 完全基于内存- 优点：数据处理效率高- 缺点：数据的持久化
• 合并日志文件和镜像 - 当搭建好集群的时候，格式化主备节点的时候，ANN和SNN都会会默认创建 - fsimage_000000000000000- 当我们操作HDFS的时候ANN会产生日志信息 - edits_inprogress_0000000000001- 主节点会将日志文件中新增的数据同步到JournalNode集群上- edits 文件默认 2 分钟生成一个，默认上限 100W 个；- 只有 Active NameNode 才可以将 edits 元数据写入到 QJM；- 每个 NameNode 上的 edits 元数据是不完整的（主备切换导致），但是 QJM 中一定是完整的；- Hadoop 2.x 以及以后 fsimage 文件的合并机制： - 时间纬度：1 小时合并一次；- 纬度检查周期：默认 1 分钟检查一次。- 操作纬度：edits 操作次数超过 100W 次；- QJM 只保存 edits 文件，不保存 fsimage 文件，fsimage 文件只保存在 NameNode 中；- SNN将合并好的Fsimage发送给ANN，ANN验证无误后，存放到自己的目录中。

DataNode(DN)

• 存储 - 文件的Block数据

• 介质 - 硬盘

• 启动时 - 同时向两个NN汇报Block信息

• 运行中 - 同时和两个NN节点保持心跳机制

QJM

• Quorum JournalNode Manager 共享存储系统，NameNode通过共享存储系统实现日志数据同步。

• JournalNode是一个独立的小集群，它的实现原理和Zookeeper的一致( Paxos)

• ANN产生日志文件的时候，就会同时发送到 JournalNode的集群中每个节点上

• JournalNode不要求所有的jn节点都接收到日志，只要有半数以上的（n/2+1）节点接受收到日志，那么本条日志就生效

• SNN每间隔一段时间就去QJM上面取回最新的日志 - SNN上的日志有可能不是最新的

• HA集群的状态正确至关重要，一次只能有一个NameNode处于活动状态。

• JournalNode只允许单个NameNode成为作者。在故障转移期间，将变为活动状态的NameNode将承担写入 JournalNodes的角色，这将有效地防止另一个NameNode继续处于活动状态，从而使新的Active节点可以安全地进行故障转移。

ZKFC （Zookeeper 故障转移控制器）

• Failover Controller(故障转移控制器)
• 对 NameNode 的主备切换进行总体控制，能及时检测到 NameNode 的健康状况 - 在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换- 为了防止因为NN的GC失败导致心跳受影响，ZKFC作为一个deamon进程从NN分离出来
• 启动时 - 当集群启动时，主备节点的概念是很模糊的- 当ZKFC只检查到一个节点是健康状态，直接将其设置为主节点- 当zkfc检查到两个NN节点是的健康状态，发起投票机制- 选出一个主节点，一个备用节点，并修改主备节点的状态
• 运行时 - 由这 3 个组件来协同实现主备切换 - ZKFailoverController启动的时候会创建 HealthMonitor 和 ActiveStandbyElector 这两个主要的内部组件- ActiveStandbyElector 主要负责完成自动的主备选举，内部封装了 Zookeeper 的处理逻辑- HealthMonitor 主要负责检测 NameNode 的健康状态
• 主备节点正常切换 - NameNode 在选举成功后，ActiveStandbyElector会在 zk 上创建一个ActiveStandbyElectorLock 临时节点，而没有选举成功的备 NameNode 中的 ActiveStandbyElector会监控这个节点- 如果 Active NameNode 对应的 HealthMonitor 检测到 NameNode 的状态异常时， ZKFailoverController 会主动删除 当前在 Zookeeper 上建立的临时节点ActiveStandbyElectorLock- 如果是 Active NameNode 的机器整个宕掉的话，那么跟zookeeper连接的客户端线程也挂了,会话结束,那么根据 Zookeepe的临时节点特性，ActiveStandbyElectorLock 节点会自动被删除，从而也会自动进行一次主备切换- 处于 Standby 状态的 NameNode 的 ActiveStandbyElector 注册的监听器就会收到这个节点的 NodeDeleted 事件，并创建 ActiveStandbyElectorLock 临时节点，本来处于 Standby 状态的 NameNode 就选举为Active NameNode 并随后 开始切换为 Active 状态。

ZooKeeper

• 为主备切换控制器提供主备选举支持。
• 辅助投票
• 和ZKFC保持心跳机制，确定ZKFC的存活

脑裂brain-split

• 定义 - 脑裂是Hadoop2.X版本后出现的全新问题，实际运行过程中很有可能出现两个namenode同时服务于整个集群的情况，这种情况称之为脑裂。

• 原因 - 脑裂通常发生在主从namenode切换时，由于ActiveNameNode的网络延迟、设备故障等问题，另一个NameNode 会认为活跃的NameNode成为失效状态，此时StandbyNameNode会转换成活跃状态，此时集群中将会出现两个活 跃的namenode。因此，可能出现的因素有网络延迟、心跳故障、设备故障等。

• 脑裂场景 - NameNode 可能会出现这种情况，NameNode 在垃圾回收（GC）时，可能会在长时间内整个系统无响应- zkfc客户端也就无法向 zk 写入心跳信息，这样的话可能会导致临时节点掉线，备 NameNode 会切换到 Active 状态- 这种情况可能会导致整个集群会有同时有两个Active NameNode

• 脑裂问题的解决方案是隔离（Fencing） - 1.第三方共享存储：任一时刻，只有一个 NN 可以写入；- 2.DataNode：需要保证只有一个 NN 发出与管理数据副本有关的命令；- 3.Client需要保证同一时刻只有一个 NN 能够对 Client 的请求发出正确的响应。 - (a) 每个NN改变状态的时候，向DN发送自己的状态和一个本次选举对应的序列号。- (c) 如果这时原来的active（比如GC）恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时DN就 会拒绝这个NN的命令。- DN接收到这个返回是认为该NN为新的active。- (b) DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更 大的序列号。

• 解决方案 - ActiveStandbyElector为了实现 fencing，当NN成为ANN之后创建Zookeeper临时节点ActiveStandbyElectorLock，创 建ActiveBreadCrumb 的持久节点，这个节点里面保存了这个 Active NameNode的地址信息(node-01)- Active NameNode的 ActiveStandbyElector在正常的状态下关闭 Zookeeper Session 的时候，会一起删除这个持久节 点- 但如果 ActiveStandbyElector在异常的状态下关闭，那么由于 /hadoop-ha/${dfs.nameservices}/ActiveBreadCrumb 是持久节点，会一直保留下来，后面当另一个 NameNode 选主成功之后，会注意到上一个 Active NameNode 遗留 下来的这个节点，从而会回调 ZKFailoverController的方法对旧的 Active NameNode 进行 fencing。 - 首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的 transitionToStandby 方法，看能不能 把它转换为 Standby 状态；- 如果 transitionToStandby 方法调用失败，那么就执行 Hadoop 配置文件之中预定义的隔离措施。 - 1. sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死- 2. shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离- 在成功地执行完成 fencing 之后，选主成功的 ActiveStandbyElector 才会回调 ZKFailoverController 的 becomeActive 方法将对应的 NameNode 转换为 Active 状态，开始对外提供服务。- 新的主创建临时节点ActiveStandbyElectorLock，创建持久化节点ActiveBreadCrumb ，并将自己的主机地址Node02 赋值给初始化节点