分布式文件系统 HDFS 技术原理概述——《大数据技术原理与应用》课程学习总结

分布式文件系统

相对于传统的本地文件系统，分布式文件系统（Distributed File System）是一种通过网络实现文件在多台主机上记性分布式存储的文件系统。分布式文件系统的设计一般采用 “客户端/服务器” 模式。

目前，应用广泛的分布式文件系统主要包括 GFS 和 HDFS，后者是前者的开源实现。

3.1.1 计算机集群结构

普通的文件系统只需要单个计算机节点就可以完成文件的存储和处理，单个计算机节点由处理器、内存、高速缓存和本地磁盘构成。

分布式文件系统把文件分布存储到多个计算机节点上，成千上万的计算机节点构成 计算机集群。目前的分布式文件系统所采用的的计算机集群都是由普通硬件构成的，大大降低了硬件上的开销。

计算机洁群的基本架构如图所示：

3.1.2 分布式文件系统的结构

在我们熟悉的 Windows、Linux 等操作系统中，文件系统一般会把磁盘空间划分为每 512 字节位一组，称为“磁盘块”，它是文件系统读写操作的最小单元，文件系统的块（Block）通常是磁盘块的整数倍，即每次读写的数据量必须是磁盘块大小的整数倍。

分布式文件系统也采用了块的概念，文件被分成若干个块进行存储，块是数据读写的基本单元。HDFS 默认的一个块的大小是 64 MB。在分布式文件系统中，如果一个文件小于一个数据块的大小，它并不占用整个数据块的存储空间。

分布式文件系统在物理结构上是由计算机集群中的多个节点构成的。这写节点分为两类：一类叫 “主节点”（Master Node），或者也被称为 “名称节点（NameNode）”；另外一类叫 “从节点（Slave Node）”，或者也被称为 “数据结点（DataNode）”。

名称节点：负责文件和目录的创建、删除和重命名等，同时管理着整个数据节点和文件块的映射关系，因此客户端只有访问名称节点才能找到请求的文件块所在的位置，进而到相应位置读取所需文件块

数据节点：负责数据的存储和读取，在存储时，由名称节点分配存储位置，然后由客户端把数据直接写入相应数据节点；在读取时，客户端从名称节点获取数据节点和文件块的映射关系，然后就可以找到相应位置访问文件块。数据节点也要根据名称节点的命令创建、删除数据块和冗余复制。

计算机集群中的节点可能发生故障，因此未来保证数据的完整性，分布式文件系统通常采用 多副本存储。文件块会被复制为多个副本，存储在不同的节点上，而且存储同一文件块的不同副本的各个节点会分布在不同的机架上。

3.1.3 分布式文件系统的设计需求

分布式文件系统的设计需求：

设计需求	含义	HDFS 的实现情况
透明性	具备访问透明性、位置透明性、性能和伸缩透明性	只提供一定程度的访问透明性，完全支持位置透明性、性能和伸缩透明性
并发控制	客户端对于文件的读写不应该影响其他客户端对统一个文件的读写	机制非常简单，任何时间都只允许有一个程序写入某个文件
文件复制	一个文件可以拥有在不同位置的多个副本	HDFS 采用了多副本机制
硬件和操作系统的异构性	可以在不同的操作系统和计算机上实现同样得客户端和服务端程序	采用 Java 语言开发，具有很好的跨平台能力
可伸缩性	支持节点的动态加入或退出	建立规模廉价机器上的分布式文件系统集群，具有很好的可伸缩性
容错	保证文件服务在客户端或者服务端出现问题的时候能正常使用	具有多副本机制和故障自动检测、回复机制
安全	故障系统的安全性	安全性较弱

访问透明性 是指用户不需要专门区分哪些是本地文件，哪些是远程文件，用户通过相同的操作来访问本地文件和远程文件资源。 位置透明性是指在不改变路径名的前提下，不管文件副本数量和实际存储位置发生何种变化，对用而言都是透明的，用户不会感受到这种变化。
性能和伸缩透明性是指系统中结点的增加和减少以及性能的变化对用户而言是透明的，用户感受不到什么时候一个结点加入或退出了。

3.2 HDFS 简介

HDFS 要实现一下目标：

• 兼容廉价的硬件设备。实现在硬件出错的情况下也能实现数据的完整性
• 流数据读写。
• 大数据集。HDFS 中的文件通常可以达到 GB 甚至是 TB 级别，一个数百台机器组成的集群里面可以支持千万级别这样的文件。
• 简单的文件模型。“一次写入、多次读取”
• 强大的跨平台兼容性。

HDFS 局限性：

• 不适合低延迟数据访问。HDFS 爱用流式数据读取，具有很高的数据吞吐量，有较高的延迟，不适合在需要较低延迟的应用场合。
• 无法高效存储大量小文件。小文件是指文件大小小于一个块的文件，HDFS 无法高效存储和处理大量小文件，过多小文件会给系统扩展性和性能带来诸多问题。
• 不支持多用户写入及任意修改文件。HDFS 只允许一个文件有一个写入者，不允许多个用户对同一文件执行写操作，而且只允许对文件执行追加操作，不能执行随机写操作。

3.3 HDFS 的相关概念

3.3.1 块

HDFS 在块的大小的设计上明显大于普通文件系统。HDFS 这样做的原因，是为了 最小化寻址开销。HDFS 寻址开销不仅包括磁盘寻道开销，还包括数据块的定位开销。块的大小也不宜设置过大，因为，通常 MapReduce 中的 Map 任务一次只处理一个块的数据，如果启动的任务太少，就会降低作业并行处理速度。

HDFS 采用抽象的块概念有如下好处：

• 支持大规模文件存储。一个文件的大小不会受到的单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量。
• 简化系统设计。首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；其次，方便元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据。
• 适合数据备份。

3.3.2 名称节点和数据节点

在 HDFS 中，名称节点（NameNode）负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即 FsImage 和 EditLog。

FsImage 用于维护文件系统树以及文件树中所有的文件和文件夹的元数据，操作日志文件 EditLog 中记录了所有针对文件的创建、删除、重命名等操作。

名称节点记录了每个文件中各个所在的数据节点的位置信息，但是并不持久化存储这些信息，而是在系统每次启动时扫描所有数据节点重构得到这些信息。

数据节点（DataNode）是分布式文件系统 HDFS 的工作节点，负责数据的存储和读取，会根据客户端或者名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表。每个数据节点中的数据会被保存在各自节点的本地 Linux 文件系统中。

3.3.3 第二名称节点

EditLog 逐渐变大，当名称节点重启时，会导致名称节点在启动过程中长期处于“安全模式”，无法正常对外提供写操作，影响用户的使用。

为了解决 EditLog 逐渐变大带来的问题，HDFS 在设计中采用了 第二名称节点（Secondary NameNode）。第二名称节点有两个方面的功能：首先，可以完成 EditLog 与 FsImage 的合并操作，减小 EditLog 文件的大小，缩短名称节点启动时间；其次，可以作为名称节点的“检查点”，保存名称节点中的元数据信息。

3.4 HDFS 体系结构

3.4.1 概述

HDFS 采用了主从（Master/Slave）结构模型，一个 HDFS 集群包括一个名称节点和若干个数据节点。

每个数据节点会周期性地向名称节点发送“心跳”信息，报告自己的状态，没有按时发送心跳信息的数据节点会被标记为“宕机”，不会再给它分配任何 I/O 请求。

3.4.2 HDFS 命名空间管理

HDFS 的命名空间包括 目录、文件 和 块。

命名空间管理 是指命名空间支持对 HDFS 中的目录、文件和块做类似文件系统的创建、修改、删除等操作。

在当前的 HDFS 体系结构中，在整个 HDFS 集群中只有一个命名空间，并且只有唯一一个名称节点，改节点负责对这个命名空间进行管理。

HDFS 使用的是传统的分级问价体系，因此用户可以像使用普通文件系统一样，创建、删除目录和文件，在目录间转移文件、重命名文件等。但是， HDFS 还没有实现磁盘配额和文件的权限等功能，也不支持文件的硬连接和软连接。

3.4.3 通信协议

所有的 HDFS 通信协议都是构建在 TCP/IP 协议基础之上的。

• 客户端通过一个可配置的端口向名称节点主动发起 TCP 连接，并使用客户端协议与名称节点进行交互。
• 名称节点和数据节点之间则使用数据节点协议进行交互
• 客户端与数据节点的交互式通过 RPC（Remote Procedure Call）来实现的。

3.4.4 客户端

客户端并不算是 HDFS 的一部分。

3.4.5 HDFS 体系结构的局限性

HDFS 只设置唯一一个名称节点，这样做虽然大大简化了系统设计，但也带来了一些明显的局限性：

1. 命名空间的限制。名称节点是保存在内存中的，因此名称节点能够容纳对象的个数会受到内存空间大小的限制。
2. 性能的瓶颈。整个分布式文件系统的吞吐量受限于单个名称节点的吞吐量。
3. 隔离问题。由于集群中只有一个名称节点，只有一个命名空间，因此无法对不同应用程序进行隔离。
4. 集群的可用性。一旦这个唯一的名称节点发生故障，会导致整个集群变得不可用。

3.5 HDFS 的存储原理

3.5.1 数据的冗余存储

为了保证系统的容错性和可用性，HDFS 采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上。

这种多副本方式具有以下 3 个优点：

1. 加快数据传输速度。当多个客户端需要同时访问同一个问价时，可以让各个客户端分别从不同的数据块副本中读取数据，这就大大加快了数据传输速度。
2. 容易检查数据错误。HDFS 的数据节点之间通过网络传输数据，采用多个副本可以很容易判断数据传输是否出错。
3. 保证数据的可靠性。即使某个数据节点出现故障失效，也不会造成数据丢失。

3.5.2 数据存取策略

数据存取策略包括 数据存放、数据读取 和 数据复制等方面。

1. 数据存放

HDFS 采用了以机架（Rack）为基础的数据存放策略。一个 HDFS 集群通常包含多个机架，不同机架之间的数据通信需要经过交换机或路由器，同一机架的不同机器之间数据通信不需要交换机或路由器，因此同一机架中不同机器之间的通信要比不同机架之间机器的通信带宽大。

HDFS 默认每个数据节点都是在不同机架上的，这样有一个缺点：++写入数据的时候不能充分利用同一机架内部机器之间的带宽++。这种方法同时也带来了更多显著的优点：

1. 可以获得很高的数据可靠性，即使一个机器发生故障，位于其他机架上的数据副本仍然可用。
2. 在读数据的时候，可以在多个机架上并行读取数据，大大提高了数据读取速度。
3. 可以更容易实现系统内部负载均衡和错误处理。

HDFS 默认的冗余复制因子是 3，每一个文件会被同时保存到 3 个地方，其中两份副本放在同一个机架的不同机器上面，第三个副本放在不同机架的机器上面。

HDFS 副本的存放策略是：

1. 如果是在集群内发起写操作请求，则把第一个副本放置在发起写操作请求的数据节点上，实现就近写入数据。如果是来自集群外部的写操作，则从集群内部挑选一台磁盘不太满、CPU不太忙的数据节点，作为第一个副本的存放地。
2. 第二个副本会被放置在与第一个副本不同的机架的数据节点上。
3. 第三个副本会被放置在与第一个副本相同的机架的其他结点上。
4. 如果还有更多的副本，则继续从集群中随机天泽数据节点进行存放。

2. 数据读取

HDFS 提供了一个 API 可以确定一个数据节点所属的机架的 ID，客户端可以调用 API 获取自己所属机架的 ID。

当客户端读取数据时，从名称节点获取数据块不同副本的存放位置的列表，列表中包含了副本所在的数据节点，可以调用 API 开确定客户端和这些数据节点所属的机架 ID。当发现某个数据块副本对应的机架 ID 和客户端对应的机架的 ID 相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据。

3. 数据复制

HDFS 的数据复制采用了 流水线复制 的策略，大大提高了数据复制过程的效率。

3.5.3 数据错误与恢复

1. 名称节点出错

Hadoop 采用两种机制来确保名称节点的安全：

1. 把名称节点上的元数据信息同步存储到其他文件系统中；
2. 运行一个第二名称节点，当名称节点宕机以后，利用第二名称节点中的元数据信息进行系统恢复。

但是用第二种方法恢复数据，仍然会丢失部分数据。 因此，一般会吧上述两种方法结合使用，当名称节点宕机时，首先到远程挂载的网络文件系统中获取备份的元数据信息，放到第二名称节点上进行恢复，并把第二名称节点作为名称节点来使用。

2. 数据节点出错

每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态。当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自这些节点的“心跳”信息，这时这些节点就会被标记为“宕机”，节点上面的数据都会被标记为“不可读”，名称节点不会再给它们发送任何 I/O 请求。

当名称节点检查发现，某个数据的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本。

3. 数据出错

网络传输和磁盘错误等因素都会造成数据错误。客户端在读取到数据后，会采用 md5 和 sha1 对数据块进行校验，以确定读取到正确的数据。

客户端在对读取的数据块进行校验的时候，如果校验出错，客户端会请求到另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有错误，名称节点会定期检查并且重新复制这个块。

3.6 HDFS 的数据读写过程

关于 HDFS 的数据读写过程，有详细的视频讲解

3.6.1 读数据的过程

在读取数据的过程中，如果客户端与数据节点通信时出现错误，就会尝试连接包含此数据块的下一个数据节点。

3.6.2 写数据的过程

在没有任何异常的情况下，客户端连续调用 create()、write()和close()时，HDFS 内部的执行过程：