解析大数据领域 Kafka 的日志清理策略：从原理到实践的全面指南
在大数据生态中，Kafka 作为“消息队列的瑞士军刀”，承载着海量数据的流转任务——从电商的订单日志、物联网的设备监控数据到实时推荐系统的行为流，几乎每个高并发场景都能看到它的身影。但伴随而来的日志膨胀问题，却常常让运维人员头疼：
- 某电商平台的 Kafka 集群突然报警“磁盘使用率超过 90%”，原因是近一个月的访问日志全堆在本地；
- 某物联网项目的设备状态 topic 里，同一设备的 100 条历史状态数据占满了磁盘，而业务只需要最新状态；
- 某实时数仓的消费组因为处理延迟，导致旧日志被清理，永远丢失了未消费的关键数据。
这些问题的核心，都指向 Kafka 的日志清理策略——它决定了 Kafka 如何“丢弃”不需要的数据，平衡“数据保留”与“存储成本”的矛盾。本文将从基础原理、两大核心策略、底层实现到实践调优，全面解析 Kafka 日志清理的底层逻辑，帮你彻底解决日志膨胀的痛点。
一、前置知识：Kafka 的日志结构到底是什么？
在聊清理策略前，必须先搞懂 Kafka 是怎么存储数据的——这是理解清理逻辑的基础。
1.1 日志的“三级结构”：Topic → Partition → Segment
Kafka 的数据存储采用**“分层分段”**的设计，核心结构是：
- Topic（主题）：逻辑上的消息分类，比如“user_behavior”（用户行为日志）；
- Partition（分区）：Topic 的物理分片，每个 Partition 是一个独立的日志文件集合（分散在不同 Broker 上，实现高可用和并行处理）；
- Segment（段）：Partition 的最小存储单元，每个 Partition 由多个 Segment 文件组成（默认大小 1GB，可配置）。
举个例子：如果“user_behavior”主题有 4 个 Partition，每个 Partition 又拆分成 10 个 Segment，那么整个主题的存储结构就是 4×10=40 个 Segment 文件。
1.2 Segment 的“三文件组合”
每个 Segment 包含三个文件（以 偏移量范围 命名，比如 00000000000000000000）：
当 Segment 的大小达到 segment.bytes（默认 1GB）或时间达到 log.roll.hours（默认 24 小时）时，Kafka 会滚动生成新的 Segment——旧 Segment 不再写入新消息，成为“只读 Segment”（这是后续清理的关键对象）。
1.3 关键概念：HW、LEO 与“可清理边界”
Kafka 的日志清理不会删除未同步或未提交的消息，这涉及两个核心指标：
- LEO（Log End Offset）：Partition 的“日志末端偏移量”，代表当前 Partition 最新写入的消息偏移量；
- HW（High Watermark）：“高水位线”，代表所有副本都已同步的消息偏移量（只有 HW 之前的消息才是“已提交”的，可被消费者消费）。
清理操作只会针对 HW 之前的只读 Segment——换句话说，未同步的消息（LEO > HW）和正在写入的 Segment（未只读）不会被清理，保证数据一致性。
二、Kafka 的两大日志清理策略：Delete vs Compact
Kafka 提供两种核心清理策略，分别对应**“过期删除”和“去重压缩”**两种场景，通过配置 log.cleanup.policy 选择（默认是 delete）。
2.1 Delete 策略：过期即删，适用于“日志型数据”
2.1.1 工作原理：按“时间/大小/文件数”删除旧 Segment
Delete 策略的核心逻辑是：将超过“保留阈值”的只读 Segment 彻底删除，阈值可以是以下三种维度（满足任一条件即触发）：
