Hadoop的优化与发展

Hadoop1.0的缺陷与不足：

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

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

• 表达能力有限

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

• 难以看到程序整体逻辑

• 执行迭代操作效率低

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

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

针对Hadoop的改进与提升：

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

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

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

Hadoop框架自身的改进：从1.0到2.0：

自身改进

不断完善的Hadoop生态系统：

完善

HDFS HA：

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

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

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

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

• Zookeeper确保一个名称节点在对外服务。

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

HDFS Federation：

HDFS1.0中存在的问题：

• 单点故障问题。

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

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

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

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

HDFS Federation的设计：

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

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

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

HDFS Federation的访问方式：

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

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

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

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

HDFS Federation相对HDFS1.0的优势：

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

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

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

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

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

MapReduce1.0的缺陷：

1. 存在单点故障。

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

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

4. 资源划分不合理（强制划分为slot ，包括Map slot和Reduce slot）。

YARN的设计思路：

YARN架构思路：将原JobTacker三大功能拆分

• MapReduce1.0既是一个计算框架，也是一个资源管理 调度框架。

• 到了Hadoop2.0以后，MapReduce1.0中的资源管理调度功能，被单独分离出来形成了YARN，它是一个纯粹的资源管理调度框架，而不是一个计算框架。

• 被剥离了资源管理调度功能的MapReduce 框架就变成了MapReduce2.0，它是运行在YARN之上的一个纯粹的计算框架，不再自己负责资源调度管理服务，而是由YARN为其提供资源管理调度服务。

以上