《hadoop权威指南》笔记二： hdfs读写过程剖析

本文主要是介绍《hadoop权威指南》笔记二： hdfs读写过程剖析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

基于《hadoop权威指南》第四版。
温故知新

一、hdfs简介

Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。

hdfs的设计如下:

https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html

ps: hdfs只是hadoop文件系统实现的一种，其他还有：

二、hdfs读写分析

剖析hdfs的读写过程，是hdfs数据写入读取性能优化的基础。

1、读取过程

客户端角度

对客户端来说，读取hdfs上的文件就是创建一个fs下的FileSystem对象，并open文件。

hdfs角度

对hdfs而言，详细过程如下：

1、FileSystem对象就是DistributedFileSystem的一个实例。

2、DistributedFileSystem通过rpc调用namenode来获取文件初始块的位置。会根据集群网络拓扑图返回最近的datanode节点（假如客户端本身就是datanode时会直接本地读取数据）

(当客户端并发过多时hdfs是如何解决压力?)

3、DistributedFileSystem类返回一个FSDataInputStream对象(封装了DFSInputStream，可以流式地读取数据)，管理datanode和namenode的I/O

4\5、反复调用read方法，当这个块读完的时候会读取下一个块的最佳datanode。(整队客户端是透明的)

6、读取完成调用close方法，结束读取。

异常情况

正常情况下的读取如上所述，但当客户端与datanode通信异常的时候，就复杂的多：

1、会尝试从这块最相邻的datanode读取数据。

2、同时客户端也会记住这个故障datanode，以保证后面不会反复读取该节点的块。

3、客户端同时会校验数据是否完整，不完整的话从其他节点重新读取，同时将损坏情况上报给namenode

重点:

每个客户端可以直接在datanode上检索数据，且namenode只需告知客户端最佳的datanode。所以数据是不会经过namenode的中转。

目前hadoop并不适合跨IDC部署。

2、写入过程

写入过程相对复杂一些，这里详细记录一下:

客户端角度

与读取过程类似，创建一个fs下的FileSystem对象，create新建一个文件，然后write。

hdfs角度

1、与读取时类似，都要先生成DistributedFileSystem

2、client通过rpc调用namenode的create方法，在命名空间新增一个文件(此时hdfs中还没有实际的数据块)。 namenode会执行检查，保证文件是不存在的以及客户端是有权限创建目录，否则就会抛出IOException异常。

3、步骤2成功后DistributedFileSystem会返回一个FSDataOutputSream对象，此时可以写入数据。

4、FSDataOutputSream会将数据拆分成一个个的数据包，并写入内部的队列。另外一个对象DataStreamer会挑选出合适存储数据副本的一组datanode写入数据。在多副本情况下，第一个datanode收到数据后，它会把数据传送到下一个datanode，依次异步复制。

5、FSDataOutputSream内部也维护了一个确认队列，来等待datanode收到确认回执，然后才会从确认队列删除数据。

6、客户端写完数据后，会调用FSDataOutputSream的close方法，将所有数据写入到datanode的管线。

7、DistributedFileSystem告知namenode客户端已经写完数据，等待确认。namenode知道每个文件的存储节点情况，当成功写入最小的副本数量(dfs.namenode.replication.min配置,默认为1)时，namenode会返回写入成功。

异常情况

当任何datanode在数据写入期间发生故障，则执行以下操作(客户端无感知):

1、关闭写入管线，将队列里面的数据包添加回数据队列的最前端，以保证下游datanode不会漏数据。

2、为存储在另外一个正常datanode的当前数据块指定一个新的标识，并将该标识传递给namenode以保障故障datanode在恢复后可以删除存储的部分数据块。

3、管线中删除故障datanode，剩余正常的datanode构成临时新的管线。而namenode发现副本数据不足时，会再创建一个新的副本。

4、后续数据会继续正常处理。

副本选择

namenode如何选择在哪个datanode存储副本？一般需要权衡:

可靠性
写入带宽
读取带宽

同机架服务器之间的读取带宽是非常高的，跨数据中心虽然可以增加数据冗余和可靠性，但带宽消耗极大。

hadoop默认的策略下，同一份数据不同副本尽可能避免落到一个机架上面，这样达到冗余与性能的权衡。

三、数据一致性问题

hdfs并不严格满足POSIX

hdfs为了性能，牺牲了一些POSIX的要求。新建一个文件时，它能在文件系统中立即可见，如:

Path p = new Path("p");
Fs.create(p);
assertThat(fs.exists(p),is(true));

但是写入的内容并不能保证立即可见，即使数据流已经刷新并存储

OutputStream out = fs.create(p);
out.write("content".getBytes("UTF-8"));
out.flush();
assertThat(fs.getFileStatus(p).getLen(),is(0L));

当数据写入超过一个块之后，第一块数据对新的reader是可见的，但当前写入的块对其他reader不可见。

hflush()与hsync()

FSDataOutputStream提供了hflush()方法，强行将所有的缓存刷新到datanode中，当hflush()返回成功，则所有新的reader可见。

FSDataOutputStream out = fs.create(p);
out.write("content".getBytes("UTF-8"));
out.hflush();
assertThat(fs.getFileStatus(p).getLen(),is(((long)"content".length())));

但是hflush不保证datanode已经将数据写入到磁盘(数据仅在内存中)，为了确保数据写入到磁盘中，我们还可以使用hsync()替代(类似POSIX的fsync())。

当然 hflush()与hsync() 都是会带来更大开销，需要我们不断测试度量不同频率下调用时的性能，来选择一个最终合适的调用频率。

注意:Hadoop 1.x中hflush()被称为sync、hsync()不存在!

四、其他问题

1、put与copyFromLocal的区别

http://stackoverflow.com/questions/7811284/difference-between-hadoop-fs-put-and-hadoop-fs-copyfromlocal

在Hadoop 2.7.2版本测试发现确实无区别，但是3.X新版本有修改，增加了一个线程池并发拷贝的功能

https://github.com/apache/hadoop/blob/7a3188d054481b9bd563e337901e93476303ce7f/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/shell/CopyCommands.java