2. Databricks 协作架构总览

在 Databricks 中做跨团队协作，最容易踩的坑不是“不会写代码”，而是不清楚每个组件到底管什么、边界在哪里。一个团队把表建在个人 workspace 里，另一个团队在另一个 workspace 里找不到；或者 notebook 里能跑通，一到 job 调度就报权限错误。这些问题的根源，往往是把 workspace、metastore、Unity Catalog、compute、notebook、job、dashboard 混为一谈。本节先把这套架构的角色和边界讲清楚，再串成一条从数据生产到消费的完整链路。

七个组件，三层职责

可以把 Databricks 协作架构理解成三层：身份与权限层（account、Unity Catalog、metastore）、计算与开发层（compute、notebook）、交付与消费层（job、dashboard）。workspace 则是贯穿其中的“工作场所”，它承载 notebook、job、dashboard 这些对象，但不拥有数据权限。

关键边界要记牢：数据权限由 Unity Catalog 管，不由 workspace 管。同一个 workspace 里的两个用户，能不能读某张表，取决于 UC 的授权，而不是他们是否在同一个 workspace。反过来，不同 workspace 的用户，只要 UC 授权一致，就能访问同一张表。这正是跨团队协作的基础。

• Account（账户）：最顶层，管理所有 workspace、用户、身份联邦（SCIM）、以及 Unity Catalog 的 metastore 归属。
• Metastore：UC 的元数据容器，一个 region 一个 metastore，可挂载多个 workspace。它保存 catalog、schema、table、view、volume、function 以及权限。
• Unity Catalog：三层命名空间 catalog.schema.object，提供统一权限、血缘、审计、数据发现。它是跨团队协作的“信任中枢”。
• Workspace：团队日常进入的界面，包含 notebook、job、dashboard、cluster 配置。它是“操作台”，不是“权限边界”。
• Compute：执行引擎，分 all-purpose cluster（交互式、贵、适合探索）和 job cluster（调度式、便宜、适合生产）。
• Notebook：开发与探索载体，支持 Python/SQL/Scala/R，可挂载到不同 compute。
• Job：把 notebook 或 jar 变成可调度、可重试、可监控的生产任务。
• Dashboard：面向消费方的可视化交付物，可绑定 SQL warehouse 或 compute。

端到端协作链路

下面这张图把“数据生产 → 治理 → 消费”串起来，重点看数据流方向和权限控制点。生产团队在 workspace A 用 notebook 加工数据，写入 UC 管理的表；治理层在 metastore 中登记元数据与授权；消费团队在 workspace B 通过 job 或 dashboard 读取同一张表。整条链路中，workspace 只是入口，UC 才是权限与元数据的唯一权威。

各组件在协作中的实际角色

Workspace 是“操作台”，不是“权限边界”。很多团队误以为把表建在某个 workspace 里，就只有这个 workspace 的人能看。实际上，只要表注册在 UC 中，任何被授权的 workspace 用户都能访问。因此，跨团队协作时，应该先约定好 catalog 和 schema 的命名规范，而不是各自在 workspace 里“圈地”。

Metastore 是“区域级”的。一个 metastore 通常绑定一个云区域，可以挂载多个 workspace。这意味着同一区域内不同 workspace 的团队，天然共享同一套元数据。如果两个团队在不同区域，就需要考虑数据复制或跨区域访问策略，这是架构设计阶段就要明确的。

Unity Catalog 是“信任中枢”。它提供三层命名空间、细粒度权限（catalog/schema/table/column 级）、动态数据掩码、行级过滤、血缘追踪和审计日志。跨团队协作时，推荐的做法是：生产团队拥有 prod catalog 的写权限，消费团队只拿到 SELECT 权限，敏感列通过掩码函数处理。这样既共享了数据，又守住了边界。

Compute 是“执行引擎”，分两类。All-purpose cluster 适合交互式探索，成本高、启动慢，但支持多人共享和 notebook 附加；Job cluster 适合生产调度，按需创建、任务结束即释放，成本低。跨团队协作时，生产任务应使用 job cluster，避免占用交互式集群资源。

Notebook 是“开发载体”。它本身不保存权限，也不决定数据归属。一个常见误区是把 notebook 当成“数据资产”来共享——实际上，真正需要共享的是 notebook 里产出的表，而不是 notebook 文件本身。跨团队时，应该共享 UC 中的表或 view，而不是复制 notebook。

Job 是“生产化封装”。把 notebook 挂到 job 上，就获得了调度、重试、告警、参数化能力。跨团队协作中，生产团队通常把加工逻辑封装成 job，按小时或按天产出表；消费团队则通过自己的 job 或 dashboard 读取这些表。Job 的权限同样由 UC 控制，运行身份（service principal 或用户）决定了它能读写哪些表。

Dashboard 是“消费端交付物”。它面向业务方，绑定 SQL warehouse 或 compute，读取 UC 中的表。Dashboard 的权限可以独立于底层表权限进行管理，但最终仍受 UC 授权约束。跨团队时，建议消费团队基于生产团队发布的 view 或 gold 层表构建 dashboard，而不是直接查原始表。

一个可参考的协作链路示例

假设某公司有两个团队：数据工程团队（DE）和业务分析团队（BA）。DE 在 workspace ws-de 中开发，BA 在 workspace ws-ba 中消费。两者挂载同一个 metastore。

-- DE 团队：创建并授权
CREATE CATALOG IF NOT EXISTS prod;
CREATE SCHEMA IF NOT EXISTS prod.sales;

CREATE TABLE prod.sales.orders AS
SELECT order_id, customer_id, amount, order_date
FROM raw.orders;

GRANT USAGE ON CATALOG prod TO `ba-team`;
GRANT USAGE ON SCHEMA prod.sales TO `ba-team`;
GRANT SELECT ON TABLE prod.sales.orders TO `ba-team`;

-- BA 团队：在 ws-ba 中直接读取
SELECT order_date, SUM(amount) AS gmv
FROM prod.sales.orders
GROUP BY order_date;

这段示例中，DE 团队负责建表与授权，BA 团队只拿到 SELECT。BA 在自己的 workspace 中就能查询 prod.sales.orders，无需复制数据。如果 BA 需要更细粒度的控制，DE 可以进一步用行级过滤或列掩码限制敏感字段。这就是“生产 → 治理 → 消费”链路的实际落地方式。

常见边界误区

• 把 workspace 当权限边界：以为不同 workspace 就天然隔离，结果 UC 授权一放开，数据全可见。正确做法是始终以 UC 授权为准。
• 把 notebook 当共享资产：跨团队复制 notebook，导致逻辑分叉、版本混乱。正确做法是共享 UC 表或 view。
• 用个人身份跑生产 job：人员离职或权限变更后任务失败。正确做法是用 service principal 作为 job 运行身份。
• Dashboard 直连原始表：业务方看到未清洗数据，口径不一致。正确做法是消费 gold 层或 view。