📚 课程目录第4章 Unity Catalog权限体系

4. Unity Catalog 权限体系：Databricks 的权限模型、Securable Object 层级与 Privilege 类型

好，咱们进入 Unity Catalog 的权限核心。说白了，你要管好 Lakehouse 的数据，就得先搞懂 Databricks 是怎么定义“谁能在什么东西上干什么”的。这套体系，我称之为“三板斧”：权限模型、可保护对象层级、以及权限类型。一个一个来。

4.1 权限模型：从“扁平”到“三层”的进化

我记得最早用 Databricks 的时候，权限管理其实挺原始的。基本就是 workspace 级别的，要么是管理员，要么是普通用户，细粒度控制？不存在的。后来有了 Hive Metastore 的 ACL，但那东西性能差，而且跟 Spark 的集成很别扭。

Unity Catalog 彻底改了这套玩法。它引入了一个 三层命名空间 的权限模型：Catalog → Schema → 表/视图/函数。你想想看，这就像你公司里的组织架构：Catalog 是事业部，Schema 是部门，表就是具体的员工工位。权限可以在这三个层级上分别设置，而且下层默认继承上层的权限。

核心变化： 从“谁能在集群上跑代码”变成了“谁能在 Catalog 里看到什么数据”。权限跟计算资源解耦了，这才是 Lakehouse 该有的样子。

4.2 Securable Object 层级：一棵清晰的树

Unity Catalog 里所有能被授权的东西，都叫 Securable Object。它们天然形成一个层级结构。我习惯画一张图来理解它，你看下面这个 SVG：

嗯，这里要注意：Metastore 是根节点，但你一般不会直接给用户赋权到 Metastore 级别，那权限太大了。实际工作中，我们通常从 Catalog 开始授权。

4.3 Privilege 类型：你能干什么？

搞清楚了对象层级，接下来就是“能干什么”。Unity Catalog 的权限（Privilege）设计得很精细，我把它分成三大类：

类别	权限名称	作用说明	我常用的场景
元数据浏览	`USAGE`	允许查看对象存在，但不能读数据	给数据目录团队，让他们能看到有哪些表，但看不到数据
数据读取	`SELECT`	允许读取表/视图中的数据	给数据分析师，让他们能查表
数据写入	`MODIFY`	允许插入、更新、删除数据	给 ETL 作业，让它们能写数据
对象管理	`CREATE`	允许在 Schema 下创建表/视图	给数据工程师，让他们能建新表
对象管理	`ALTER`	允许修改对象定义（如加列、改注释）	给数据建模人员，让他们能调整表结构
对象管理	`DROP`	允许删除对象	谨慎使用，我一般只给管理员
权限管理	`OWNERSHIP`	对象所有者，拥有全部权限，且能授权给他人	创建对象的人自动获得，或者手动转移

我的一个小习惯： 给普通用户只授 USAGE + SELECT。千万别手滑给了 MODIFY，否则数据被误删了，你哭都来不及。我曾经在一个项目里，就因为图省事给了一个分析师 MODIFY 权限，结果他写 SQL 时忘了加 WHERE 条件，把整个表更新了……嗯，从那以后我都是按最小权限原则来。

4.4 实际操作：用 SQL 来赋权

理论说完了，咱们看看怎么用。Unity Catalog 支持用标准 SQL 来管理权限，这比点鼠标靠谱多了，方便自动化。

比如，我要给用户 alice@company.com 授予对 sales_db Catalog 下所有表的读取权限：

-- 第一步：先给 USAGE，让她能看到 Catalog 和 Schema
GRANT USAGE ON CATALOG sales_db TO `alice@company.com`;
GRANT USAGE ON SCHEMA sales_db.analytics TO `alice@company.com`;

-- 第二步：再给 SELECT，让她能读数据
GRANT SELECT ON ALL TABLES IN SCHEMA sales_db.analytics TO `alice@company.com`;

-- 未来新表自动继承：设置默认权限
ALTER SCHEMA sales_db.analytics SET DEFAULT PRIVILEGES
  FOR ALL USERS
  GRANT SELECT ON TABLES TO `alice@company.com`;

你看，三步走。先给 USAGE 让她能“看见”，再给 SELECT 让她能“读取”。最后那个 SET DEFAULT PRIVILEGES 是个好东西，以后在这个 Schema 下新建的表，会自动给 alice 加上 SELECT 权限，省得你每次都手动跑一遍。

避坑指南： 我曾经犯过一个错——只给了 SELECT，忘了给 USAGE。结果 alice 跑来跟我说“我查不到任何表”。我排查了半天，才发现她连 Catalog 都看不见。记住：USAGE 是“门票”，没有它，后面的权限都是白搭。

4.5 权限的继承与覆盖：一个容易搞混的点

层级权限最让人头疼的就是继承关系。我总结一个口诀：上层授权，下层生效；下层授权，覆盖上层。

举个例子：

你在 Catalog 级别给了 SELECT，那么该 Catalog 下所有 Schema 和表，用户都能读。
但是，如果你在某个表级别又给了 MODIFY，那用户在这个表上就能写数据了——这是“增加”权限。
如果你想“缩小”权限，比如某个表不想让用户读，你可以在表级别 REVOKE SELECT，或者用 DENY（如果支持的话）。

嗯，这里要特别提一下 DENY。Unity Catalog 支持显式的拒绝权限。它的优先级最高。哪怕你在 Catalog 级别给了 SELECT，只要在表级别 DENY SELECT，用户就读不了那个表。这在我们做“数据脱敏”或者“合规隔离”时特别有用。

-- 给所有人 SELECT 权限
GRANT SELECT ON CATALOG sales_db TO `account users`;

-- 但拒绝某个敏感表
DENY SELECT ON TABLE sales_db.analytics.credit_card_info TO `account users`;

这样，普通用户能看到 sales_db 下大部分表，但就是查不了信用卡信息表。干净利落。

4.6 总结一下

Unity Catalog 的权限体系，说白了就是：三层对象（Catalog-Schema-Table），一套权限（USAGE/SELECT/MODIFY/CREATE/...），加上继承和覆盖规则。 你只要记住“最小权限”和“USAGE 是门票”这两条，基本不会出大错。

我个人觉得，这套设计比传统的 Hive ACL 或者 Ranger 要清晰得多。它跟 SQL 标准结合得很好，学习成本低。你只要会写 GRANT 语句，就能搞定大部分场景。