Hadoop 的体系结构

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/a909301740/article/details/84201819

一、HDFS 的体系结构

1. NameNode

职责：

1. 管理维护 HDFS

2. 接收客户端的请求：上传、下载、创建目录等等。

3. 维护操作日志 edits 文件。

4. 维护 HDFS 元信息 fsimage 文件。

HDFS 操作日志：edits 文件

1. 文件位置：find . -name edits*

2. 最新的操作日志：edits_inprogress*****

3. 文件内容为二进制。

4. HDFS提供一个工具：edits viewer 日志查看器来把 edits 文件转换成 xml 文件。

   hdfs dfs -mkdir /mydemo
   hdfs oev -i edits_inprogress_0000000000000000106 -o ~/log.xml
   

HDFS 的元信息：fsimage 文件

1. 文件位置：跟 edits 文件在一起。

2. 记录数据块的位置、冗余信息。

3. 文件的内容为二进制。

4. HDFS 提供一个 image viewer 元信息查看器可以把 fsimage 文件转换成 文本文件或 xml 文件。

   # 转换成xml文件
   hdfs oiv -i fsimage_0000000000000000005 -o ~/image.xml -p XML
   # 转换成文本文件
   hdfs oiv -i fsimage_0000000000000000005 -o ~/image.txt
   

edits 文件和 fsimage 文件，哪个文件体现了 HDFS 最新的状态？

2. DataNode

职责：保存数据块，实现水平复制。

1. 数据块的大小：1.x 64M，2.x 128M

2. 数据块文件所在的位置：find . -name blk*

3. Demo：上传一个大于 128 M 的文件

   hdfs dfs -put hadoop-2.7.3.tar.gz /tools
   查看数据块文件。

4. 一般原则：数据块的冗余度一般跟数据节点个数一致，最大不要超过 3 ，在生产环境至少两个数据节点。

3. SecondaryNameNode

职责：把 edits 文件中最新的状态合并到 fsimage 文件中。

合并过程：

1. 先把 edits 日志和 fsimage 元信息文件下载到 SecondaryNameNode 上。

2. 对它们进行合并。

3. 将合并后的文件上传回 NameNode 上。

4. 循环往复…

面试题1：NameNode 和 SecondaryNameNode 有什么关系？

NameNode 负责维护 edits 日志文件和 fsimage 文件。
SecondaryNameNode 负责将 edits 中最新的状态合并到 fsimage 文件中。

面试题2：为什么 NameNode 和 SecondaryNameNode 会放在一起？

提高 SecondaryNameNode 合并 edits 文件和 fsimage 文件的效率。
SecondaryNameNode 合并的时候需要从 NameNode 上把 edits 文件和 fsimage 文件下载下来，放在一起可以避免网络传输带来的性能影响。

面试题3：什么时候会发生合并？

当 HDFS 发出检查点的时候。
默认：（1）每隔60分钟
（2）当edits文件达到64M

tips1：edits_inprogress 文件记录的是在合并过程中产生的新的日志文件。

tips2：SecondaryNameNode 也有 web 管理界面：http://192.168.220.111:50090

tips3：NameNode 的 web 管理界面：http://192.168.220.111:50070

tips4：Yarn 的 web 管理界面：http://192.168.220.111:8088

补充：Oracle数据库中也有检查点，如果发生检查点，会以最高优先级唤醒数据库写进程（DBWn）把内存中的脏数据写到数据文件上（持久化）。

二、Yarn 的体系结构

1. Yarn 调度 MR 任务的过程

1. 客户端执行 hadoop jar ****命令来请求执行某个 MR 任务。

2. 由JobClient.java 请求连接 ResourceManager。

3. ResourceManager 创建任务 ID。

4. JobClient.java 得到任务 ID 后，将任务保存到 HDFS 上。

5. JobClient.java 获取元信息（数据的元信息，任务的元信息）。

6. JobClient.java 将任务 ID，数据的元信息，任务的元信息提交给 Yarn。

7. ResourceManager 初始化任务（谁来执行，需要多少资源）。

8. ResourceManager 将通过心跳检测，将任务 ID，数据的元信息，任务的元信息分配给最不忙的 NodeManager 来执行。

9. NodeManager 根据得到的元信息访问 HDFS 获取数据和任务，并执行。

10. NodeManager 将结果写回 HDFS。

像不像去医院派对挂号？看来技术真的是源于生活。

2. Yarn 资源分配的方式（三种）

1. FIFO Scheduler：先来先得。

   缺点：没有考虑任务的优先级。

2. Capacity Scheduler：容器管理（默认）。
   

3. Fair Scheduler：公平调度（注意：安装配置 Hive on Spark，需要配置 Yarn 为 Fair Scheduler，否则 Hive 启动不了）。

   公平调度的前提条件：假设每个任务具有相同的优先级，平均分配系统资源。

   

   如果任务的优先级不同呢？

   需要指定每个任务的权重来为不同的任务分配不同比例的系统资源。

   比如任务 1 的权重为2，任务 2 的权重为 5，任务 3 的权重为 3。那么在分配系统资源的时候，任务 1 就可以得到 2 / 10 的资源，任务 2 就可以得到 5 / 10 的资源，任务 3 就可以得到 3 / 10 的资源。这样既兼顾了公平又考虑到了不同任务的优先级。

   如果不指定任务的权重的话，则每个任务平均分配系统资源。

3. ResourceManager 的职责

1. 接收客户端请求。

2. 分配资源和任务。

4. NodeManager 的职责

1. 根据 ResourceManager 分配的任务 ID 以及数据和任务的元信息到 HDFS 上获取数据和任务并执行。

三、HBase 的体系结构

简介：

1. HBase 是基于 HDFS 之上的一个 NoSQL数据库。

2. 基于 Key-Value 的数据库（类似的还有 Redis）。

3. 列式数据库。

HBase 由两部分组成：

1. HMaster：管理员，相当于 HDFS 中的 NameNode，Yarn 中的 ResourceManager。

2. RegionServer：存储数据，相当于 HDFS 中的 DataNode。

3. Region：位于 RegionServer 中，存储列族，关于列族的信息见 Google思想三（BigTable）。

   

   注意：我们的客户端不能直接操作 HBase，必须通过 zookeeper。

   zookeeper 相当于一个“数据库”，记录了 HMaster 的位置信息。

   和 Hadoop 一样，如果要搭建一个 HBase 的全分布式环境，至少需要 3 台服务器。

四、主从结构的单点故障和解决方案

什么是单点故障？

单点：主节点。

只有一个主节点时，宕机将导致集群无法使用。

解决方案

1. Hadoop1.x：没有解决方案。

2. Hadoop2.x：HA（High Available 高可用），思想：有多个主节点。

   默认使用 active 节点，当 active 宕机后，进行 Fail Over（失败迁移），使用 standby。

   同一时刻，只有一个主节点可用，当一个节点挂了之后，会迁移到另外一个节点上去。

   上面所有的组件都需要借助 Zookeeper 才能实现 HA。