HDFS——写文件流程

原创
2021/08/06 23:19
阅读数 1.7K

上篇文章讲了数据传输的格式,本文就来说说hdfs中写文件的流程。


hdfs客户端写文件的流程,大体可以分为两个步骤:第一步是创建或打开文件,第二步是进行block的写操作。


block的写操作具体又包括向NN请求添加一个新的block,然后根据NN的返回结果,与对应的DN建立连接,并进行数据的发送


当一个block写完时,再次向NN请求添加新的block,同样根据返回结果与对应的DN建立连接并发送数据,之后不断重复这个过程,直到文件内容全部写完。


下图以创建文件为例,展开描述详细流程:



  1. 向NN发送创建文件请求

    首先,客户端向NN发送创建文件的请求,在请求中指明文件的位置,文件的权限,文件的block副本数,block大小等。

    NN收到请求后,进行有效性检查,以及相应的鉴权动作,然后将操作写入editlog,最后给客户端应答。

  2. 向NN发送添加block请求

    文件创建成功后,对于业务层的代码来说就是直接进行write写数据了,但在客户端的底层实现中,会先向NN发送一个新增block的请求。

    NN收到请求后,主要执行一系列的分配算法(涉及就近分配,按存储策略分配,按机架感知策略分配,DN的数据均衡等因素,这里不展开说明),按照block所属文件的副本数,为block分配一组DN,并将结果返回给客户端。

  3. 向DN建立连接并发送写block请求

    客户端从新增block的请求结果中拿到DN节点列表后,向列表的第一个DN建立tcp连接,并发送block写操作请求(OpWriteBlock)。在请求中,包含了block的checksum信息,DN列表,block描述等信息。

    DN感知有新的tcp连接建立后,会创建线程(DataXceiver)用于接收连接上的数据。当接收到客户端block写操作请求后,从请求中拿到DN列表,并向列表中的第二个DN建立tcp连接,同时转发block写操作请求请求中的DN列表剔除本节点),后续的DN接收到新连接后,进行同样的操作,直到DN列表中的最后一个节点。

    当DN发现接收到的block写操作请求中DN列表为空时,会标记本节点为最后一个节点。此时,该节点不需要再下下游DN节点转发请求,从而创建用于发送packet数据包请求响应的packet responder线程,然后向上游DN节点回复block写操作请求的ack响应。

    上游的DN收到block写操作请求的响应后,继续向该节点的上游DN节点转发请求响应,同样,内部也会创建用于发送packet数据包请求响应的packet responder线程。

    这样,DN与DN之间形成一个流水线,后续的packet包数据会在DN之间依次传递。

    这里一点需要注意:对于一个block的写操作,DN内部实际上是创建了两个线程这两个线程属于同一个线程组。线程组中的线程总数是可配置的,当线程数到达配置的上限后,不会再创建新的线程,此时与该节点数据传输的tcp连接是无法成功建立的。

  4. packet数据的发送

    当客户端接收到block写操作请求的应答后,意味着所有的DN均已准备就绪。此后,客户端按packet格式组织数据,并依次发送给DN。


    DN接收到一个完整packet后,先转发给下游DN然后将packet中的数据按chunk大小进行checksum校验,校验无误后将packet中的数据写入本地文件,最后通过内部的队列向packet responder线程发送该packet的ack应答

    packet responder线程从队列中取出packet的应答消息后,阻塞等待下游DN的packet的应答消息,当接收到下游DN的packet应答消息后,才真正向客户端回复packet的应答消息。

    由此可见,只要客户端收到了packet的应答消息,就意味着该packet一定是在所有副本节点上都成功接收了,这样可以保证数据的一致性。

  5. 结束block

    当客户端发送的数据达到block的大小时,客户端底层实现会自动结束该block。

    具体是向NN请求更新block的信息,NN收到请求后,会检查该block的状态,为该block更新时间戳,最后将操作记录写入editlog,并给客户端应答。

    客户端收到应答后,继续向NN发送complete请求,到此,一个block的写流程全部结束。

  6. 重复步骤2-5写新的block直到文件写完

    如果此时,文件内容还没有写完,客户端会继续重复步骤2到5,继续一个新的block写流程,直到文件写完。

    注意:这里没有文件的关闭动作,当一个block写完,不再申请新的block,逻辑上就意味着该文件已经完成写流程。


总的流程捋清楚了后,我们来推敲一些细节。


  • packet是同步发送还是异步发送?

从上面的流程描述,并不能直观的说明客户端packet发送是采用同步还是异步方式。


也就是说客户端发送完一个packet后,是否必须等接收到该packet的应答包后才发送下一个packet?


答案显然是否定的,因为这样会极大的降低吞吐量,客户端发送完一个packet后,不需要等待DN的应答,就可以继续发送下一个packet。packet发送后,将该packet放到等待应答的队列中,等待DN的应答。


注:每个packet都会有对应的应答包。并且由于每个packet都有各自的包序号,packet的发送也是按序号递增的,因此如果接收到的应答包不是按递增序号来的,客户端通常会报错。


  • 客户端侧的packet缓存问题

虽然客户端可以不用等DN的应答就可以继续发送packet,但由于发送的包没有被确认,因此,客户端通常都会在内部将这些packet进行缓存,以便异常时可以告知上层哪些packet被应答了,哪些没有被应答,方便业务进行重试。


那么问题来了,这个缓存大小是多少呢?缓存满了又会这样呢?


这个问题,对于不同的客户端实现有不同的处理。


例如原生java客户端内部,将待发送的packet会放到一个队列中,发送线程从队列中取出packet进行发送,发送成功后将packet放到待确认队列中。另外一个线程接收DN的响应后,从待确认队列中将packet取出并删除。

两个队列的长度累计达到一定数量后,write操作将被阻塞


而对于go客户端,逻辑上大同小异,以发送的packet写入管道,管道的最大长度为5,即当有5个packet未被DN确认时,成功发送的packet写管道将被阻塞,进而阻塞业务的write接口。


  • packet包何时刷到磁盘中

DN接收到完整的packet包后,先转发到下游DN,然后写入本地文件。这个写文件本质上只是写到了文件系统的缓存中,并没有执行sync/flush将数据刷到磁盘上。


那么什么时候,会将数据刷到磁盘中呢?


DN默认的策略是依赖操作系统自身的机制,而不去主动触发调用进行刷盘的动作。这么做的原因是刷盘耗时相对比较长,从而会影响性能,而数据通常都是有3副本的,即便是该节点突然出现了断电,数据在其他节点上还有副本。


因此,综合性能和数据可靠性的考虑,完全依赖操作系统自身的机制还是可以保证数据不会丢失的。


当然,我们可以通过配置项dfs.datanode.synconclose设置为true,这样,当DN接收到block的最后一个packet后,会触发进行一次刷盘的动作。


除此之外,客户端在打开文件时,也可以设置SYNC_BLOCK标识,可以达到同样的效果。


【总结】


本文先讲述了hdfs的写文件流程,以及流程中的一些细节。当然,整个写流程中,可挖掘的细节还有很多,这里不逐一展开说明,后续如有遇到问题,再进行对应的总结说明。


好了,本文就介绍到这里,原创不易,点赞,在看,分享是最好的支持, 谢谢~


本文分享自微信公众号 - hncscwc(gh_383bc7486c1a)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
0
分享
返回顶部
顶部