第9章 Hadoop再探讨

第9章 Hadoop再探讨

9.1Hadoop的优化与发展

9.1.1Hadoop的局限与不足

Hadoop1.0的核心组件（仅指MapReduce和HDFS，不包括Hadoop生态系统内的Pig、Hive、HBase等其他组件）， 主要存在以下不足：

•抽象层次低，需人工编码

•表达能力有限

•开发者自己管理作业（Job）之间的依赖关系

•难以看到程序整体逻辑

•执行迭代操作效率低

•资源浪费（Map和Reduce分两阶段执行）

•实时性差（适合批处理，不支持实时交互式）

9.1.2针对Hadoop的改进与提升

Hadoop的优化与发展主要体现在两个方面：

•一方面是Hadoop自身两大核心组件MapReduce和HDFS的架构设计改进

•另一方面是Hadoop生态系统其它组件的不断丰富，加入 了Pig、Tez、Spark和Kafka等新组件

---

9.2 HDFS2.0的新特性

9.2.1 HDFS HA

名称节点保存元数据：

（1）在磁盘上：FsImage和EditLog

（2）在内存中：映射信息，即文件包含哪些块，每个块存储在哪个数据节点

**HDFS HA（High Availability）**是为了解决单点故障问题

1.HA集群设置两个名称节点，“活跃（Active）”和“待命（Standby）”

2.两种名称节点的状态同步，可以借助于一个共享存储系统来实现

3.一旦活跃名称节点出现故障，就可以立即切换到待命名称节点

4.Zookeeper确保一个名称节点在对外服务

5.名称节点维护映射信息，数据节点同时向两个名称节点汇报信息

---

9.2.2 HDFS Federation

1.HDFS1.0中存在的问题

•单点故障问题

•不可以水平扩展（是否可以通过纵向扩展来解决？）

•系统整体性能受限于单个名称节点的吞吐量

•单个名称节点难以提供不同程序之间的隔离性

•HDFS HA是热备份，提供高可用性，但是无法解决可扩展性、系统性能和隔离性

2.HDFS Federation的设计

•在HDFS Federation中，设计了多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展，这些名称节点分别进行各自命名空间和块的管理，相互之间是联盟 （Federation）关系，不需要彼此协调。 并且向后兼容

•HDFS Federation中，所有名称节点会共 享底层的数据节点存储资源，数据节点向所有名称节点汇报

•属于同一个命名空间的块构成一个“块池”

3.HDFS Federation的访问方式

•对于Federation中的多个命名空间，可以采用客户端挂载表（Client Side Mount Table）方式进行数据共享和访问

•客户可以访问不同的挂载点来访问不同的子命名空间

•把各个命名空间挂载到全局“挂载表” （mount-table）中，实现数据全局共享

•同样的命名空间挂载到个人的挂载表中， 就成为应用程序可见的命名空间

4.HDFS Federation相对于HDFS1.0的优势

HDFS Federation设计可解决单名称节点存在的以下几个问题：

（1）HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集 群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件存储数目

（2）性能更高效。多个名称节点管理不同的数据，且同时对外提供服务， 将为用户提供更高的读写吞吐率

（3）良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小

需要注意的，HDFS Federation并不能解决单点故障问题，也就是说，每 个名称节点都存在在单点故障问题，需要为每个名称节点部署一个后备名称节点，以应对名称节点挂掉对业务产生的影响

---

9.3新一代资源管理调度框架YARN

9.3.1 MapReduce1.0的缺陷

（1）存在单点故障

（2）JobTracker“大包大揽”导致任务过重（任务多时内存开销大，上限4000节点）

（3）容易出现内存溢出（分配资源只考虑MapReduce任务数，不考虑CPU、内存）

（4）资源划分不合理（强制划分为slot ，包括Map slot和Reduce slot，YARN中的资源管理比MapReduce1.0更加高效，以容器为单位，而不是以slot为单位）

---

9.3.2 YARN体系结构

MapReduce1.0： 计算框架+资源管理调度框架

MapReduce2.0： 计算框架 YARN： 资源调度框架

（1）ResourceManager：

•处理客户端请求

•启动/监控ApplicationMaster

•监控NodeManager

•资源分配与调度

（2）NodeManager： NodeManager是驻留在一个YARN集群中的每个节点上的代理

•单个节点上的资源管理

•处理来自ResourceManger的命令

•处理来自ApplicationMaster的命令

（3）ApplicationMaster：

•为应用程序申请资源， 并分配给内部任务
•任务调度、监控与容错

---

9.3.3 YARN工作流程

步骤1：用户编写客户端应用程序，向YARN提交应用程序，提交的内容包括 ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等

步骤2：YARN中的ResourceManager负责接收和处理来自客户端的请求，为应用程序分配一个容器，在该容器中启动一个ApplicationMaster

步骤3：ApplicationMaster被创建后会首先向 ResourceManager注册

步骤4：ApplicationMaster采用轮询的方式向 ResourceManager申请资源

步骤5：ResourceManager以“容器”的形式向提出申请的ApplicationMaster分配资源

步骤6：在容器中启动任务（运行环境、脚本）

步骤7：各个任务向ApplicationMaster汇报自己的状态和进度

步骤8：应用程序运行完成后， ApplicationMaster向ResourceManager的应用程序管理器注销并关闭自己

---

9.4 Hadoop生态系统中具有代表性的功能组件

9.4.1 Pig

•提供了类似SQL的Pig Latin语言（包含Filter、GroupBy、Join、 OrderBy等操作，同时也支持用户自定义函数）

•允许用户通过编写简单的脚本来实现复杂的数据分析，而不需要编写复杂的MapReduce应用程序

•Pig会自动把用户编写的脚本转换成MapReduce作业在Hadoop集群上运行，而且具备对生成的MapReduce程序进行自动优化的功能

•用户在编写Pig程序的时候，不需要关心程序的运行效率，这就大大减少了用户编程时间

•通过配合使用Pig和Hadoop，在处理海量数据时就可以实现事半功倍的效果，比使用Java、C++等语言编写MapReduce程序的难度要小很多，并且用更少的代码量实现了相同的数据处理分析功能

---

9.4.2 Tez

•Tez是Apache开源的支持DAG作业的计算框架，它直接源于 MapReduce框架

•核心思想是将Map和Reduce两个操作进一步拆分 •Map被拆分成Input、Processor、Sort、Merge和Output

• Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output等

•分解后的元操作可以任意灵活组合，产生新的操作

•这些操作经过一些控制程序组装后，可形成一个大的DAG作业

•通过DAG作业的方式运行MapReduce作业，提供了程序运行的整体处理逻辑，就可以去除工作流当中多余的Map阶段，减少不必要的操作， 提升数据处理的性能

•Hortonworks把Tez应用到数据仓库Hive的优化中，使得性能提升了约100倍

---

9.4.3 Spark

Spark是一个开源集群运算框架，最初是由加州大学柏克莱分校AMPLab所开发。相对于Hadoop的MapReduce会在运行完工作后将中介资料存放到磁盘中，Spark使用了存储器内运算技术，能在资料尚未写入硬盘时即在存储器内分析运算。Spark在存储器内运行程序的运算速度能做到比Hadoop MapReduce的运算速度快上100倍，即便是运行程序于硬盘时，Spark也能快上10倍速度。[1]Spark允许用户将资料加载至集群存储器，并多次对其进行查询，非常适合用于机器学习算法。

---

9.4.4 Kafka

•Kafka是一种高吞吐量的分布式发布订阅消息系统，用户通过Kafka系统可以发布大量的消息，同时也能实时订阅消费消息

•Kafka可以同时满足在线实时处理和批量离线处理 ，在公司的大数据生态系统中，可以把Kafka作为数据交换枢纽，不同类型的分布式系统（关系数据库、 NoSQL数据库、流处理系统、批处理系统等），可以统一接入到Kafka，实现和Hadoop各个组件之间的不同类型数据的实时高效交换