HDFS的工做原理

元数据管理机制

一、文件读取过程

1.客户端经过调用 DistributedFileSystem 的create方法，建立一个新的文件。

2.DistributedFileSystem经过RPC（远程过程调用）调用NameNode，去建立一个没有blocks关联的新文件。建立前，NameNode会作各类校验，好比文件是否存在，客户端有无权限去建立等。若是校验经过，NameNode就会记录下新文件，不然就会抛出IO异常。

3.前两步结束后会返回FSDataOutputStream的对象，和读文件的时候类似，FSDataOutputStream被封装成DFSOutputStream，DFSOutputStream 能够协调 NameNode和DataNode。客户端开始写数据到DFSOutputStream,DFSOutputStream会把数据切成一个个小packet，而后排成队列 data queue。

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

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

6.客户端完成写数据后，调用close方法关闭写入流。

7.DataStreamer 把剩余的包都刷到 pipeline 里，而后等待 ack 信息，收到最后一个 ack 后，通知 DataNode 把文件标示为已完成。

二、文件写入过程

一、首先调用FileSystem对象的open方法，其实获取的是一个DistributedFileSystem的实例。

二、DistributedFileSystem经过RPC(远程过程调用)得到文件的第一批block的locations，同一block按照重复数会返回多个locations，这些locations按照Hadoop拓扑结构排序，距离客户端近的排在前面。

三、前两步会返回一个FSDataInputStream对象，该对象会被封装成DFSInputStream对象，DFSInputStream能够方便的管理datanode和namenode数据流。客户端调用read方法，DFSInputStream就会找出离客户端最近的datanode并链接datanode。

四、数据从datanode源源不断的流向客户端。

五、若是第一个block块的数据读完了，就会关闭指向第一个block块的datanode链接，接着读取下一个block块。这些操做对客户端来讲是透明的，从客户端的角度来看只是读一个持续不断的流。

六、若是第一批block都读完了，DFSInputStream就会去namenode拿下一批blocks的location，而后继续读，若是全部的block块都读完，这时就会关闭掉全部的流。

名词解释

一、NameNode

​ hdfs-site.xml的dfs.name.dir属性

​ 是整个文件系统的管理节点。它维护着整个文件系统的文件目录树，文件/（根）目录的元信息和每一个文件对应的数据块列表。接收用户的操做请求。

文件包括：

​ fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息

​ edits:操做日志文件

​ fstime:保存最近一次checkpoint的时间

以上这些文件是保存在linux的文件系统中。

二、Bolck

​ 文件块（block）：最基本的存储单位。

对于文件内容而言，一个文件的长度大小是size，那么从文件的0偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每个块称一个Block。

​ HDFS默认Block大小是128MB，以一个256MB文件为例，共有256/128=2个Block。

​ dfs.block.size不一样于普通文件系统的是，HDFS中，若是一个文件小于一个数据块的大小，并不占用整个数据块存储空间Replication。

三、DataNode

​ hdfs-site.xml的dfs.replication属性

​ 提供真实文件数据的存储服务。

​ 一个DataNode上有多个bolck——多复本。默认是三个。

四、客户端上传元数据

​ 一、客户端发起写入请求

​ 二、NN返回可用的DN

​ 三、客户端把元数据拆分红多个块

​ 四、上传第一个块到某个DN1

​ 五、DN1向DN2发起复制请求，DN2向DN3发起复制请求，若是失败，则由NN从新指定一个block向新的DN4发起复制请求

五、上传元数据信息安全机制

​ 一、客户端发起写入请求

​ 二、把操做写入到edits logs

​ 三、客户端上传文件文件，并把结果反馈给NN，NN在内存中写入本次上传信息

​ 四、当edits logs写满，则同步（flush）到 fs image文件系统中

​ 五、读取的时候日志以特殊的方式跟fs image合并（因此不能在NN作合并）

六、元数据存储与读取细节

SN的checkpoint机制

​fs.checkpoint.period 指定两次checkpoint的最大时间间隔， 默认3600秒。

​ fs.checkpoint.size 规定edits文件的最大值，一旦超过这个值则强制checkpoint，无论是否到达最大时间间隔。默认大小是64M。

​ Namenode始终在内存中保存metedata，用于处理“读请求”，到有“写请求”到来时，namenode会首先写editlog到磁盘，即向edits文件中写日志，成功返回后，才会修改内存，而且向客户端返回，Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，可是fsimage不会随时与namenode内存中的metedata保持一致，而是每隔一段时间经过合并edits文件来更新内容。Secondary namenode就是用来合并fsimage和edits文件来更新NameNode的metedata的。