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设计可解决单名称节点存在的以下几个问题：
- HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件存储数目 。
- 性能更高效。多个名称节点管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率 。
- 良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小。
需要注意的，HDFS Federation并不能解决单点故障问题，也就是说，每个名称节点都存在在单点故障问题，需要为每个名称节点部署一个后备名称节点，以应对名称节点挂掉对业务产生的影响。
MapReduce1.0的缺陷：
- 存在单点故障。
- JobTracker“大包大揽”导致任务过重（任务多时内存开销大，上限4000节点）。
- 容易出现内存溢出（分配资源只考虑MapReduce任务数，不考虑CPU、内存）。
- 资源划分不合理（强制划分为slot ，包括Map slot和Reduce slot）。
YARN的设计思路：
YARN架构思路：将原JobTacker三大功能拆分
- MapReduce1.0既是一个计算框架，也是一个资源管理
调度框架。 - 到了Hadoop2.0以后，MapReduce1.0中的资源管理调度功能，被单独分离出来形成了YARN，它是一个纯粹的资源管理调度框架，而不是一个计算框架。
- 被剥离了资源管理调度功能的MapReduce 框架就变成了MapReduce2.0，它是运行在YARN之上的一个纯粹的计算框架，不再自己负责资源调度管理服务，而是由YARN为其提供资源管理调度服务。
以上内容为听华为大数据培训课程和大学MOOC上厦门大学 林子雨的《大数据技术原理与应用》课程而整理的笔记。
大数据技术原理与应用： https://www.icourse163.org/course/XMU-1002335004
