【大数据存储与管理】分布式文件系统HDFS：03 HDFS的相关概念
【作者主页】Francek Chen
【专栏介绍】 ⌈ ⌈ ⌈大数据技术原理与应用 ⌋ ⌋ ⌋专栏系统介绍大数据的相关知识，分为大数据基础篇、大数据存储与管理篇、大数据处理与分析篇、大数据应用篇。内容包含大数据概述、大数据处理架构Hadoop、分布式文件系统HDFS、分布式数据库HBase、NoSQL数据库、云数据库、MapReduce、Hadoop再探讨、数据仓库Hive、Spark、流计算、Flink、图计算、数据可视化，以及大数据在互联网领域、生物医学领域的应用和大数据的其他应用。
【GitCode】专栏资源保存在我的GitCode仓库：https://gitcode.com/Morse_Chen/BigData_principle_application。
文章目录
本文介绍 HDFS 中的相关概念，包括块、名称节点和数据节点、第二名称节点。
一、块
在传统的文件系统中，为了提高磁盘读写效率，一般以数据块为单位，而不是以字节为单位。比如机械式硬盘（磁盘的一种）包含了磁头和转动部件，在读取数据时有一个寻道的过程，通过转动盘片和移动磁头的位置，找到数据在机械式硬盘中的存储位置，才能进行读写。在 I/O 开销中，机械式硬盘的寻址时间是最耗时的部分，一旦找到第一条记录，剩下的顺序读取效率是非常高的。因此，以块为单位读写数据，可以把磁盘寻道时间分摊到大量数据中。
HDFS 也同样采用了块的概念，默认的一个块大小是 64 MB。在 HDFS 中的文件会被拆分成多个块，每个块作为独立的单元进行存储。我们所熟悉的普通文件系统的块一般只有几千字节，可以看出，HDFS 在块的大小的设计上明显要大于普通文件系统。HDFS 这么做，是为了最小化寻址开销。HDFS 寻址开销不仅包括磁盘寻道开销，还包括数据块的定位开销。当客户端需要访问一个文件时，首先从名称节点获得组成这个文件的数据块的位置列表，然后根据位置列表获取实际存储各个数据块的数据节点的位置，最后数据节点根据数据块信息在本地 Linux 文件系统中找到对应的文件，并把数据返回给客户端。设计一个比较大的块，可以把上述寻址开销分摊到较多的数据中，降低了单位数据的寻址开销。因此，HDFS 在文件块大小设置上要远远大于普通文件系统，以期在处理大规模文件时能够获得更好的性能。当然，块的大小也不宜设置过大，因为通常 MapReduce 中的 Map 任务一次只处理一个块中的数据，如果启动的任务太少，就会降低作业并行处理速度。
HDFS 采用抽象的块概念可以带来以下几个明显的好处。
- 支持大规模文件存储。文件以块为单位进行存储，一个大规模文件可以被拆分成若干个文件块，不同的文件块可以被分发到不同的节点上，因此一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量。
- 简化系统设计。首先，HDFS 采用块概念大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；其次，这方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据。
- 适合数据备份。每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性。
二、名称节点和数据节点
在 HDFS 中，名称节点负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构（见图1），即 FsImage 和 EditLog。FsImage 用于维护文件系统树以及文件树中所有的文件和文件夹的元数据，操作日志文件 EditLog 中记录了所有针对文件的创建、删除、重命名等操作。名称节点记录了每个文件中各个块所在的数据节点的位置信息，但是并不持久化地存储这些信息，而是在系统每次启动时扫描所有数据节点并重构，得到这些信息。
名称节点在启动时，会将 FsImage 的内容加载到内存当中，然后执行 EditLog 文件中的各项操作，使内存中的元数据保持最新。这个操作完成以后，就会创建一个新的 FsImage 文件和一个空的 EditLog 文件。名称节点启动成功并进入正常运行状态以后，HDFS 中的更新操作都会被写入 EditLog，而不是直接被写入 FsImage。这是因为对于分布式文件系统而言，FsImage 文件通常都很庞大（一般都是 GB 级别以上），如果所有的更新操作都直接在 FsImage 文件中进行，那么系统的运行速度会变得非常缓慢。相对而言，EditLog 通常都要远远小于 FsImage，更新操作写入EditLog 是非常高效的。名称节点在启动的过程中处于“安全模式”，只能对外提供读操作，无法提供写操作。启动过程结束后，系统就会退出安全模式，进入正常运行状态，对外提供读写操作。
图1 名称节点的数据结构
数据节点（DataNode）是分布式文件系统 HDFS 的工作节点，负责数据的存储和读取，会根据客户端或者名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表信息。每个数据节点中的数据会被保存在各自节点的本地 Linux 文件系统中。
三、第二名称节点
在名称节点运行期间，HDFS 会不断产生更新操作，这些更新操作直接被写入 EditLog 文件，因此 EditLog 文件也会逐渐变大。在名称节点运行期间，不断变大的 EditLog 文件通常对于系统性能不会产生显著影响，但是当名称节点重启时，需要将 FsImage 加载到内存中，然后逐条执行 EditLog 中的记录，使 FsImage 保持最新。可想而知，如果 EditLog 很大，就会导致整个过程变得非常缓慢，使名称节点在启动过程中长期处于“安全模式”，无法正常对外提供写操作，影响用户的使用。
为了有效解决 EditLog 逐渐变大带来的问题，HDFS 在设计中采用了第二名称节点（Secondary NameNode）。第二名称节点是 HDFS 架构的一个重要组成部分，具有两个方面的功能：首先，它可以完成 EditLog 与 FsImage 的合并操作，减小 EditLog 文件大小，缩短名称节点重启时间；其次，它可以作为名称节点的“检查点”，保存名称节点中的元数据信息。具体如下。
- EditLog 与 FsImage 的合并操作。每隔一段时间，第二名称节点会和名称节点通信，请求其停止使用 EditLog 文件（这里假设这个时刻为 t 1 t_1 t1），如图2所示，暂时将新到达的写操作添加到一个新的文件 EditLog.new 中。然后，第二名称节点把名称节点中的 FsImage 文件和 EditLog 文件拉回本地，再加载到内存中；对二者执行合并操作，即在内存中逐条执行 EditLog 中的操作，使 FsImage 保持最新。合并结束后，第二名称节点会把合并后得到的最新的 FsImage.ckpt 文件发送到名称节点。名称节点收到后，会用最新的 FsImage.ckpt 文件去替换旧的 FsImage 文件，同时用 EditLog.new 文件去替换 EditLog 文件（这里假设这个时刻为 t 2 t_2 t2），从而减小了 EditLog 文件的大小。
- 作为名称节点的“检查点”。从上面的合并过程可以看出，第二名称节点会定期和名称节点通信，从名称节点获取 FsImage 文件和 EditLog 文件，执行合并操作得到新的 FsImage.ckpt 文件。从这个角度来讲，第二名称节点相当于为名称节点设置了一个“检查点”，周期性地备份名称节点中的元数据信息，当名称节点发生故障时，就可以用第二名称节点中记录的元数据信息进行系统恢复。但是，在第二名称节点上合并操作得到的新的 FsImage 文件是合并操作发生时（即 t 1 t_1 t1 时刻）HDFS 记录的元数据信息，并没有包含 t 1 t_1 t1 时刻和 t 2 t_2 t2 时刻期间发生的更新操作。如果名称节点在 t 1 t_1 t1 时刻和 t 2 t_2 t2 时刻期间发生故障，系统就会丢失部分元数据信息，在 HDFS 的设计中，也并不支持把系统直接切换到第二名称节点。因此从这个角度来讲，第二名称节点只是起到了名称节点的“检查点”作用，并不能起到“热备份”作用。即使有了第二名称节点的存在，当名称节点发生故障时，系统还是有可能会丢失部分元数据信息的。
图2 第二名称节点工作过程示意
小结
HDFS 以块为单位存储文件，默认块大小 64MB，远大于普通文件系统，以最小化寻址开销，支持大规模文件存储，简化系统设计，方便数据备份。名称节点管理命名空间，保存 FsImage 和 EditLog。数据节点负责数据存储和读取。第二名称节点负责合并 EditLog 与 FsImage，减小文件大小，缩短名称节点重启时间，并作为名称节点的“检查点”备份元数据，但不能“热备份”，名称节点故障时系统仍可能丢失部分元数据。
欢迎 点赞👍 | 收藏⭐ | 评论✍ | 关注🤗
