9.1 Hadoop的优化与发展
9.1.1 Hadoop1.0的局限与不足
(1)抽象层次低:简单任务也要很复杂的编码;
(2)表达能力优先:不是所有的任务都能抽象成Map和Reduce
(3)需开发者自行管理Job间依赖关系
(4)难以看到程序的整体逻辑:可以理解为没有主流程,只有一个个的MR程序组合起来
(5)执行迭代操作时效率低:每次MR后都写入磁盘,供下一次MR使用,这对机器学习等而言效率很低
(6)资源浪费:M和R是严格分先后顺序的
(7)实时性很差,只能离线批处理
9.1.2 主要的优化和发展
(1)对M和R两个核心组件的改进
HDFS改进:① 设计了HDFS HA,实现对名称节点的热备份,② HDFS联邦
(2)新增了很多其它组件
① Pig - 抽象层次高,使用脚本语言处理大规模数据
② Spark - 基于内存的分布式并行编程框架,较高实时性
③ Oozie - 工作流和协作服务引擎
④ Tez - 支持DAG作业的计算框架,减少重复操作
⑤ Kafka - 衔接不同类型的分布式系统
9.2 HDFS2.0新特性
9.2.0 HDFS1.0的问题
1)单点故障问题
2)不可以水平扩展,纵向扩展会导致启动耗时激增
3)系统整体整体性能受限于单个名称节点的吞吐量
4)不同程序间不可以隔离
9.2.1 HDFS HA
解决单点故障问题:设置两个名称节点,一个活跃,一个待命,两者通过共享存储系统实现实时的状态同步,由Zookeeper确保任意时刻只有一个名称节点对外服务。
9.2.2 HDFS Federation
解决9.2.0中后几个问题:设置了多个相互独立的名称节点,共享底层的存储资源,数据节点向所有名称节点汇报,不同的名称节点管理不同业务数据,实现程序隔离。
9.3 新一代资源管理调度框架 - YARN
9.3.1 MR1.0的缺陷
1)单点故障,一个JobTracker负责所有MR作业的调度
2)任务过重:一个JoTracker既要管资源的管理分配,又要管作业调度和失败恢复等,进而导致内存开销过大和易出故障
3)容易内存溢出:TaskTracker端资源的分配仅根据MR任务的个数,而不管每个任务实际消耗的CPU和内存资源
4)资源划分不合理:CPU和内存都被划分为slot,slot又被进一步划分为M槽和R槽,互相不使用对方的槽,而同一个程序的M和R是串行的,所以容易导致资源浪费。
9.3.2 YARN设计思路
把JobTracker的资源管理、任务调度、任务监控三个任务拆分出来,由YARN的不同模块(ResourdeManager和ApplicationMaster)去负责,原TaskTracker改为NodeManager。
注意:YARN是一个纯粹的资源调度框架,而MR2.0则是一个运行在YARN之上的纯粹的计算框架。
9.3.3 YARN体系结构
包含ResourceManager、ApplicationMaster、NodeManager三个模块,功能阐述如下。
1)ResourceManager
RM是全局的资源管理器,负责整个集群的资源管理和分配,包含调度器Scheduler、应用程序管理器ApplicationManager两个核心模块。
调度器接受AppMaster的资源请求,以容器形式进行分配。
启动/监控AppMaster、监控NodeManager、等
2)ApplicationMaster
为应用程序申请资源,并分配给内部任务;任务调度、监控与容错;以心跳的方式随时向ResoureceManager报备。
3)NodeManager
是YARN驻留在每个节点的代理,管理着节点(容器)的生命周期、资源使用情况等,并随时与ResourceManager通信。
注意:在部署上,ResourceManager和HDFS的名称节点部署在同意节点上,而AppMaster和NodeManager和HDFS的数据节点在同一节点上。
9.3.4 YARN工作流程
1)用户准备好AppMaster程序、启动AppMaster的命令、用户程序,三个东西,并提交给YARN
2)ResourceManager接收到请求,为应用程序分配一个容器,并在容器里启动一个AppMaster
具体流程看教材P163,如图所示。
9.3.5~6 YARN框架的补充
YARN不仅可以为MR计算框架提供资源调度服务,也可以为Spark、Storm等跨框架服务。事实上,这也是YARN的发展目标,发展成为集群统一的资源管理调度框架,上面可以部署各式各样的的计算框架,包括MR、Tez、HBase、Storm、Giraph、Spark、等等。
9.4 Hadoop生态中的代表性组件
9.4.1 Pig
1)类SQL语言的Pig Latin语言,支持过滤、分组、连接、排序等类SQL操作;
2)把Pig脚本转化成MR作业,且可以自动优化,因此不需要考虑代码效率问题;
3)基本格式
① 通过LOAD语句从文件系统中读取数据
② 一系列ETL语句进行数据处理
③ 通过STORE把处理结果输出到文件系统中
9.4.2 Tez
1)支持DAG作业的计算框架
2)把Map和Reduce进一步拆分成更细的作业,包括输入、处理、排序、合并、输出等
3)在更细颗粒度的设计下,任务可以被转换成一个有向无环图,避免了重复的M或R操作。经过Tez优化后的Hive性能可以提升100倍。
4)在Hadoop生态中的位置:MR、Pig、Hive等框架的任务最终都被转换成MR任务执行,而Tez相当于对MR进行了优化,因此可以把MR、Pig、Hive运行于Tez之上,而把Tez运行于YARN之上,把YARN运行于HDFS之上。
5)于Impala的区别:Impala抛弃了MR框架,采用与商用并行关系数据库类似的分布式查询引擎,效率更高,但是能处理的数据类型有限。
9.4.3 Spark
1)与MR相比,每次计算把结果放到内存中(而非放到磁盘中)
2)同样采用DAG任务调度机制,可以有效避免重复操作
上述两点改进,加之以结构一体化、功能多元化的优势,使得Spark逐渐成为当今大数据领域最热门的计算平台。
9.4.5 Kafka
1)高吞吐量的分布式发布订阅消息系统
2)同时满足在线实时处理和批量离线处理
3)充当数据枢纽的作用,实现和Hadoop各个组件之间的不同类型的数据的实时高效交换。
如下图