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的读写流程了。咱们下篇文章见。

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