HDFS原理解析（整体架构，读写操作流程及源代码查看等）

布满荆棘的人生 2022-05-16 05:56 212阅读 0赞

# [HDFS原理解析（整体架构，读写操作流程及源代码查看等）][HDFS] #

### **前言** ###

> HDFS 是一个能够面向大规模数据使用的。可进行扩展的文件存储与传递系统。是一种同意文件通过网络在多台主机上分享的文件系统，可让多机器上的多用户分享文件和存储空间。让实际上是通过网络来訪问文件的动作。由程序与用户看来，就像是訪问本地的磁盘一般。即使系统中有某些节点脱机，总体来说系统仍然能够持续运作而不会有数据损失。
> 
>

### **一、HDFS体系结构** ###

![20150601193442805][]

**1、Namenode**   
Namenode是整个文件系统的管理节点。它维护着整个文件系统的文件文件夹树，文件/文件夹的元信息和每个文件相应的数据块列表, 接收用户的操作请求。   
文件包含：   
①fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息。   
②edits:操作日志文件。   
③fstime:保存近期一次checkpoint的时间   
以上这些文件是保存在linux的文件系统中。通过hdfs-site.xml的dfs.namenode.name.dir属性进行设置。

**查看NameNode的fsimage与edits内容**   
这个两个文件里的内容使用普通文本编辑器是无法直接查看的，幸运的是hadoop为此准备了专门的工具用于查看文件的内容，这些工具分别为oev和oiv，能够使用hdfs调用运行。

启动server：bin/hdfs oiv -i 某个fsimage文件

> bash$ bin/hdfs oiv -i fsimage   
> 14/04/07 13:25:14 INFO offlineImageViewer.WebImageViewer: WebImageViewer started.   
> Listening on /127.0.0.1:5978. Press Ctrl+C to stop the viewer.

查看内容：bin/hdfs dfs -ls -R webhdfs://127.0.0.1:5978/

> bash$ bin/hdfs dfs -ls webhdfs://127.0.0.1:5978/   
> Found 2 items   
> drwxrwx–\* - root supergroup 0 2014-03-26 20:16 webhdfs://127.0.0.1:5978/tmp   
> drwxr-xr-x - root supergroup 0 2014-03-31 14:08 webhdfs://127.0.0.1:5978/user

导出fsimage的内容：bin/hdfs oiv -p XML -i   
tmp/dfs/name/current/fsimage\_0000000000000000055 -o fsimage.xml

> bash$ bin/hdfs oiv -p XML -i fsimage -o fsimage.xml   
> 0000055 -o fsimage.xml

查看edtis的内容：bin/hdfs oev -i   
tmp/dfs/name/current/edits\_0000000000000000057-0000000000000000186 -o edits.xml

> bash$ bin/hdfs oev -i   
> tmp/dfs/name/current/edits\_0000000000000000057-0000000000000000186 -o edits.xml

**2、Datanode**   
提供真实文件数据的存储服务。

文件块（ block）： 最主要的存储单位。   
对于文件内容而言，一个文件的长度大小是size。那么从文件的０偏移開始，依照固定的大小，顺序对文件进行划分并编号，划分好的每个块称一个Block。

HDFS默认Block大小是128MB。 因此。一个256MB文件。共同拥有256/128=2个Block.   
与普通文件系统不同的是，在 HDFS中，假设一个文件小于一个数据块的大小，并不占用整个数据块存储空间。   
Replication：多复本。默认是三个。通过hdfs-site.xml的dfs.replication属性进行设置。

### **二、数据存储操作** ###

**1、数据存储： block**   
默认数据块大小为128MB，可配置。若文件大小不到128MB，则单独存成一个block。   
为何数据块如此之大？   
传输数据时间超过寻道时间（高吞吐率）   
一个文件存储方式？   
按大小被切分成若干个block。存储到不同节点上。默认情况下每个block有三个副本。   
![20150601211236355][]   
HDFS Block的设计理念：一个文件由哪些块组成。

一个块存储在哪些节点上。**优点：**易于分摊到各个节点。

例如以下：

> block1:node1,node2,node3   
> block2:node2,node3,node4   
> block3:node4,mode5,node6   
> block4:node5,node6.node7

**2、数据存储： staging**   
HDFS client上传数据到HDFS时，首先，在本地缓存数据，当数据达到一个block大小时。请求NameNode分配一个block。 NameNode会把block所在的DataNode的地址告诉HDFS client。 HDFS client会直接和DataNode通信，把数据写到DataNode节点一个block文件里。

**3、数据存储：读文件操作**   
![20150601193510900][]   
1.首先调用FileSystem对象的open方法，事实上是一个DistributedFileSystem的实例。

2.DistributedFileSystem通过rpc获得文件的第一批block的locations，同一个block依照反复数会返回多个locations，这些locations依照hadoop拓扑结构排序，距离client近的排在前面。

3.前两步会返回一个FSDataInputStream对象，该对象会被封装DFSInputStream对象，DFSInputStream能够方便的管理datanode和namenode数据流。client调用read方法。DFSInputStream最会找出离client近期的datanode并连接。

4.数据从datanode源源不断的流向client。

5.假设第一块的数据读完了，就会关闭指向第一块的datanode连接。接着读取下一块。

这些操作对client来说是透明的，client的角度看来仅仅是读一个持续不断的流。

6.假设第一批block都读完了， DFSInputStream就会去namenode拿下一批block的locations。然后继续读。假设全部的块都读完，这时就会关闭掉全部的流。   
假设在读数据的时候， DFSInputStream和datanode的通讯发生异常。就会尝试正在读的block的排序第二近的datanode,而且会记录哪个datanode错误发生，剩余的blocks读的时候就会直接跳过该datanode。 DFSInputStream也会检查block数据校验和，假设发现一个坏的block,就会先报告到namenode节点，然后DFSInputStream在其它的datanode上读该block的镜像。

该设计就是client直接连接datanode来检索数据而且namenode来负责为每个block提供最优的datanode。 namenode仅仅处理block location的请求，这些信息都载入在namenode的内存中。hdfs通过datanode集群能够承受大量client的并发訪问。   
**Hadoop2.6.0源代码查看读过程**   
![20150602195123973][]

**4、数据存储：写文件操作**   
![20150601193334152][]

1.client通过调用DistributedFileSystem的create方法创建新文件。

2.DistributedFileSystem通过RPC调用namenode去创建一个没有blocks关联的新文件，创建前， namenode会做各种校验。比方文件是否存在，client有无权限去创建等。假设校验通过。 namenode就会记录下新文件，否则就会抛出IO异常。

3.前两步结束后。会返回**FSDataOutputStream**的对象，与读文件的时候类似， FSDataOutputStream被封装成DFSOutputStream。DFSOutputStream能够协调namenode和datanode。client開始写数据到DFSOutputStream，DFSOutputStream会把数据切成一个个小的packet。然后排成队列data quene。

4.DataStreamer会去处理接受data quene，它先询问namenode这个新的block最适合存储的在哪几个datanode里（比方反复数是3。那么就找到3个最适合的datanode），把他们排成一个pipeline。DataStreamer把packet按队列输出到管道的第一个datanode中。第一个datanode又把packet输出到第二个datanode中。以此类推。

5.DFSOutputStream另一个对列叫ack quene。也是由packet组成，等待datanode的收到响应，当pipeline中的全部datanode都表示已经收到的时候，这时akc quene才会把相应的packet包移除掉。

假设在写的过程中**某个datanode错误发生**，会採取下面几步：   
1) pipeline被关闭掉；   
2)为了防止防止丢包ack quene里的packet会同步到data quene里；   
3)把产生错误的datanode上当前在写但未完毕的block删掉；   
4)block剩下的部分被写到剩下的两个正常的datanode中。   
5)namenode找到另外的datanode去创建这个块的复制。当然。这些操作对client来说是无感知的。

6.client完毕写数据后调用close方法关闭写入流。

7.DataStreamer把剩余得包都刷到pipeline里，然后等待ack信息，收到最后一个ack后，通知datanode把文件标视为已完毕。

**注意：**client运行write操作后，写完的block才是可见的，正在写的block对client是不可见的，仅仅有调用sync方法。client才确保该文件的写操作已经全部完毕。当client调用close方法时，会默认调用sync方法。

是否须要手动调用取决你依据程序须要在数据健壮性和吞吐率之间的权衡。

**Hadoop2.6.0源代码查看写过程**   
![20150602195231584][]

[HDFS]: https://www.cnblogs.com/yutingliuyl/p/7294935.html
[20150601193442805]: /images/20220516/5b6e04dea6dc4156970dd0ed372fedf6.png
[20150601211236355]: /images/20220516/197da3cd9b254734b4ff71a665ccead6.png
[20150601193510900]: /images/20220516/0498f0649a2d4981b1433c4e563786b3.png
[20150602195123973]: /images/20220516/7c68ba8b10e74e2daf744d0edc2c331c.png
[20150601193334152]: /images/20220516/8378d5936af64c908f6b53b944b3773f.png
[20150602195231584]: /images/20220516/c5fd2b4a06f6450fa3e2901627f9b949.png