2. Databricks工作空间与协作基础
在Databricks上做AI数据共享与跨团队协作，第一步不是写代码，而是把“谁在什么边界内、对哪些数据、能做什么操作”这件事理清楚。这一节围绕五个核心对象展开：工作空间（Workspace）、用户（User）、组（Group）、服务主体（Service Principal），以及贯穿它们的权限模型，最后说明Unity Catalog在整个协作体系中的定位。
工作空间：协作的物理与逻辑边界
工作空间是Databricks中最基础的协作单元。一个工作空间绑定到某个云区域（例如 eastus2 或 westeurope），拥有独立的URL、独立的计算资源（集群、SQL仓库）、独立的Notebook目录和作业调度。团队日常登录、开发、调试，几乎都发生在某个具体工作空间里。
但工作空间并不是数据治理的边界。这一点非常关键：如果只依赖工作空间，数据会被“锁”在各自空间内，跨团队共享只能靠复制或导出，既低效又难以审计。因此Databricks引入了账户层（Account Console）来统一管理身份，再由Unity Catalog统一管理数据资产，工作空间则退化为“计算与开发入口”。理解这个分层，是后续所有协作设计的前提。
用户、组与服务主体：三类身份主体
Databricks中的身份主体分为三类，它们的用途和生命周期完全不同：
- 用户（User）：对应真实的人，通常通过SSO（如Azure Entra ID、Okta）同步到账户层，再分配到各工作空间。用户适合交互式开发、Notebook探索、临时查询。
- 组（Group）：用户的集合，是权限授予的主要载体。最佳实践是“权限授给组，用户加入组”，而不是逐个用户授权。组可以来自IdP同步，也可以在Databricks账户层手工创建。
- 服务主体（Service Principal）：非人类身份，用于自动化。例如CI/CD流水线部署作业、外部系统调用REST API、定时任务访问数据。服务主体有自己的Application ID和OAuth密钥，不依赖任何个人账号，避免“人离职导致任务失败”。
一个常见的反模式是：生产作业用某个工程师的个人账号运行。一旦该员工转岗或离职，作业立即中断，且审计日志里所有操作都记在个人名下，无法追溯责任。正确做法是为每类自动化任务创建独立服务主体，例如 sp-etl-daily、sp-ml-training，并只授予其完成任务所需的最小权限。
权限模型：从工作空间到数据对象
Databricks的权限分为两个层面，容易混淆，需要明确区分：
第一层是工作空间权限，控制“能不能进入这个空间、能不能用这里的计算资源”。典型权限包括：CAN_ATTACH_TO（可挂载集群）、CAN_MANAGE（可管理集群/作业）、CAN_VIEW（只读查看）。这一层不涉及具体数据表。
第二层是Unity Catalog数据权限，控制“能对哪些数据对象做什么”。Unity Catalog采用三层命名空间：catalog.schema.table，权限沿层级继承。常见权限有：
| 权限 | 作用对象 | 含义 |
|---|---|---|
| USE CATALOG | Catalog | 允许在该Catalog下操作 |
| USE SCHEMA | Schema | 允许访问该Schema内的对象 |
| SELECT | Table / View | 读取数据 |
| MODIFY | Table | 插入、更新、删除数据 |
| CREATE TABLE | Schema | 在该Schema下建表 |
| ALL PRIVILEGES | 任意对象 | 授予该对象全部权限 |
注意：要读取 sales.gold.orders，主体必须同时拥有 USE CATALOG sales、USE SCHEMA sales.gold 和 SELECT sales.gold.orders。缺少任何一层，查询都会报权限错误。这是初学者最常踩的坑。
GRANT SELECT ON TABLE ... TO `data-analysts` 这类语句授给组，而不是授给个人。组名用反引号包裹，避免特殊字符解析问题。Unity Catalog的协作定位
Unity Catalog不是“另一个工作空间”，而是横跨所有工作空间的统一数据治理层。它统一管理：数据资产（表、视图、卷、模型、函数）、身份主体（用户、组、服务主体）、权限策略（GRANT/REVOKE）、血缘（Lineage）和审计（Audit Log）。
它的协作价值体现在三点：一是跨空间共享——A工作空间产出的表，B工作空间可直接查询，无需复制；二是统一授权——权限在账户层定义一次，所有工作空间生效；三是可审计——谁在何时读了哪张表，全部记录在案。对于AI数据共享场景，这意味着特征表、训练数据集、模型注册表可以在团队间安全流转，而不是靠邮件发文件。
一个可执行的授权示例
假设团队要共享一张特征表 ml.features.user_churn 给分析组 data-analysts，只读。完整授权过程如下：
-- 1. 确保组存在（通常由 IdP 同步，此处假设已存在）
-- 2. 授予 Catalog 级使用权限
GRANT USE CATALOG ON CATALOG ml TO `data-analysts`;
-- 3. 授予 Schema 级使用权限
GRANT USE SCHEMA ON SCHEMA ml.features TO `data-analysts`;
-- 4. 授予表级只读权限
GRANT SELECT ON TABLE ml.features.user_churn TO `data-analysts`;
-- 5. 验证：查看当前授权
SHOW GRANTS ON TABLE ml.features.user_churn;执行后，data-analysts 组内任意成员即可在任意工作空间中查询该表。若某成员查询报错，按“Catalog → Schema → Table”顺序逐层检查 SHOW GRANTS，通常能快速定位缺失的那一层权限。
GRANT ALL PRIVILEGES 图省事。ALL PRIVILEGES 包含 MODIFY、CREATE 等写权限，对只读分析场景属于过度授权，违反最小权限原则，也会让审计变得困难。协作设计中的三个判断点
在实际项目中，遇到协作需求时，可以按以下顺序判断：第一，这个操作是人做的还是机器做的？人用用户身份，机器用服务主体。第二，权限授给谁？优先授给组，避免个人绑定。第三，数据放在哪一层？跨团队共享的数据应放在Unity Catalog管理的Catalog中，而不是某个工作空间的本地DBFS路径。本地路径无法被其他工作空间直接访问，也无法享受统一权限和血缘。