HDFS工作原理

HDFS工作原理

一、HDFS特性

HDFS是一个文件系统，用于存储和管理文件，通过统一的命名空间（类似于本地文件系统的目录树）。HDFS是分布式的系统，服务器集群中各个节点都有自己的角色和职责。理解HDFS，需要注意以下几个概念：

1、HDFS中的文件在物理上是分块存储（block），块的大小可以通过配置参数(
dfs.blocksize)来规定，默认大小在hadoop2.x版本中是128M，之前的版本中是64M。

2、HDFS文件系统会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data

3、目录结构及文件分块位置信息(元数据)的管理由namenode节点承担，namenode是HDFS集群主节点，负责维护整个hdfs文件系统的目录树，以及每一个路径（文件）所对应的数据块信息（blockid及所在的datanode服务器）

4、文件的各个block的存储管理由datanode节点承担，datanode是HDFS集群从节点，每一个block都可以在多个datanode上存储多个副本（副本数量也可以通过参数设置dfs.replication，默认是3）

5、Datanode会定期向Namenode汇报自身所保存的文件block信息，而namenode则会负责保持文件的副本数量，HDFS的内部工作机制对客户端保持透明，客户端请求访问HDFS都是通过向namenode申请来进行。

6、HDFS是设计成适应一次写入，多次读出的场景，且不支持文件的修改。需要频繁的RPC交互，写入性能不好。

二、各节点的功能

• Namenode:元数据节点
  功能：
  （1）管理 HDFS 的名称空间（文件目录树）；HDFS 很方便的一点就是对于用户来说很友好，用户不考虑细节的话，看到的目录结构和我们使用 Window 和Linux 文件系统很像。
  （2）管理数据块（Block）映射信息及副本信息；一个文件对应的块的名字以及块被存储在哪里，以及每一个文件备份多少都是由 NameNode 来管理。
  （3）处理客户端读写请求。

• Datanode:数据节点
  功能：
  （1）存储实际的数据块。
  （2）执行数据块的读/写操作。
  （3）定期向Namenode发送心跳信息

• SecondaryNamenode:从元数据节点
  并非 NameNode 的热备份。当 NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。
  功能：
  （1）辅助 NameNode，分担其工作量。
  （2）定期合并 Fsimage 和 Edits，并推送给 NameNode。
  （3）在紧急情况下，可辅助恢复 NameNode，不能替代。

• RescourceManager
  ResourceManager 即 资源管理者
  功能：
  在YARN中，ResourceManager负责集群中所有资源的统一管理和分配，它接收来自各个节点（NodeManager）的资源汇报信息，并把这些信息按照一定的策略分配给各个应用程序（实际上是ApplicationManager）。
  RescourceManager包括Scheduler（定时调度器）和ApplicationManager（应用管理器）。Schedular负责向应用程序分配资源，它不做监控以及应用程序的状态跟踪，并且不保证会重启应用程序本身或者硬件出错而执行失败的应用程序。ApplicationManager负责接受新的任务，协调并提供在ApplicationMaster容器失败时的重启功能。
  这里简单介绍以下ApplicationMaster，每个应用程序的AM负责项Scheduler申请资源，以及跟踪这些资源的使用情况和资源调度的监控

• NodeManager
  是ResourceManager在每台机器上的代理
  功能：
  负责容器（Container：实际在Datanode中）的管理，并监控它们的资源使用情况，以及向ResourceManager/Scheduler提供资源使用报告
  定期发送心跳给ResourceManager

• editlog和fsimage
  内存元数据就是当前namenode正在使用的元数据，是存储在内存中的。磁盘元数据镜像文件是内存元数据的镜像，保存在namenode工作目录中，它是一个准元数据，作用是在namenode宕机时能够快速较准确的恢复元数据。称为fsimage。数据操作日志文件是用来记录元数据操作的，在每次改动元数据时都会追加日志记录，如果有完整的日志就可以还原完整的元数据。主要作用是用来完善fsimage，减少fsimage和内存元数据的差距。称为editlog。
  功能：
  editlog，fsimage 镜像文件，是元数据在某个时间段的快照，editlog记录了生成快照之后的一些列操作。HDFS 在最初格式化启动时，创建 editlog和 fsimage 文件，并在内存中维护一版元数据信息，这时候，fsimage 和内存中的元数据信息是相同的。后续每一次客户端操作时，会先记录客户端执行的操作，这个操作是记录 editlog在文件中的，然后再更新内存中对应的目录树结构，比如用户删除一个文件，会先在 editlog文件中记录一个 delete 操作，然后在内存中真正删除改文件。也就是说，内存中的元数据信息是完整的。前面生成的快照 fsimage 只是元数据的一部分，执行完 editlog文件中相关操作才能与内存中元数据相同。

Client：就是客户端，自己编写的代码+Hadoop API。其主要功能：
（1）进行文件切分。文件上传 HDFS 的时候，Client 将文件切分成一个一个的Block，然后进行存储。
（2）当我们要查询一个文件时，与 NameNode 交互，获取文件的位置信息。
（3）与 DataNode 交互，读取或者写入数据。
（4）Client 提供一些命令来管理 HDFS，比如启动或者关闭 HDFS。
（5）Client 可以通过一些命令来访问 HDFS。

三、HDFS读写删除的工作过程

1、读数据

客户端将要读取的文件路径发送给namenode，namenode获取文件的元信息（主要是block的存放位置信息）返回给客户端，客户端根据返回的信息找到相应datanode逐个获取文件的block并在客户端本地进行数据追加合并从而获得整个文件。
HDFS读数据步骤大概可以用以下的流程图表示：

1. 客户端向namenode发起RPC调用，请求读取文件数据。
2. namenode检查文件是否存在，如果存在则获取文件的元信息（blockid以及对应的datanode列表）。
3. 客户端收到元信息后选取一个网络距离最近的datanode，依次请求读取每个数据块。客户端首先要校检文件是否损坏，如果损坏，客户端会选取另外的datanode请求。
4. datanode与客户端建立socket连接，传输对应的数据块，客户端收到数据缓存到本地，之后写入文件。
   依次传输剩下的数据块，直到整个文件合并完成。

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

2、写数据

客户端要向HDFS写数据，首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode，然后客户端按顺序将文件逐个block传递给相应datanode，并由接收到block的datanode负责向其他datanode复制block的副本。
对于HDFS写数据的流程大概可以用以下的流程图表示：

1. 客户端向namenode发送上传文件请求，namenode对要上传目录和文件进行检查，判断是否可以上传，并向客户端返回检查结果。
2. 客户端得到上传文件的允许后读取客户端配置，如果没有指定配置则会读取默认配置（例如副本数和块大小默认为3和128M，副本是由客户端决定的）。向namenode请求上传一个数据块。
3. namenode会根据客户端的配置来查询datanode信息，如果使用默认配置，那么最终结果会返回同一个机架的两个datanode和另一个机架的datanode。这称为“机架感知”策略。
4. 客户端在开始传输数据块之前会把数据缓存在本地，当缓存大小超过了一个数据块的大小，客户端就会从namenode获取要上传的datanode列表。之后会在客户端和第一个datanode建立连接开始流式的传输数据，这个datanode会一小部分一小部分（4K）的接收数据然后写入本地仓库，同时会把这些数据传输到第二个datanode，第二个datanode也同样一小部分一小部分的接收数据并写入本地仓库，同时传输给第三个datanode，依次类推。这样逐级调用和返回之后，待这个数据块传输完成客户端后告诉namenode数据块传输完成，这时候namenode才会更新元数据信息记录操作日志。
5. 第一个数据块传输完成后会使用同样的方式传输下面的数据块直到整个文件上传完成。

【注意】

1.请求和应答是使用RPC的方式，客户端通过ClientProtocol与namenode通信，namenode和datanode之间使DatanodeProtocol交互。在设计上，namenode不会主动发起RPC，而是响应来自客户端或 datanode 的RPC请求。客户端和datanode之间是使用socket进行数据传输，和namenode之间的交互采用nio封装的RPC。
2.HDFS有自己的序列化协议。
3.在数据块传输成功后但客户端没有告诉namenode之前如果namenode宕机那么这个数据块就会丢失。
4.在流式复制时，逐级传输和响应采用响应队列来等待传输结果。队列响应完成后返回给客户端。
5.在流式复制时如果有一台或两台（不是全部）没有复制成功，不影响最后结果，只不过datanode会定期向namenode汇报自身信息。如果发现异常namenode会指挥datanode删除残余数据和完善副本。如果副本数量少于某个最小值就会进入安全模式。
【Tips】

RPC(Remote Procedure Call)是远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。

3、删除数据

1. 客户端向namenode发起RPC调用，请求删除文件。namenode检查合法性。
2. namenode查询文件相关元信息，向存储文件数据块的datanode发出删除请求。
3. datanode删除相关数据块。返回结果。
4. namenode返回结果给客户端。

【注意】
当用户或应用程序删除某个文件时，这个文件并没有立刻从HDFS中删除。实际上，HDFS会将这个文件重命名转移到/trash目录。只要文件还在/trash目录中，该文件就可以被迅速地恢复。文件在/trash中保存的时间是可配置的，当超过这个时间时，Namenode就会将该文件从名字空间中删除。删除文件会使得该文件相关的数据块被释放。注意，从用户删除文件到HDFS空闲空间的增加之间会有一定时间的延迟。只要被删除的文件还在/trash目录中，用户就可以恢复这个文件。如果用户想恢复被删除的文件，他/她可以浏览/trash目录找回该文件。/trash目录仅仅保存被删除文件的最后副本。/trash目录与其他的目录没有什么区别，除了一点：在该目录上HDFS会应用一个特殊策略来自动删除文件。目前的默认策略是删除/trash中保留时间超过6小时的文件。将来，这个策略可以通过一个被良好定义的接口配置。
当一个文件的副本系数被减小后，Namenode会选择过剩的副本删除。下次心跳检测时会将该信息传递给Datanode。Datanode遂即移除相应的数据块，集群中的空闲空间加大。同样，在调用setReplication API结束和集群中空闲空间增加间会有一定的延迟。

四、checkpoint机制

因为namenode本身的任务就非常重要，为了不再给namenode压力，日志合并到fsimage就引入了另一个角色secondarynamenode。secondarynamenode负责定期把editslog合并到fsimage，“定期”是namenode向secondarynamenode发送RPC请求的，是按时间或者日志记录条数为“间隔”的，这样即不会浪费合并操作又不会造成fsimage和内存元数据有很大的差距。因为元数据的改变频率是不固定的。
每隔一段时间，会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程称为checkpoint）

checkpoint步骤：

1. namenode向secondarynamenode发送RPC请求，请求合并editslog到fsimage。
2. secondarynamenode收到请求后从namenode上读取（通过http服务）editslog（多个，滚动日志文件）和fsimage文件。
3. secondarynamenode会根据拿到的editslog合并到fsimage。形成最新的fsimage文件。（中间有很多步骤，把文件加载到内存，还原成元数据结构，合并，再生成文件，新生成的文件名为fsimage.checkpoint）。
4. secondarynamenode通过http服务把fsimage.checkpoint文件上传到namenode，并且通过RPC调用把文件改名为fsimage。
   namenode和secondary namenode的工作目录存储结构完全相同，所以，当namenode故障退出需要重新恢复时，可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录，以恢复namenode的元数据。