大数据学习系列（九）Hadoop1.X痛点分析及Hadoop2.X提出的解决方案

一、Hadoop1.X痛点分析

上篇博客搭建了hadoop1.x的全分布式集群项目，角色及角色之间的关系如下图：

搭建完成后会发现有明显的问题，该集群只有一台服务器位 namenode角色，而在整个hadoop系统中，namenode的作用和责任又如此之大 ，如果namenode节点挂掉了，那么就意味着整个hadoop系统挂掉，因为所有的文件上传及管理操作及计算操作都是通过client(客户端)去请求namenode,namenode再去调用datanode。

痛点一、所以只有一台namenode节点是 不可靠的。统称：单点故障

痛点二、而只有一台namenode节点，当大量的客户端并发操作的时候，肯定会降低namenode的响应速度，所以从性能角度，hadoop1.X也是存在着很大的 弊端。统称：内存受限

二、Hadoop2.X提供的解决方案

Hadoop 2.x由HDFS、MapReduce和YARN三个分支构成；

HDFS：分布式文件系统

MapReduce：运行再YARN上的MR，用于离线计算，基于磁盘I/O计算。

YARN：资源管理系统

针对痛点一：解决单点故障

          HDFS  HA:  

                      解释：HA是high alive，高可用的意思，通过部署主备namenode来解决。2.X需要部署 两台namenode,3.X可部署 三台，如果主namenode发生故障，则切换至备namenode上。

针对痛点二：解决内存首先问题

           HDFS Federation(联邦)：

                      解释：类似HA的思想，水平扩展，部署多台namenode,所有的namenode服务器共享所有的datanode存储 的资源。但是每台namenode上只能操作和分管一部分目录。

三、2.X中，HA详解

从下往上开始说明

1.最下面是datanode节点服务器。

2.往上为两台namenode节点，一台为active(活跃状态)，一台为standby(备用状态)，只能有一台active。当active的namenode节点挂掉后，standby状态的namenode状态变为active,并将挂掉的namenode状态强制改为standby状态。

主NameNode对外提供服务，备NameNode同步主NameNode元数据，以待切换。

所有DataNode同时向两个NameNode汇报数据块信息（位置）

3.JournalNodes(JN集群 )：在1.X版本中，通过搭建一台secondary namenode节点来记录"所有操作"到edits文件，然后存放在namenode上。在2.x版本中，为了同步两台namenode节点，”所有操作“都记录在JN上，然后为解决JN存在单点故障的问题，所以应用JN集群,官方要求最少3台，允许挂掉一台。

到此已经可以把2.X的hadoop跑起来了，但是此时的HA环境，当active状态的namenode节点挂掉后，需要手动的去改standby状态的namenode。我需要的是这种情况下的自动状态切换，所以就需要应用了zookeeper集群。

4.zookeeper集群：zk是是分布式应用程序协调服务，避免单点故障发生，用zk集群。通过配置后，他会在namenode上开启一个zkfc线程(zookeeper  FailoverController)来监测NN的健康状态。当然这个监测行为并不是主动的，是standby的NN委托ZK监测active的NN。

四、2.X中 ，HDFS Federation(联邦)详解

待更新