HDFS入门看这篇就够了

作者: Feel_狗焕 | 来源:发表于2023-04-23 15:41 被阅读0次

目录：
1、简介及概念
1.1、文件系统的名字空间 (namespace)
1.2、namenode和datanode
1.3、HDFS数据组织方式和副本复制
1.4、文件系统元数据的持久化
1.5、块缓存
1.6、数据完整性
1.7、存储空间回收
2、HDFS功能特性
2.1、节点角色类型
2.2、联邦HDFS
2.3、HDFS的高可用性

1、简介及概念：

当需要存储的数据集的大小超过了一台独立的物理计算机的存储能力时，就需要对数据进行分区并存储到若干台计算机上去。管理网络中跨多台计算机存储的文件系统统称为分布式文件系统（distributed fileSystem）。
分布式文件系统 distributed file system 是指文件系统管理的物理存储资源不一定直接链接在本地节点上，而是通过计算机网络与节点相连，可让多机器上的多用户分享文件和存储空间。分布式文件系统的设计基于客户机/服务器模式

分布式文件系统由于其跨计算机的特性，所以依赖于网络的传输，势必会比普通的本地文件系统更加复杂，比如：如何使得文件系统能够容忍节点的故障并且保证不丢失数据，这就是一个很大的挑战。

HDFS（Hadoop Distributed File System）是hadoop生态系统的一个重要组成部分，是hadoop中的的存储组件，在整个Hadoop中的地位非同一般，是最基础的一部分，因为它涉及到数据存储，MapReduce等计算模型都要依赖于存储在HDFS中的数据。HDFS是一个分布式文件系统，以流式数据访问模式存储超大文件，将数据分块存储到一个商业硬件集群内的不同机器上，简单的就说将数据块分布在多台物理机上。

分布式文件系统的特点：
1、分布式文件系统可以有效解决数据的存储和管理难题;
2、将固定于某个地点的某个文件系统，扩展到任意多个地点/多个文件系统;
3、众多的节点组成一个文件系统网络;
4、每个节点可以分布在不同的地点，通过网络进行节点间的通信和数据传输;
5、在使用分布式文件系统时，无需关心数据是存储在哪个节点上、或者是从哪个节点获取的，只需要像使用本地文件系统一样管理和存储文件系统中的数据;

HDFS优势：
1、可构建在廉价机器上，设备成本相对低;
2、高容错性，HDFS将数据自动保存多个副本，副本丢失后，自动恢复，防止数据丢失或损坏;
3、适合批处理，HDFS适合一次写入、多次查询（读取）的情况，适合在已有的数据进行多次分析，稳定性好;
4、适合存储大文件，其中的大表示可以存储单个大文件，因为是分块存储，以及表示存储大量的数据;

HDFS劣势：
1、由于提高吞吐量，降低实时性；
2、由于每个文件都会在namenode中记录元数据，如果存储了大量的小文件，会对namenode造成很大的压力；不合适小文件处理，在mapreduce的过程中小文件的数量会造成map数量的增大，导致资源被占用，而且速度慢；
3、不适合文件的修改，文件只能追加在文件的末尾，不支持任意位置修改，不支持多个写入者操作；
4、不支持低时间延迟的数据访问。hdfs关心的是高数据吞吐量，不适合那些要求低时间延迟数据访问的应用；
5、单用户写入，不支持任意修改。hdfs的数据以读为主，只支持单个写入者，并且写操作总是以添加的形式在文末追加，不支持在任意位置进行修改；

架构：

hdfs-arth.png

1.1、文件系统的名字空间 (namespace)：

HDFS支持传统的层次型文件组织结构。用户或者应用程序可以创建目录，然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似：用户可以创建、删除、移动或重命名文件。HDFS支持用户磁盘配额和访问权限控制，不支持硬链接和软链接。但是HDFS架构并不妨碍实现这些特性。（老版本1.x是不支持磁盘配额和访问权限的）

hdfs中namespace的概念主要是一个逻辑上对文件的相关属性的管理以及文件的拆分数据块后的映射关系的一个统称；

整个文件系统名称空间（包括块到文件的映射和文件系统属性）存储在称为FsImage的文件中。 FsImage也作为文件存储在NameNode的本地文件系统中。

Namenode负责维护文件系统的namespace，任何对文件系统命名空间或属性的修改都将被Namenode记录下来。应用程序可以设置HDFS保存的文件的副本数目。文件副本的数目称为文件的副本系数，这个信息也是由Namenode保存的。

1.2、namenode和datanode：

HDFS集群的节点分为两类角色：namenode和datanode，以管理节点-工作节点的模式运行，即一个namenode和多个datanode，理解这两类节点对理解HDFS工作机制非常重要。

namenode：作为管理节点，它负责整个文件系统的命名空间，并且维护着文件系统树和整棵树内所有的文件和目录，这些信息以两个文件的形式（命名空间镜像文件和editlog事务日志文件）永久存储在namenode 的本地磁盘上。除此之外，同时，namenode也记录每个文件中各个块所在的数据节点信息，但是不永久存储块的位置信息，因为块的信息可以在系统启动时重新构建。
datanode：作为文件系统的工作节点负责处理客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。根据需要存储并检索数据块，定期向namenode发送他们所存储的块的列表。

hdfs-1.png

由此可见，namenode作为管理节点，它的地位是非同寻常的，一旦namenode宕机，那么所有文件都会丢失，因为namenode是唯一存储了元数据、文件与数据块之间对应关系的节点，所有文件信息都保存在这里，namenode毁坏后无法重建文件。因此，必须高度重视namenode的容错性。

为了使得namenode更加可靠，hadoop提供了两种机制：

第一种机制是备份那些组成文件系统元数据持久状态的文件(即保存namenode上的元数据文件)，比如：将文件系统的信息写入本地磁盘的同时，也写入一个远程挂载的网络文件系统（NFS），这些写操作实时同步并且保证原子性。
第二种机制是运行一个辅助namenode，用以保存命名空间镜像的副本，在namenode发生故障时启用。（也可以使用热备份namenode代替辅助namenode）。

hdfs-2.png

1)、NameNode的安全模式：

Namenode启动后会进入一个称为安全模式的特殊状态。处于安全模式的Namenode是不会进行数据块的复制的。Namenode从所有的 Datanode接收心跳信号和块状态报告。块状态报告包括了某个Datanode所有的数据块列表。每个数据块都有一个指定的最小副本数。当Namenode检测确认某个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全(safely replicated)的；在一定百分比（这个参数可配置）的数据块被Namenode检测确认是安全之后（加上一个额外的30秒等待时间），Namenode将退出安全模式状态。接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些数据块复制到其他Datanode上。

如果需要，你也可以通过'bin/hadoop dfsadmin -safemode'命令显式地将HDFS置于安全模式。NameNode首页会显示当前是否处于安全模式。

2)、通信方式：

所有的HDFS通讯协议都是建立在TCP/IP协议之上。客户端通过一个可配置的TCP端口连接到Namenode，通过ClientProtocol协议与Namenode交互。而Datanode使用DatanodeProtocol协议与Namenode交互。一个远程过程调用(RPC)模型被抽象出来封装ClientProtocol和Datanodeprotocol协议。在设计上，Namenode不会主动发起RPC，而是响应来自客户端或 Datanode 的RPC请求。

1.3、HDFS数据组织方式和副本复制：

每个磁盘都有默认的数据块大小默认是512kb，这是文件系统进行数据读写的最小单位。这涉及到磁盘的相应知识，这里我们不多讲。

HDFS同样也有数据块的概念，将文件存储成一系列的数据块，默认一个块（block）的大小为128MB（HDFS的块这么大主要是为了最小化寻址开销），要在HDFS中存储的文件可以划分为多个分块，每个分块可以成为一个独立的存储单元。与本地磁盘不同的是，HDFS中小于一个块大小的文件并不会占据整个HDFS数据块。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定，也可以在之后改变。

对HDFS存储进行分块有很多好处：

一个文件的大小可以大于网络中任意一个磁盘的容量，文件的块可以利用集群中的任意一个磁盘进行存储。
使用抽象的块，而不是整个文件作为存储单元，可以简化存储管理，使得文件的元数据可以单独管理。
冗余备份。数据块非常适合用于数据备份，进而可以提供数据容错能力和提高可用性。每个块可以有多个备份（默认为三个），分别保存到相互独立的机器上去，这样就可以保证单点故障不会导致数据丢失。

hdfsdatanodes.png

1)、Staging：

客户端创建文件的请求其实并没有立即发送给Namenode，事实上，在刚开始阶段HDFS客户端会先将文件数据缓存到本地的一个临时文件。应用程序的写操作被透明地重定向到这个临时文件。当这个临时文件累积的数据量超过一个数据块的大小，客户端才会联系Namenode。Namenode将文件名插入文件系统的层次结构中，并且分配一个数据块给它。然后返回Datanode的标识符和目标数据块给客户端。接着客户端将这块数据从本地临时文件上传到指定的Datanode上。当文件关闭时，在临时文件中剩余的没有上传的数据也会传输到指定的Datanode上。然后客户端告诉Namenode文件已经关闭。此时Namenode才将文件创建操作提交到editlog事务日志里进行存储。如果Namenode在文件关闭前宕机了，则该文件将丢失。

2)、流水线复制：

当客户端向HDFS文件写入数据的时候，一开始是写到本地临时文件中。假设该文件的副本系数设置为3，当本地临时文件累积到一个数据块的大小时，客户端会从Namenode获取一个Datanode列表用于存放副本。然后客户端开始向第一个Datanode传输数据，第一个Datanode一小部分一小部分(4 KB)地接收数据，将每一部分写入本地，并同时传输该部分到列表中第二个Datanode节点。第二个Datanode也是这样，一小部分一小部分地接收数据，写入本地，并同时传给第三个Datanode。最后，第三个Datanode接收数据并存储在本地。因此，Datanode能流水线式地从前一个节点接收数据，并在同时转发给下一个节点，数据以流水线的方式从前一个Datanode复制到下一个。

1.4、文件系统元数据的持久化：

Namenode上保存着HDFS的名字空间。对于任何对文件系统元数据产生修改的操作，Namenode都会使用一种称为EditLog的事务日志记录下来。例如，在HDFS中创建一个文件，Namenode就会在Editlog中插入一条记录来表示；同样地，修改文件的副本系数也将往Editlog插入一条记录。Namenode在本地操作系统的文件系统中存储这个Editlog。整个文件系统的命名空间，包括数据块到文件的映射、文件的属性等，都存储在一个称为FsImage的文件中，这个文件也是放在Namenode所在的本地文件系统上。

Namenode在内存中保存着整个文件系统的namespace和文件数据块映射(Blockmap)的image。这个关键的元数据结构设计得很紧凑，因而一个有4G内存的Namenode足够支撑大量的文件和目录。当Namenode启动时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的文件操作的事务重放在内存中的FsImage上生成新的FsImage，并将这个新版本的FsImage从内存中保存到本地磁盘上，然后删除旧的Editlog，因为这个旧的Editlog的事务都已经作用(合并)在FsImage上了。这个过程称为一个检查点(checkpoint这个检查点也就是新的fsimage文件)。在当前实现中，检查点只发生在Namenode启动时，在不久的将来将实现支持周期性的检查点。虽然读取 FsImage镜像文件是高效的，但直接对 FsImage 进行增量编辑并不高效。HDFS不会为每次对文件编辑而直接修改FsImage，而是将编辑内容保存在 Editlog事物日志中。在检checkpoint时候在将Editlog的更改内容应用于FsImage镜像文件中。新版本的2.10.x版本的HDFS可以在以秒为单位的给定时间间隔 (dfs.namenode.checkpoint.period) 或在累积给定数量的文件系统事务 (dfs.namenode.checkpoint.txns) 后触发checkpoint。如果设置了这两个属性，则要达到的第一个阈值会触发checkpoint。

Datanode将HDFS数据以文件的形式存储在本地的文件系统中(即将hdfs的数据块以文件形式进行存储)，它并不知道有关HDFS文件的信息。它把每个HDFS数据块存储在本地文件系统的一个单独的文件中。Datanode并不在同一个目录创建所有的文件(数据块)，实际上，它用试探的方法来确定每个目录的最佳文件(数据块)数目，并且在适当的时候创建子目录。在同一个目录中创建所有的本地文件并不是最优的选择，这是因为本地文件系统可能无法高效地在单个目录中支持大量的文件。当一个Datanode启动时，它会扫描本地文件系统，产生一个这些本地文件对应的所有HDFS数据块的列表，然后作为报告发送到Namenode，这个报告就是块状态报告。

1.5、块缓存：

数据通常情况下都保存在磁盘，但是对于访问频繁的文件，其对应的数据块可能被显式的缓存到datanode的内存中，以对外缓存的方式存在，一些计算任务（比如mapreduce）可以在缓存了数据的datanode上运行，利用块的缓存优势提高读操作的性能。

1.6、数据完整性：

从某个Datanode获取的数据块有可能是损坏的，损坏可能是由Datanode的存储设备错误、网络错误或者软件bug造成的。HDFS客户端软件实现了对HDFS文件内容的校验和(checksum)检查。当客户端创建一个新的HDFS文件，会计算这个文件每个数据块的校验和，并将校验和作为一个单独的隐藏文件保存在同一个HDFS名字空间下。当客户端获取文件内容后，它会检验从Datanode获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择从其他Datanode获取该数据块的副本。

1.7、存储空间回收：

1)、文件的删除和恢复：

当用户或应用程序删除某个文件时，这个文件并没有立刻从HDFS中删除。实际上，HDFS会将这个文件重命名转移到/trash目录。只要文件还在/trash目录中，该文件就可以被迅速地恢复。文件在/trash中保存的时间是可配置的，当超过这个时间时，Namenode就会将该文件从名字空间中删除。删除文件会使得该文件相关的数据块被释放。注意，从用户删除文件到HDFS空闲空间的增加之间会有一定时间的延迟。

只要被删除的文件还在/trash目录中，用户就可以恢复这个文件。如果用户想恢复被删除的文件，可以浏览/trash目录找回该文件。/trash目录仅仅保存被删除文件的最后副本。/trash目录与其他的目录没有什么区别，除了一点：在该目录上HDFS会应用一个特殊策略来自动删除文件。目前的默认策略是删除/trash中保留时间超过6小时的文件。将来，这个策略可以通过一个被良好定义的接口配置。

2)、减少副本系数：

当一个文件的副本系数被减小后，Namenode会选择过剩的副本删除。下次心跳检测时会将该信息传递给Datanode。Datanode遂即移除相应的数据块，集群中的空闲空间加大。同样，在调用setReplication API结束和集群中空闲空间增加间会有一定的延迟。

2、HDFS功能特性：

2.1、节点角色类型：

1)、secondary namenode ：

NameNode将对文件系统的改动追加保存到本地文件系统上的一个日志文件（editlog）。当一个NameNode启动时，它首先从一个映像文件（fsimage）中读取HDFS的状态，接着应用日志文件中的edits操作。然后它将新的HDFS状态写入（fsimage）中，并使用一个空的edits文件开始正常操作。因为NameNode只有在启动阶段才合并fsimage和edits，所以久而久之editlog日志文件可能会变得非常庞大，特别是对大型的集群。日志文件太大的另一个副作用是下一次NameNode启动会花很长时间。

该节点角色会周期性的从活动的namenode节点下载fsimage和editlog文件然后合并fsimage和edits的日志文件，从而确保edits日志文件大小维持在最小的限制范围内。Secondary NameNode保存最新checkpoint的目录与NameNode的目录结构相同。所以NameNode可以在需要的时候读取Secondary NameNode上的checkpoint镜像。Secondary NameNode的checkpoint进程启动，是由两个配置参数控制的：

dfs.namenode.checkpoint.period：指定连续两次检查点的最大时间间隔，默认值是1小时；
dfs.namenode.checkpoint.txns：定义了edits日志文件的最大值，一旦超过这个值会导致强制执行检查点（即使没到检查点的最大时间间隔）。默认值是100MB；

这个节点独立的运行于活动的namemode节点，且拥有和namenode一样的配置。这个节点主要是周期性的从活动的namenode下载fsimage和editlog文件然后创建checkpoint等待活动的namenode来使用。

如果NameNode上除了最新的checkpoint以外，所有的其他的历史FsImage镜像和edits文件都丢失了， NameNode可以引入这个最新的检查点。以下操作可以实现这个功能：

在配置参数dfs.name.dir指定的位置建立一个空文件夹；
把检查点目录的位置赋值给配置参数fs.checkpoint.dir；
启动NameNode，并加上-importCheckpoint。
NameNode会从fs.checkpoint.dir目录读取检查点，并把它保存在dfs.name.dir目录下。如果dfs.name.dir目录下有合法的镜像文件，NameNode会启动失败。 NameNode会检查fs.checkpoint.dir目录下镜像文件的一致性，但是不会去改动它。

2)、checkpoint node：

该节点角色主要用于从活动的namenode节点下载fsimage和editlog文件到本地然后将这两个文件进行合并即生成一个checkpoint，然后将新生成的checkpoint（fsimage镜像文件）上传到namenode节点上，更新活动的namenode节点的元数据内容。Checkpoint节点由配置文件中指定的节点上的bin/hdfs namenode -checkpoint启动。
Checkpoint节点上的checkpoint进程的启动由两个配置参数控制：

dfs.namenode.checkpoint.period：默认设置为1小时，指定两个连续检查点之间的最大时间间隔；
dfs.namenode.checkpoint.txns：它定义了NameNode上的非检查点事务数，即使尚未达到检查点期限，该事务也会强制执行紧急检查点；默认100MB；

这个节点独立的运行于活动的namenode节点，且拥有和namenode一样的配置。该节点周期性的从活动的namenode节点下载fsimage和editlog文件创建checkpoint，然后将最新的fsimage回传到namenode上；

3)、backup node：

该节点无需向secondery namenode和checkpoint node一样需要从活动的namenode下载fsimage、editlog文件到本地进行创建checkpoint，该节点直接同步活动的namenode内存中最新状态的fsimage。NameNode一次支持一个备份节点。如果使用了备份节点，则不能注册任何Checkpoint节点。一对多形式的多个备份节点目前暂时不支持。
备份节点的配置方式与检查点节点相同。它从bin/hdfs namenode -backup开始。
同样的这个节点独立的运行于活动的namemode节点，且拥有和namenode一样的配置。

使用备份节点提供了在不具有持久性存储的情况下运行NameNode的选项，将namespace状态持久化的所有责任委托给了备份节点。为此，请使用-importCheckpoint选项启动NameNode，并为NameNode配置不指定类型为dfs.namenode.edits.dir的持久性存储目录。

2.2、联邦HDFS：

namenode在内存中保存了文件系统中每个文件和每个数据块的引用关系，这意味着，当文件足够多时，namenode的内存将成为限制系统横向扩展的瓶颈。hadoop2.0引入了联邦HDFS允许系统通过添加namenode的方式实现扩展，每个namenode管理文件系统命名空间中的一部分，比如：一个namenode管理/usr下的文件，另外一个namenode管理/share目录下的文件。

2.3、HDFS的高可用性：

通过备份namenode存储的文件信息或者运行辅助namenode可以防止数据丢失，但是依旧没有保证了系统的高可用性。一旦namenode发生了单点失效，那么必须能够快速的启动一个拥有文件系统信息副本的新namenode，而这个过程需要以下几步：
（1）将命名空间的副本FsImage导入内存；
（2）重放editlog日志文件，将变更事物增加到FsImage文件中或者重新构建FsImage；
（3）接收足够多来自datanode的数据块报告，从而重建起数据块与位置的对应关系；

上述实际上就是一个namenode的冷启动过程，但是在数据量足够大的情况下，这个冷启动可能需要30分钟以上的时间，这是无法忍受的。

Hadoop2.0开始，增加了对高可用性的支持。采用了双机热备份的方式。同时使用一对活动-备用namenode，当活动namenode失效后，备用namenode可以迅速接管它的任务，这中间不会有任何的中断，以至于使得用户根本无法察觉。

为了实现这种双机热备份，HDFS架构需要作出以下几个改变：

两个namenode之间要通过高可用共享存储来实现editlog的共享；
datanode要同时向两个namenode发送数据块的报告信息；
客户端要使用特定机制来处理namenode的失效问题；
备用namenode要为活动namenode设置周期性的checkpoint，从中判断活动namenode是否失效；

HDFS系统中运行着一个故障转移控制器，管理着将活动namenode转移为备用namenode的转换过程。同时，每一个namenode也运行着一个轻量级的故障转移控制器，主要目的就是监视宿主namenode是否失效，并在失效时实现迅速切换。