API 文档

数据压缩

最近更新时间:2022-01-20 17:56:38

操作场景

数据压缩可以减少网络 IO 传输量,减少磁盘存储空间。您可以通过本文档,了解数据压缩支持的消息格式,并根据需求配置数据压缩。

消息格式

目前 Kafka 支持两类消息格式,分别为V1版本和V2版本(在0.11.0.0引入)。目前 CKafka 支持0.9、0.10、1.1、2.4和2.8版本。

不同版本对应不同的配置,说明如下:

  • 消息格式转换主要是为了兼容老版本的消费者程序,在一个 Kafka 集群中通常同时保存多种版本的消息格式(V1/V2)。
  • Broker 端会对新版本消息执行向老版本格式的转换,该过程中会涉及消息的解压缩和重新压缩。
  • 消息格式转换对性能的影响很大,除了增加额外的压缩和解压缩操作之外,还会让 Kafka 丧失其优秀的 Zero Copy 特性。因此,一定要保证消息格式的统一
  • Zero Copy:数据在磁盘和网络进行传输时,避免昂贵的内核态数据拷贝,从而实现快速的数据传输。

压缩算法对比

官方推荐使用的压缩算法为 Snappy 算法。分析过程如下:

评估一个压缩算法的优劣,主要有两个指标:压缩比、压缩/解压缩吞吐量。
Kafka 2.1.0之前的版本支持三种压缩算法:GZIP、Snappy、LZ4。
在 Kafka 的实际使用中,三种算法的性能指标对比如下:

  • 压缩比:LZ4 > GZIP > Snappy
  • 吞吐量:LZ4 > Snappy > GZIP

物理资源占用如下:

  • 带宽:由于 Snappy 的压缩比最低,因此占用的网络带宽最大。
  • CPU:各个压缩算法差不多,在压缩时 Snappy 使用更多的 CPU,在解压缩时 GZIP 使用更多的 CPU。

因此,正常情况下三种压缩算法的推荐排序为:LZ4 > GZIP > Snappy。
经过长时间的现网运行试验,发现在大多数情况下上面的模型是没问题的。但是在某些极端情况下 LZ4 压缩算法会导致 CPU 负载增大。
经分析是业务的源数据内容不一样,导致压缩算法的性能表现不一样。 故建议对 CPU 指标敏感的用户采用更为稳定的 Snappy 压缩算法。

配置数据压缩

生产者可通过下述方法配置数据压缩:

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");

// Producer 启动后,生产的每个消息集合都会经过压缩,能够很好地节省网络传输带宽和 Kafka Broker 端的磁盘占用

// 请注意不同版本对应不同的配置,0.9及以下版本不允许使用压缩。0.10及以上版本不允许使用 GZip 压缩。

props.put("compression.type", " lz4 ");
Producer<String, String> producer = new KafkaProducer<>(props);

大部分情况下,Broker 从 Producer 接收到消息后,仅仅只是原封不动地保存,而不会对其进行任何修改

说明与注意

  • 发送数据到 Ckafka,不能设置压缩 compression.codec。
  • CKafka 不支持 Gzip 压缩格式。
    Gzip 压缩对于 CPU 的消耗较高,使用 Gzip 会导致所有的消息都是 InValid 消息。
  • 使用 LZ4 压缩方法时,程序不能正常运行,可能的原因如下:
    消息格式错误。CKafka 默认版本为0.10.2,您需要使用 V1 版本的消息格式。
  • 不同 Kafka Client 的 SDK 设置方式不同,您可以通过开源社区进行查询(例如 C/C++ Client 的说明),设置消息格式的版本。
目录