📚 课程目录第4章 Catalog资源模型

4. Catalog资源模型：Catalog、Schema、Table、Column、Function、Resource的层级关系

聊权限模型之前，得先把资源长什么样搞清楚。说白了，你要管谁能不能访问什么，总得知道「什么」是怎么组织的。

我刚开始接触数据平台时，最头疼的就是这堆概念——Catalog、Schema、Table……它们到底谁套谁？后来在项目里被坑过一次，才真正理解了这个层级结构的重要性。

你可以把整个资源模型想象成一棵倒挂的树。根在最上面，叶子在最下面。权限就是从根一路往下传递的。

核心层级（从上到下）：

嗯，这里要注意：不同引擎的叫法可能略有差异。比如Hive Metastore里叫Database而不是Schema，但逻辑是一样的。

Catalog是权限控制的第一道门。我习惯把它理解成「数据域」——一个完全隔离的命名空间。

举个例子，你在一个平台上有两个Catalog：prod_catalog 和 dev_catalog。生产环境的数据和开发环境的数据完全隔开。你在 prod_catalog 里看不到 dev_catalog 的任何东西，除非管理员显式授权。

我的经验： 在大型企业中，Catalog通常对应业务线或环境。比如「金融线Catalog」「风控线Catalog」。这样做的好处是——权限边界清晰，一个Catalog的误操作不会影响另一个。

Catalog下面就是Schema。Schema的作用是进一步细分命名空间。比如在 prod_catalog 下，你可以建 sales、marketing、hr 三个Schema。

我曾经遇到过一个项目，所有表都堆在同一个Schema里，结果权限配置变得极其混乱——你没法精确控制「这个团队只能看销售数据」，因为表和表之间没有逻辑隔离。后来我们重构了Schema设计，把不同业务域拆开，权限配置瞬间清爽了。

避坑指南： 不要把所有表都塞进一个Schema。哪怕你暂时觉得「反正权限在Catalog级别控制」，但未来业务扩张后，Schema级别的细粒度控制会让你少掉很多头发。

Table是权限控制的核心对象。大部分场景下，你给用户授权就是授权到表级别。

但Column级别的权限也很常见。比如一张用户表里有 user_name、email、phone、credit_card 四列。普通分析师只能看 user_name 和 email，而风控团队才能看 phone 和 credit_card。

我建议你在设计权限模型时，优先考虑Table级别。Column级别虽然灵活，但配置成本高，而且查询性能会有轻微损耗——因为引擎需要做列级别的权限校验。

粒度	适用场景	配置复杂度	性能影响
Catalog	环境隔离、业务线隔离	低	无
Schema	业务域分组	低	无
Table	日常数据访问控制	中	轻微
Column	敏感字段脱敏、合规要求	高	有（需逐列校验）

Function和Resource在权限模型里经常被忽略，但实际项目中它们很重要。

Function 指的是UDF（用户自定义函数）或存储过程。为什么需要权限控制？因为函数可以访问数据。如果一个用户没有表的查询权限，但他能调用一个封装了查询逻辑的函数，那就绕过了权限控制。我见过有人利用这个漏洞「曲线救国」——所以Function的权限必须和Table一样严格管理。

Resource 涵盖的范围比较广：模型文件、外部存储路径、甚至是一些配置资源。在AI平台或数据湖场景下，Resource权限越来越重要。比如一个训练好的模型文件，不是所有人都能下载的。

一句话总结： Catalog是房子，Schema是房间，Table是柜子，Column是抽屉里的格子。Function和Resource是房间里特殊的「保险箱」——同样需要上锁。

下面这张图把整个层级关系画清楚了。我建议你保存下来，后面讲权限继承时会反复用到。

这个层级结构最核心的特性就是权限继承。什么意思？

如果你给一个用户授予了 prod_catalog 的读权限，那么他自动拥有这个Catalog下所有Schema、所有Table、所有Column的读权限。不需要逐级配置。

反过来，如果你只给了某个Table的权限，那他就只能看到这个Table，看不到同Schema下的其他表。

我的建议： 权限配置遵循「最小够用」原则。能配在Table级别就别配在Catalog级别。虽然Catalog级别省事，但风险也大——万一误操作，整个Catalog的数据都暴露了。

我曾经在一个金融项目里，管理员图省事，把整个Catalog的读权限给了所有分析师。结果一个实习生不小心把敏感客户数据导出到了个人电脑……嗯，后面的事情你懂的。从那以后，我坚持Table级别的权限控制，哪怕配置工作量大一点。

最后分享一个我在项目中常用的层级设计模板，供你参考：

这个模板不是银弹，但能覆盖80%的场景。剩下的20%需要根据你公司的组织架构和数据敏感度来微调。

最后提醒一句： 层级越深，权限配置越灵活，但管理成本也越高。别为了追求「完美」而把模型搞得过于复杂。够用就好。