自学大数据的第15天~Hadoop框架的历史沿革

前面学习了MongoDB,也只是一些入门的操作,后续还会继续深入学习

深入学习Hadoop,那么就需要了解Hadoop发展的历史沿革,就像学习历史一样;

当然一件事物被创作出来需要不断地发展才能完善;

Hadoop1.0

在Hadoop刚刚出来时,由于相关能力还不完善,所以会有一些缺陷,比如下面的几个方面:

1. 抽象层次低

为什么这么说呢,你看现在我们使用Hadoop的时候只需要编写一个JAR文件就可以了,在hadoop1.0时候需要开发者自己管理各个作业之间的依赖关系所以Hadoop1.0时不像现在那样只需要关心jar怎么写(当然也可以使用其他语言编写处理逻辑,这里只是举个例子);

2. 表达能力有限

表达能力有限是说什么呢?即使Hadoop的适用场景有限,像什么遗传算法~迭代计算等他是不适用的,因为他是通过Map处理完之后再通过reduce来处理,所以对于迭代计算,hadoop是不适用的;

3. 实时性差

前面说了Map处理完之后,Reduce再来处理,所以他的实时性是较差的;

4. 单点故障

由于那时候设计的只有一个主namenode节点(secondarynamenode并不是热备节点),所以当namenode节点出现故障时,整个系统就崩了;

5. 隔离性

由于是单节点机制,所以对于命名空间上的隔离性就很差,

6. 资源管理效率低下

对于资源的管理,1.0并没有提供很好的一套解决方案,往往需要开发人员去写代码实现,但这是不通用的;

所以hadoop2.0对以上的缺陷进行了改进;

Hadoop2.0

都改了些什么呢?

1. 解决了单节点故障问题
   对于namenode新增了一个热备份节点,通过zookeeper来监控节点状态以此来实现始终有一个节点处于活跃状态,另一个节点随时待命;

这两个节点之间是如何做到数据同步的?

通过共享内存空间实现了blockid的同步
然后是通过datanode实时向namenode汇报自己存储的块的信息

2. 新增组件,丰富生态
   对于hadoop1.0的缺陷,hadoop2.0又推出了相应的组件来解决1.0版本时候的一些缺陷;

新增组件	解决的问题
pig	处理大规模数据的脚本语言,解决了1.0版本需要自己编写代码去处理数据的问题
spark	基于内存的分布式并行编程框架,支持迭代计算,实时性计算能力得到了提升
Oozie	工作流和协调服务引擎,用于协调hadoop上不同的任务
Tez	DAG计算框架,用于对作业实现分解,重新组合以减少重复作业的任务
Kafka	用于解决各个组件之间的数据交换

还有一个问题~那就是命名空间之间的隔离性;

3. 命名空间隔离

Hadoop Fedoration机制解决了该问题:
该机制通过拆分原来一个命名空间为N个,这样保证了每个命名空间之间的隔离性,每个命名空间中的元数据被称为一个块池(即保存了指向每个块的所有数据,就像一个水池),但是底部存储空间大家是公用的;

简单的来说就是将原来一个命名空间切分成N份,每份都可用于寻址;

画个图看一下啊:

这一点就像是我们的文件系统,每一个文件夹下可以有不同的数据,只有通过这一个文件夹才能访问该数据,这就实现了命名空间之间的隔离性;

4. 资源管理效率
   hadoop1.0的时候通过jobtracker实现资源的分配,但是他跟namenode一样也是只有一个节点,这同样会出现单点故障的问题:

当任务过多的时候,jobtracker对任务的分配处理压力就很大了,根本处理不过来呀,(可能会出现内存溢出哦),如果任务出现故障还要负责任务的恢复…
有数据显示hadoop1.0版本中节点数量超过4000就很容易出现故障;

hadoop1.0中jobtracker对资源的划分单位为一个个slot(对内存和cpu的分配单位),map有map的slot,reduce有reduce的slot,同样是slot两者却不同通用,不能互用;

为了解决这个问题,推出了Yarn来管理资源

将原来hadoop1.0时候的jobtracker的能力进行拆分,拆分方案如下:

master端:将JobTRacker功能拆分成以下

• 资源管理~ResourceManager
• 任务调度 ~ApplicationMaster
• 任务监控~ApplicationMaster

slave端,将tasktracker替换为nodemanager

这样原来hadoop1.0的体系架构就被拆分成了下面这个样子:
hadoop(负责计算)+yarn(负责资源管理)

Yarn组件功能

ResourceManager

全局的资源管理器,负责整个系统的资源管理和分配,主要包括两个组件~调度器和应用程序管理器

1. 处理客户端请求
2. 启动/监控ApplicationMaster
3. 监控NodeManager
4. 资源分配与调度

调度器

调度器接受来自applicationmaster的应用程序资源请求,把集群中的资源以容器¹的形式(1.0是一个个slot)分配给提出申请的应用程序,容器的选择会考虑应用程序所要处理的数据的位置,进行就近选择从而实现计算向数据靠拢

调度器被设计成一个可插拔的组件,允许用户自定义调度器;

应用程序管理器

管理所有应用程序的管理工作,主要包括应用程序提交,与调度器协调资源以
启动ApplicationMaster,
监控ApplicationMaster运行状态
在状态失败时重新启动;

ApplicationMaster作用

1. 为程序申请资源,并分配给内部任务
2. 任务调度,监控与容错,(请求发送们给ApplicationMaster,由ApplicationMaster向ResourceManager申请内存等资源,ResourceManager会以容器的形式向申请对象分配资源;

NodeManager作用

1. 单个节点的资源管理器
2. 处理来自ResourceManager的命令
3. 处理来自ApplicationMaster命令

yarn集群中每个节点都有nodemanager,负责监控容器的生命周期;

Yarn体系结构

Yarn的工作流程

• 客户端向Yarn提交请求

1. 应用程序
2. applicationmaster程序
3. 启动applicationmaster命令

• 分配容器

ResourceManager接受请求后为应用程序分配一个容器,然后在容器中启动一个ApplicationMaster

• 注册
  Applicationmaster向ResourceManager注册,以使得RM能够获得容器的运行情况;

• 申请资源
  ApplicationMaster采用轮询的方式向RM申请资源

• 分配资源
  容器资源分配给每一个任务(map/reduce)

• 注销资源
  任务运行完毕后,ApplicationMaster向ResourceManager管理器注销并关闭容器;

如下图所示:

Yarn的到来给Hadoop1.0版本带来了性能的提升:

1. 减少了原来Jobtracker的功能挤压,减少了资源消耗
2. 每个作业单独分配一个applicationmaster,由applicationmaster去管理容器的运行,不像jobtracker那样每个作业都管)根本管不过来)
3. yarn框架是纯粹的资源调度管理框架,可以单独定制资源调度管理的方式(实现Applicationmaster即可)

Yarn资源管理框架,它不仅仅可以自定义资源管理调度方式,也可基于这个框架²运行各种其他的框架:

1. 运行MR的批处理
2. 运行流计算Storm
3. 运行基于内存计算的Spark

---

1. 一个动态的资源分配单位,每个容器内都封装了一定数量的CPU,内存,磁盘等资源,从而限定每个应用程序可以使用的资源量 ↩︎

2. 一个业务场景中可能需要不同的计算框架,yarn统一管理 ↩︎