我们将log retention hours设置为1小时，如下所示(之前的设置为72小时(
使用下面的Kafka命令行工具，我们将Kafkaretention.ms设置为1H。我们的目标是清除主题-test_topic中早于1H的数据，因此我们使用了以下命令：
kafka-configs.sh --alter
--zookeeper localhost:2181
--entity-type topics
--entity-name topic_test
--add-config retention.ms=3600000
以及
kafka-topics.sh --zookeeper localhost:2181 --alter
--topic topic_test
--config retention.ms=3600000
两个命令运行时都没有出现错误。
但问题是关于Kafka的数据，它比1H更老，而且仍然存在！
实际上，没有从主题topic_test分区中删除任何数据。我们有HDP Kafka集群版本1.0x和ambari
我们不明白为什么主题topic_test的数据仍然存在？并且即使在我们按照已经描述的运行了两个cli之后也没有减少
下面的kafkacli有什么问题？
kafka-configs.sh --alter --zookeeper localhost:2181 --entity-type topics --entity-name topic_test --add-config retention.ms=3600000
kafka-topics.sh --zookeeper localhost:2181 --alter --topic topic_test --config retention.ms=3600000
从Kafkaserver.log中，我们可以看到以下
2020-07-28 14:47:27,394] INFO Processing override for entityPath: topics/topic_test with config: Map(retention.bytes -> 2165441552, retention.ms -> 3600000) (kafka.server.DynamicConfigManager)
[2020-07-28 14:47:27,397] WARN retention.ms for topic topic_test is set to 3600000. It is smaller than message.timestamp.difference.max.ms's value 9223372036854775807. This may result in frequent log rolling. (kafka.server.TopicConfigHandler)
参考-https://ronnieroller.com/kafka/cheat-sheet
日志清理器将只在非活动(有时也称为"旧"或"干净"(段上工作。只要所有数据都适合由segment.bytes大小限制定义其大小的活动("脏"、"不干净"(段，就不会发生清理。
配置cleanup.policy描述为：
一个字符串；删除"；或"；紧凑型"；或两者兼有此字符串指定要在旧日志段上使用的保留策略。当达到旧段的保留时间或大小限制时，默认策略("删除"(将丢弃旧段。"；紧凑型"；设置将启用该主题的日志压缩。
此外，segment.bytes是：
此配置控制日志的段文件大小。保留和清理总是一次完成一个文件，因此较大的段大小意味着更少的文件，但对保留的精细控制更少。
配置segment.ms也可用于引导删除：
此配置控制一段时间，在这段时间之后，即使分段文件未满，Kafka也会强制日志滚动，以确保保留可以删除或压缩旧数据。
由于默认为一周，您可能需要减少它以满足您的需求。
因此，如果你想将主题的保留时间设置为例如一小时，你可以设置：
cleanup.policy=delete
retention.ms=3600000
segment.ms=3600000
file.delete.delay.ms=1 (The time to wait before deleting a file from the filesystem)
segment.bytes=1024
注：我指的不是retention.bytes。如上所述，segment.bytes是一个非常不同的东西。此外，请注意log.retention.hours是集群范围的配置。所以，如果你计划对不同的主题有不同的保留时间，这将解决它