4. Kafka Topic 规划：特征数据、缺失告警与死信队列
在实时特征缺失检测系统中，Topic 是数据流的载体。合理的 Topic 命名规范与分区策略直接影响系统的可维护性、扩展性以及数据隔离性。本章将围绕三类核心 Topic——特征数据 Topic、缺失告警 Topic 与 死信队列 Topic——展开详细规划。
4.1 命名规范：分层清晰，语义自明
采用 “域-应用-数据类型-版本” 的四段式命名结构，确保 Topic 名称在集群中全局唯一且可读性强。各段之间使用下划线 _ 分隔。
| 段位 | 说明 | 示例值 |
|---|---|---|
| 域 | 业务域或系统域缩写 | feat (特征域) |
| 应用 | 具体应用或模块名称 | detect (检测模块) |
| 数据类型 | 数据用途分类 | input / alert / dlq |
| 版本 | Schema 或协议版本号 | v1 |
推荐命名示例：
feat_detect_input_v1—— 特征数据输入 Topicfeat_detect_alert_v1—— 缺失告警 Topicfeat_detect_dlq_v1—— 死信队列 Topic
4.2 分区策略：按业务键散列，保障顺序与负载均衡
分区策略决定了数据如何分布到不同的 Broker 以及消费端如何并行处理。针对三类 Topic 的不同特性，采用差异化的分区策略。
4.2.1 特征数据 Topic 分区策略
- 分区键：使用
特征实体ID（如设备ID、用户ID）作为分区键。 - 策略：
一致性哈希或按实体ID取模。 - 目的：保证同一实体的特征数据写入同一分区，便于下游按实体进行时间窗口内的缺失检测，同时避免数据倾斜。
4.2.2 缺失告警 Topic 分区策略
- 分区键：使用
告警规则ID或实体ID。 - 策略：
按规则ID哈希。 - 目的：相同规则的告警汇聚到同一分区，方便告警聚合与去重，减少下游消费者跨分区合并的开销。
4.2.3 死信队列 Topic 分区策略
- 分区键：使用
原始消息的元数据哈希（如原始Topic+分区+偏移量）。 - 策略：
随机散列。 - 目的：死信消息通常需要人工或重试机制介入，随机散列可均匀分布负载，避免单分区积压。
分区数建议：特征数据 Topic 分区数建议设置为
max(3 * Broker数, 12)，以匹配下游消费者并行度；告警与死信 Topic 分区数可适当减少，通常 3~6 个分区即可满足吞吐需求。
4.3 三类 Topic 的配置对比
| 配置项 | 特征数据 Topic | 缺失告警 Topic | 死信队列 Topic |
|---|---|---|---|
| 分区数 | 12~24 | 3~6 | 3~6 |
| 副本因子 | 3 | 2 | 2 |
| 清理策略 | delete (保留7天) |
compact (保留最新告警状态) |
delete (保留30天) |
| 压缩类型 | lz4 |
gzip |
zstd |
| 消息保留时间 | 72小时 | 7天 | 30天 |
4.4 Topic 架构关系图
下图展示了三类 Topic 在实时特征缺失检测系统中的位置与数据流转关系。
4.5 创建 Topic 的代码示例
以下示例使用 Kafka 命令行工具创建三类 Topic，并指定分区数与副本因子。
# 创建特征数据 Topic
kafka-topics.sh --bootstrap-server localhost:9092 \
--create --topic feat_detect_input_v1 \
--partitions 12 --replication-factor 3 \
--config cleanup.policy=delete \
--config retention.ms=259200000 \
--config compression.type=lz4
# 创建缺失告警 Topic
kafka-topics.sh --bootstrap-server localhost:9092 \
--create --topic feat_detect_alert_v1 \
--partitions 6 --replication-factor 2 \
--config cleanup.policy=compact \
--config compression.type=gzip
# 创建死信队列 Topic
kafka-topics.sh --bootstrap-server localhost:9092 \
--create --topic feat_detect_dlq_v1 \
--partitions 3 --replication-factor 2 \
--config cleanup.policy=delete \
--config retention.ms=2592000000 \
--config compression.type=zstd
注意事项：
- 分区数一旦创建后只能通过
--alter增加，不能减少，请根据预估流量合理设置初始值。 - 副本因子建议至少为 2，生产环境推荐 3，以保证高可用。
- 死信队列的保留时间应长于特征数据 Topic，以便有足够时间排查异常。
4.6 分区数调整与再均衡
当业务增长导致现有分区数不足时，可通过以下步骤进行扩容：
- 增加 Topic 分区数：
kafka-topics.sh --alter --topic feat_detect_input_v1 --partitions 24 - 调整消费者组内消费者数量，使其不超过新分区数。
- 使用
kafka-reassign-partitions.sh工具进行分区再均衡，确保数据分布均匀。
通过上述命名规范与分区策略，可以构建一个清晰、可扩展且易于运维的 Topic 体系，为实时特征缺失检测系统打下坚实基础。