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的消息，也就是说消费端可以不设置解压缩，
不过可能性能有所下降。