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.消費者負責消息的解壓：消息體中有封裝加密算法，消費者接收到消息后可以判斷出消息是否壓縮，以及使用的什么壓縮算法。

Kafka MapReduce

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。