Kafka 的架构设计遵循“分布式、分区、多副本”原则其核心在于将数据流Topic拆解为并行单元Partition进行水平扩展。Kafka 的架构本质是一个分布式的提交日志系统。它通过“分区”解决了并发瓶颈通过“副本”解决了高可用问题通过“消费者组”解决了数据复用问题是现代数据管道和实时流处理的主流技术。吞吐优先利用顺序 I/O和PageCache规避磁盘随机读写瓶颈。水平扩展通过增加 Partition 和 Broker 线性提升吞吐量。解耦与缓冲作为生产者与消费者之间的异步缓冲层抵御流量洪峰。多租户广播通过 Consumer Group 机制实现一份数据被多个业务系统独立消费Pub-Sub。1. Kafka架构设计1.1 架构全景图组件角色与职责关键特性Producer消息生产者通过 Key 决定消息发往哪个 Partition负载均衡Consumer消息消费者以 Consumer Group 为单位每个 Partition 只能被组内一个 Consumer 消费BrokerKafka 服务器节点存储数据组成集群无需主从通过 Zookeeper/KRaft 协调Topic逻辑数据分类如 order_events是消息的集合Partition物理数据分片Topic 的并行单元每个 Partition 是一个有序、不可变的日志Replica副本每个 Partition 有多个副本Leader/FollowerLeader 负责读写Follower 同步备份Zookeeper / KRaft元数据与协调中心管理 Broker 注册、Leader 选举、Consumer Offset新版用 KRaft 替代 ZK1.2 数据流与存储机制写入流程Producer → Broker路由Producer 根据 Key 哈希或轮询将消息发送到 Topic 的特定 Partition。追加日志消息到达 Broker 后以顺序追加Append-Only的方式写入 Partition 日志文件。持久化消息并非立即落盘而是先写入 PageCache由操作系统异步刷盘兼顾高性能与持久性。2. 消费流程Broker → Consumer拉取模式Consumer 主动向 Broker 拉取Pull消息可控制消费速率。Offset 管理Consumer Group 维护消费位移Offset标记已消费位置支持at-least-once、at-most-once、exactly-once语义。Rebalance当 Consumer 加入或离开 Group 时触发重新分配 Partition实现自动容错。3. 高可用机制ReplicationLeader/Follower每个 Partition 有一个 Leader 和多个 Follower。所有读写仅通过 Leader。ISRIn-Sync Replicas与 Leader 保持同步的副本集合。只有 ISR 中的副本才有资格竞选 Leader。故障转移若 Leader 宕机ZooKeeper/KRaft 会从 ISR 中选举新的 Leader保证服务不间断。1.3 ZooKeeper 与 KRaft模式架构特点适用场景ZooKeeper 模式依赖外部 ZK 集群进行元数据管理旧版本Kafka 3.3运维复杂KRaft 模式内置元数据仲裁机制去外部依赖新版本Kafka ≥ 3.3简化部署提升稳定性2. Kafka数据流转2.1 生产者向 Kafka 发送消息生产者是将数据发送到 Kafka 主题的应用程序。它们能智能地决定将每条消息发送到何处。生产者逻辑分区选择如果消息有键key则使用 hash(key) % partition_count计算分区如果无键则使用轮询round-robin分配也可以使用自定义的分区器逻辑2. 交付保证acks0发送即忘最快可靠性最低acks1等待领导者确认平衡型acksall等待所有副本确认最慢可靠性最高生产者代码示例Properties props new Properties(); props.put(bootstrap.servers, broker1:9092,broker2:9092); props.put(key.serializer, org.apache.kafka.common.serialization.StringSerializer); props.put(value.serializer, org.apache.kafka.common.serialization.StringSerializer); ProducerString, String producer new KafkaProducer(props); // 发送消息到 user-events 主题 ProducerRecordString, String record new ProducerRecord(user-events, user123, {\action\: \purchase\}); producer.send(record);2.2 消费者从 Kafka 读取消息消费者从 Kafka 主题读取数据。与传统消息系统在消费后即删除消息不同Kafka 会保留消息允许多个消费者独立地读取相同的数据。消费者组属于同一组的消费者共享工作负载每个分区在同一时间只能被组内的一个消费者消费不同的消费者组可以独立地消费相同的数据消费者代码示例Properties props new Properties(); props.put(bootstrap.servers, broker1:9092,broker2:9092); props.put(group.id, user-analytics-group); props.put(key.deserializer, org.apache.kafka.common.serialization.StringDeserializer); props.put(value.deserializer, org.apache.kafka.common.serialization.StringDeserializer); ConsumerString, String consumer new KafkaConsumer(props); consumer.subscribe(Arrays.asList(user-events)); while (true) { ConsumerRecordsString, String records consumer.poll(Duration.ofMillis(100)); for (ConsumerRecordString, String record : records) { System.out.printf(Consumed: key%s, value%s, partition%d, offset%d%n, record.key(), record.value(), record.partition(), record.offset()); } }2.3 生产者与消费者如何“对齐”生产者与消费者如何管理offset在 Kafka 中生产者不管理 Offset消费者负责管理 Offset但两者的管理机制和目的完全不同。下面是详细说明一、生产者端不管理 Offset生产者不关心 Offset只负责发送消息。它管理的是消息确认机制这间接影响了消息的持久化位置。生产者确认机制acks配置含义可靠性性能acks0不等待确认只管发送最低可能丢失最高acks1等待 Leader 写入成功确认中等Leader 宕机可能丢失中等acksall/acks-1等待所有 ISR 副本写入成功确认最高强一致最低生产者代码示例// 设置高可靠性配置 props.put(acks, all); // 等待所有副本确认 props.put(retries, 3); // 失败重试3次 props.put(max.in.flight.requests.per.connection, 1); // 保证顺序二、消费者端Offset 管理的核心消费者全权负责 Offset 的管理这是 Kafka 消费语义的核心。Offset 存储位置:存储方式位置管理方特点自动提交Kafka 内部 Topic__consumer_offsetsKafka 自动管理默认方式简单但有风险手动提交__consumer_offsets或 外部存储如数据库消费者应用控制精确控制避免重复/丢失Offset 提交方式对比:提交方式配置特点适用场景自动提交enable.auto.committrueauto.commit.interval.ms5000每5秒自动提交可能重复消费允许少量重复的业务同步手动提交enable.auto.commitfalse调用 consumer.commitSync()提交成功才继续性能较低金融、交易等强一致性场景异步手动提交enable.auto.commitfalse调用 consumer.commitAsync()不阻塞性能高失败不重试大部分业务场景按记录提交处理一条提交一次最安全性能最差极少使用手动提交代码示例// 禁用自动提交 props.put(enable.auto.commit, false); try { while (true) { ConsumerRecordsString, String records consumer.poll(Duration.ofMillis(100)); for (ConsumerRecordString, String record : records) { // 处理消息 processMessage(record); // 同步提交确保提交成功 // consumer.commitSync(); } // 批量异步提交推荐 consumer.commitAsync(); } } catch (Exception e) { // 处理异常 } finally { try { // 最后同步提交确保成功 consumer.commitSync(); } finally { consumer.close(); } }三、高级 Offset 管理策略自定义 Offset 存储将 Offset 存储到外部系统如 MySQL、Redis实现精确一次Exactly-Once处理// 从数据库获取上次保存的 Offset long offset loadOffsetFromDB(topic, partition); // 指定从该 Offset 开始消费 consumer.seek(new TopicPartition(topic, partition), offset); while (true) { ConsumerRecordsString, String records consumer.poll(Duration.ofMillis(100)); for (ConsumerRecordString, String record : records) { processMessage(record); // 处理成功后保存 Offset 到数据库 saveOffsetToDB(record.topic(), record.partition(), record.offset() 1); } }2. 消费语义控制语义实现方式特点至少一次(At-Least-Once)先处理消息后提交 Offset可能重复但不会丢失至多一次(At-Most-Once)先提交 Offset后处理消息可能丢失但不会重复精确一次(Exactly-Once)事务或幂等生产者外部存储不丢失不重复实现复杂3. Offset 重置策略当消费者组第一次启动或 Offset 失效时可配置重置行为# 配置项 auto.offset.resetlatest|earliest|none # latest从最新位置开始消费默认 # earliest从最早位置开始消费 # none找不到 Offset 时抛出异常3. 理解几个关键概念Kafka 本质上是一个高吞吐、分布式、基于发布-订阅模型的实时消息系统。它通过“日志Log”这一底层数据结构解决了海量数据流转的难题。3.1 三大基础角色这是理解数据流向的基石Producer生产者推数据到 Kafka 的应用。Consumer消费者拉数据并处理的应用。Broker服务器节点Kafka 集群中的单个实例负责存储和转发消息。3.2 数据组织与存储Topic主题数据的逻辑分类类似于数据库的表名。生产者发送消息时必须指定 Topic消费者也按 Topic 订阅。Partition分区Topic 的物理分片这是 Kafka 实现高并发和高扩展性的核心。顺序性消息在单个 Partition 内有序全局无序。并行度Partition 是并发的最小单位。Consumer 的吞吐量上限由它消费的 Partition 数量决定。偏移量OffsetPartition 中每条消息的唯一 ID类似数组下标由 Kafka 自动维护。Log日志Partition 在磁盘上的物理存储形式表现为只能追加Append-Only的文件。这种设计决定了 Kafka 的高性能——写入就是顺序写读取是顺序读。3.3 消费与保障机制Consumer Group消费组一组协同工作的消费者是 Kafka 实现“负载均衡”和“队列/发布订阅”模式的关键。组内竞争一个 Partition 在同一时间只能被组内一个 Consumer消费。组间独立不同 Consumer Group 消费同一 Topic 互不影响实现广播。2. Replication副本数据高可用的保障。每个 Partition 有多个副本Leader 和 Follower。Leader负责处理所有读写请求。Follower异步同步 Leader 的数据。Leader 挂掉后Follower 自动竞选成为新 Leader。4. 理解几组关键关系4.1 Topic与Partition的关系Topic 和 Partition 是 Kafka 中逻辑与物理的关系。你可以把 Topic 看作数据库中的“表”而 Partition 是这张表底层的“物理分片”。一、核心关系一对多的包含关系一个 Topic 必须包含至少 1 个 Partition一个 Partition 必须属于且仅属于一个 Topic。Topic逻辑分类数据的主题或类别例如 order_events。它是面向业务和开发者的逻辑概念。Partition物理分片Topic 在物理存储上的实际分片。每个 Partition 是一个独立的、有序的日志文件。二、关键特性与约束消息顺序性Partition 内有序在单个 Partition 内部消息严格按照写入顺序Offset排列Kafka 保证此顺序。Partition 间无序跨 Partition 的消息没有全局顺序。如果你需要某类消息如同一个用户 ID严格有序必须通过 Key 将它们路由到同一个 Partition。2. 并行度与扩展性Partition 数量决定最大并行度一个 Consumer Group 中同时消费的 Consumer 实例数量不能超过 Partition 数量。例如Topic 有 3 个 PartitionConsumer Group 最多只能有 3 个 Consumer 同时工作每个处理 1 个 Partition。如果有第 4 个 Consumer它会处于空闲状态。水平扩展增加 Partition 数量可以提升 Topic 的吞吐量上限。3. 数据分布与路由Producer 路由Producer 发送消息时通过 Key 的哈希值或轮询决定消息写入哪个 Partition。物理隔离不同 Partition 可以分布在不同的 Broker 节点上实现负载均衡。三、设计决策参考场景建议策略需要高吞吐增加 Partition 数量如 12, 24, 32需要严格顺序使用 Key 确保相关消息进入同一 Partition消费者扩展Partition 数应 ≥ 预期的最大消费者实例数最佳实践Partition 数量在创建 Topic 时设定后期修改增加虽然可以但可能会导致 Key 的哈希分布变化建议初期预留一定余量如 6-12 个。4.2 Topic与key的关系Topic 是消息的逻辑分类“去哪”Key 是消息的路由标签“怎么去”。Key 本身不独立存在它依附于 Topic用于决定消息被发送到 Topic 下的哪一个Partition。一、基础定义Topic主题消息的逻辑集合类似数据库的“表名”。Key键消息的元数据用于控制消息在 Topic 内的分布逻辑。二、Key 如何影响 Topic 内的路由Key 的核心作用是决定消息进入 Topic 的哪个 Partition从而影响顺序性和数据局部性。Key 设置情况路由逻辑Partition 选择典型应用场景Key null轮询Round-Robin发送到所有 Partition。吞吐量优先无需顺序保障。Key ≠ nullhash(key) % partition_num相同 Key 必进同一 Partition。保证同一用户、订单 ID 的消息顺序。三、关系本质逻辑与物理的映射Topic 是逻辑容器Key 是物理路由策略的输入参数。无 KeyTopic 只是一个数据池消息均匀分布。有 KeyTopic 被 Key 划分为多个“逻辑子流”Partition实现了数据分片Sharding。四、设计误区与最佳实践Key 不是必选项如果不需要顺序或聚合建议不设 Key 以获得最佳吞吐。热点 Key 风险如果某个 Key 的数据量极大如“默认用户”会导致单个 Partition 成为瓶颈。Key 的选择优先使用业务主键如 user_id、order_id作为 Key而非随机值。4.3 Topic 与消费者组的关系Topic 与消费者组Consumer Group的关系本质上是“广播内容”与“订阅观众”的关系。它们之间是完全解耦的一个 Topic 可以被多个消费者组独立消费互不影响。一、核心关系一对多的独立订阅一个 Topic 可以被 0 个、1 个或多个消费者组同时订阅每个消费者组都会独立、完整地消费该 Topic 的所有消息二、多消费者组场景Pub-Sub 模式这是 Kafka 最强大的特性之一一份数据多份消费。假设你有一个 user_login_topic记录了所有用户的登录事件消费者组 A数据分析团队消费该 Topic计算实时 UV/PV写入数据仓库。消费者组 B风控团队消费该 Topic检测异常登录行为触发告警。消费者组 C推送服务团队消费该 Topic判断用户是否长时间未登录触发召回 Push。这三个消费者组互不知晓对方的存在各自维护独立的消费进度Offset互不干扰。三、消费者组内部机制Queue 模式虽然 Topic 是广播但同一个消费者组内部是竞争关系实现负载均衡。维度同一个消费者组内Competing Consumers不同消费者组之间Pub-Sub消息分配一个 Partition 只能被组内一个 Consumer 消费每个组都能收到全部消息消费模式队列模式负载均衡发布订阅模式广播Offset 管理组内共享进度__consumer_offsets各组独立维护进度典型场景业务逻辑处理需要扩容时增加 Consumer数据复用不同团队消费同一份数据四、关键设计约束1 Partition 数量是并行度上限一个消费者组内有效的 Consumer 实例数量不能超过 Topic 的 Partition 数量。例如Topic 有 3 个 Partition消费者组最多有 3 个 Consumer 在干活。如果有第 4 个 Consumer它会处于空闲状态Idle直到有 Partition 被释放。2 消费进度Offset独立每个消费者组在 Kafka 的内部 Topic __consumer_offsets中独立记录自己的消费位置。消费者组 A 可能消费到了 Offset1000。消费者组 B 可能因为重启还在消费 Offset500。它们互不影响。五、设计决策参考表业务场景Topic 与 消费者组 设计策略单一业务逻辑处理如订单处理1 个 Topic 1 个消费者组通过增加组内 Consumer 实例来扩容数据复用如一份日志多方使用1 个 Topic N 个消费者组每个组对应一个下游业务需要顺序保证确保同一类消息相同 Key进入同一 Partition且该 Partition 在同一组内仅由一个 Consumer 处理测试或调试使用独立的消费者组如 test_group避免干扰线上业务的消费进度最佳实践Topic 是数据的“生产者视图”消费者组是数据的“消费者视图”。设计时应优先考虑“谁需要这份数据”而不是“怎么消费这份数据”。4.4 partition与 消费者组的关系Consumer Group消费者组与 Partition分区的关系是 Kafka并行处理与负载均衡的基石。简单来说一个 Partition 在同一时刻只能被一个 Consumer Group 内的唯一 Consumer 消费。这种“一对一”的锁定关系直接决定了系统的吞吐量和并发能力。一、核心关系抢占式消费在同一个 Consumer Group 内Partition 是分配的最小单位。你可以把 Partition 想象成“蛋糕”Consumer 是“吃蛋糕的人”。规则每个 Partition 只能分配给组内的一个 Consumer。结果组内 Consumer 的数量与 Partition 的数量直接决定了并发上限。二、数量关系的三种状态这是面试和工作中最常考察的重点状态关系现象与影响C P消费者数 分区数理想状态。每个 Consumer 独占一个 Partition资源被充分利用。C P消费者数 分区数部分 Consumer 需承担多个 Partition。此时虽然能运行但部分消费者压力较大。C P消费者数 分区数有 Consumer 处于空闲状态。多出来的 Consumer 无法分配到 Partition造成资源浪费。关键结论一个 Consumer Group 的并发度上限等于该 Topic 的 Partition 数量。增加 Consumer 数量超过 Partition 数量不会提升性能。三、为什么需要这种关系这种设计主要解决了两个核心问题顺序性保障因为一个 Partition 只被一个 Consumer 处理所以 Partition 内部的消息顺序得以严格保持适用于订单流水等场景。负载均衡Kafka 通过 Coordinator 自动将 Partition 均匀分配给组内的所有 Consumer实现自动的负载均衡Rebalance。四、Group 之间的隔离性不同 Consumer Group 消费同一 Topic 是完全隔离的。Group A和Group B可以同时消费 topic.order的所有 Partition。这实现了“广播”效果一条消息可以被多个不同业务如风控、数仓同时消费互不干扰。五、实战建议规划分区数创建 Topic 时Partition 数量应至少等于你预计的最大 Consumer 数量为未来扩容留足空间分区数只能增不能减。避免闲置尽量不要让 Consumer 数量长期大于 Partition 数量。Rebalance当 Consumer 加入或离开组时会触发 Partition 的重新分配此时消费会短暂暂停这是正常现象。4.5 Partition 与 Broker的关系Partition分区与 Broker服务器节点的关系是“存储单元”与“物理载体”的关系。你可以把 Broker 理解为书架把 Partition 理解为书。一个书架可以放很多本书但同一本书的副本不能放在同一个书架上。一、核心关系多对多的物理分布一个 Broker 可以存储多个 Partition一个 Partition 的多个副本必须分布在不同的 Broker 上。这是 Kafka 实现高吞吐通过 Partition 拆分和高可用通过副本分布的物理基础。数据分布机制Partition 是存储实体Topic 是逻辑概念数据实际存储在 Partition 的日志文件中。Broker 是存储节点Partition 的物理文件最终落在 Broker 的磁盘上。副本放置策略关键每个 Partition 有多个副本ReplicaKafka 强制要求同一个 Partition 的所有副本不能放在同一个 Broker 上。这是为了确保一台机器宕机时数据依然可用。示例假设你有一个 3 节点的 Kafka 集群Broker-0, Broker-1, Broker-2一个 Partition P0有 3 个副本它的分布必须是P0的 Leader 副本在 Broker-0P0的 Follower 副本在 Broker-1P0的 Follower 副本在 Broker-2二、读写机制Leader 与 FollowerPartition 副本分为 Leader 和 Follower读写操作只与 Leader Broker 交互。角色职责读写权限Leader Replica处理所有 Producer 和 Consumer 的读写请求可读可写Follower Replica从 Leader 异步/同步拉取数据保持同步只同步不提供读服务关键点写放大Producer 只向 Leader Broker 写入数据Leader 负责将数据复制到 Follower。读隔离Consumer 默认只从 Leader Broker 读取数据除非配置了 Follower 读取但通常不建议。三、容量与扩展性设计分区数 vs Broker 数Partition 数量决定了 Topic 的最大并行度一个 Partition 只能被一个 Consumer 消费。Broker 数量决定了集群的总存储容量和故障容忍度。2. 容量规划公式为了保证集群健康通常建议遵循以下经验法则单个 Broker 上的 Partition 总数 ≤ 2000 - 4000计算逻辑假设你有 10 个 Topic每个 Topic 有 100 个 Partition副本因子为 3。那么整个集群的 Partition 总数为 10 × 100 × 3 3000。如果均匀分布在 3 个 Broker 上每个 Broker 承载 3000 / 3 1000个 Partition这在安全范围内。如果单个 Broker 上的 Partition 数量过多如超过 5000会导致文件句柄耗尽、Leader 选举变慢、恢复时间变长四、故障转移Failover流程当 Broker 宕机时Partition 与 Broker 的关系会动态调整检测ZooKeeper/KRaft 检测到 Broker-0 失联。选举对于所有 Leader 在 Broker-0 上的 Partition从 ISR同步副本列表中选举一个新的 Leader例如 Broker-1。恢复Producer 和 Consumer 自动切换到新的 Leader Broker 继续工作。注意如果宕机的 Broker 是 Follower通常对服务无影响因为读写只依赖 Leader。五、设计决策参考表场景策略目标提高吞吐量增加 Partition 数量提升并行处理能力提高容错性增加 Broker 数量并确保副本因子 ≤ Broker 数确保宕机时仍有副本可用均衡负载确保 Partition 均匀分布在所有 Broker 上避免单节点热点最佳实践在创建 Topic 时Partition 数量建议设置为 Broker 数量的整数倍如 3 个 Broker设置 6、9、12 个 Partition这样数据分布会更均匀。5. 如何设计Topic5.1 命名规范清晰、一致推荐结构环境.数据领域.数据来源.事件/对象.数据格式示例prod.log.app.user_click.avroprod.metric.server.cpu_usage.jsonprod.biz.order.order_created.avro简化版常用业务线.数据源.事件名trade.pc.payment_success5.2 分区数Partition设计 - 决定并发度核心公式分区数 ≈ 目标吞吐量 / 单个分区吞吐量单个分区吞吐量经验值约 10-50 MB/s。估算步骤评估峰值写入速率例如高峰时每秒 10 万条消息每条平均 1KB则吞吐量为 100,000 msg/s * 1KB ≈ 100 MB/s。计算最小分区数100 MB/s ÷ 20 MB/s/分区 ≈ 5 个分区。预留缓冲考虑未来增长可设定为2-4 倍例如 5 * 3 15 个分区。通常选择 2 的 N 次方如 16。关键限制分区数只能增加不能减少。所以初期可适度多分但不宜过多每个分区都有开销。5.3 副本数Replication Factor - 决定可靠性建议值开发/测试环境1节约资源。生产环境至少为 3。这是保证高可用的标准配置允许同时宕机 2 个节点而不丢失数据。5.4 数据格式序列化推荐 Avro或Protobuf绝不推荐纯字符串 JSON。原因它们 Schema 清晰、压缩率高、兼容性好便于上下游系统解析。配合Schema Registry如 Confluent Schema Registry使用最佳。5.5 经典设计模式模式一按数据来源/设备分离topic.app_clickApp端点击 topic.web_clickWeb端点击 topic.iot_sensor物联网传感器优点来源隔离互不影响便于按来源分配资源和设置策略。模式二按数据优先级/延迟要求分离topic.high_priority_realtime延时1s分区多副本多 topic.low_priority_batch延时允许分钟级可压缩保留时间长优点资源分配更合理保障核心业务。模式三原始数据与标准化数据分离推荐架构1. 原始上报层 (Raw Ingestion) - topic.raw_app_log (所有App原始日志格式不一保留7天) - 消费者一个统一的“标准化处理服务”。 2. 标准化数据层 (Standardized Data) - topic.biz_user_event (处理后的标准用户事件Avro格式保留30天) - topic.biz_app_performance (处理后的性能数据) - 消费者数仓、风控、推荐等各业务系统。优点解耦原始数据可追溯下游用标准数据清爽稳定。5.6 两种设计策略设计维度起步阶段稳中求进快速验证扩张阶段精细治理保障稳定核心目标低成本启动、架构清晰、便于迭代支撑高并发、保障数据质量、多团队协作命名规范极简结构业务线.事件类型例trade.order_created完整结构环境.数据领域.来源.事件.格式例prod.trade.app.payment_success.avro分区策略固定数量从 6 个分区 起步兼顾 扩展性与高性能动态评估业务并行度如按 user_id哈希至少 30 个并发单元 → 分区数 ≥ 30吞吐量规划(峰值吞吐 / 20MB/s) * 缓冲系数(2-3)副本数生产环境 直接设为 3建立高可用基线分级设置• 核心业务 Topic → 可提升至 4 或 5• 非核心 Topic → 保持 3数据格式必须使用 Protobuf/Avro Schema Registry杜绝 JSON 字符串强制化 流程管控• 所有 Topic 强制注册 Schema• Schema 变更需走审批与兼容性检查流程保留时间统一策略默认 30 天简化管理分级策略• 热数据订单/支付30 天• 温数据用户行为15 天• 冷数据调试日志8 天• 永久数据归档至廉价存储归档机制核心数据先行仅对支付、用户等核心事件配置自动化归档至 S3分级自动化体系实时归档核心数据实时入数据湖Iceberg/Hudi定时归档所有数据按保留策略过期前批量压缩转储成本可视建立存储费用监控看板Topic 数量与治理粗粒度少量 Topic按数据领域划分如 user.events, order.events共 3-5 个细粒度 分层架构原始接入层topic.raw_source标准数据层topic.std_domain_event衍生数据层topic.dwd_agg_name治理措施• Topic 申请审批流程• 血缘图谱与依赖管理• “僵尸 Topic”定期审计下线5.7 Checklist命名是否清晰、符合团队规范分区数量是否足够支撑未来 1-2 年的峰值流量建议 6/12/16/24/32…副本生产环境是否 ≥ 3格式是否使用 Avro/Protobuf 并配备了 Schema Registry保留时间是否根据数据价值设置如 7天、30天、永久归档重要数据是否有下游归档到 HDFS/S3 的机制最后建议在项目初期可以先按“数据来源”划分 Topic并采用“原始-标准化”两层结构。这个模式能很好地应对初期的复杂性和未来的变化。可以先创建 1-2 个核心 Topic 跑通流程再按业务扩展。