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

网友投稿 812 2022-05-28

集群后续需要搬迁,割接期同一个业务对接两套集群,发现旧的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

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

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.消费者负责消息的解压:消息体中有封装加密算法,消费者接收到消息后可以判断出消息是否压缩,以及使用的什么压缩算法。

Kafka MapReduce

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:UAV心跳机制与容器、进程数据采集
下一篇:学会针对永洪API接口的性能测试,工作效率提升百倍
相关文章