1. 课程导入
在多数中大型组织里，数据并不是“没有”，而是“散落在各自系统里、彼此看不见”。订单团队把事件写进自己的 Kafka 集群，风控团队需要同一批事件却拿不到；营销团队想要用户行为流，只能靠离线导出和 T+1 批处理。结果是：每个团队都在重复采集、重复清洗、重复维护管道，数据口径不一致，协作靠工单和邮件。Confluent Kafka 的数据共享与跨团队协作，正是为了解决这类“数据在组织内部流通不畅”的问题。
本课程讨论的不是“如何再搭一个 Kafka 集群”，而是如何让数据作为一种可治理、可授权、可发现的产品，在团队之间安全、低延迟地流动。它涉及三个层面的能力：数据共享的机制（Cluster Linking、Schema Registry、共享主题）、跨团队协作的治理（RBAC、ACL、服务账号、配额）、以及数据产品的组织方式（Data Contract、Stream Catalog、数据域）。这三者共同构成 Confluent 平台在“数据网格（Data Mesh）”方向上的落地路径。
为什么这件事值得单独学
先看一个典型场景。某零售企业有三个团队：订单团队维护 orders 主题，库存团队维护 inventory 主题，分析团队需要把两者关联后计算“下单后库存扣减延迟”。在没有共享机制时，分析团队的做法通常是：申请一个独立集群，用 Kafka Connect 把两个主题各自同步过来，再在本地做 join。问题在于：同步链路要自己维护、Schema 变更要自己跟进、权限要单独申请、延迟和重复都要自己处理。三个团队之间形成了三套“影子管道”。
引入 Confluent 的数据共享能力后，分析团队可以直接通过 Cluster Linking 把远端主题以只读方式链接到本地集群，或通过 Stream Catalog 发现已有数据产品并申请订阅。Schema Registry 保证字段语义一致，RBAC 保证只读权限边界清晰，Data Contract 保证生产方变更字段时消费方能提前感知。此时，数据共享从“项目制集成”变成了“平台化自助”。
这就是本课程的核心价值：把跨团队数据交换从一次性工程，转变为可复用、可治理、可审计的常态能力。它带来的直接收益包括：
- 降低集成成本：消费方自助订阅，生产方不再为每个下游单独开发同步任务。
- 缩短数据时效：从 T+1 批处理变为秒级流式共享，Cluster Linking 可做到近实时复制。
- 统一语义与契约：Schema Registry 与 Data Contract 让字段含义、兼容性策略有据可依。
- 权限与合规可控：RBAC、ACL、服务账号、配额让“谁能读什么、读多少”可配置、可审计。
- 支撑数据网格：数据域自治、数据即产品、联邦治理，在 Kafka 层面有了具体抓手。
整体框架：本课程要走的四条主线
为了让学习路径清晰，本课程按四条主线展开，它们不是四个孤立模块，而是同一套协作能力的四个切面。
第一条主线是共享机制。 包括 Cluster Linking 的链接建立与方向、Mirror Topic 的命名与偏移量语义、共享主题的读写权限模型，以及跨集群消费时的延迟与重复边界。这条线回答“数据怎么过去”。
第二条主线是契约与 Schema。 包括 Schema Registry 的兼容性级别（BACKWARD、FORWARD、FULL、NONE）、Avro/Protobuf/JSON Schema 的选择、Data Contract 的字段级约束，以及 Schema 演进时消费方如何安全升级。这条线回答“数据过去后语义是否还对得上”。
第三条主线是治理与权限。 包括 RBAC 角色绑定、ACL 精细授权、服务账号与 API Key 管理、配额（Quota）防止单团队打满集群，以及审计日志如何追踪跨团队访问。这条线回答“谁可以共享、共享多少、出了事怎么查”。
第四条主线是协作与数据产品。 包括 Stream Catalog 的数据发现、数据域划分、数据产品负责人（Data Product Owner）职责、SLA 与变更通知机制，以及跨团队故障排查的协作流程。这条线回答“团队之间怎么长期稳定地协作”。
学习目标：学完之后你能做什么
本课程的目标不是让你记住一堆产品名词，而是让你具备“设计并运行一条跨团队数据共享链路”的能力。具体来说，学完后你应该能够：
- 判断共享方式：面对两个团队的数据交换需求，能判断该用 Cluster Linking、共享主题还是 Connect 同步，并说明各自在延迟、重复、偏移量语义上的差异。
- 设计 Schema 策略：为一条跨团队主题选择兼容性级别，写出可演进的 Avro Schema，并说明消费方在字段新增、删除、类型变更时会发生什么。
- 配置权限边界：用 RBAC 角色和服务账号，让消费方只能读指定主题、只能读指定前缀，并设置合理配额防止单团队打满集群。
- 组织数据产品：把一个主题注册为可发现的数据产品，明确负责人、SLA、变更通知方式和消费方接入流程。
- 排查协作故障：当消费方读不到数据、Schema 不兼容、权限被拒或延迟异常时，能按链路逐段定位问题。
一个贯穿课程的示例场景
为了让抽象概念有落点，本课程会反复使用一个示例场景（以下参数均为教学假设，非实测结果）：
| 角色 | 团队 | 数据对象 | 关键诉求 |
|---|---|---|---|
| 生产方 | 订单团队 | orders 主题，Avro Schema，约 3000 条/秒 | 字段可演进，不因下游需求频繁改代码 |
| 生产方 | 库存团队 | inventory 主题，Protobuf Schema | 只读共享，不允许外部写入 |
| 消费方 | 分析团队 | 需要 orders + inventory 关联 | 秒级时效，自助订阅，字段语义稳定 |
| 消费方 | 风控团队 | 只读 orders 中部分字段 | 权限最小化，可审计 |
围绕这个场景，我们会逐步展开：如何建立 Cluster Linking、如何设置 Schema 兼容性、如何用 RBAC 给风控团队只读权限、如何把 orders 注册为数据产品并定义 SLA。每一章都会在这个场景上增加一层能力，最终形成一条完整的跨团队数据共享链路。
本课程的整体结构
课程共 30 章，按“认知 → 机制 → 治理 → 协作 → 实战”推进。前几章建立数据共享与跨团队协作的基本认知和框架；中间章节分别深入 Cluster Linking、Schema Registry、RBAC/ACL、配额与审计等具体机制；随后进入数据产品化、Stream Catalog、数据域划分与协作流程；最后通过综合案例，把四条主线串成一条可运行的共享链路，并覆盖常见故障排查与复盘方法。
需要强调的是，Confluent Kafka 的数据共享不是“把集群连起来”这么简单。它真正的难点在于：让不同团队对同一份数据的含义、权限、时效和变更节奏达成一致。技术机制是基础，协作约定才是长期稳定的关键。本课程会同时讲清楚这两面，避免只学工具、不懂治理，或只谈流程、落不了地。
接下来，我们从最基础的问题开始：数据共享到底共享的是什么，跨团队协作中常见的障碍有哪些，以及 Confluent 平台提供了哪些能力来对应解决这些问题。