学习Hadoop写文件的流程时,看《Hadoop权威指南》中文版,在datenode发生故障时的处理那里,真的是看不懂。于是找来英文原版进行翻阅,终于有种看明白的感觉了。不过,由于没有看过源码,只能按照书上的内容和自己的理解来讲一下。
在具体说datenode发生故障时的处理过程之前,我们要回顾一下整个Hadoop写文件的流程。
![5679451-0b126f9815846713.png](https://i-blog.csdnimg.cn/blog_migrate/a20700b060e0a3d5768a3650cd376fe8.png)
首先客户端通过DistributedFileSystem对象调用create()函数来新建文件(步骤一)。DistributedFIleSystem对namenode创建一个RPC调用,在文件系统的命名空间创建一个文件,此时该文件中还没有相应的数据块(步骤二)。namenode执行各种不同的检查一确保这个文件不存在以及客户端有新建该文件的权限。如果这些检查均通过,namenode就会为创建新文件记录一条记录;否则,文件创建失败并向客户端抛出一个IOException异常。DistributedFileSystem向客户端返回一个FSDataOutputStream对象,客户端可以用FSDataOutputStream对象开始写入数据。就像读取事件一样,FSDataOutputStream封装一个DFSoutputstream对象,该对象负责处理datanode和namenode之间的通信。
在客户端写入数据时(步骤三),DFSOutputStream将数据分成一个个的数据包(packet),并写入一个内部队列,这个队列称为"数据队列”(data queue)。DataStreamer处理数据队列,它先询问namenode这个新的block最适合存储的在哪几个datanode里(比如重复数是3,那么就找到3个最适合的 datanode),把他们排成一个pipeline。DataStreamer把packet按队列输出到管道的第一个datanode中,第一个 datanode又把packet输出到第二个datanode中,以此类推。(步骤四)
DFSOutputStream还有一个队列叫ack queue,也是由packet组成,等待datanode的收到响应,当pipeline中的所有datanode都表示已经收到的时候,这时akc queue才会把对应的packet包移除掉。(步骤五)
本文重点来了:
如果在数据写入期间datanode发生故障,则执行以下操作(对写入的数据的客户端是透明的)。首先关闭管道,然后将确认队列(ack queue)中的数据包都添加回数据队列(data queue)的最前端,以确保故障节点下游的datanode不会漏掉任何一个数据包。为存储在正常的datanode上的数据块指定一个新的标识,并将该标识传递给namenode,以便故障datanode在恢复后可以删除存储的部分数据块。从管线(pipeline)中删除故障数据节点并把使用剩下的正常的datanode构建一个新的管线(pipeline)。余下的数据块写入新的管线中。namenode注意到块副本量不足时,会在另一个节点上创建一个新的复本,后续的数据块继续正常接受处理。这里接受正常处理的意思,我的理解是:因为namenode 发现副本数小于我们配置的数目,从新找一个datanode,然后把副本数不足的数据块都复制到新的datanode上,处理完这些数据块后,后面的新数据块就可以又按照管线(pipeline)的方式去处理了。
在一个块被写入期间可能会有多个datanode同时发生故障,但非常少见。只要写入了dfs.replication.min的副本书(默认为一),写入操作就会成功,并且这个块可以在集群中异步复制,直到达到其目标复本数(默认三个复本)
客户端完成数据的写入后,对数据流调用close()方法(步骤六),该操作将剩余的所有数据包写入datanode管线,并在联系到namenode告知其文件写入完成之前,等待确认(步骤7)namenode已经知道文件后那些块组成(因为之前datastreamer请求分配数据块)。
最后附上英文原版(Hadoop 权威指南第四版)的介绍:
![5679451-f3a6fa15d99d17e6.png](https://i-blog.csdnimg.cn/blog_migrate/3d5d01bf8aed3b1aa01f4c53bf63c9f7.png)