HDFS——读写文件的数据传输格式

原创
2021/08/04 00:07
阅读数 3K

hdfs中很重要的一个流程就是数据的读写,但在此之前,需要先了解数据是如何传输的,数据包的具体的传输格式是怎样的,本文就此进行总结说明。


【数据包格式】


了解客户端写hdfs是如何组织数据的,需要先了解三个概念:block,packet,chunk。


  • block

这个大家应该比较熟悉,hdfs中的文件就是由一个或多个block组成的,block的大小是可以配置的,默认是128MB。


  • chunk

客户端与datanode的数据传输中进行数据checksum计算的大小。该大小可以配置,默认是512字节。


也就是说,传输数据中,每512个字节进行一次checksum计算,并生成4字节长度的checksum。因此,chunk最大长度为512字节(为什么说最大长度是512字节,因为可能存在最后一个chunk数据长度不足512字节的情况,也会当做一个完整的chunk进行发送)


  • packet

介于chunk和block之间的一个单位,也是数据传输的基本单元,即客户端每次是按照一个packet进行数据发送的。


packet有固定的格式,如下图所示:



首先是4字节的packet长度(PLen);然后是2字节的packet header长度(HLen);接着是packet header,长度由HLen指定,再接下来是checksum列表和chunk数据列表。chunk和checksum一一对应,即有多少个chunk就有多少个checksum


packet header是按照protobuf进行编码传输的,主要包括这么几个字段:

message PacketHeaderProto {  // All fields must be fixed-length  required sfixed64 offsetInBlock = 1;  required sfixed64 seqno = 2;  required bool lastPacketInBlock = 3;  required sfixed32 dataLen = 4;  optional bool syncBlock = 5 [default = false];}


  • offsetInBlock

    数据在block中的偏移位置

  • seqno

    packet包的序号

  • lastPacketInBlock

    是否是block中的最后一个packet

  • dataLen

    数据长度

  • sycnBlock

    指示该block是否需要datanode写完后执行sync动作,将数据刷到磁盘中


以上是一个正常数据包的格式说明。


如果客户端不是连续写入,客户端会有心跳保活机制,也就是定时向datanode发送心跳包。


心跳包的组织也是按照packet方式进行的,区别在于packet header中的几个字段的值是固定的。例如:offsetInBlock为0,seqno为-1;并且packet中没有checksum和chunk数据列表。


在写完一个block时(可能是一个block写满128MB,也可能还未达到128MB,但文件已经写完,需要关闭文件),此时,客户端会构造一个没有chunk数据的packet,同时通过packet header的lastPacketInBlock中设置为true,告知datanode,该block已经写完,准备进行相应的结束动作。这就是所谓的空数据包。


通常请求和响应都是成对的。因此,有请求数据包,自然就有对数据包应答的ack包。


ack包形式比较简单,就是一个protobuf的编码数据,原始信息为:

message PipelineAckProto {  required sint64 seqno = 1;  repeated Status reply = 2;  optional uint64 downstreamAckTimeNanos = 3 [default = 0];  repeated uint32 flag = 4 [packed=true];}


【抓包分析】


正常数据包:


结合前面的描述,可以清楚的了解到packet数据包的组成格式。


【其他组织形式】


考虑一种情况:客户端打开文件,第一次写入了300字节,然后关闭文件。接着重新append打开文件,追加写入300字节。


对于第二次的写入,按照上面的分析,理论上,客户端的数据应当是组成一个packet,其中chunk大小为300字节,发送给datanode。


然而通过抓包分析,第二次发送的300字节数据,却划分成两个packet进行了发送。


第一个packet,包含一个chunk,chunk的大小为212字节,剩余的88字节作为一个chunk,放到第二个packet中发送。



为什么会这样呢?


其主要原因是:在datanode中,对存储的数据都尽量按照完整的chunk大小进行checksum计算和存储,只有block的最后一个数据按照实际大小进行checksum和存储。


也就是说对于append操作,datanode将接收到的数据,先进行补齐操作,然后重新按照一个完整的chunk大小进行checksum计算,并覆盖原有的checksum,然后保存到文件中。


因此,出于效率的考虑,这个真正的补齐动作在客户端进行,而不是在datanode中,即客户端append打开文件后,先获取追加写入的偏移位置,计算出应该补齐的chunk数据长度,并以该长度构造对应的packet进行发送,后续的数据则继续按原有的逻辑组织chunk,packet进行发送。


这样在datanode在处理客户端发送的packet时,不需要额外再对数据进行切割补齐,大大减少了相应的处理逻辑。


【总结】


本文对hdfs数据传输的格式进行了详细说明。实际上,客户端服务端对数据也是按照packet,chunk形式组织,并构造逻辑的缓存区域,来进行数据的发送和接收。有了这个基础,接下里就可以深入分析hdfs的读写流程了。咱们下篇文章见。


原创不易,点赞,在看,分享是最好的支持, 谢谢~


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

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