本文详细探讨了Hadoop1.0的局限与不足，以及Hadoop如何通过HDFS HA和Federation进行改进。介绍了新一代资源管理框架YARN的设计思路和优势，包括ResourceManager、ApplicationMaster、NodeManager的角色。同时，讨论了Hadoop生态系统中如Pig、Tez、Spark等组件的优化与应用。
目录
(Tez+Hive)与Impala、Dremel和Drill的区别
8.1 Hadoop的优化与发展
Hadoop1.0的局限与不足
抽象层次低，需人工编码；表达能力有限；开发者需要自己管理作业（Job）之间的依赖关系；
难以看到程序整体逻辑；执行迭代操作效率低；资源浪费（Map和Reduce分两阶段执行）；
实时性差（适合批处理，不支持实时交互式）
Hadoop进行的改进的提升
一方面是Hadoop自身两大核心组件MapReduce和 HDFS的架构设计改进；
另一方面是Hadoop生态系统其它组件的不断丰富，加入 了Pig、Tez、Spark和Kafka等新组件。
Hadoop模块的自身改进：从1.0到2.0
Hadoop生态系统2.0新增组件
8.2 HDFS HA和HDFS Federation
Hadoop1.0 HDFS
名称节点保存元数据
（1）在磁盘上：FsImage（文件系统树）和EditLog
（2）在内存中：映射信息，即文件包含哪些block块，每个块存储在哪个DataNode数据节点
数据节点储存文件内容
保存在磁盘上，维护block id到DataNode本地文件的映射关系。
第二名称节点
不是热备份；主要是防止日志文件EditLog过 大，导致名称节点失败恢复时消 耗过多时间；附带起到冷备份功能
HDFS HA架构
HDFS HA（High Availability）是为了解决单点故障问题：HA集群设置两个名称节点，“活跃（Active）”和“待命（Standby）”；两种名称节点的状态同步，可以借助于一个共享存储系统（同步活跃状态名称节点的EditLog）来实现（block id与DataNode的映射关系则是数据节点向活跃和待命的名称节点都要汇报得到）；一旦活跃名称节点出现故障，就可以立即切换到待命名称节点；Zookeeper确保一个名称节点在对外服务；名称节点维护映射信息，数据节点同时向两个名称节点汇报信息。
HDFS Federation
HDFS1.0存在的问题
单点故障问题（HDFS HA解决）；
不可以水平扩展（只有一个名称节点，不能往里加很多个名称节点）是否可以纵向扩展来解决？
系统整体性能受限于单个名称节点的吞吐量；
单个名称节点难以提供不同程序之间的隔离性；
HDFS HA是热备份，提供高可用性，但是无法解决可扩展性、系统性能和隔离性。
HDFS Federation架构
在HDFS Federation中，设计了 多个相互独立的名称节点，使得 HDFS的命名服务能够水平扩展， 这些名称节点分别进行各自命名空间和块的管理，相互之间是联盟（Federation）关系，不需要彼此协调；向后兼容性（基于单名称开发的程序可以直接迁移到Federation体系中）；HDFS Federation中，所有名称节点会共享底层的数据节点存储资源，数据节点向所有名称节点汇报；属于同一个命名空间的块构成一个“块池”（逻辑概念，物理上仍然是数据节点的储存）。
HDFS Federation的访问方式
对于Federation中的多个命名空间，可以采用客户端挂载表（Client Side Mount Table）方式进行数据共享和访问；客户可以访问不同的挂载点来访问不同的子命名空间；把各个命名空间挂载到全局“挂载表” （mount-table）中，实现数据全局共享；同样的命名空间挂载到个人的挂载表中， 就成为应用程序可见的命名空间。
HDFS Federation相对于HDFS1.0的优势
HDFS Federation设计可解决单名称节点存在的以下几个问题：
（1）HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件 存储数目；
（2）性能更高效。多个名称节点管理不同的数据，且同时对外提供服务， 将为用户提供更高的读写吞吐率；
（3）良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点 管理，这样不同业务之间影响很小。
需要注意的，HDFS Federation并不能解决单点故障问题，也就是说，每个名称节点都存在在单点故障问题，需要为每个名称节点部署一个后备
最低0.47元/天 解锁文章
扫一扫
668
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
