Hadoop的优化与发展
最后更新于
最后更新于
Hadoop1.0的核心组件（仅指MapReduce和HDFS，不包括Hadoop生态系统内的Pig、Hive、HBase等其他组件），主要存在以下不足：
抽象层次低，需人工编码
表达能力有限
开发者自己管理作业（Job）之间的依赖关系
难以看到程序整体逻辑
执行迭代操作效率低
资源浪费（Map和Reduce分两阶段执行）
实时性差（适合批处理，不支持实时交互式）
Hadoop的优化与发展主要体现在两个方面：
一方面是Hadoop自身两大核心组件MapReduce和HDFS的架构设计改进。
另一方面是Hadoop生态系统其它组件的不断丰富，加入了Pig、Tez、Spark和Kafka等新组件。
Hadoop框架自身的改进：从1.0到2.0：
不断完善的Hadoop生态系统：
HDFS HA（High Availability）是为了解决单点故障问题。
HA集群设置两个名称节点，“活跃（Active）”和“待命（Standby）”。
两种名称节点的状态同步，可以借助于一个共享存储系统来实现。
一旦活跃名称节点出现故障，就可以立即切换到待命名称节点。
Zookeeper确保一个名称节点在对外服务。
名称节点维护映射信息，数据节点同时向两个名称节点汇报信息。
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设计可解决单名称节点存在的以下几个问题：
HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件存储数目 。
性能更高效。多个名称节点管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率 。
良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小。
需要注意的，HDFS Federation并不能解决单点故障问题，也就是说，每个名称节点都存在在单点故障问题，需要为每个名称节点部署一个后备名称节点，以应对名称节点挂掉对业务产生的影响。
存在单点故障。
JobTracker“大包大揽”导致任务过重（任务多时内存开销大，上限4000节点）。
容易出现内存溢出（分配资源只考虑MapReduce任务数，不考虑CPU、内存）。
资源划分不合理（强制划分为slot ，包括Map slot和Reduce slot）。
YARN架构思路：将原JobTacker三大功能拆分
MapReduce1.0既是一个计算框架，也是一个资源管理 调度框架。
到了Hadoop2.0以后，MapReduce1.0中的资源管理调度功能，被单独分离出来形成了YARN，它是一个纯粹的资源管理调度框架，而不是一个计算框架。
被剥离了资源管理调度功能的MapReduce 框架就变成了MapReduce2.0，它是运行在YARN之上的一个纯粹的计算框架，不再自己负责资源调度管理服务，而是由YARN为其提供资源管理调度服务。
以上
