CDH Kafka集群和Mrs kafka集群对接同样的业务，但是MRS集群磁盘上存储的文件大小比CDH的大量许多

集群后续需要搬迁，割接期同一个业务对接两套集群，发现旧的CDH Kafka集群和新的Mrs kafka集群节点上存储的文件大小相差了几十倍。

问题处理过程：

一、创建新的消费组分别从头部和尾部进行消费，并查询offset，计算当前存储的消息总数量，对比是否数据量差异导致

1.执行如下语句创建新的consumerGroup，并消费数据【这里不能使用现网使用的consumerGroup】

kafka-verifiable-consumer.sh --broker-list xxx.xx.xx.xx:21007 --topic topicName --group-id consumerGroupName --max-messages 5 --verbose --consumer.config ../config/consumer.properties

2.执行下面语句获取最大的offset

kafka-consumer-groups.sh --reset-offsets --bootstrap-server xxx.xx.xx.xx:21007 --group consumerGroupName --command-config ../config/consumer.properties --topic topicName --to-latest

3.执行下面语句获取最小的offset

kafka-consumer-groups.sh --reset-offsets --bootstrap-server xxx.xx.xx.xx:21007 --group consumerGroupName --command-config ../config/consumer.properties --topic topicName --to-earliest

4.两个NEW-OFFSET相减，得到的就是各分区的消息总条数。两个集群存储的总数据量差异不大也就相差几倍而已

二、怀疑是否因为是数据压缩导致的差异

1.在broker节点，执行如下语句解析日志数据文件，确认两个集群上的数据是否压缩以及压缩格式。

kafka-run-class.sh kafka.tools.DumpLogSegments --files /xxx/xxxxx/kafka-logs/TopicName-1/00000000000000000000.log

如下截图只是个示例

2.查询后发现旧的CDH集群的消息使用gzip进行了压缩，MRS集群的消息没有压缩，故问题原因就在于此。【应该先排查压缩因素】

问题总结：

1.消息压缩可以提高kafka的吞吐量，压缩即空间换时间，通过空间的压缩带来速度的提升，即通过少量的cpu消耗来减少磁盘和网络传输的io。

2.消息何时压缩

在生产者端进行压缩：1）压缩使用的是生产者端的CPU，对生产效率有一定影响；2）对Kafka性能无影响；3）可以减小生产者到Kafka的网络IO。一般使用场景都是此模式。

在Kafka Broker侧压缩：1）Broker需要对消息进行压缩，导致broker所在的节点CPU使用率高；2）Broker侧压缩会导致kafka丧失“零拷贝”（当数据在磁盘和网络进行传输时避免昂贵的内核态数据拷贝，从而实现快速的数据传输），影响Kafka的IO性能；3）生产者到Kafka的网络IO没有减少。一般不建议在Broker侧进行压缩，kafka只负责把数据原封不动的保存；

3.消费者负责消息的解压：消息体中有封装加密算法，消费者接收到消息后可以判断出消息是否压缩，以及使用的什么压缩算法。