一、更改日志輸出級別
config/log4j.properties中日志的級別設置的是TRACE，在長時間運行過程中產生的日志大小嚇人，所以如果沒有特殊需求，強烈建議將其更改成INFO級別。具體修改方法如下所示，將config/log4j.properties文件中最后的幾行中的TRACE改成INFO，修改前如下所示：
log4j.logger.kafka.network.RequestChannel$=TRACE, requestAppender log4j.additivity.kafka.network.RequestChannel$=false #log4j.logger.kafka.network.Processor=TRACE, requestAppender #log4j.logger.kafka.server.KafkaApis=TRACE, requestAppender #log4j.additivity.kafka.server.KafkaApis=false log4j.logger.kafka.request.logger=TRACE, requestAppender log4j.additivity.kafka.request.logger=false log4j.logger.kafka.controller=TRACE, controllerAppender log4j.additivity.kafka.controller=false log4j.logger.state.change.logger=TRACE, stateChangeAppender log4j.additivity.state.change.logger=false
修改后如下所示：
log4j.logger.kafka.network.RequestChannel$=INFO, requestAppender log4j.additivity.kafka.network.RequestChannel$=false #log4j.logger.kafka.network.Processor=INFO, requestAppender #log4j.logger.kafka.server.KafkaApis=INFO, requestAppender #log4j.additivity.kafka.server.KafkaApis=false log4j.logger.kafka.request.logger=INFO, requestAppender log4j.additivity.kafka.request.logger=false log4j.logger.kafka.controller=INFO, controllerAppender log4j.additivity.kafka.controller=false log4j.logger.state.change.logger=INFO, stateChangeAppender log4j.additivity.state.change.logger=false
二、利用Kafka日志管理器
Kafka日志管理器允許定制刪除策略。目前的策略是刪除修改時間在N天之前的日志（按時間刪除），也可以使用另外一個策略：保留最后的N GB數據的策略(按大小刪除)。為了避免在刪除時阻塞讀操作，采用了copy-on-write形式的實現，刪除操作進行時，讀取操作的二分查找功能實際是在一個靜態的快照副本上進行的，這類似於Java的CopyOnWriteArrayList。
Kafka消費日志刪除思想：Kafka把topic中一個parition大文件分成多個小文件段，通過多個小文件段，就容易定期清除或刪除已經消費完文件，減少磁盤占用
log.cleanup.policy=delete啟用刪除策略 直接刪除，刪除后的消息不可恢復。可配置以下兩個策略： 清理超過指定時間清理： log.retention.hours=16 超過指定大小后，刪除舊的消息： log.retention.bytes=1073741824
三、壓縮策略
將數據壓縮，只保留每個key最后一個版本的數據。首先在broker的配置中設置log.cleaner.enable=true啟用cleaner，這個默認是關閉的。在Topic的配置中設置log.cleanup.policy=compact啟用壓縮策略。
壓縮策略的細節如下：
如上圖，在整個數據流中，每個Key都有可能出現多次，壓縮時將根據Key將消息聚合，只保留最后一次出現時的數據。這樣，無論什么時候消費消息，都能拿到每個Key的最新版本的數據。
壓縮后的offset可能是不連續的，比如上圖中沒有5和7，因為這些offset的消息被merge了，當從這些offset消費消息時，將會拿到比這個offset大的offset對應的消息，比如，當試圖獲取offset為5的消息時，實際上會拿到offset為6的消息，並從這個位置開始消費。
這種策略只適合特俗場景，比如消息的key是用戶ID，消息體是用戶的資料，通過這種壓縮策略，整個消息集里就保存了所有用戶最新的資料。
壓縮策略支持刪除，當某個Key的最新版本的消息沒有內容時，這個Key將被刪除，這也符合以上邏輯。