Delta Lake 基础安全模型：用户与角色、权限模型、数据访问控制层级
聊安全，得先搞清楚“谁”能对“什么”做“哪些操作”。Delta Lake 的安全模型，说白了就是一套规则，用来回答这三个问题。我见过不少团队，一上来就搞加密、审计，结果基础的用户和角色都没理清楚，最后权限乱成一锅粥。嗯，咱们今天就把地基打牢。
2.1 用户与角色：谁在操作？
在 Delta Lake 的生态里，用户不是直接跟数据打交道的。用户先被映射成“主体”（Principal），然后主体再绑定“角色”（Role）。角色才是权限的载体。
我个人习惯把用户分为三类：
- 数据管理员：负责建表、授权、管理元数据。权限最大，但操作频率最低。
- 数据工程师：负责 ETL、写数据、修数据。需要读写权限，但一般不能删库。
- 数据分析师：只读用户，跑查询、做报表。权限最小，但并发最高。
你想想看，如果让分析师也能删分区，那离事故就不远了。我曾经在一个项目中，就因为角色划分不清，分析师误操作删了历史分区，导致整整两天的数据要重跑。从那以后，我强制要求每个用户必须通过角色才能访问数据，绝不直接授权。
2.2 权限模型：RBAC vs ABAC
权限模型主要有两种：RBAC（基于角色的访问控制）和 ABAC（基于属性的访问控制）。Delta Lake 两者都支持，但适用场景不同。
| 特性 | RBAC | ABAC |
|---|---|---|
| 授权粒度 | 粗粒度（角色级别） | 细粒度（属性级别） |
| 管理成本 | 低，角色固定 | 高，需要定义属性规则 |
| 灵活性 | 一般，角色变更需重新授权 | 高，动态匹配属性 |
| 典型场景 | 部门隔离、环境隔离 | 数据脱敏、行级过滤 |
RBAC 适合大多数团队。比如“数据工程师”角色可以读写所有表，“分析师”角色只能读。简单、清晰、好维护。
ABAC 则更灵活。比如你可以定义一条规则：“只有用户所在部门等于数据所属部门时，才能看到该行数据”。这在金融、医疗等强合规场景下非常有用。
我记得有一次帮一个银行客户做数据安全方案，他们要求不同支行的员工只能看到自己支行的交易记录。用 RBAC 的话，得为每个支行建一个角色，支行一多就炸了。后来改用 ABAC，在数据写入时打上“branch_id”标签，查询时自动过滤，问题迎刃而解。
2.3 数据访问控制层级
Delta Lake 的访问控制是分层的。从大到小，依次是：
- Catalog 级别：控制谁能访问整个 Catalog（相当于数据库实例）。
- Schema 级别：控制谁能访问某个 Schema（相当于数据库）。
- Table 级别：控制谁能读写某张表。
- Partition 级别：控制谁能访问某个分区（比如某天的数据）。
- File 级别：控制谁能访问底层 Parquet 文件。
层级越高，控制范围越大，但粒度越粗。层级越低，控制越精细，但管理复杂度也越高。
我个人的经验是：尽量在 Table 级别做控制。Catalog 和 Schema 级别太粗，容易误伤；Partition 和 File 级别太细，维护起来想哭。Table 级别刚刚好，既能隔离数据，又不会让权限表爆炸。
2.4 知识体系总览
下面这张图，把 Delta Lake 的基础安全模型串起来了。你可以把它当作本章的“地图”。
2.5 实践建议：如何选择？
说了这么多，到底该怎么落地？我总结了几条经验：
- 团队小于 50 人：直接用 RBAC，建 3-5 个角色就够了。别搞复杂了。
- 团队大于 50 人且有合规需求：RBAC + ABAC 混合使用。RBAC 管大方向，ABAC 管细节。
- 控制层级：默认用 Table 级别。如果表数据量极大（比如每天新增几十亿行），再考虑 Partition 级别。
- 审计日志：无论选哪种模型，一定要开启审计日志。出了问题，得有据可查。
我曾经在一个数据中台项目中，团队一开始用了纯 RBAC，后来业务方要求“不同渠道的数据只能被对应渠道的运营看到”。没办法，只好在 Table 级别加了一层 ABAC 属性过滤。虽然改起来费了点劲，但好在 Delta Lake 的权限模型足够灵活，没动底层架构。