喵喵爱编程

这个屌丝很懒，什么也没留下！

热门标签

HDFS学习笔记（三）：HDFS 分布式文件系统原理

作者：喵喵爱编程 | 2024-06-30 10:29:03

踩

分布式文件系统原理

文章目录

1、HDFS 概述
- 1.1、HDFS 特性
- 1.2、HDFS 架构图
2、HDFS 总体架构
3、HDFS 读写流程
4、NameNode 元数据管理
5、NameNode Web 介绍

1、HDFS 概述

HDFS 全称是 Hadoop Distribute File System，翻译过来就是 Hadoop 分布式文件系统。官网地址：https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html

1.1、HDFS 特性

支持大数据存储，非常适合 GB 到 TB的文件存储；
文件分块存储，HDFS 会将一个完整的大文件分块存储到不同的机器上，读取文件同时从多个主机取不同的区块的文件，提高了读取效率；
多副本存储，HDFS 认为所有计算机都可能会出问题，为了防止某个主机失效读取不到主机的块文件，HDFS 将一个块文件副本分配到其他某几个主机上，如果其中一台主机失效，可以迅速找到另一块副本取文件；
流式数据访问，一次写入多次读取，它不支持动态改变文件内容，改变也只能在文件末尾追加内容；
廉价硬件，HDFS 可以应用在普通 PC 机上，这种机制能够使用几十台廉价的计算机撑起一个大数据集群；

1.2、HDFS 架构图

HDFS 官网架构图：
架构图1
从官网的架构图我们可以看出 HDFS 具有主/从架构，HDFS 集群由单个 NameNode 和很多个 DataNode 组成，NameNode 是所有 HDFS 元数据的仲裁者和存储库，DataNode 负责处理来自文件系统客户端的读取、写入、块创建、快删除等操作。

2、HDFS 总体架构

HDFS 系统架构图：
架构原理图
HDFS 的一些关键元素：

Block：文件分块，默认 128MB（参数位于hdfs-default.xml中：dfs.blocksize。默认大小是128MB（134217728））
NameNode：是主节点，管理数据块映射、处理客户端读写请求、配置副本策略、管理 HDFS 命名空间。保存整个文件系统的目录信息、文件信息以及分块信息。
SecondaryNameNode：是 NameNode 的冷备份；合并 fsimage 和 fsedits 然后再发给 NameNode。（热备份：b 是 a 的热备份，如果 a 坏掉。那么 b 马上运行代替 a 的工作。冷备份：b 是 a 的冷备份，如果 a 坏掉。那么 b 不能马上代替 a 工作。但是 b 上存储 a 的一些信息，减少 a 坏掉之后的损失）
DataNode：数据节点。负责存储数据块 block，执行数据库的读写操作。
fsimage：元数据镜像文件（文件系统的目录树）
edits：元数据的操作日志（针对文件系统做的修改操作记录）

特别注意：

SecondaryNameNode它并不是NameNode的热备，在NameNode挂掉后不能立刻替换NameNode提供服务

3、HDFS 读写流程

因为namenode维护管理了文件系统的元数据信息，这就造成了不管是读还是写数据都是基于NameNode开始的，也就是说NameNode成为了HDFS访问的唯一入口。入口地址是：http://nn_host:8020。

3.1、写数据流程（write）

写数据

3.1.1、Pipeline 管道、ACK 应答相应

Pipeline，中文翻译为管道。这是 HDFS 在上传文件写数据过程中采用的一种数据传输方式。

客户端将数据块写入第一个数据节点
第一个数据节点保存数据之后再讲块复制到第二个数据节点
第二个数据节点保存后将其复制到第三个数据节点。

Pipeline 的过程就是：Clinet -> A -> B -> C

为什么 datanode 之间采用 pipeline 线性传输，而不是一次给三个 datanode 拓扑式传输呢？

因为数据以管道的方式，顺序的沿着一个方向传输，这样能够充分利用每台机器的带宽，避免网络瓶颈和高延迟时的连接，最小化推送所有数据的延时。在线性推送模式下，每台机器所有的出口宽带都用于以最快的速度传输数据，而不是在多个接受者之间分配带宽。

ACK（Acknowledge character）即时确认字符，在数据通信中，接收方发给发送方的一种传输类控制字符。表示发来的数据已确认接收无误。在 pipeline 管道传输数据的过程中，传输的反方向会进行 ACK 校验，确保数据传输安全。
ACK1

3.1.2、具体流程

HDFS Client 通过对 DistributedFileSystem 对象调用 create() 请求创建文件，DistributedFileSystem 对 NameNode 进行 RPC 调用，请求上传文件。NameNode 执行各种检查判断：目标文件是否存在、父目录是否存在、客户端是否具有创建该文件的权限。检查通过后，NameNode 就会为创建新文件记录一条记录。否则，文件创建失败并向客户端抛出 IOException。
DistributedFileSystem 为客户端返回 FSDataOutputStream 输出流对象。由此客户端开始写入数据。FSDataOutputStream 是一个包装类，所包装的是 DFSOutStream。
在客户端写入数据时，DFSOutputStream 将它分成一个个数据包（packet 默认 64kb），并写入一个称之为数据队列的内部队列。DFSOutputStream 有一个内部类做 DataStreamer，用于请求 NameNode 挑选适合存储数据副本的一组 DataNode。这一组 DataNode 采用 pipeline 机制做数据的发送。默认是 3 副本存储。
pipeline 传递数据给 DataNode，DataSteamer 将数据包流式传输到 pipeline 的第一个 datanode，该 DataNode 存储数据包并将它发送到 pipeline 的第二个DataNode。同样，第二个 DataNode 存储数据包并且发送给第三个（3副本的话是最后一个）DataNode。
DFSOutputStream 也维护着一个内部数据包队列来等待 DataNode 的手打确认回执，称之为确认队列（ack queue），收到 pipeline 中所有 DataNode 确认信息后，该数据包才会从确认队列删除。
客户端完成数据写入后，将在流上调用 close() 方法关闭。该操作将剩余的所有数据包写入到 DataNode pipeline，并在联系到 NameNode 告知其文件写入完成之前，等待确认。
因为 NameNode 已经知道文件由哪些块组成（DataStream 请求分配数据块），因此它仅需要等待最小复制快即可成功返回。
数据块最小赋值是由参数 dfs.namenode.replication.min 指定，默认是1。

3.1.3、默认3副本存储策略

默认副本存储策略是由 BlockPlacementPolicyDefault 指定。策略如下：
第一块副本：优先客户端本地，否则随机；
第二块副本：不同于第一块副本的不同机架；
第三块副本：第二块副本相同机架不同机器。

3.2、读数据流程（read）

客户端通过调用 DistributedFileSystem 对象上的 open() 来打开希望读取的文件
DistributedFileSystem 使用 RPC 调用 NameNode 来确定文件中前几个块的块位置。对于每个块，NameNode 返回具有该块副本的 DataNode 的地址，并且 DataNode 根据块与客户端的距离进行排序。注意此距离指的是网络拓扑中的距离。比如客户端的本身就是一个DataNode，那么从本地读取数据明显比跨网络读取数据效率要高。
DistributedFileSystem 将 FSDataInputStream（支持文件seek定位读的输入流）返回到客户端以供其读取数据。FSDataInputStream 类转而封装为 DFSInputStream 类，DFSInputStream管理着datanode和namenode之间的IO。
客户端在流上调用 read() 方法。然后，已存储着文件前几个块 DataNode 地址的 DFSInputStream 随即连接到文件中第一个块的最近的 DataNode 节点。通过对数据流反复调用 read() 方法，可以将数据从 DataNode 传输到客户端。
当该块快要读取结束时，DFSInputStream 将关闭与该 DataNode 的连接，然后寻找下一个块的最佳 DataNode 。这些操作对用户来说是透明的。所以用户感觉起来它一直在读取一个连续的流。
客户端从流中读取数据时，块是按照打开 DFSInputStream 与 DataNode 新建连接的顺序读取的。它也会根据需要询问 NameNode 来检索下一批数据块的 DataNode 位置信息。一旦客户端完成读取，就对FSDataInputStream调用close()方法。
如果 DFSInputStream 与 DataNode 通信时遇到错误，它将尝试该块的下一个最接近的 DataNode 读取数据。并将记住发生故障的 DataNode ，保证以后不会反复读取该 DataNode 后续的块。此外，DFSInputStream 也会通过校验和（checksum）确认从 DataNode 发来的数据是否完整。如果发现有损坏的块，DFSInputStream 会尝试从其他 DataNode 读取该块的副本，也会将被损坏的块报告给 NameNode 。

3.3、角色职责（role）

3.3.1、NameNode 职责

NameNode 是 HDFS 的核心，集群的主角色，被称为Master。
NameNode 仅存储管理 HDFS 的元数据，文件系统namespace操作维护目录树，文件和块的位置信息。
NameNode 不存储实际数据或数据集。数据本身实际存储在 DataNode 中。
NameNode 知道 HDFS 中任何给定文件的块列表及其位置。使用此信息 NameNode 知道如何从块中构建文件。
NameNode 并不持久化存储每个文件中各个块所在的 DataNode 的位置信息，这些信息会在系统启动时从 DataNode 汇报中重建。
NameNode 对于 HDFS 至关重要，当 NameNode 关闭时，HDFS / Hadoop集群无法访问。
NameNode 是 Hadoop 集群中的单点故障。
NameNode 所在机器通常会配置有大量内存（RAM）

3.3.2、DataNode 职责

DataNode 负责将实际数据存储在 HDFS 中。是集群的从角色，被称为 Slave。
DataNode 启动时，它将自己发布到 NameNode 并汇报自己负责持有的块列表。
根据 NameNode 的指令，执行块的创建、复制、删除操作。
DataNode 会定期（dfs.heartbeat.interval 配置项配置，默认是3秒）向 NameNode 发送心跳，如果 NameNode 长时间没有接受到 DataNode 发送的心跳， NameNode 就会认为该 DataNode 失效。
DataNode 会定期向 NameNode 进行自己持有的数据块信息汇报，汇报时间间隔取参数dfs.blockreport.intervalMsec，参数未配置的话默认为 6 小时。
DataNode 所在机器通常配置有大量的硬盘空间。因为实际数据存储在 DataNode中。

4、NameNode 元数据管理

4.1、元数据是什么

元数据（Metadata），又称为中介数据，为描述数据的数据（data about data），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。

在 HDFS 中元数据主要指的是文件相关的元数据，由 NameNode 管理维护。从冠以的角度来说，因为 NameNode 还需要管理众多 DataNode 节点，因此 DataNode 的位置和健康状态信息也属于元数据。

4.2、元数据管理概述

在 HDFS 中，文件相关元数据有两种类型：

文件自身属性信息
文件块位置映射信息

4.2.1、文件自身属性信息

包括：文件名称、权限、修改时间、文件大小、复制因子、数据块大小。
文件自身属性信息

4.2.2、文件块位置映射信息

记录文件块和 DataNode 之间的映射信息，即哪个快位于哪个节点上。按照存储形式分为：内存元数据和磁盘元数据。分别存在内存和磁盘上。
block位置信息

4.2.2.1、内存元数据

为了保证用户操作元数据交互高效，延迟低，NameNode 把所有的元数据都存储在内存中，我们叫做内存元数据。内存中的元数据是最完整的，包括文件自身属性信息、文件块位置映射信息。 但是内存的致命问题是，断点数据丢失，数据不会持久化。因此 NameNode 又辅佐了元数据文件来保证元数据的安全完整。

4.2.2.2、磁盘元数据

1） fsimage 内存镜像文件
是内存元数据的一个持久化的检查点。但是 fsimage 中仅包含 Hadoop 文件系统中文件自身属性相关的元数据信息，但不包含文件块位置的信息。文件块位置信息只存储在内存中，时由 DataNode 启动加入集群的时候，向 NameNode 进行数据块的汇报得到的，并且后续间断指定时间进行数据块报告。持久化的动作是一种数据从内存到磁盘的 IO 过程。会对 NameNode 正常服务造成一定的影响，不能频繁的进行持久化。

2） Edits log编辑日志
为了避免两次持久化之间数据丢失的问题，又设计了 Edits log 编辑日志文件。文件中记录的是HDFS所有更改操作（文件创建，删除或修改）的日志，文件系统客户端执行的更改操作首先会被记录到 edits 文件中。

3）加载元数据顺序
    fsimage 和 edits 文件都是经过序列化的，在 NameNode 启动的时候，它会将 fsimage 文件中的内容加载到内存中，之后再执行edits文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作，也是最完整的元数据。
    当客户端对 HDFS 中的文件进行新增或者修改操作，操作记录首先被记入 edits 日志文件中，当客户端操作成功后，相应的元数据会更新到内存元数据中。因为 fsimage 文件一般都很大（GB级别的很常见），如果所有的更新操作都往 fsimage 文件中添加，这样会导致系统运行的十分缓慢。
    HDFS 这种设计目的是实现：一是内存中数据更新、查询快，极大缩短了操作响应时间；二是内存中元数据丢失风险颇高（断电等），因此辅佐元数据镜像文件（fsimage）+ 编辑日志文件（edits）的备份机制进行确保元数据的安全。
    NameNode维护整个文件系统元数据。因此，元数据的准确管理，影响着 HDFS 提供文件存储服务的能力。

4.3、元数据管理相关目录文件

4.3.1、元数据存储目录

    在 HDFS 首次部署好配置文件之后，并不能马上启动使用，而是先要对文件系统进行格式化操作：hdfs namenode -format
    在这里要注意两个概念：一个是 format 之前，HDFS 在物理上还不存在；二就是此处的 format 并不是指传统意义上的本地磁盘格式化，而是一些清除与准备工作。其中就会创建元数据本地存储目录和一些初始化的元数据相关文件。
    NameNode 元数据存储目录由参数：dfs.namenode.name.dir 指定。
    格式化完成之后，将会在$dfs.namenode.name.dir/current目录下创建如下的文件：
current
其中的dfs.namenode.name.dir是在hdfs-site.xml文件中配置的，默认值如下：
current2
    dfs.namenode.name.dir 属性可以配置多个目录，各个目录存储的文件结构和内容都完全一样，相当于备份，这样做的好处是当其中一个目录损坏了，也不会影响到 Hadoop 的元数据，特别是当其中一个目录是 NFS（网络文件系统 Network File System，NFS）之上，即使你这台机器损坏了，元数据也得到保存。

4.3.2、元数据相关文件

Version
vesion-1
1）namespaceID/clusterID/blockpoolID
这些都是 HDFS 集群的唯一标识符。标识符被用来防止DataNode 意外注册到另一个集群中的 NameNode 上。这些标识在联邦（federation）部署中特别重要。联邦模式下，会有多个NameNode独立工作。每个的NameNode提供唯一的命名空间（namespaceID），并管理一组唯一的文件块池（blockpoolID）。clusterID将整个集群结合在一起作为单个逻辑单元，在集群中的所有节点上都是一样的。
2）storageType
说明这个文件存储的是什么进程的数据结构信息,如果是DataNode，storageType=DATA_NODE。
3）cTime
NameNode 存储系统创建时间，首次格式化文件系统这个属性是0，当文件系统升级之后，该值会更新到升级之后的时间戳；
4）layoutVersion
HDFS 元数据格式的版本。添加需要更改元数据格式的新功能时，请更改此数字。当前的 HDFS 软件使用比当前版本更新的布局版本时，需要进行 HDFS 升级。

4.4、SecondaryNameNode

4.4.1、SNN职责

snn职责
NameNode 职责是管理元数据信息， DataNode 的职责是负责数据具体存储，那么 SecondaryNameNode 的作用是什么？对很多初学者来说是非常迷惑的。它为什么会出现在 HDFS 中。从它的名字上看，它给人的感觉就像是 NameNode 的备份。但它实际上却不是。

当 HDFS集群运行一段事件后，就会出现下面一些问题： 
1）edits logs 会变的很大，fsimage 将会变得很旧； 
2）NameNode 重启会花费很长时间，因为有很多改动要合并到 fsimage 文件上
3）如果频繁进行 fsimage 持久化，又会影响 NameNode 正常服务，毕竟 IO 操作是一种内存到磁盘的耗精力操作
1
2
3
4

因此为了克服这个问题，需要一个易于管理的机制来帮助我们减小 edit logs 文件的大小和得到一个最新的 fsimage 文件，这样也会减小在 NameNode 上的压力。
SecondaryNameNode 就是来帮助解决上述问题的，它的职责是合并 NameNode的 edit logs 到 fsimage 文件中。

4.4.2、SNN checkpoint 机制

概述：Checkpoint 核心是把 fsimage 与 edits log 合并以生成新的 fsimage 的过程。此过程有两个好处：fsimage 版本不断更新不会太旧、edits log 文件不会太大。

当触发 checkpoint 操作条件时，SNN 发生请求给 NN 滚动edits log 。然后 NN 会生成一个新的编辑日志文件：edits new，便于记录后续操作记录。
同时 SNN 会将 edits 文件和 fsimage 复制到本地（使用 HTTP GET 方式）。
SNN 首先将 fsimage 载入到内存，然后一条一条地执行edits 文件中的操作，使得内存中的 fsimage 不断更新，这个过程就是 edits 和 fsimage 文件合并。合并结束，SNN 将内存中的数据 dump 生成一个新的 fsimage 文件。
SNN 将新生成的 Fsimage new 文件复制到 NN 节点。
至此刚好是一个轮回，等待下一次checkpoint触发SecondaryNameNode进行工作，一直这样循环操作。

触发机制
Checkpoint 触发条件受两个参数控制，可以通过 core-site.xml 进行配置

dfs.namenode.checkpoint.period=3600  //两次连续的checkpoint之间的时间间隔。默认1小时
dfs.namenode.checkpoint.txns=1000000 //最大没有执行checkpoint事务的数量，满足将强制执行紧急checkpoint，即使尚未达到检查点周期。默认100万事务数量。
1
2

从上面的描述我们可以看出，SecondaryNameNode 根本就不是 NameNode 的一个热备，只是将 fsimage 和 edits 合并。

4.5、NameNode 元数据恢复

4.5.1、NameNode 存储多目录

NameNode 元数据存储目录由参数： dfs.namenode.name.dir 指定。dfs.namenode.name.dir 属性可以配置多个目录，各个目录存储的文件结构和内容都完全一样，相当于备份。
这样做的好处是当其中一个目录损坏了，也不会影响到 Hadoop 的元数据，特别是当其中一个目录是 NFS（网络文件系统 Network File System，NFS）之上，即使你这台机器损坏了，元数据也得到保存。

4.5.2、SecondaryNameNode 中恢复

SecondaryNameNode在checkpoint的时候会将fsimage和edits log下载到自己的本机上本地存储目录下。并且在checkpoint之后也不会进行删除。
如果 NameNode 中的 fsimage 真的出问题了，还是可以用 SecondaryNameNode 中的 fsimage 替换一下 NameNode 上的 fsimage ，虽然已经不是最新的fsimage，但是我们可以将损失减小到最少！

5、NameNode Web 介绍

5.1、Web 地址

Hadoop 可以通过 HDFS 提供的 Web 用户界面操作，地址和端口通过以下配置，配置文件在 hdfs-site.xml。

        <!-- nn web 端访问地址-->
        <property>
                <name>dfs.namenode.http-address</name>
                <value>node1:9870</value>
        </property>
        <!-- 2nn web 端访问地址-->
        <property>
                <name>dfs.namenode.secondary.http-address</name>
                <value>node2:9868</value>
        </property>
1
2
3
4
5
6
7
8
9
10