3. Kafka架构与生态

在工业数据流场景中，Kafka 很少以“单机消息队列”的形态出现，它通常是一个由 Broker、元数据控制器、连接器、流处理引擎和模式治理组件共同构成的数据管道中枢。理解 Kafka 的架构与生态，核心是回答三个问题：集群元数据由谁管理？外部系统如何进出 Kafka？流式数据在 Kafka 内部如何被加工与约束？本节围绕 ZooKeeper 与 KRaft、Kafka Connect、Kafka Streams、Schema Registry 四个关键点展开，并给出它们在工业数据集成中的定位。

一、元数据管理：ZooKeeper 模式与 KRaft 模式

Kafka 集群需要维护大量元数据，例如 Broker 注册信息、Topic 与 Partition 的分布、ISR 列表、Controller 选举结果、ACL 与配置项等。早期 Kafka 把这些职责交给外部 ZooKeeper 集群，形成“Kafka + ZooKeeper”双集群架构。ZooKeeper 负责一致性协调，Kafka Controller 从 ZooKeeper 读取元数据并驱动分区 Leader 选举与副本状态变更。

ZooKeeper 模式在长期生产实践中暴露出几个问题：需要额外运维一套 ZK 集群；元数据规模增大时 Controller 故障恢复变慢；元数据变更需要经过 ZK 与 Kafka 两套系统，路径长、延迟高；分区数量达到数万甚至数十万时，Controller 重选举可能耗时数分钟。KRaft（Kafka Raft）模式把元数据管理内置到 Kafka 自身，由一组 Controller 节点组成 Raft 仲裁组，元数据以日志形式复制，Broker 通过 Controller 获取集群状态。KRaft 去掉了 ZooKeeper 依赖，元数据变更路径更短，Controller 故障切换更快，也更容易支持超大规模分区。

二、Kafka Connect：外部系统与 Kafka 之间的标准化桥梁

工业数据集成中，数据源可能是 PLC 网关、OPC UA 服务器、MQTT Broker、关系数据库、时序数据库或文件系统。Kafka Connect 提供了一套标准化的连接框架，用 Source Connector 把外部数据写入 Kafka，用 Sink Connector 把 Kafka 数据写出到目标系统。它把“连接器配置、偏移量管理、任务并行、错误处理、格式转换”从业务代码中抽离出来，使数据接入更可运维。

Connect 的核心概念包括：Connector（连接器逻辑）、Task（并行执行单元）、Worker（运行连接器的进程）、Converter（数据格式转换，如 JSON、Avro）、Transform（轻量级单条消息转换）。在工业场景中，常用组合是 MQTT Source Connector 接入设备遥测，JDBC Sink Connector 写入关系库，S3 Sink Connector 归档原始数据。

{
  "name": "mqtt-source-connector",
  "config": {
    "connector.class": "io.confluent.connect.mqtt.MqttSourceConnector",
    "tasks.max": "4",
    "mqtt.server.uri": "tcp://mqtt-broker:1883",
    "mqtt.topics": "factory/line1/+/telemetry",
    "kafka.topic": "industrial.telemetry.raw",
    "key.converter": "org.apache.kafka.connect.storage.StringConverter",
    "value.converter": "io.confluent.connect.avro.AvroConverter",
    "value.converter.schema.registry.url": "http://schema-registry:8081"
  }
}

三、Kafka Streams：在 Kafka 内部完成流式加工

Kafka Streams 是一个客户端库，应用以普通 Java 程序运行，直接消费 Kafka Topic、做有状态或无状态计算，再把结果写回 Kafka。它不需要额外集群，扩缩容通过启动更多应用实例实现，分区并行度由输入 Topic 的分区数决定。工业场景中，Streams 常用于实时清洗、单位换算、滑动窗口均值、设备状态判定、异常阈值告警和跨 Topic 关联。

Streams 的关键抽象是 KStream（事件流）、KTable（变更日志表）、GlobalKTable（全局表）以及窗口（Tumbling、Hopping、Session）。状态存储默认基于 RocksDB，配合 changelog Topic 实现容错。对于“每 10 秒统计每条产线最近 1 分钟平均温度并写入告警 Topic”这类需求，Streams 比外部流处理引擎更轻量，部署也更贴近 Kafka 生态。

四、Schema Registry：工业数据的契约治理

工业数据往往由多个厂商、多个网关、多个版本的应用共同写入。如果消息格式没有约束，消费者很容易因为字段缺失、类型变化或枚举值扩展而解析失败。Schema Registry 为 Avro、Protobuf、JSON Schema 提供集中式模式存储与版本管理，生产者写入时注册 Schema，消费者按 Schema ID 反序列化。它支持向后兼容、向前兼容和完全兼容策略，使数据契约可演进、可审计。

在工业数据集成中，Schema Registry 的价值不仅是“格式校验”，更是数据字典与接口契约：设备测点、单位、精度、时间戳语义都可以固化在 Schema 中，避免“同名不同义”或“同义不同名”造成的数据湖污染。

五、生态组件在工业数据集成中的定位

六、案例：一条产线数据从设备到数据湖

某工厂产线有 200 台设备，通过 MQTT 网关上报温度、振动、转速。数据集成链路可以设计为：MQTT Broker → Kafka Connect MQTT Source → industrial.telemetry.raw（Avro + Schema Registry）→ Kafka Streams 做 1 分钟窗口均值与阈值判断 → industrial.telemetry.clean 与 industrial.alarm → Connect Sink 写入时序库与对象存储。ZooKeeper 或 KRaft 负责整个 Kafka 集群的元数据一致性。这样，接入、加工、治理、落库各司其职，链路可观测、可扩展、可回放。

七、常见误区与复盘

• 误区一：把 Connect 当业务 ETL 用。Connect 适合标准化、配置化接入，复杂业务逻辑应放到 Streams 或外部应用，避免 Transform 堆叠成难以维护的“配置代码”。
• 误区二：忽略 Schema 兼容性。生产端直接改字段类型或删除字段，会导致消费者批量失败。应先在测试环境验证兼容策略，再灰度发布。
• 误区三：ZooKeeper 模式直接照搬到新集群。新集群若无历史包袱，KRaft 能减少运维面并提升 Controller 恢复速度。
• 误区四：Streams 状态存储不规划。窗口聚合会产生状态，需关注 RocksDB 磁盘、changelog Topic 副本与恢复时间，避免状态过大导致再平衡缓慢。

综上，Kafka 在工业数据集成中的定位不是单一消息中间件，而是“接入—传输—加工—治理—分发”的中枢。ZooKeeper 与 KRaft 决定集群底座，Connect 解决外部系统进出，Streams 承担实时加工，Schema Registry 保障数据契约。四者协同，才能让工业数据管道在规模、稳定性和数据质量上同时可控。