HDFS文件读写机制思考及图解

HDFS（Hadoop Distributed File System）作为GFS思想的开源实现，支持数据流读取和处理超大规模文件，并能够运行在由廉价服务器组成的集群上；HDFS将硬件出错视为一种常态，而不是异常，故而HDFS采用了多种机制来保证存储文件的完整性；如在hadoop2.x中采用文件副本、hadoop3.x采用纠删码机制。在此以hadoop2.x为例结合图解论述HDFS的文件读写机制。

HDFS客户端写文件

以HDFS客户端发起hadoop fs -put file.data /为例：其首先需要通过客户端DistributedFileSystem向NameNode发起文件上传请求，Namenode会对请求进行权限检查、查询Namenode文件目录树并判断是否已存在当前客户端请求上传的文件路径、查询DataNode（满足节点数据分布安全性）信息并返回。客户端得到DataNode信息后，选取最适合的一个节点dn1（假设是dn1）进行文件传输通信请求，也就是发起TCP连接。
而在建立连接过程中，所获得的DataNode节点之间也会建立起pipeline数据传输通道进行数据传输（在此假设replication=3，即获取了三个DataNode节点，假设为dn1、dn2、dn3）。假设此时数据传送到了dn1，数据块不会直接保存在磁盘上（毕竟磁盘IO时延还是较高的），而是先保存在内存中，而后由dn1通过pipeline机制传送到dn2，dn2传送给dn3，同时在节点数据传送完成后会将数据持久化至磁盘；数据传送完毕ack状态信息由dn3向dn2传送，dn2接收到dn3信息后向dn1传送，dn1向客户端传送。客户端接收dn1传送完成信息时即判断本次block数据传送完毕，而后向Namenode汇报并申请下一个block数据传送（若有的话）。个人认为数据传送确认过程有点类似于连续ARQ协议+数据拓扑。
HDFS客户端写文件详细图示如下：

HDFS客户端读文件

我们知道hadoop1.x中HDFS的默认blockSize为64MB，在hadoop2.x中blockSize默认为128MB，同时我们可以联想到目前大多数磁盘传输速率在百兆字节每秒上下，这是为什么呢？HDFS虽然无法进行数据实时处理，但对数据传输还是有一定性能追求的，一般而言一个块的传输时间控制在一秒上下比较合适。在HDFS中文件是分块存放的，一个大文件，假设有1280MB，采用默认blockSIze存放，其会被切分为10个block；假设HDFS集群datanode节点数大于10，name将会把block分散存储在不同节点上。
进行文件读取时：客户端通过DistributedFileSystem向Namenode发起文件读取RPC请求，通过Namenode验证后获得block最佳节点位置信息；在此会获得能够组成完整文件的各个block所在datanode节点信息，客户端将会并发向这些节点发送文件读取请求。请求的datanode数据多数情况下不会按文件流数据顺序返回每个block，客户端会为文件传输建立一个数据接收窗口，待所有节点的block数据都传输到客户端后进行block文件合并得到完整文件。
对于同一个大文件，大多数情况下其文件读取速率将会比文件写入速率更高。就以上述文件为例，假设磁盘IO速率DIV=128MB/s，不受网络带宽、节点IO吞吐及其他相关限制，在进行文件写入时将会面临至少1280/128=10s的IO时延。而在进行文件读取时由于客户端并发向datanode发送RPC请求，故而理论上能够在blockSize(128MB)/DIV(128MB/s)=1s时延下读取文件，当然单客户机还是会受限于IO及相关性能参数，理论终究还是理论，这是针对于多客户机并发请求设计的。个人认为这是HDFS将文件分块分节点存储的一个非常重要的原因。
HDFS客户端读文件详细图示如下：