Kafka压缩

一、kafka压缩几点说明

首先说明一点kafka的压缩和kafka的compact是不同的,compact就是相同的key只保留一条,是数据清理方式的一种和kafka的定期删除策略是并列的;而kafka的压缩是指数据不删除只是采用压缩算法进行压缩。
kafka从0.7版本就开始支持压缩功能:
1)kafka的发送端将消息按照批量(如果批量设置一条或者很小,可能有相反的效果)的方式进行压缩。
2)服务器端直接将压缩消息保存(特别注意,如果kafka的版本不同,那么就存在broker需要先解压缩再压缩的问题,导致消耗资源过多)。
3)消费端自动解压缩,测试了下,发送端无论采用什么压缩模式,消费端无论设置什么解压模式,都可以自动完成解压缩功能。
4)压缩消息可以和非压缩消息混存,也就是说如果你kafka里面先保存的是非压缩消息,后面改成压缩,不用担心,kafka消费端自动支持。

二、kafka压缩算法种类和性能区别

测试的kafka版本:kafka_2.12-1.1.1
测试的kafka客户端版本:0.10.2.1
测试数据的条数:20000
kafka支持三种压缩算法,lz4、snappy、gzip,

压缩算法 大小 压缩比 生成耗时(毫秒) 消费耗时(毫秒)
None 8.2MB 0 4739 17464
gzip 1.9 MB 23% 4684 16257
snappy 3.2 MB 39% 3936 16726
lz4 2.9 MB 35% 3723 17229

测试遇到疑问,开始非压缩算法发送2万条大小为16MB,后面再发送到gzip的时候大小竟然自动变成了8.2MB,采用的是delete模式,估计可能是日志之类的,snappy也有类似的现象开始是4.0MB,后面log大小缩小为3.2MB,有朋友知道麻烦告知。
我怀疑可能是版本原因导致数据重新被压缩,1.1.1优化的更好,所以压缩效果更好

通过上面数据来看,gzip的压缩效果最好,但是生成耗时更长,snappy和lz4的数据差不多,更倾向于lz4,具huxi大神的书上所说kafka里面对snappy做了硬编码,所以性能上最好的是lz4,推荐使用此压缩算法。

压缩率对比:


图:http://i.stack.imgur.com/LPCSe.png

性能对比图:


网上找来图

压缩设置

很简单:

  /*compressType有四种取值:none lz4 gzip snappy*/
    props.put(ProducerConfig.COMPRESSION_TYPE_CONFIG, compressType);

其他说明

消费端无论设置什么压缩模式,都可以正确的解压kafka的消息,也就是说消费端可以不设置解压缩,
不过可能性能有所下降。

推荐阅读更多精彩内容