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

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/u013128262/article/details/100593915

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

一、hdfs简介

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

hdfs的设计如下:

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

image.png

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

image.png

二、hdfs读写分析

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

1、读取过程

image.png

客户端角度

对客户端来说,读取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、写入过程

image.png

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

客户端角度

与读取过程类似,创建一个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 对象存储系统。值得关注!

展开阅读全文

没有更多推荐了,返回首页