HDFS写入和读取流程

Posted on feb. 2 2014

HDFS写入和读取流程

您还未登录！|登录|注册|帮助

guisu，程序人生。

能干的人解决问题。智慧的人绕开问题(A clever person solves a problem. A wise person avoids it)

HDFS写入和读取流程

分类：云计算hadoop 2012-02-14 23:50 8282人阅读评论(17) 收藏举报存储 hadoop image system mysql

目录(?)[+]

HDFS全称是Hadoop Distributed System。HDFS是为以流的方式存取大文件而设计的。适用于几百MB，GB以及TB，并写一次读多次的场合。而对于低延时数据访问、大量小文件、同时写和任意的文件修改，则并不是十分适合。

目前HDFS支持的使用接口除了Java的还有，Thrift、C、FUSE、WebDAV、HTTP等。HDFS是以block-sized chunk组织其文件内容的，默认的block大小为64MB，对于不足64MB的文件，其会占用一个block，但实际上不用占用实际硬盘上的64MB，这可以说是HDFS是在文件系统之上架设的一个中间层。之所以将默认的block大小设置为64MB这么大，是因为block-sized对于文件定位很有帮助，同时大文件更使传输的时间远大于文件寻找的时间，这样可以最大化地减少文件定位的时间在整个文件获取总时间中的比例。

二、HDFS的体系结构

构成HDFS主要是Namenode（master）和一系列的Datanode（workers）。Namenode是管理HDFS的目录树和相关的文件元数据，这些信息是以"namespace image"和"edit log"两个文件形式存放在本地磁盘，但是这些文件是在HDFS每次重启的时候重新构造出来的。Datanode则是存取文件实际内容的节点，Datanodes会定时地将block的列表汇报给Namenode。

由于Namenode是元数据存放的节点，如果Namenode挂了那么HDFS就没法正常运行，因此一般使用将元数据持久存储在本地或远程的机器上，或者使用secondary namenode来定期同步Namenode的元数据信息，secondary namenode有点类似于MySQL的Master/Salves中的Slave，"edit log"就类似"bin log"。如果Namenode出现了故障，一般会将原Namenode中持久化的元数据拷贝到secondary namenode中，使secondary namenode作为新的Namenode运行起来。

                        ![]()

三、读写流程

GFS论文提到的文件读取简单流程：

**

详细流程：

文件读取的过程如下：

使用HDFS提供的客户端开发库Client，向远程的Namenode发起RPC请求；
Namenode会视情况返回文件的部分或者全部block列表，对于每个block，Namenode都会返回有该block拷贝的DataNode地址；
客户端开发库Client会选取离客户端最接近的DataNode来读取block；如果客户端本身就是DataNode,那么将从本地直接获取数据.
读取完当前block的数据后，关闭与当前的DataNode连接，并为读取下一个block寻找最佳的DataNode；
当读完列表的block后，且文件读取还没有结束，客户端开发库会继续向Namenode获取下一批的block列表。
读取完一个block都会进行checksum验证，如果读取datanode时出现错误，客户端会通知Namenode，然后再从下一个拥有该block拷贝的datanode继续读。

GFS论文提到的写入文件简单流程：

                                 ![]()

详细流程：

写入文件的过程比读取较为复杂：

使用HDFS提供的客户端开发库Client，向远程的Namenode发起RPC请求；
Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异常；
当客户端开始写入文件的时候，开发库会将文件切分成多个packets，并在内部以数据队列"data queue"的形式管理这些packets，并向Namenode申请新的blocks，获取用来存储replicas的合适的datanodes列表，列表的大小根据在Namenode中对replication的设置而定。
开始以pipeline（管道）的形式将packet写入所有的replicas中。开发库把packet以流的方式写入第一个datanode，该datanode把该packet存储之后，再将其传递给在此pipeline中的下一个datanode，直到最后一个datanode，这种写数据的方式呈流水线的形式。
最后一个datanode成功存储之后会返回一个ack packet，在pipeline里传递至客户端，在客户端的开发库内部维护着"ack queue"，成功收到datanode返回的ack packet后会从"ack queue"移除相应的packet。
如果传输过程中，有某个datanode出现了故障，那么当前的pipeline会被关闭，出现故障的datanode会从当前的pipeline中移除，剩余的block会继续剩下的datanode中继续以pipeline的形式传输，同时Namenode会分配一个新的datanode，保持replicas设定的数量。

分享到：

上一篇：Hadoop Hive sql语法详解
下一篇：Hadoop HDFS分布式文件系统设计要点与架构

顶 3 踩 1 查看评论

3楼 huangbo1988911 2012-04-09 11:25发表 [回复] [引用] [举报]在写数据的过程中，一个文件被分割成很多blocks，这些block是按顺序一个个操作的，还是并发的进行传输的？Re: 真实的归宿 2012-04-09 12:45发表 [回复] [引用] [举报]回复huangbo1988911：写数据的是以流的方式传输，即管道的方式，一个一个block顺序传输。而不是像树形拓扑结构那样分散传输。Re: huangbo1988911 2012-04-17 18:03发表 [回复] [引用] [举报]回复hguisu：您好，很感谢您回答我，但是我仍有点疑惑，hdfs中的文件大小区分为：chunk<packet<block,在每个packet的传输到多个DN（datanode）的过程中是以pipeline方式，但是当其中一个block在以这种方式传输时，其他的block是要等待还是并发的进行呢？谢谢！Re: 真实的归宿 2012-04-20 16:23发表 [回复] [引用] [举报]回复huangbo1988911：管道方式，即是队列方式传输。只能一个block传完了，接着传下个block。Re: huangbo1988911 2012-04-30 18:18发表 [回复] [引用] [举报]回复hguisu：你好！如果这样，那hdfs的并发写实如何体现的呢？Re: 真实的归宿 2012-05-02 09:29发表 [回复] [引用] [举报]回复huangbo1988911：hdfs没有并发写入。Re: huangbo1988911 2012-05-03 23:39发表 [回复] [引用] [举报]回复hguisu：这样的话，那hadoop是比较适合大数据的处理了，对于文件的写的速度并没有多大的提高了?Re: 真实的归宿 2012-05-04 09:40发表 [回复] [引用] [举报]回复huangbo1988911：hadoop本来就是通往云服务的捷径，为处理超大数据集而准备。Re: huangbo1988911 2012-05-07 10:57发表 [回复] [引用] [举报]回复hguisu：这样hadoop的主要优势是在map/reduce那一块，而其文件系统有什么样的优势呢（在文件的读写方面，和其他的文件系统）？Re: 真实的归宿 2012-05-07 11:50发表 [回复] [引用] [举报]回复huangbo1988911：hdfs可以存储超大数据，而map/reduce要处理的数据存储在hdfs上，即MR分布式运算。Re: huangbo1988911 2012-05-09 22:35发表 [回复] [引用] [举报]回复hguisu：那多个文件同时向hdfs写入是如何进行的呢？Re: huangbo1988911 2012-05-09 00:39发表 [回复] [引用] [举报]回复hguisu：恩，hdfs相对于其他的文件系统，除了更适合存储大数据以外，而且有很强的容错能力，但是对数据的读写等，没有并发性，只是采用了管道的方式，这可能是它的一个小缺点吧。2楼 CD_xiaoxin 2012-03-19 09:44发表 [回复] [引用] [举报]很详细很有帮助谢谢1楼 lin_FS 2012-03-16 10:01发表 [回复] [引用] [举报]client端的那个queue是在内存中，还是写在临时文件里了？Re: 真实的归宿 2012-03-19 09:43发表 [回复] [引用] [举报]回复lin_FS：client分割数据成一个个block（packet）这些数据都不在内存中，你可以想象，如果一个数据是100G，它你那个放进内存吗？Re: lin_FS 2012-03-21 17:26发表 [回复] [引用] [举报]在client端，多个block（packet）组成一个队列，然后可以想象把文件（100G）分成若干个packet，如果队列满了就根本写不进去数据了，根本不会出现你想象的那种情况。我想了解的是，这个队列在内存中还是以文件的形式，呵呵Re: 真实的归宿 2012-03-31 18:47发表 [回复] [引用] [举报]回复lin_FS：这个队列肯定是文件的形式存在的。您还没有登录,请[登录]或[注册]