本文主要是介绍《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
2、Ozone
Hadoop 社区推出了新的分布式存储系统-Ozone。Ozone能够轻松管理小文件和大文件，是一个分布式Key-value 对象存储系统。值得关注！
这篇关于《hadoop权威指南》笔记二： hdfs读写过程剖析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
