第9章 Hadoop再探讨

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体系结构

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，如图所示。

YARN的工作流程

9.3.5~6 YARN框架的补充

YARN不仅可以为MR计算框架提供资源调度服务，也可以为Spark、Storm等跨框架服务。事实上，这也是YARN的发展目标，发展成为集群统一的资源管理调度框架，上面可以部署各式各样的的计算框架，包括MR、Tez、HBase、Storm、Giraph、Spark、等等。

YARN之上，部署各种计算框架

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各个组件之间的不同类型的数据的实时高效交换。
如下图

Kafka充当数据交换枢纽