2.1.3 hadoop体系之离线计算-hdfs分布式文件系统-副本机制+node工作机制+HDFS文件读写过程

水深无声 2022-12-04 08:53 139阅读 0赞

**目录**

1.HDFS 文件副本和 Block 块存储

1.1 引入块机制的好处

1.2 块缓存

1.3 HDFS 文件权限验证

1.4 副本放置策略

2.HDFS 的元信息和 SecondaryNameNode

2.1 FsImage 和 Edits 详解

2.2 fsimage 中的文件信息查看

2.3 edits 中的文件信息查看

2.4 SecondaryNameNode 如何辅助管理 fsimage 与 edits 文件?

3.HDFS 文件写入过程

4.HDFS 文件读取过程

--------------------

# 1.HDFS 文件副本和 Block 块存储 #

所有的文件都是以 block 块的方式存放在 HDFS 文件系统当中, 在 Hadoop1 当中, 文件的 block 块默认大小是 64M, hadoop2 当中, 文件的 block 块大小默认是 128M, block 块的大小可以通过 hdfs-site.xml 当中的配置文件进行指定

<property>
        <name>dfs.block.size</name>
        <value>块大小 以字节为单位</value>
    </property>

## 1.1 引入块机制的好处 ##

1.  一个文件有可能大于集群中任意一个磁盘
2.  使用块抽象而不是文件可以简化存储子系统
3.  块非常适合用于数据备份进而提供数据容错能力和可用性

## 1.2 块缓存 ##

通常 DataNode 从磁盘中读取块, 但对于**访问频繁**的文件, 其对应的块可能被显式的**缓存在 DataNode 的内存**中, 以堆外块缓存的形式存在. 默认情况下，一个块仅缓存在一个 DataNode 的内存中，当然可以针对每个文件配置 DataNode 的数量. 作业调度器通过在缓存块的 DataNode 上运行任务, 可以利用块缓存的优势提高读操作的性能.

**例如：**

连接(join) 操作中使用的一个小的查询表就是块缓存的一个很好的候选

用户或应用通过在缓存池中增加一个 Cache Directive 来告诉 NameNode 需要缓存哪些文件及存多久. 缓存池(Cache Pool) 是一个拥有管理缓存权限和资源使用的管理性分组.

例如一个文件 130M, 会被切分成 2 个 block 块, 保存在两个 block 块里面, 实际占用磁盘 130M 空间, 而不是占用256M的磁盘空间

## 1.3 HDFS 文件权限验证 ##

HDFS 的**文件权限机制与 Linux 系统的文件权限机制类似**

r:read  w:write  x:execute

权限 `x` 对于文件表示忽略, 对于文件夹表示是否有权限访问其内容 如果 Linux 系统用户 zhangsan 使用 Hadoop 命令创建一个文件, 那么这个文件在 HDFS 当中的 Owner 就是 zhangsan **HDFS 文件权限的目的, 防止好人做错事, 而不是阻止坏人做坏事.** HDFS相信你告诉我你是谁, 你就是谁

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70][]

## 1.4 副本放置策略 ##

在hdfs-site.xml中可以修改副本数量。如果最后只有两台没有宕机，namenode也会将一个block复制，其中一台主机上有两个副本，也会保证3个副本的要求。

![20200930105818640.png][]

副本机制：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 1][]

机架感知：**第一个副本：**如果客户端和文件恰巧在集群中的一个节点上，第一个副本就放置在本节点上；如果是集群外提交，则随机挑选一台磁盘不太满、cpu不太忙的节点。**第二个副本：**放置在于第一个副本不同的机架的节点上。**第三个副本：**与第二个副本相同机架的不同节点（同机架不同服务器）。**更多副本：**随机节点。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 2][]

# 2.HDFS 的元信息和 SecondaryNameNode #

当 Hadoop 的集群当中, **只有一个 NameNode 的时候, 所有的元数据信息都保存在了 FsImage 与 Eidts 文件当中**, 这两个文件就记录了所有的数据的元数据信息, 元数据信息的保存目录配置在了 `hdfs-site.xml` 当中

<property>
      <name>dfs.namenode.name.dir</name>
      <value>file:///export/servers/hadoop-3.1.1/datas/namenode/namenodedatas</value>
    </property>
    <property>
      <name>dfs.namenode.edits.dir</name>
      <value>file:///export/servers/hadoop-3.1.1/datas/dfs/nn/edits</value>
    </property>

## 2.1 FsImage 和 Edits 详解 ##

*  `edits`
    
     *  `edits` 存放了客户端**最近一段时间的操作日志**
     *  客户端对 HDFS 进行写文件时会首先被记录在 `edits` 文件中
     *  `edits` 修改时元数据也会更新
     *  每次 HDFS 更新时 `edits` 先更新后客户端才会看到最新信息
 *  `fsimage`
    
     *  NameNode 中关于元数据的镜像, 一般称为检查点, **`fsimage` 存放了一份比较完整的元数据信息**
     *  因为 `fsimage` 是 NameNode 的完整的镜像, 如果每次都加载到内存生成树状拓扑结构，这是非常耗内存和CPU, 所以一般开始时对 NameNode 的操作都放在 edits 中
     *  `fsimage` 内容包含了 NameNode 管理下的所有 DataNode 文件及文件 block 及 block 所在的 DataNode 的元数据信息.
     *  **随着 `edits` 内容增大, 就需要在一定时间点和 `fsimage` 合并**

## 2.2 fsimage 中的文件信息查看 ##

[官方查看文档][Link 1]

使用命令 `hdfs oiv`

cd /export/servers/hadoop-3.1.1/datas/namenode/namenodedatas
    hdfs oiv -i fsimage_0000000000000000864 -p XML -o hello.xml

## 2.3 edits 中的文件信息查看 ##

[官方查看文档][Link 2]

使用命令 `hdfs oev`

cd /export/servers/hadoop-3.1.1/datas/dfs/nn/edits
    hdfs oev -i  edits_0000000000000000865-0000000000000000866 -o myedit.xml -p XML

## 2.4 SecondaryNameNode 如何辅助管理 fsimage 与 edits 文件? ##

*  **SecondaryNameNode 定期合并 fsimage 和 edits, 把 edits 控制在一个范围内，并不是一个namenode，只是减轻了namenode的压力**
 *  配置 SecondaryNameNode
    
     *  SecondaryNameNode 在 `conf/masters` 中指定
     *  在 masters 指定的机器上, 修改 `hdfs-site.xml`
     *      <property>
              <name>dfs.http.address</name>
              <value>host:50070</value>
            </property>
        
         
     *  修改 `core-site.xml`, 这一步不做配置保持默认也可以
     *      
            <property>
              <name>fs.checkpoint.period</name>
              <value>3600</value>
            </property>
            
            <property>
              <name>fs.checkpoint.size</name>
              <value>67108864</value>
            </property>
 *  SecondaryNameNode 通知 NameNode 切换 editlog
 *  SecondaryNameNode 从 NameNode 中获得 fsimage 和 editlog(通过http方式)
 *  SecondaryNameNode 将 fsimage 载入内存, 然后开始合并 editlog, 合并之后成为新的 fsimage
 *  SecondaryNameNode 将新的 fsimage 发回给 NameNode
 *  NameNode 用新的 fsimage 替换旧的 fsimage

特点

*  完成合并的是 SecondaryNameNode, 会请求 NameNode 停止使用 edits, 暂时将新写操作放入一个新的文件中 `edits.new`
 *  SecondaryNameNode 从 NameNode 中通过 Http GET 获得 edits, 因为要和 fsimage 合并, 所以也是通过 Http Get 的方式把 fsimage 加载到内存, 然后逐一执行具体对文件系统的操作, 与 fsimage 合并, 生成新的 fsimage, 然后通过 Http POST 的方式把 fsimage 发送给 NameNode. NameNode 从 SecondaryNameNode 获得了 fsimage 后会把原有的 fsimage 替换为新的 fsimage, 把 edits.new 变成 edits. 同时会更新 fstime
 *  Hadoop 进入安全模式时需要管理员使用 dfsadmin 的 save namespace 来创建新的检查点
 *  SecondaryNameNode 在合并 edits 和 fsimage 时需要消耗的内存和 NameNode 差不多, 所以一般把 NameNode 和 SecondaryNameNode 放在不同的机器上

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 3][]

# 3.HDFS 文件写入过程 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 4][]

1.  Client 发起文件上传请求, 通过 RPC 与 NameNode 建立通讯, NameNode 检查目标文件是否已存在, 父目录是否存在, 返回是否可以上传
2.  Client 请求第一个 block 该传输到哪些 DataNode 服务器上
3.  NameNode 根据配置文件中指定的备份数量及机架感知原理进行文件分配, 返回可用的 DataNode 的地址如: A, B, C
4.  Hadoop 在设计时考虑到数据的安全与高效, 数据文件默认在 HDFS 上存放三份, 存储策略为本地一份, 同机架内其它某一节点上一份, 不同机架的某一节点上一份。
5.  Client 请求 3 台 DataNode 中的一台 A 上传数据（本质上是一个 RPC 调用，建立 pipeline ）, A 收到请求会继续调用 B, 然后 B 调用 C, 将整个 pipeline 建立完成, 后逐级返回 client
6.  Client 开始往 A 上传第一个 block（先从磁盘读取数据放到一个本地内存缓存）, 以 packet 为单位（默认64K）, A 收到一个 packet 就会传给 B, B 传给 C. A 每传一个 packet 会放入一个应答队列等待应答
7.  数据被分割成一个个 packet 数据包在 pipeline 上依次传输, 在 pipeline 反方向上, 逐个发送 ack（命令正确应答）, 最终由 pipeline 中第一个 DataNode 节点 A 将 pipelineack 发送给 Client
8.  当一个 block 传输完成之后, Client 再次请求 NameNode 上传第二个 block 到服务 1

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 5][]

# 4.HDFS 文件读取过程 #

1.  Client向NameNode发起RPC请求，来确定请求文件block所在的位置；
2.  NameNode会视情况返回文件的部分或者全部block列表，对于每个block，NameNode 都会返回含有该 block 副本的 DataNode 地址； 这些返回的 DN 地址，会按照集群拓扑结构得出 DataNode 与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离 Client 近的排靠前；心跳机制中超时汇报的 DN 状态为 STALE，这样的排靠后；
3.  Client 选取排序靠前的 DataNode 来读取 block，如果客户端本身就是DataNode,那么将从本地直接获取数据(短路读取特性)；
4.  底层上本质是建立 Socket Stream（FSDataInputStream），重复的调用父类 DataInputStream 的 read 方法，直到这个块上的数据读取完毕；
5.  当读完列表的 block 后，若文件读取还没有结束，客户端会继续向NameNode 获取下一批的 block 列表；
6.  读取完一个 block 都会进行 checksum 验证，如果读取 DataNode 时出现错误，客户端会通知 NameNode，然后再从下一个拥有该 block 副本的DataNode 继续读。
7.  read 方法是并行的读取 block 信息，不是一块一块的读取；NameNode 只是返回Client请求包含块的DataNode地址，并不是返回请求块的数据；
8.  最终读取来所有的 block 会合并成一个完整的最终文件。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 6][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70]: /images/20221123/af1dc18545424bbd934de3d6a66222d5.png
[20200930105818640.png]: /images/20221123/046e1bb07c814012b37cdb621ebf519b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 1]: /images/20221123/1c36a3dae7d941079da55ef00bb20d18.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 2]: /images/20221123/140e67d105d0437a8794a770f4c31e3a.png
[Link 1]: http://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-hdfs/HdfsImageViewer.html
[Link 2]: http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.14.0/hadoop-project-dist/hadoop-hdfs/HdfsEditsViewer.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 3]: /images/20221123/c6ed11aec6c340709ed2099c464eaefa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 4]: /images/20221123/f664a5aad36545fd952fe8982caf46af.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 5]: /images/20221123/b0756eae7d884ff488fa57ac9e795847.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1eWViaXViaXU_size_16_color_FFFFFF_t_70 6]: /images/20221123/8ea2cf9d9ee04e73b8039a97c854f79b.png