文章目录
总述
▍HADOOP.html" title=Hadoop>Hadoop1.0的局限与不足
- 抽象层次低，需要人工编写大量代码
- 表达能力有限
- 开发者自己管理作业（Job）之间的依赖关系
- 难以看到程序的整体逻辑
- 延迟高，因此迭代效率低
- 浪费资源（分为Map和Reduce两阶段）
- 实时性差 （适合批处理，不支持实时交互）
这里的HADOOP.html" title=Hadoop>Hadoop1.0仅指HDFS和MapReduce两个核心组件，不包括生态内的Pig、Hive、HBase等组件
▍HADOOP.html" title=Hadoop>Hadoop1.0的改进思路
- HADOOP.html" title=Hadoop>Hadoop自身核心组件之一的HDFS的架构设计改进
- HADOOP.html" title=Hadoop>Hadoop自身核心组件之一的MapReduce的架构设计改进
- HADOOP.html" title=Hadoop>Hadoop生态其他组件的丰富（Pig、Tez、Spark、Kafka等）
▍HADOOP.html" title=Hadoop>Hadoop1.0的针对性改进
| 组件 | HADOOP.html" title=Hadoop>Hadoop1.0的问题 | HADOOP.html" title=Hadoop>Hadoop2.0的改进 |
|---|---|---|
| HDFS | 单一名称节点，存在单点失效问题 | HDFA HA，提供名称节点热备份机制 |
| HDFS | 单一命名空间，无法实现资源隔离 | HDFA Federation，管理多个命名空间 |
| MapReduce | 资源管理效率低 | 新型资源管理框架YARN |
▍HADOOP.html" title=Hadoop>Hadoop1.0的生态完善
| 组件 | 功能 | 针对的问题 |
|---|---|---|
| Pig | 处理大规模数据的脚本语言，用户只需要编写几条简单的语句，系统会自动将其转换为MapReduce作业 | 抽象层次低，需要人工编写大量代码 |
| Spark | 基于内存的分布式比并行编程框架，具有较高的实时性，切较好支持迭代计算 | 延迟高，因此不适合迭代计算 |
| Oozie | 工作流引擎，协调HADOOP.html" title=Hadoop>Hadoop上的不同任务 | 没有提供作业（Job）之间依赖关系管理机制 |
| Tez | 支持DAG作业的计算框架，对作业的操作进行分解和重新组合，形成一个大的DAG作业，从而减少不必要操作 | 不同的MapReduce任务之间存在重复操作，降低了效率 |
| Kafka | 分布式发布订阅消息系统，不同的分布式系统可统一接入到Kafka，实现和HADOOP.html" title=Hadoop>Hadoop各组件之间不同数据的实时高效交换 | HADOOP.html" title=Hadoop>Hadoop生态中各组件和其他产品之间缺乏统一的、高效的数据交换中介 |
HDFS_HA_49">HDFS HA
▍名称节点与数据节点（复习）
| 名称节点 NameNode | 数据节点 DataNode |
|---|---|
| 维护文件→块→数据节点的映射 | 维护块id到本地文件的映射 |
| 存储元数据 | 存储文件内容 |
| 元数据位于内存 | 文件内容位于磁盘 |
▍第二名称节点（SecondaryNameNode）
N a m e N o d e = F s I m a g e + E d i t L o g NameNode = FsImage + EditLog NameNode=FsImage+EditLog
EditLog的作用是日志备份，它通常可以达到GB级，并且会不断膨胀。为了解决名称节点运行期间EditLog不断膨胀的问题，采用了SecondaryNameNode——第二名称节点
但是，SecondaryNameNode无法解决单点故障
- HDFA HA（High Availability）就是为了解决单点故障问题
- HA集群有两个名称节点：活跃（Active）和待命 （Standby）
- 两个名称节点状态同步——这通过一个共享存储系统来实现
- 一旦活跃名称节点出现故障，待命名称节点立即补上
- 如何确保某个时刻只有一个NameNode在对外服务？通过ZooKeeper实现
- DataNode需要同时向两个NameNode汇报信息
HDFS_Federation_83">HDFS Federation
▍HDFS 1.0存在的问题
- 「扩展性」不可以水平扩展
- 「系统性能」系统整体性能受限于单个NameNode的吞吐量
- 「隔离性」单个名称节点难以提供不同程序之间的隔离型
▍HDFS Federation的设计
- 设计了多个相互独立的NameNode，使得HDFS的命名服务能够水平扩展
- 这些NameNode各自管理自己的命名空间和块
- 它们是联盟 （Federation）关系，不需要彼此协调
- 所有NameNode共享底层的DataNode存储的资源，DataNode需要向所有的NameNode汇报
- 属于同一个命名空间的块构成一个「块池 」
▍HDFS Federation的设计（图解）
▍HDFS Federation的访问模式
对于Federation联盟中的多个命名空间，采用客户端挂载表（Client Side Mount Table）的方式——用户可以通过访问不同的挂载点来访问不同的子命名空间
▍HDFS Federation的优点
- 「扩展性」NameNode的数量不再局限于一个，从而一个集群可以扩展到更多的节点
- 「系统性能」多个NameNode同时对外提供服务，不再受限于一个NameNode的吞吐量
- 「隔离性」用户可以根据不同的业务，交由不同的命名空间，隔离性非常好
值得注意的是，HDFS Federation并没有解决单点故障的问题——单点故障是由HDFS HA负责解决的。
也就是说，虽然有了多个NameNode，但每一个NameNode仍存在单点故障问题——因此，我们要为每一个NameNode部署一个后备NameNode >_<!
− − E N D − − --END-- −−END−−
