4、数据湖权限模型设计：细粒度权限设计原则、数据目录与权限映射、权限继承与覆盖策略

权限模型设计，说白了就是回答三个问题：谁？能干什么？在哪儿干？

但数据湖里，这三个问题会变得特别复杂。你想想看，一个湖里可能有几千张表、几万个文件、上百个用户。如果权限模型设计得不好，要么管得太死，业务跑不动；要么管得太松，数据裸奔。

我个人习惯把权限模型设计分成三层来思考：原则层（定规矩）、映射层（绑目录）、策略层（定继承）。这一章我们就一层一层拆开聊。

4.1 细粒度权限设计原则

先讲原则。没有原则的权限设计，最后一定会变成一团乱麻。我在项目中遇到过好几次，一开始图省事，给了一堆粗粒度权限，结果半年后根本理不清谁有什么权限。

4.1.1 最小权限原则

只给用户完成任务所需的最小权限集合。听起来简单，做起来难。

• 按需分配：用户只需要读某张表，就别给写权限。
• 时间限定：临时任务结束后，权限自动回收。
• 路径限定：只允许访问特定路径下的数据，而不是整个桶。

4.1.2 职责分离原则

数据湖里，一个人不能同时拥有「写数据」和「审批权限」的能力。这是合规审计的基本要求。

角色	允许的操作	禁止的操作
数据生产者	写入、更新	审批、删除
数据消费者	读取、查询	写入、修改结构
数据管理员	审批、审计	直接读写业务数据

4.1.3 数据分类原则

不同敏感级别的数据，用不同的权限策略。我一般分四级：

1. 公开：全员可读，无需审批。
2. 内部：仅限本部门或项目组。
3. 敏感：需要审批，且只能读脱敏后的数据。
4. 机密：仅限指定人员，且操作需审计。

4.2 数据目录与权限映射

原则定好了，接下来就是怎么把权限挂到数据上。这里的关键是数据目录。

数据湖里的数据是分散的，但权限不能分散管。你需要一个统一的目录层，把物理存储和逻辑权限解耦。

4.2.1 目录结构设计

我个人习惯用三层目录结构：

数据湖根目录
├── 数据域（如：交易域、用户域、风控域）
│   ├── 业务线（如：支付、信贷、理财）
│   │   ├── 数据表/文件
│   │   └── 分区（如：dt=2024-01-01）
│   └── 共享层（跨域通用数据）
└── 系统目录（审计日志、元数据等）

为什么要这样设计？因为权限可以按目录层级批量授予，而不是一条一条配。

4.2.2 权限与目录的绑定

数据目录和权限的映射，我建议用标签+策略的方式：

• 给目录打标签（如：敏感等级、所属部门、数据域）。
• 权限策略引用标签，而不是直接引用路径。

4.2.3 映射关系表

目录路径	标签	权限策略	适用角色
/data/交易域/支付/	内部-可读	策略B	全员
/data/风控域/黑名单/	机密-风控	策略A	风控VP
/data/用户域/隐私/	敏感-脱敏	策略C	数据科学家（脱敏后）

4.3 权限继承与覆盖策略

权限继承，说白了就是「父目录有权限，子目录默认也有」。但现实往往没这么简单。

4.3.1 继承规则

我一般用以下规则：

• 默认继承：子目录继承父目录的所有权限。
• 显式覆盖：如果子目录单独配置了权限，以子目录为准。
• 拒绝优先：如果父目录允许，但子目录明确拒绝，则拒绝。

4.3.2 覆盖策略的三种模式

模式	说明	适用场景
白名单模式	只允许显式授权的操作，其余全部拒绝	机密数据、敏感操作
黑名单模式	继承父目录权限，但拒绝指定操作	临时限制、异常处理
增量模式	在继承基础上，额外增加权限	项目特批、临时授权

4.3.3 实际案例：继承冲突怎么解？

假设有这样的目录结构：

/data/交易域/（全员可读）
├── /支付/（全员可读，继承）
├── /风控/（仅风控组可读，覆盖父目录）
└── /审计/（仅审计组可读，覆盖父目录）

用户A属于风控组，他想读「/交易域/风控/」下的数据，没问题。但他想读「/交易域/审计/」下的数据，会被拒绝。因为审计目录显式覆盖了父目录的权限。

4.4 权限模型整体架构

下面这张图，是我在项目中常用的权限模型架构。它把原则、目录、继承串在了一起。

4.5 避坑指南

最后，分享几个我踩过的坑：

• 别把权限写死在代码里：我曾经见过一个项目，权限判断逻辑散落在各个微服务中。后来要改一个权限规则，改了三天还没改全。权限一定要集中管理。
• 继承层级不要太深：超过5层的继承，基本没人能理清。我建议最多3层。
• 覆盖策略一定要有审计日志：谁在什么时候覆盖了谁的权限，必须能追溯。否则出了问题，你连锅都甩不出去。