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源创计划”,欢迎正在阅读的你也加入,一起分享。