1、Catalog权限模型概述
什么是Catalog
先聊聊Catalog这个词。说白了，它就是数据资产的「目录册」。
你想想看，一个企业里数据散落在各个系统——Hive表、Kafka Topic、ClickHouse集群、S3文件……没有Catalog，你连自己有什么数据都搞不清楚。我最早接触数据平台时，就遇到过这种尴尬：业务方问「咱们有没有用户画像表」，我得翻三四个系统才能确认。
Catalog的核心作用就两个：找得到、管得住。
- 找得到——统一注册所有数据资产，提供搜索、血缘、元数据
- 管得住——通过权限模型控制谁能看、谁能改、谁能删
嗯，这里要注意：Catalog不是简单的「表清单」。它包含库、表、字段、分区、标签、生命周期……是一个完整的元数据管理体系。
为什么需要权限模型
Catalog建好了，数据都登记上去了。然后呢？
没有权限模型，Catalog就是个「裸奔」的系统。谁都能看所有表，谁都能改元数据，谁都能删分区——这在生产环境里是灾难。
我亲身经历过一个事故：某同事在测试环境误删了生产库的Catalog元数据，导致整个数据平台三天不可用。原因？当时Catalog没有权限控制，任何人都有删除权限。
权限模型要解决三个核心问题：
- 认证——你是谁？（身份识别）
- 授权——你能干什么？（权限判定）
- 审计——你干了什么？（操作追溯）
一句话总结：权限模型是Catalog的「门禁系统」。没有它，数据资产就是敞开的保险柜。
权限模型的核心要素
我习惯把权限模型拆成四个要素：用户、角色、权限、资源。它们之间的关系，可以用一张图说清楚。
1. 用户（User）
用户就是访问Catalog的实体。可以是人，也可以是服务账号。
我在项目中见过最典型的坑：把服务账号和个人账号混在一起管理。结果离职的人账号一删，ETL任务全挂了。所以，用户必须区分「自然人」和「服务」，权限策略完全不同。
2. 角色（Role）
角色是权限的「容器」。它把一组权限打包，然后分配给用户。
为什么需要角色？直接给用户授权不行吗？
行，但维护成本极高。100个用户，每人单独授权，改一次权限要改100次。有了角色，你只需要改角色定义，所有关联用户自动生效。
我的建议：角色设计遵循「最小权限原则」。不要搞一个「超级管理员」角色包打天下。拆成「数据读取者」「数据写入者」「元数据管理者」等细粒度角色，更安全、更灵活。
3. 权限（Privilege）
权限定义了对资源的具体操作。常见的权限类型：
| 权限类型 | 说明 | 示例 |
|---|---|---|
| SELECT | 读取数据 | 查询表内容 |
| INSERT | 写入数据 | 向表追加记录 |
| ALTER | 修改元数据 | 修改表结构、添加分区 |
| DROP | 删除资源 | 删除表或分区 |
| OWNER | 完全控制权 | 包含所有操作，可转授 |
嗯，这里有个细节：权限是有「粒度」的。有的系统只支持库级权限，有的支持表级，甚至字段级。粒度越细，管理越灵活，但配置复杂度也越高。我一般建议：先粗后细，从库级开始，有需求再细化。
4. 资源（Resource）
资源就是Catalog管理的数据资产。常见的资源层级：
- Catalog —— 顶层命名空间，类似数据库实例
- Database —— 逻辑数据库，一组表的集合
- Table —— 数据表，核心数据载体
- Column —— 字段，最细粒度的数据单元
- Function / Model —— 函数、机器学习模型等扩展资源
我曾经踩过的坑：资源层级设计不合理。一开始只设计了「表」级资源，后来业务需要字段级权限控制，不得不重构整个权限模型。所以，资源层级一定要预留扩展性，哪怕初期只用表级，也要在模型上支持字段级。
四个要素如何协同工作
我习惯用一个实际场景来说明：
假设有个数据分析师叫小明。他需要读取「订单表」的数据。
- 系统识别小明是用户（User）
- 小明被赋予「数据分析师」角色（Role）
- 该角色绑定了「SELECT」权限（Privilege）
- 该权限作用于「订单表」这个资源（Resource）
整个过程，小明只知道自己能查订单表。他不知道背后有角色、权限这些概念。这就是权限模型的价值——对用户透明，对管理员可控。
核心要点：用户 ↔ 角色 ↔ 权限 ↔ 资源，四层模型解耦了「谁」和「能做什么」的直接关系。角色是中间的「胶水层」，让权限管理从「点对点」变成「点对面」，可维护性大幅提升。
好了，这一章就聊到这儿。Catalog权限模型的核心骨架你已经清楚了。后面我们会深入每个要素的设计细节和实战经验。