Hadoop学习四 2.x介绍

1、Hadoop 1.x带来问题

1、单点故障

• 每个群集只有一个NameNode，NameNode存在单点故障（SPOF）。
• 如果该计算机或进程不可用，则整个群集在整个NameNode重新启动或在另一台计算机上启 动之前将不可用
• 如果发生意外事件（例如机器崩溃），则在操作员重新启动NameNode之前，群集将不可 用。
• 计划内的维护事件，例如NameNode计算机上的软件或硬件升级，将导致群集停机时间的延 长

2、水平扩展 将来服务器启动的时候，启动速度慢

3、namenode随着业务的增多，内存占用也会越来越多 如果namenode内存占满，将无法继续提供服务

4、日志丢失问题

 2、Hadoop 2.x解决问题

2.1 Hadoop-HA

1、hadoop2.x启用了主备节点切换模式（1主1备）

2、当主节点出现异常的时候，集群直接将备用节点切换成主节点

•         要求备用节点马上就要工作
•         主备节点内存几乎同步 有

3、独立的线程对主备节点进行监控健康状态

4、需要有一定的选举机制，帮助我们确定主从关系

5、我们需要实时存储日志的中间件

2.1 Active NameNode

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

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

2、存储数据的元数据信息

•         数据文件：Block：DN的映射关系

3、工作

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

存储介质：完全基于内存

•         优点：数据处理效率高
•         缺点：数据的持久化(日志edits+快照fsimage)

2.1 Standby NameNode 

1、Standby NameNode：NN的备用节点

2、他和主节点做同样的工作，但是它不会发出任何指令

3、存储：数据的元数据信息

•         数据文件：Block：DN的映射关系
•         它的内存数据和主节点内存数据几乎是一致的

4、工作：

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

5、存储介质：完全基于内存

•         优点：数据处理效率高
•         缺点：数据的持久化 

 6、合并日志文件和镜像

        当搭建好集群的时候，格式化主备节点的时候，ANN和SNN都会默认创建

•                 fsimage_000000000000000

        当我们操作HDFS的时候ANN会产生日志信息

•                 edits_inprogress_0000000000001

        主节点会将日志文件中新增的数据同步到JournalNode集群上

        所以只需要snn有操作的日志信息，就可以合并fsImage与edits信息,理论上是一直在合并数

•                 fsimage -->初始化创建
•                 edits-->从JournalNode集群上定时同步
•                 只要同步到edits文件，就开始于fsimage合并
•                 当达到阈值的时候，直接拍摄快照即可

        SNN将合并好的Fsimage发送给ANN，ANN验证无误后，存放到自己的目录中

 2.3 JournalNode

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

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

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

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

5、SNN每间隔一段时间就去QJM上面取回最新的日志

•         SNN上的日志有可能不是最新的

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

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

 2.4 ZKFC（Failover Controller故障转移控制器）

对 NameNode 的主备切换进行总体控制，能及时检测到 NameNode 的健康状况，在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换，为了防止因为NN的GC失败导致心跳受影响，ZKFC作为一个deamon进程从NN分离出来

启动时：

• 当集群启动时，主备节点的概念是很模糊的
• 当ZKFC只检查到一个节点是健康状态，直接将其设置为主节点
• 当zkfc检查到两个NN节点是的健康状态，发起投票机制
• 选出一个主节点，一个备用节点，并修改主备节点的状态 

运行时： 由 ZKFailoverController、HealthMonitor 和 ActiveStandbyElector 这 3 个组件来协同实现

• 主备切换 ZKFailoverController启动的时候会创建 HealthMonitor 和 ActiveStandbyElector 这两 个主要的内部组件
• HealthMonitor 主要负责检测 NameNode 的健康状态
• ActiveStandbyElector 主要负责完成自动的主备选举，内部封装了 Zookeeper 的处理逻辑