Kafka 生产者压缩算法有哪些？

前言

本文隶属于专栏《大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见大数据技术体系

---

关联

数据压缩算法该如何选择？

---

WHY 压缩？

数据压缩显著地降低了磁盘占用或带宽占用，从而有效地提升了 I/O 密集型应用的性能。

不过引入压缩同时会消耗额外的 CPU 时钟周期，因此压缩是 I/O 性能和 CPU 资源的平衡。

---

producer 压缩，broker 压缩，consumer 解压

Kafka 自 0.7.x 版本便开始支持压缩特性，producer 端能够将一批消息压缩成一条消息发送，而 broker 端将这条压缩消息写入本地日志文件。

当 consumer 获取到这条压缩消息时，它会自动地对消息进行解压缩，还原成初始的消息集合返还给用户。

如果使用一句话来总结 Kafka 压缩特性的话，那么就是一producer 压缩，broker 压缩，consumer 解压。

所谓的 broker 端保持是指 broker 端在通常情况下不会进行解压缩操作，它只是原样保存消息而已。

这里的“通常情况下”表示要满足一定的条件。

如果有些前置条件不满足（比如需要进行消息格式的转换等)，那么 broker 端就需要对消息进行解压缩然后再重新压缩。

---

Kafka支持的压缩算法

在 Kafka 2.1.0 版本之前，Kafka 支持 3 种压缩算法：GZIP、Snappy 和 LZ4。

从 2.1.0 开始，Kafka 正式支持 Zstandard 算法（简写为 zstd）。它是 Facebook 开源的一个压缩算法，能够提供超高的压缩比（compression ratio）。

---

compression.type

指定给定主题的最终压缩类型。

此配置接受标准压缩编解码器（gzip、snappy、lz4、zstd）。

它还接受uncompressed，这相当于没有压缩；

和producer，即保留 producer 设置的原始压缩编解码器。

类型：字符串
默认值： producer
重要性： 高
更新模式： 集群范围

---

假定要设置使用 gzip 压缩算法，则设置方法如下：

 Properties props = new Properties();
 props.put("bootstrap.servers", "localhost:9092");
 props.put("acks", "all");
 props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
 props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
 // 开启GZIP压缩
 props.put("compression.type", "gzip");
 
 Producer<String, String> producer = new KafkaProducer<>(props);

这里比较关键的代码行是 props.put(“compression.type”, “gzip”)，它表明该 Producer 的压缩算法使用的是 GZIP。

这样 Producer 启动后生产的每个消息集合都是经 GZIP 压缩过的，故而能很好地节省网络传输带宽以及 Kafka Broker 端的磁盘占用。

---

算法性能比较与调优

对 Kafka 源代码熟悉的读者会发现 KafkaProducer.send 方法逻辑的主要耗时都在消息压缩操作上，因此妥善地调优压缩算法至关重要。

不过在此之前，首先比较一下目前 Kafka 支持的压缩算法的性能。

看一个压缩算法的优劣，有两个重要的指标：一个指标是压缩比，原先占 100 份空间的东西经压缩之后变成了占 20 份空间，那么压缩比就是 5，显然压缩比越高越好；另一个指标就是压缩 / 解压缩吞吐量，比如每秒能压缩或解压缩多少 MB 的数据。同样地，吞吐量也是越高越好。

下面这张表是 Facebook Zstandard 官网提供的一份压缩算法 benchmark 比较结果：

在实际使用中，GZIP、Snappy、LZ4 甚至是 zstd 的表现各有千秋。

但对于 Kafka 而言，它们的性能测试结果却出奇得一致，即：

• 在吞吐量方面：LZ4 > Snappy > zstd > GZIP；
• 而在压缩比方面，zstd > LZ4 > GZIP > Snappy。
• 具体到物理资源，使用 Snappy 算法占用的网络带宽最多，zstd 最少，这是合理的，毕竟 zstd 就是要提供超高的压缩比；
• 在 CPU 使用率方面，各个算法表现得差不多，只是在压缩时 Snappy 算法使用的 CPU 较多一些，而在解压缩时 GZIP 算法则可能使用更多的 CPU。