Kafka数据清理：日志清理和日志删除

Kafka的消息存储在磁盘中，为了控制磁盘占用空间，Kafka需要不断地对过去的一些消息进行清理工作。Kafka的每个分区都有很多的日志文件，这样也是为了方便进行日志的清理。在Kafka中，提供日志清理和日志压缩两种方式：

日志删除(Log Deletion)：按照指定的策略直接删除不符合条件的日志。

日志压缩(Log Compaction)：按照消息的key进行整合，有相同key的但有不同value值，只保留最后一个版本。

在Kafka的broker或topic配置中：

以段(segment日志)为单位来进行定期清理的。本节我们来详细介绍Kafka数据处理中的日志删除和日志压缩。

定时日志删除任务

1. 基于时间的保留策略

2. 基于日志大小的保留策略

3. 基于日志起始偏移量的保留策略

基于时间的保留策略

以下三种配置可以指定如果Kafka中的消息超过指定的阈值，就会将日志进行自动清理：

- log.retention.hours

- log.retention.minutes

- log.retention.ms

其中，优先级为 log.retention.ms > log.retention.minutes > log.retention.hours。默认情况，在broker中，配置如下：

log.retention.hours=168

也就是，默认日志的保留时间为168小时，相当于保留7天。

删除日志分段时:

1. 从日志文件对象中所维护日志分段的跳跃表中移除待删除的日志分段，以保证没有线程对这些日志分段进行读取操作

2. 将日志分段文件添加上“.deleted”的后缀(也包括日志分段对应的索引文件)

3. Kafka的后台定时任务会定期删除这些“.deleted”为后缀的文件，这个任务的延迟执行时间可以通过file.delete.delay.ms参数来设置，默认值为60000，即1分钟。

设置topic 5秒删除一次

1. 为了方便观察，设置段文件的大小为1M。

key: segment.bytes

value: 1048576

1. 设置topic的删除策略

key: retention.ms

value: 5000

尝试往topic中添加一些数据，等待一会，观察日志的删除情况。我们发现，日志会定期被标记为删除，然后被删除。

基于日志大小的保留策略

日志删除任务会检查当前日志的大小是否超过设定的阈值来寻找可删除的日志分段的文件集合。可以通过broker端参数 log.retention.bytes 来配置，默认值为-1，表示无穷大。如果超过该大小，会自动将超出部分删除。

注意:

log.retention.bytes 配置的是日志文件的总大小，而不是单个的日志分段的大小，一个日志文件包含多个日志分段。

基于日志起始偏移量保留策略

每个segment日志都有它的起始偏移量，如果起始偏移量小于 logStartOffset，那么这些日志文件将会标记为删

日志压缩(Log Compaction)

Log Compaction是默认的日志删除之外的清理过时数据的方式。它会将相同的key对应的数据只保留一个版本。

Log Compaction执行后，offset将不再连续，但依然可以查询Segment。

Log Compaction执行前后，日志分段中的每条消息偏移量保持不变。Log Compaction会生成一个新的Segment文件。

Log Compaction是针对key的，在使用的时候注意每个消息的key不为空。

基于Log Compaction可以保留key的最新更新，可以基于Log Compaction来恢复消费者的最新状态。