0.9版本
1、消息集Message set
一个消息集中包含一条或多条消息,消息集不仅是存储在磁盘及网络传输的基本形式,而且是kafka压缩的基本单元。
2、消息Recode
一个recode是由多个key-value键值对组成,以下介绍各个key的含义。
CRC32,大小4B。CRC校验值,校验范围为magic到value之间。
magic,大小1B。 消息格式版本号。
attributes,大小1B。 消息类型,最低三位为压缩类型。0 无 1 gzip 2 snappy 3 lz4。
key length,大小4B。 key的长度,为-1表示没有设置key。
key,可选。没有设置key就没有该字段。
value length,大小4B。 value的长度,为-1表示没有设置消息。
value,可选。 这是消息体。
3、日志头部log_overheader
每一个recode都有一个日志头部包含offset和message size两个字段。
offset,大小8B。 记录消息在partition中的偏移量。
message size,大小4B。 表示消息的总大小。
4、最小长度
当没有设置key和value时,recode长度最小,为4B+1B+1B+4B+4B=14B。日志头部为8B+4B=12B。
所以消息总大小和.log文件大小为14B+12B=26B。
2、0.10
1、对比
对比0.9版本,新增了一个timestamp字段,大小8B。
且attributes字段第四位启用,标记为时间戳类型。0为CreateTime类型,1为LogAppendTime类型。
2、最小长度
当没有设置key和value时,recode长度最小,为4B+1B+8B+1B+4B+4B=22B。
日志头部为8B+4B=12B。所以消息总大小为22B+12B=34B。
0.11版本
1、版本变化
对于key length和value length这样记录长度的字段,以int类型保存需要4个字节。
在0.11中引入了变长整型(varint&varlong)和zigzag编码,以此来节约存储空间。
记录长度字段的数值和占用字节的关系:[0,63]占用1B [64,8191]占用2B [8192,108575]占用3B。
2、消息集Recode Batch
一个recode batch包含一条或多条消息。
每个消息集都分为header和recodes两部分。压缩时只压缩recodes不压缩header。
recodes部分则包含一条或多条recode记录。
header包含了所有recode的最大最小时间戳、offset、recode个数等信息,共占用61B空间。
2、消息Recode
一个recode是由多个key-value键值对组成,以下介绍各个key的含义。
length varint 。记录本recode的长度。
attributes 1B 。 保留字段,暂时没用。
timestamp delta varlong 。 保存此recode的时间戳与header中最小时间戳的差值。
offset delta varint。 保存此recode的offset与header中最小offset的差值。
key length varint。 没有设置key则为0,占用1B。
key,可选。没有设置key就没有该字段。
value length varint。 没有设置key则为0,占用1B。
value,可选。 这是消息体。
headers count varint 。 记录本recode中headers的数量。没有则为0,占用1B。
headers,可选。
可以有多个。以前很多应用级别的设置要嵌在消息体中,现在设置在headers中即可。
有四个字段。header key\header value\header key length\header value length。
长度都是varint类型。header key是utf8类型。
3、最小长度
当key value都为null,且recode中未设置header,则recode达到理论最小长度:7个变长整形字段,即7B。
则该消息的最小长度:61B+7B=68B.
当一个消息集中含有的recode数较少时,由于消息集的header占用61B,
所以0.11版本可能会占用更大的存储。当消息集中recode数较多时,则节省空间较为明显。
4、各版本对比
eg. 假设一个消息集中含100个key value都为空的消息时,占用大小对比。
0.9版本: 26B*10=260B.
0.10版本:34B*10=340B.
0.11版本:61B+7B*10=131B.