3. 数据生命周期管理：分类、分级与Kafka的清理机制

数据生命周期管理，说白了就是管好数据从生到死的全过程。我在不少数据平台项目里都见过一个通病——只关心数据怎么进来、怎么用，却很少想过数据什么时候该走、怎么走。结果就是集群里堆满了没人碰的“僵尸数据”，磁盘报警天天响，消费延迟也越来越高。

这一章，我们就聚焦数据生命周期里最核心的三个环节：数据分类与分级、基于Kafka的保留策略、以及数据过期与清理机制。嗯，尤其是Log Compaction和Deletion，这两个东西搞不清楚，你的Kafka集群迟早要出问题。

3.1 数据分类与分级：先分清楚再谈管理

数据治理的第一步，不是上工具，而是先给数据“贴标签”。你想想看，如果连哪些数据重要、哪些可以丢都不知道，那保留策略根本没法定。

我个人习惯把数据分成三个维度：

• 业务维度：订单、支付、用户画像这类核心数据，必须高保真、高可用；日志、埋点这类辅助数据，可以适当降级。
• 合规维度：涉及GDPR、个人信息保护法的数据，必须严格按法规保留和销毁，不能多留一天。
• 成本维度：数据量越大，存储和计算成本越高。分级之后，高价值数据用高性能存储，低价值数据用冷存储甚至直接丢弃。

我在一个金融项目里遇到过这样的场景：交易流水数据需要保留7年，但实时风控的中间结果只需要保留24小时。如果混在一起用同一套策略，要么浪费存储，要么丢失关键数据。所以，分类分级是数据生命周期管理的前提。

3.2 基于Kafka的数据保留策略

Kafka提供了两种保留策略：基于时间和基于大小。这两种策略可以单独使用，也可以组合使用。我一般建议组合使用，因为单一策略容易出问题。

策略类型	配置项	说明	我的建议
基于时间	retention.ms	消息保留的最长时间，默认7天	核心业务数据建议72小时以上
基于大小	retention.bytes	分区保留的最大数据量，默认-1（不限）	设置一个上限，防止磁盘写爆
组合策略	两者同时设置	满足任一条件即触发清理	最稳妥的方式，推荐使用

举个例子，假设你有一个订单Topic，每天产生100GB数据。你希望保留3天，同时最多保留500GB。配置如下：

# 基于时间的保留策略：保留72小时
retention.ms=259200000

# 基于大小的保留策略：每个分区最多500GB
retention.bytes=536870912000

这里有个坑——retention.ms是从消息的日志时间戳开始算的，不是从生产时间算的。我曾经帮一个团队排查过问题，他们发现消息明明才过了2天就被删了，后来一查，是生产者没设置时间戳，Kafka用了Broker的接收时间，而那个Broker的时间跑快了。嗯，所以记得检查时间同步。

3.3 数据过期与清理机制：Log Compaction vs Deletion

Kafka的清理机制有两种：Log Deletion（日志删除）和Log Compaction（日志压缩）。这两种机制不是互斥的，而是可以共存的。我见过不少新手把两者搞混，结果数据要么丢得莫名其妙，要么膨胀得不可收拾。

3.3.1 Log Deletion：简单粗暴的清理方式

Log Deletion就是按照时间或大小阈值，直接删除旧的日志段。这是Kafka默认的清理方式，也是大多数场景下的首选。

它的工作流程是这样的：

1. Kafka会定期检查日志段是否满足删除条件（时间过期或大小超限）。
2. 如果满足，就把整个日志段标记为“可删除”。
3. 后台线程会异步清理这些标记的日志段，释放磁盘空间。

配置起来也很简单：

# 启用删除策略（默认就是delete）
cleanup.policy=delete

# 检查间隔，默认5分钟
log.retention.check.interval.ms=300000

但要注意，删除不是实时的。Kafka的检查间隔默认是5分钟，也就是说，消息过期后最多还要等5分钟才会被真正删除。如果你对数据合规有严格要求，比如必须精确到秒级删除，那Kafka的原生机制可能不够用，需要配合外部工具。

3.3.2 Log Compaction：保留最新状态的清理方式

Log Compaction和Deletion完全不同。它不是按时间或大小删数据，而是保留每个Key的最新一条消息，删除旧的重复Key。说白了，它维护的是“最终状态”，而不是“完整历史”。

我举个例子你就明白了。假设有一个用户信息Topic，用户ID是Key：

Key: user_001, Value: {"name": "张三", "age": 25}
Key: user_002, Value: {"name": "李四", "age": 30}
Key: user_001, Value: {"name": "张三", "age": 26}  # 更新了年龄
Key: user_003, Value: {"name": "王五", "age": 28}
Key: user_001, Value: {"name": "张三", "age": 27}  # 再次更新

经过Log Compaction之后，Topic里只会保留：

Key: user_002, Value: {"name": "李四", "age": 30}
Key: user_003, Value: {"name": "王五", "age": 28}
Key: user_001, Value: {"name": "张三", "age": 27}  # 最新的状态

user_001的旧版本全部被清理掉了。这就是Log Compaction的核心价值——用存储空间换查询效率。

配置方式：

# 启用压缩策略
cleanup.policy=compact

# 压缩的最小脏数据比例，默认0.5
min.cleanable.dirty.ratio=0.5

# 压缩线程数，默认1
log.cleaner.threads=2

这里有个关键参数min.cleanable.dirty.ratio。它控制的是“脏数据比例达到多少时触发压缩”。默认0.5的意思是，当一个日志段里有一半以上的数据是重复Key时，才启动压缩。这个值设得太小，压缩频繁，CPU开销大；设得太大，磁盘浪费多。我一般建议从0.5开始，观察一段时间再调整。

3.3.3 混合策略：Deletion + Compaction

你可能会问：能不能同时用两种策略？答案是可以。Kafka允许你在同一个Topic上同时设置delete和compact：

cleanup.policy=compact,delete

这种组合策略的意思是：先按时间或大小删除旧数据，再对剩余数据做压缩。我一般在处理“既有时间约束又有状态保留需求”的场景时用这个。比如订单状态变更Topic，既希望保留最近7天的数据，又希望每个订单只保留最新状态。

但要注意，组合策略的优先级是delete优先。也就是说，Kafka会先检查数据是否过期，过期的直接删掉，不过期的再考虑是否要压缩。这个顺序很重要，别搞反了。

3.4 一张图看懂数据生命周期管理

说了这么多，我画了一张图帮你梳理整个流程。从数据分类分级开始，到策略配置，再到清理机制的执行，每一步都环环相扣。

3.5 实战中的几个关键建议

最后，分享几个我在实战中总结的经验，希望能帮你少走弯路。

• 先分类，再配置：不要一上来就改retention.ms。先搞清楚每个Topic的数据性质，再决定用delete还是compact，或者两者都用。
• 监控磁盘使用率：我习惯给每个Topic的磁盘使用量设置告警。当某个Topic的磁盘占用超过预期时，优先检查是不是清理策略没生效，而不是盲目扩容。
• 测试环境先验证：Log Compaction的压缩效果和预期可能有偏差。我建议先在测试环境跑几天，观察脏数据比例和压缩频率，再调整min.cleanable.dirty.ratio。
• 注意Tombstone消息：在Log Compaction中，如果你发送一个Value为null的消息，Kafka会把它当作“删除标记”（Tombstone）。压缩时，这个Key的旧数据会被清理，但Tombstone本身会保留一段时间。这个机制在实现“软删除”时很有用，但也容易造成数据膨胀，需要配合delete.retention.ms来控制Tombstone的保留时间。