1. 课程导入与全景认知

在多数企业里，数据并不是“没有”，而是“散、慢、难对齐”。一个典型场景是：算法团队在 Databricks 上训练模型，需要风控团队的特征表；风控团队的数据又来自业务系统的订单流水；而业务方希望模型结果能直接回写到自己的看板。三方各自都有数据，却因为权限边界、格式差异、交付方式不统一，导致一次协作要经历导出 CSV、邮件传输、手工对齐字段、反复确认口径的漫长过程。Databricks 的 AI 数据共享与跨团队协作能力，正是为缩短这条链路而设计的。

本课程的核心不是讲“某个按钮怎么点”，而是建立一套可复用的协作认知：数据以什么形态被共享、共享的边界在哪里、跨团队如何在不复制数据的前提下完成消费、以及当协作出现问题时如何定位。整门课围绕 Databricks 的 Unity Catalog、Delta Sharing、Marketplace、Feature Store、Model Serving 等能力展开，最终目标是让学员能够独立设计一条从“数据生产方”到“模型消费方”再到“业务使用方”的协作链路。

一、为什么需要“共享”而不是“复制”

传统跨团队数据交付最常见的方式是复制：把表导出到对象存储，对方再导入。这种方式有三个隐性成本。第一是时效性，复制是批量的，T+1 是常态，实时特征几乎无法交付。第二是一致性，同一份数据在不同团队各存一份，口径一旦变更，所有副本都要重新同步，遗漏一处就会导致模型输入与训练输入不一致。第三是治理成本，副本脱离了原始权限体系，谁看过、谁改过、是否合规，很难追溯。

Delta Sharing 的思路是“共享访问权，而不是共享文件”。数据仍留在生产方的存储中，消费方通过共享协议读取，生产方随时可以撤销授权。这意味着权限、审计、版本都集中在生产方一侧，消费方拿到的是“当前有效”的数据视图。对于 AI 场景，这一点尤其关键：特征表、训练集、模型输入往往需要频繁更新，复制模式下的版本漂移会直接污染模型效果。

二、全景视图：一条协作链路由哪些角色和组件构成

把跨团队协作拆开看，它至少包含四个角色：数据生产方（Provider）、数据消费方（Consumer）、平台治理方（Unity Catalog 管理员）、以及最终业务使用方。组件层面，Unity Catalog 负责元数据与权限，Delta Sharing 负责跨组织或跨工作区的数据访问协议，Marketplace 负责共享包的分发与发现，Feature Store 负责特征的注册与复用，Model Serving 负责把模型能力以接口形式交付给业务方。

下面这张图把“生产方—共享层—消费方—业务方”的链路、关键组件以及数据流向放在同一张视图中，便于在后续章节中反复对照定位。

三、典型场景：三类协作需求与对应能力

第一类是跨工作区共享。同一家企业的算法团队与风控团队使用不同的 Databricks 工作区，但同属一个 Unity Catalog 元存储。此时通过 Catalog 级别的授权即可完成共享，消费方直接以 SELECT 读取生产方的表，无需复制。关键参数是共享对象的粒度：可以按 Catalog、Schema 或 Table 授权，实践中建议按 Schema 授权，避免单表授权过多导致管理成本上升。

第二类是跨组织共享。企业与外部合作方（如数据服务商、联合建模伙伴）之间没有共同的元存储，此时使用 Delta Sharing 的开放协议。生产方创建 Share，把表加入 Share，再为消费方生成凭证文件（.share 文件）。消费方在自己的 Databricks 或兼容客户端中挂载该凭证，即可读取。这里的关键判断是：消费方是否具备 Databricks 环境。若具备，直接挂载；若不具备，可通过开放协议用 Python 或 Spark 连接器读取。

第三类是AI 资产共享。除了表，模型、特征、Notebook 也可以作为共享对象。例如生产方把训练好的模型注册到 Unity Catalog 的 Model Registry，消费方通过 mlflow.pyfunc.load_model 加载并部署为 Serving 端点。这条链路的价值在于：模型版本、训练数据血缘、评估指标都记录在治理层，业务方调用的是“经过审批的模型版本”，而不是某个工程师本地导出的 pickle 文件。

四、学习路径与实战目标

本课程按“认知—配置—协作—排障”四段推进。前几章建立共享模型与权限边界；中间章节进入具体操作，包括创建 Share、配置 Recipient、挂载共享表、注册特征与模型；后续章节处理跨团队协作中的典型问题，例如消费方读取失败、权限变更未生效、共享表版本不一致等；最后通过一个端到端案例，把订单流水→特征表→训练集→模型→Serving 端点→业务看板的链路完整跑通。

实战目标可以量化为三条：第一，能够独立创建一个 Delta Share，并让另一个工作区成功读取；第二，能够把一张特征表注册到 Feature Store，并在训练任务中通过 FeatureLookup 引用；第三，能够定位一次共享读取失败的原因，判断是权限、凭证、网络还是表版本问题。这三条目标分别对应“会配、会用、会查”，也是后续章节反复回扣的主线。

五、一个可对照的示例参数

为了后续章节有统一的参照，这里给出一个示例场景（参数为教学假设，非实测结果）：生产方工作区名为 prod-ws，消费方工作区名为 ml-ws，共享表为 prod_catalog.risk.feature_order_agg，按天分区，分区字段 dt。生产方创建 Share 名为 risk_feature_share，Recipient 名为 ml_team，授权有效期设为 90 天。消费方挂载后，读取语句为：

SELECT user_id, order_cnt_7d, amount_sum_7d
FROM risk_feature_share.feature_order_agg
WHERE dt = '2025-06-01';

这条语句在后续章节中会反复出现，用来验证权限是否生效、分区裁剪是否正常、以及消费方看到的字段是否与生产方一致。当读取返回空结果时，优先检查 dt 分区是否存在、Recipient 是否被授予该 Share、以及消费方是否使用了正确的 Catalog 前缀。

把这条链路走通之后，跨团队协作就不再是“发文件、等回复、对字段”的循环，而是一套可授权、可审计、可撤销的数据访问机制。接下来的章节会从 Unity Catalog 的权限模型开始，逐步展开每一个环节的具体配置与判断依据。