[hadoop]hadoop2.x（七）

一、hadoop2.0产生背景

Hadoop1.0中HDFS和MapReduce在高可用、扩展性等方面存在问题

HDFS存在的问题

NameNode单点故障，难以应用于在线场景

NameNode压力过大，且内存受限，影响系统扩展性
MapReduce存在问题

JobTracker访问压力大，影响系统扩展性

难以支持除MapReduce之外的计算框架，比如Spark，Storm等

二、Hadoop1.x与Hadoop2.x





1、Hadoop2.x由HDFS、MapReduce和Yarn三个分支构成

HDFS: NNFederation、HA
MapReduce: 运行在YARN上的MR
YARN: 资源管理系统

2、HDFS2.x

解决HDFS1.0中单点故障和内存受限问题
解决单点故障

HDFS HA: 通过主备NameNode解决

如果主NameNode发生故障，则切换到备NameNode上
解决内存受限问题

HDFSFederation（联邦）

水平扩展，支持多个NameNode

每个NameNode分管一部分目录

所有NameNode共享所有DataNode存储资
2.x仅是架构上发生了变化，使用方式不变
对HDFS使用者透明
HDFS1.x中的命令和API仍可以使用

3、HDFS2.x HA[b]（High Avalability，高可用性）[/b]



名词解释：
ZK：Zookeeper，ZK的基本特性：

可靠存储小量数据且提供强一致性

ephemeral node, 在创建它的客户端关闭后，可以自动删除

对于node状态的变化，可以提供异步的通知(watcher)

ZK在ZKFC中可以提供的功能：

Failure detector: 及时发现出故障的NN，并通知zkfc

Active node locator: 帮助客户端定位哪个是Active的NN

Mutual exclusion of active state: 保证某一时刻只有一个Active的NN

ZKFC：ZKFailoverController，ZKFC主要分成三个线程，一是主线程，二是HealthMonitor线程，三是zookeeper客户端的线程，它们的主要工作方式是：

主线程在启动所有的服务后就开始循环等待

HealthMonitor是一个单独的线程，它定期向NN发包，检查NN的健康状况

当NN的状态发生变化时，HealthMonitor线程会回调ZKFailoverController注册进来的回调函数，通知ZKFailoverController NN的状态发生了变化

ZKFailoverController收到通知后，会调用ActiveStandbyElector的API，来管理在zookeeper上的结点的状态

ActiveStandbyElector会调用zookeeper客户端API监控zookeeper上结点的状态，发生变化时，回调ZKFailoverController的回调函数，通知ZKFailoverController，做出相应的变化

JN：JournalNode，JournalNode的作用是存放EditLog的,在MR1中editlog是和fsimage存放在一起的然后SecondNamenode做定期合并,Yarn在这上面就不用SecondNamanode了。JournalNode数量不一定只有1个,作用相当于NFS共享文件系统.Active Namenode往里写editlog数据,StandBy再从里面读取数据进行同步。

HA特点：
主备NameNode，解决单点故障

主NameNode对外提供服务，备NameNode同步主NameNode元数据，以待切换
所有DataNode同时向两个NameNode汇报数据块信息

两种切换选择

手动切换：通过命令实现主备之间的切换，可以用HDFS升级等场合
自动切换：基于Zookeeper实现

基于Zookeeper自动切换方案

ZookeeperFailoverController：监控NameNode健康状态
并向Zookeeper注册NameNode
NameNode挂掉后，ZKFC为NameNode竞争锁，获得ZKFC锁的NameNode变为Active

4、HDFS2.0 Federation

通过多个namenode/namespace把元数据的存储和管理分散到多个节点上，使到namenode/namespace可以通过增加机器来进行水平扩展
能把单个namenode的负载分散到多个节点上，在HDFS数据规模较大的时候不会也降低HDFS的性能。可以通过多个namespace来隔离不同类型的应用，把不同类型应用的HDFS元数据的储存和管理分派到不同的namenode中



三、YARN Yet Another Resource Negotiator

第一特性：资源管理系统，直接从MRV1演化而来

核心思想：将MRV1中JobTracker的资源管理和任务调度两个功能分开，分别由ResourceManager和ApplicationMaster进程实现

ResourceManager：负责整个集群的资源管理和调度

ApplicationMaster：负责应用程序相关的事务，比如任务调度、任务监控和容错等
第二特性：Yarn的引入，实现了可接口化，使得多个计算框架可运行在一个集群中

每个应用程序对应一个ApplicationMaster

多个计算框架可以运行在YARN上，比如MapReduce、Spark、Storm等

四、MapReduce On YARN

MapReduce on YARN：MRv2
将MapReduce直接运行在YARN上，而不是由Jobtracker和TaskTracker构建MRv1系统中
基本功能模块

1、YARN：负责资源管理和调度

2、MRAppMaster：负责任务切分、任务调度、任务监控和容错等

3、MapTask/ReduceTask：任务驱动引擎，与MPv1一致
每个MapReduce作业对应一个MRAppMaster

1、MRAppMaster任务调度

2、YARN将资源分配给MRAppMaster

3、MRAppMaster进一步将资源分配给内部的任务
MRAppMaster容错

1、失败后，由YARN重新启动

2、任务失败后，MRAppMaster重新申请资源