HDFS

HDFS(Hadoop Distribution File System, Hadoop分布式文件系统)，是一种分布式文件系统，他能联合多个服务器节点组成一个集群，并管理这个集群提供各种高容错的、大规模的数据存储和读取等服务。

HDFS一般由Client, NameNode, SecondaryNameNode和多个DataNode组成。

NameNode可以说是整个HDFS的核心，大部分的操作都需要围绕着NameNode进行。

• NameNode管理着HDFS的命名空间。
• NameNode记录了每个文件中每个块所在集群节点的地址信息。
• NameNode负责配置副本策略。
• NameNode负责处理Client对HDFS的读写请求。

为了保证HDFS使用的高效率，HDFS会将系统文件树的元数据加载到内存中。但是如果NameNode断电，内存中的数据就消失了，所以需要以下两个数据结构来记录NameNode的元数据：FsImage和EditLog。

• FsImage保存了文件系统树及文件树中所有文件和文件夹的元数据。FsImage存储在磁盘中，是对内存中元数据的备份。
• 但是若在更新内存元数据的同时更新FsImage，这种做法效率也太低了。于是有了EditLog。 EditLog记录了所有针对文件的创建、删除、重命名等操作。有了EditLog后，内存中的元数据更新将记录到EditLog中。
• 当NameNode启动的时候，NameNode会把FsImage加载进内存，然后再执行EditLog中的操作。当NameNode将EditLog的操作执行完毕后，NameNode就更新到上次关机时的元数据状态了。

但是如果服务器上次开启了很长时间，EditLog记录了非常多的操作，那么在重启载入FsImage后执行EditLog中的操作就会非常耗时。如何解决这个办法？此时就需要Secondary NameNode出场了。

Secondary NameNode负责定期进行FsImage和EditLog的合并。

• NameNode启动时加载FsImage和EditLog进内存。若客户端对元数据做增删改要求时，操作先记录在日志中并更新日志，随后再对内存中的元数据进行修改。
• Secondary NameNode会根据定时时间或者EditLog的数据量是否满这两个触发条件，来决定是否发出CheckPoint请求。
• 当执行CheckPoint的时候，NameNode会创建一个新的日志文件（edits_inprogress_xxx），让NameNode接下来都往这个文件写入文件操作日志，并将原来的edits_inprogress_xxx文件重命名为edits_xxx文件。随后，NameNode将FsImage和edits_xxx文件拷贝到Secondary NameNode。
• Secondary NameNode将拷贝来的FsImage和edits_xxx文件加载到内存中，并生成新的FsImage。
• Secondary NameNode将新的FsImage拷贝到NameNode
• NameNode将新的FsImage重命名，并覆盖旧的FsImage

这样，EditLog就可以通过这种方法定期进行合并，不会出现过大的情况。

DataNode是HDFS中的工作节点，被记录在workers的列表中。DataNode负责数据的读取和存储，接受Client或者NameNode的指令进行数据的存储和检索。

• DataNode的数据存储以数据块（Block）为单位，一个个大文件会被拆成多个小小的块。在Hadoop2.x和Hadoop3.x中，数据块的大小默认为128M，在Hadoop1.x则默认为64M。每个块都有一个块id。每个块都会被复制到多个节点上，默认为3个。
• 要注意，这里的大小是指块最大的容量。例如，我要写入一个200M的文件，那么就会被分成两块，第0块大小为128M，第1块的大小为72M。但如果我要写入一个1M的文件，那么还是会分配到一个块id，代表着一个块，只不过这个块特别小。之后再写入新的文件也是新建一个块。
• 一个数据块在磁盘上包括了两个文件，一个是块数据本身，一个是该块的元数据文件(.meta)，包括数据块的长度，数据块的校验和和时间戳。
• DataNode启动后会向NameNode报告当前存储的数据块信息，后续周期性（默认为6小时）地向NameNode发送自己存储的所有块信息。
• 除了报告块信息外，DataNode会默认每3秒向NameNode发送心跳，心跳返回结果带有NameNode给DataNode的命令。若超过10min+30s没有收到某个DataNode的心跳，则认为该DataNode已不可用。

Client是HDFS的客户端，用户通过给予客户端命令来操控HDFS。

• 文件上传HDFS的时候，由Client将文件分块后进行上传。
• Client通过向NameNode发送请求后，获取所要读/写的DataNode位置信息。
• Client通过与DataNode发送请求进行读/写操作。

一般来说，当HDFS存储一个块时会选择三个DataNode作为副本。

这三个副本默认情况下，第一个副本为Client本地节点（如果Client为远程操控那么随机选择一个节点）；第二个副本为和第一个副本不同机架上的一个节点； 第三个副本为和第二个副本相同机架上的节点。

在进行HDFS的读写操作时，NameNode会选择距离最近的DataNode进行下载和上传。这个最短距离指的是两个结点到达最近的共同祖先的距离总和。

例如，这里的/d1/r1/n1到/d2/r4/n1的距离就是6。

在介绍些流程之前，我先介绍三个单位：block、packet和chunk。

• block是DataNode的存储粒度，由dfs.block.size参数决定（hdfs-site.xml，下同），默认128M。
• packet是数据传输时的粒度，由dfs.write.packet.size参数决定，默认是64KB。
• chunk是数据传输时数据校验的粒度，由io.bytes.per.checksum参数决定，默认是512B

写入过程中，文件写入到chunk大小的buf中，当写满一个chunk时，则会计算chunksum（校验用），并填充到packet中；当chunk填充到足够一个packet的大小后，将这个packet放到数据队列中(data queue)；进入数据队列的packet会被另一个线程发送到DataNode中。

• Client通过DistributionFileSystem模块向NameNode请求上传文件。
• NameNode检查文件是否可以创建（Client是否存在权限和Client请求的目录是否存在），若可行，则相应可以上传文件。
• Client把文件分块，并向NameNode请求上传第一个块。
• NameNode根据配置副本策略，选择节点dn1、dn2、dn3，向Client发送节点地址，并告知每个节点距离Client的顺序。
• Client选择最近的一个节点dn1，通过FSDataOutputStream模块请求建立传输通道，dn1向dn2建立传输通道，dn2向dn3建立传输通道。
• dn1、dn2、dn3逐级应答Client。
• Client开始向dn1传输第1个块。在传输的过程中，Client是以packet（64KB）的为单位进行传输。d1n收到一个packet后传给dn2，dn2收到packet后传给dn3。同样，当传输完成后，接受方会向发送方发送传输成功的确认信息。
• FSDataOutputStream会为此保留一个确认队列（ack queue），里面保存了发送但没收到确认信息的packet，只有当所有的DataNode都发送了该packet的传输成功信息，确认队列的packet才会被删除。
• Client收到block的所有传输成功的确认信息后，Client再次请求向NameNode上传第二个block。

• Client通过DistributionFileSystem模块向NameNode请求下载文件。
• NameNode根据查找元数据，找到文件所在的节点dn1、dn2、dn3，向Client发送节点地址，并告知每个节点距离Client的顺序。
• Client通过网络拓扑上的就近原则选择最近的一个节点dn1，通过FSDataInputStream模块请求读数据。
• dn1开始以packet为单位做校验并传输数据。
• Client以packet为单位接收数据，先在本地缓存，然后写入目标文件。

图片来源尚硅谷。