深色模式
第二章 上手:登录、角色与你的第一次进入
新账号刚到手,第一件事往往不是"我要做什么",而是"我登进去之后,会看到什么、又为什么是这些"。本章带用户走完最开始的三步:先看懂整个平台的全局地图、登录进系统看懂自己被分到的角色、完成第一次工作台巡视。走完这三步,用户就能回答一个关键问题——"眼前这些菜单,是平台给我划定的作业范围;别人看到的和我不一样,是设计使然,不是出错。"
本平台把"数据接进来 → 治理好 → 建成模型和规则 → 发布成对外 API"收敛成一条流水线,由三大模块拼成:数据中台 → 决策引擎 → 数据网关。登录后,这三大模块就是侧边菜单的三个主分区。理解这条流水线,是理解"我该去哪个模块做哪件事"的地图。
mermaid
flowchart LR
A["数据中台<br/>接入 · 建模 · 治理 · 编目"] -->|喂数据| B["决策引擎<br/>指标 · 模型 · 规则 · 决策流"]
B -->|发布| C["数据网关<br/>注册应用 · 绑定路由 · 鉴权"]
C -->|一次 HTTP 调用| D["下游业务系统"]2.1 全局地图:一个平台、三大模块、一条流水线
第一次进入之前,先花两分钟建立全局认知。理解了"平台是什么形态、三块各干什么、一条数据从头到尾怎么流",后面每一步操作才有来由,不至于点到哪算哪。
2.1.1 产品一句话定位
场景:传统做法里,"原始数据"和"业务系统能直接消费的风控决策"之间,隔着建模、工程化、发布、鉴权好几道墙,每道墙都要一拨人接力。
是什么:本平台是一个把"接进来 → 治理好 → 建成模型和规则 → 发布成对外 API"整条链路收敛进一个闭环的一体化风控数据平台。它在成熟的数据中台形态之上,内置了决策引擎与数据网关,让"数据"能直接变成"业务系统一次 HTTP 调用就能拿到的风控结论"。
为什么:链路收敛进一个平台后,下游业务方不必再关心中间的建模、发布、鉴权,只需发起一次带应用凭据的 HTTP 调用,即可拿回一个决策结论加一个分数。通俗来讲,平台把"从一堆库表到一句业务结论"这段长路,替下游走完了。
怎么组织:整条链路由三大模块拼成一条流水线——数据中台产出干净数据,决策引擎把数据变成能出结论的打分逻辑,数据网关把逻辑安全地发布成对外 API。
说明: 平台当前形态是批处理平台,暂不含实时流式能力;底层数据存储采用列式分析型数仓引擎(列式存储、向量化执行、秒级查询),这也是后文"引擎级脱敏"能成立的技术前提。
说明: 想直观感受产品规模,登录后停在工作台首页即可——左侧三大模块的菜单分区一次铺开,就是这条流水线的三段。
2.1.2 三大模块各解决什么
是什么:这三块正是上面那条流水线的三段,各解决一件事。
- 数据中台——把散落在各处的库表接进来,按数仓分层建模,定标准、查质量,再编成资产目录。通俗来讲,它负责"让平台里始终有一份干净、及时、能用的数据"。
- 决策引擎——把中台的数据变成"能出结论的逻辑"。它用指标定义可复用口径,用模型算概率,用规则集把概率翻译成业务结论,再用决策流把"取数 → 跑模型 → 过规则 → 出结论"编排成一条可视化流程。通俗来讲,它负责"会判断"。
- 数据网关——把决策引擎发布出来的能力安全地开放给下游,管住"谁能调、走哪条路由、怎么鉴权"。通俗来讲,它负责"安全地对外"。
为什么按这个顺序:三块串成一条有向的流水线,前一块的产出是后一块的输入——数据中台到决策引擎是"喂数据",决策引擎到数据网关是"对外开放"。理解了这条方向,就知道"建模找决策引擎、开放找数据网关、找不到数据源先回数据中台"。
注意: 三块虽是一条流水线,但资源可见性各自受角色与资源层授权约束。举例来说,只做决策或只管网关的人,未必看得到数据中台的数据源下拉——这是设计使然的隔离,不是缺陷(详见第 2.5 节)。
2.1.3 一条数据的一生:一次信贷评分的端到端时序
场景:把三大模块串成一个具体故事,最容易记住。下面用"一笔信贷申请从提交到出分"走一遍。
是什么:平时数据中台每天定时把业务库同步进数仓、加工成特征宽表;请求来时,经网关鉴权 → 转发决策流 → 跑模型算概率 → 规则集给结论 → 网关把出分送回下游。
平时(数据中台,每天自动跑):业务库通过数据同步任务每天定时(如 02:30)搬进数仓贴源层(ODS),再经两个 SQL 加工任务:ODS → DWD(去重、类型规整、标准化、挂数据元与脱敏)、DWD → DWS(按申请人汇总成特征宽表)。治理侧已给 DWD 的证件号、手机号配好引擎级列脱敏,给关键字段配好质量规则。结果:数仓里始终有一份干净、及时、可训练可打分的数据。
运行时(一次真实调用):
mermaid
sequenceDiagram
participant 下游 as 下游业务系统
participant 网关 as 对外业务网关
participant 决策 as 决策流
participant 模型 as 评分模型
participant 规则 as 规则集
下游->>网关: POST /score/credit + X-APP-ID + X-API-Key + 特征JSON
网关->>网关: 校验 apiKey 与「应用—路由」绑定关系
网关->>决策: 转发请求(切成打分服务身份执行)
决策->>模型: 传入 age/income/debt_ratio/overdue_count
模型-->>决策: 通过概率=0.7448
决策->>规则: 概率 + 负债率 → 命中规则
规则-->>决策: 决策=通过, 准入分=90
决策-->>网关: 返回 决策结论 / 分数 / 通过概率
网关-->>下游: 出分原样返回打分流用谁的身份执行:已发布的对外打分 API 不借用超管,而是切到一个专用的打分服务账号(演示环境是 svc_scoring,昵称"打分服务身份")上执行——角色与权限按该账号的真实画像现取,取不到就直接拒绝执行,不回落超管。这解决的是"外部消费方没有平台账号、取数会断链"的问题:下游只有 apiKey,平台内部得有一个具体的人头来承接权限判定。
重要提示: 打分服务账号是最小权限身份,不是"看什么都明文"的特权身份。它要读中台数仓的哪张表,就得像普通受让人一样被显式授权到那张表;它看到明文还是掩码,同样由 2.5 讲的那套脱敏口径决定(演示环境给它的那条授权没配列脱敏,所以读到的是明文)。搭新打分流时忘了给这个账号授权,表现就是流程跑到取数那一步失败——不是模型的问题。
说明: 上图信贷 demo 的四个特征(age / income / debt_ratio / overdue_count)由下游请求体直接传入
ml/execute与rule/execute,全程不读数仓。决策流的节点类型只有开始 / 结束 / 规则集 / 分支 / 子流 / 机器学习模型六种,并没有"读数仓表"这类节点;要给打分流喂中台数据,靠的是上游把数据算成指标 / 宽表,或由下游在请求体里直接传。
验证:同一条链路对四种申请画像会给出可复现的决策——优质(负债 0.3、无逾期)→ 通过、分 90;高逾期(逾期 4 次)→ 拒绝、分 20;高负债(负债 0.75)→ 拒绝、分 20;边缘(概率不足 0.5)→ 拒绝、分 40。跑出这组结果,即证明三块协同链路已通。
说明: 这一节只求"看懂全局";真正把这条链路一环一环搭出来,是后续章节的内容。本章接下来先解决"怎么进、进去看什么"。
2.1.4 谁在用:五个部门的协作画像
是什么:平台面向五个部门——三个建设部门(数据管理部、风险管理部、信息科技部)供数据、出模型、编流程发布,两个业务线部门(信贷业务部、金融市场部)消费分数。整条流水线的分工如下。
| 部门 | 主要作业 | 落到哪个模块 |
|---|---|---|
| 数据管理部 | 接入数据源、建数仓分层、定标准/质量/脱敏、编目;审批他人的数据申请与建表工单 | 数据中台 |
| 风险管理部 | 用模型算概率、用规则集/评分卡给结论、编决策流;拍板阈值与模型上线 | 决策引擎(模型/规则/决策流) |
| 信息科技部 | 定指标口径、把模型与规则编成打分流、发布成对外 API 并对接下游 | 决策引擎(指标/流程)+ 数据网关 |
| 信贷业务部 / 金融市场部 | 平台只读需求方,可登录只读浏览但不建模;作下游消费方经网关应用凭据调用对外 API 取分 | 数据网关(消费侧) |
| 平台/租户管理员 | 菜单下发与安全策略收口 | 平台管理 + 各模块安全动作 |
为什么按部门分工:同一个动作换个部门,权限边界就变了;而且"建数仓、定指标、出模型规则、编打分流"分属不同部门,不再由一个人一肩挑。把"谁在用"先摆清,后面"为什么他能建、我只能看"才有落点。
说明: 业务线向建设部门"提需求"属于组织流程,平台不为它建假工单;只有"申请数据 / 建表 / 数据标准 / 建指标 / 资产发布"这类数据中台侧动作,才走系统里的真实工单(见第 2.6 节)。决策引擎的规则流 / 模型发布不走审批工单,由内容层属主写权限直控、发布即刻生效。
2.2 登录:从浏览器地址到工作台
场景:管理员开好账号后,会给一个平台前端地址、一个用户名、一个初始密码。用户在浏览器打开地址,就到了登录页。
是什么:登录是进入平台的唯一入口。用户提交用户名与密码后,系统在后端完成校验,签发一枚 Token(一种带签名、可自证身份的令牌),之后每一次页面请求都带着这枚 Token,系统据此识别"当前是谁、能看什么"。平台支持多租户,每个租户是一套相互隔离的数据与配置空间,用 tenant_id 区分,开发演示环境的主租户为 000000。
为什么:登录不只是"进门",它同时决定了两件事——Token 承载身份(后续所有操作都以此人名义执行),以及菜单按角色下发(登录成功后,系统拉取当前用户的角色,据此计算出这个人能看到的菜单树)。也就是说,同一个登录页,不同的人进去后看到的是不同的系统。
怎么做
- 在浏览器打开管理员提供的平台前端地址,进入登录页。
- 在用户名输入框填入账号,在密码输入框填入密码。
- 若为多租户部署,按管理员告知在租户处选择;单租户部署通常无需选择。
- 点击登录按钮提交。
登录页各输入项含义如下:
| 参数名称 | 描述 |
|---|---|
| 用户名 | 1. 由管理员在平台管理中创建并分发;2. 演示环境按五个部门预置了一批账号,常用代表账号有 data_admin(数据管理部)、dwh_lin(数仓组建表)、model_zhao(风险管理部建模)、dev_engineer(信息科技部编打分流)、credit_biz / stock_biz(信贷 / 金融市场业务线消费)(第 2.6 节详解)。 |
| 密码 | 1. 由管理员设置;2. 演示环境各账号的初始密码统一为 <初始密码>;3. 首次登录后建议尽快修改,初始密码不宜长期沿用。 |
| 租户 | 1. 单租户部署时通常无需选择,系统默认落到主租户;2. 多租户部署时按管理员告知选择,开发演示主租户为 000000。 |
验证:提交后页面跳转到工作台首页,左侧出现菜单分区,即表示登录成功、Token 已签发、菜单已按角色下发。若停留在登录页并提示账号或密码错误,核对账号与密码大小写后重试。
说明: 平台由多个后端服务组成,登录、菜单、用户信息等请求都经由统一的平台统一网关转发(认证走
/auth前缀,用户与菜单走/system前缀,其中获取当前用户菜单与权限的接口在/system下)。这些是系统内部路由,用户无需关心;实际地址与端口随部署环境而定,以运维《运行说明》为准。
重要提示: 如果管理员刚为某账号调整了角色或权限,而该账号登录后页面没有变化,多半是权限缓存尚未刷新——平台会把用户的权限画像缓存一段时间(有效期较长)以提升性能。此时需让该用户重新登录;若是在数据库侧直接改的角色,还需先清理对应用户的权限缓存,再重新登录才会生效。
2.3 第一次进入:工作台首页与三大模块导览
场景:登录成功,画面停在工作台首页。新用户最想知道的是"这么多菜单,哪块是干什么的、我该从哪进"。
是什么:工作台首页是登录后的落地页。它左侧是三大模块的菜单分区,让新人对产品规模有一个直观的第一印象,同时也是"该去哪个模块做哪件事"的导航起点。
菜单是怎么组织的:平台的菜单固定分为五个顶层分区,它们就是侧边栏最外层的五项。先记住这五项,就知道任何一件事该往哪儿找:
| 顶层分区 | 下面有什么 | 什么时候进它 |
|---|---|---|
| 数据中台 | 8 个二级目录(数据开发、数据资产、自助分析、数据标准、数据模型、指标引擎、数据安全、数据质量),共 31 个可见页面,是页面最多的一块 | 接数据、建模、定标准、查质量、编目、配同步与调度 |
| 决策引擎 | 没有二级目录,5 个页面直接挂在分区下:内容管理、规则集、规则流、模型管理、策略实验室 | 建模型、写规则、编决策流、跑策略实验 |
| 数据网关 | 同样没有二级目录,5 个页面直接挂在分区下:路由管理、上游服务管理、客户端管理、密钥管理、插件模版 | 注册应用、配路由、发密钥、对外开放 |
| 流程中心 | 流程设计(流程定义、流程分类)、流程实例、系统配置(表单管理、流程监控),共 5 个可见页面 | 看和管工单流程本身 |
| 平台管理 | 系统管理(9 页)、租户管理(2 页)、调度中心(3 页) | 开账号、配角色、下发菜单、管租户,见 2.3.4 |
注意: 「数据网关」下面没有「网关管理」这一层中间目录——五个页面是直接挂在顶层分区下的。找路由就点"数据网关 → 路由管理",别照着"数据网关 → 网关管理 → 路由管理"这条路径去找。
菜单树本身分三级,每一条菜单记录都属于其中一类。这三类不只是显示上的差别,它们在"授权时勾了会发生什么"上完全不同:
| 级别 | 是什么 | 授给角色后会怎样 |
|---|---|---|
| M(目录) | 一组功能的分区,点开是子菜单而不是页面。全平台 29 条 | 只在侧边栏里撑出一层分区。只授目录、不授它下面的页面,侧边栏会留下一个点开是空的分区 |
| C(页面) | 真正能打开、能操作的功能页面,必须配组件路径。全平台 77 条,其中显示 60 条、隐藏 17 条 | 页面出现在侧边栏。一个页面出不出现,只由它自己这一条被没被授权决定——授了它所在的目录、或授了它里面的按钮,都不会把这一页带出来 |
| F(按钮) | 页面内的一个操作(新增 / 编辑 / 删除 / 运行 / 发布…),没有路由也没有页面,只有权限标识有意义。全平台 405 条 | 前端据此决定按钮显不显示,后端据此决定接口放不放行。授按钮不会顺带把它所在的页面带出来 |
每一项权限用一个权限标识表达,形如 模块:资源:动作。举几个例子:standard:element:add 表示"数据标准—数据元—新增",asset:map:catalog 表示"数据资产—数据地图—目录"。按钮级动作通常是 list(列表)、query(查看)、add(新增)、edit(编辑)、remove(删除)、run(运行)、publish(发布)等。用户能不能看到某个页面、能不能点某个按钮,归根结底就是"当前角色有没有对应的权限标识"。三种菜单类型的完整配置项(是否显示、是否外链、是否缓存等)见 2.4.9,权限标识的写法与各种动作后缀见 2.4.10。
为什么强调这一点:第一次进入时,新用户常见的困惑是"某位同事的截图里有的菜单,我这里没有"。这不是缺陷——菜单是按角色下发的,看不到,通常意味着当前角色没有被授予那块菜单。理解了这一层,后面所有"我为什么看不到 / 点不动"的问题都能自查。
说明: 数据资产模块的页面在近期做过收敛,现保留三页——数据地图(总览与目录)、资产治理(元数据登记)、我的数据。原先的"资产地图首页 / 数仓表导引 / 统一资产池"已合并进以上三页。因此,若某个非管理员角色对已下线页面的权限标识(如
asset:map:home、asset:map:guide)返回无权,是预期结果,不是故障。
下面把三大模块各自的子功能铺一遍,让新人知道"每块下面有哪些页面、进去大概能干什么"。这里只做导览,具体操作在各自章节展开。
2.3.1 数据中台:接入 → 建模 → 治理 → 编目
入口:侧边导航栏顶层分区数据中台。
是什么:数据中台把数据的接入、建模、治理、编目收成一条龙,使用顺序基本就是数仓的自然生长顺序。它主要提供五大能力:
- 接数据——在数据源页面新建连接并测试连通。
- 建模型表——在模型设计页面按 ODS / DWD / DWS 分层加主题域(如信贷风控
credit_risk)设计逻辑模型,预览 DDL,再以工单式建表落库。 - 定标准——在数据标准页面维护数据元、数据字典、词根、分类方案、资源目录配置,并把标准挂到字段上。
- 查质量——在数据质量页面配规则、定时校验。
- 编资产——在数据资产页面把表编成目录并浏览;在数据集成页面配库到库同步加定时任务。
几处密集字段,先在这里备个案,后文操作时可回查:
| 参数名称 | 描述 |
|---|---|
| 数仓分层 | 1. ODS(贴源,ods_ 前缀)、DWD(明细,dwd_ 前缀)、DWS(汇总,dws_ 前缀);2. 建表时按层归位,前缀即分层。 |
| 建表字段属性 | 1. 名称;2. 类型;3. 注释;4. 是否非空。 |
| 数据元字段 | 1. 中文名 / 英文名;2. elementCode;3. 定义;4. 对象类词 / 特性词;5. valueDomainType(值域类型);6. dataFormat(数据格式)。 |
| 质量规则 | 1. 规则类型 NOT_NULL / UNIQUE / RANGE / 正则;2. 阈值比较符 thresholdOp ∈ >=, <=, =, >, <。 |
注意: 有两处"模型"字样分属不同服务,别找错入口:数据中台里的模型设计(数仓逻辑模型、建表)与决策引擎里的模型(评分模型、算概率)是两个模块,菜单入口不同。
重要提示: 数据元的
valueDomainType与dataFormat是最容易漏填的两项;质量的规则在数据管理侧建、而检查由治理执行器跑,是两处,排查"规则建了却没跑"时别只盯着规则页。
2.3.2 决策引擎:指标 → 模型 → 规则集 → 决策流 → 发布 API
入口:侧边导航栏顶层分区决策引擎(五个页面直接挂在这个分区下,没有中间目录)。
是什么:决策引擎把中台的数据变成"能出结论的逻辑",支持规则与机器学习双决策。搭建顺序固定:指标 → 模型 → 规则集 → 决策流 → 发布 API。它主要提供五大能力:
- 定指标——用指标定义可复用口径(如近 3 月逾期次数、负债率)。
- 算概率——模型支持两类:机器学习模型(离线训练后导出标准化模型文件,平台在服务进程内加载执行,输入特征、输出概率)与评分卡。
- 给结论——规则集用 DSL 把模型概率翻译成业务结论。
- 编流程——决策流把"取数 → 跑模型 → 过规则 → 出结论"编排成一条可视化流程(
START → 模型节点 → 规则节点 → END)。 - 发 API——模型、规则、决策流都可发布成对外 API。
关键字段与写法:
| 参数名称 | 描述 |
|---|---|
| 指标 | 1. 类型 = 统计 / 衍生 / 复合;2. 统计方法 statMethod ∈ COUNT, COUNT_DISTINCT, SUM, AVG, MAX, MIN;3. 发布状态 publishStatus 大写 UNPUBLISHED / PUBLISHED。 |
| 机器学习模型 | 1. 只认标准化模型文件;2. 输出名 output.labelName 需对齐执行运行时合成的名称(逻辑回归输出对应 probability(1))。 |
| 规则集 DSL | 1. 字符串字面量必须用单引号;2. 相等判断用 = 而非 ==;3. 命中即 return。 |
为什么强调"接口"按钮:模型列表操作列有一个接口按钮,点开是接口文档加在线试调——这是本版新增的核心入口。不填参时,系统会按参数类型自动生成随机样例值(浮点 / 整数 / 布尔 / 日期),方便快速试调。
说明: 规则集与机器学习是串联关系,不是并列:先由模型算出通过概率,再把这个值喂给规则集出结论。出分概率后端统一最多保留 6 位小数、以 JSON 数值返回。
注意: 策略实验室的 A/B 只做并排对比,不自动判胜负——胜负由业务人依据对比结果自行判断,不要期待系统给"赢家"。
2.3.3 数据网关:注册应用 → 绑定路由 → 鉴权 → 下游消费
入口:侧边导航栏顶层分区数据网关(五个页面直接挂在这个分区下,没有中间目录)。
是什么:数据网关把决策引擎发布的 API 安全地开放给下游,管住"谁能调、走哪条路由、怎么鉴权"。它主要提供三步能力:
- 注册应用——在应用页为每个下游方建一个应用(如
RISK-CONSUMER-001),系统发 apiKey。 - 绑定路由加鉴权——把发布的 API 注册成路由(如
/score/credit)并绑定授权应用。 - 下游消费——下游一次 HTTP 调用带上双头,即可拿出分。
调用与鉴权的关键约定:
| 参数名称 | 描述 |
|---|---|
| 调用双头 | 1. X-APP-ID(应用标识)加 X-API-Key(密钥);2. 只给 key 不给应用标识,会报"缺少应用标识"。 |
| 对外路由 | 1. 类别 category=api 须带 apiConfig;2. 经请求头规则注入共享密钥头 X-Gateway-Auth;3. needAuth=true 表示走 apiKey 鉴权。 |
| 鉴权失败 | 缺应用标识 / 缺 key / 错 key / 未知应用,统一返回 401;应用合法但未被授权访问该路由(跨应用),返回 403。 |
为什么默认拒绝:路由默认必须绑定应用才能被调用,没绑定一律拒绝(fail-closed);不会因持有任意一个合法 apiKey 就通吃,跨应用也不能互调。这道默认拒绝,是"安全地对外"的底线。
注意: "网关"一词在平台里指三样不同的东西,极易混,是上手最常见的翻车点——留到第 2.7 节专门讲清。
2.3.4 平台管理:开账号 → 配角色 → 下发菜单 → 管租户
入口:侧边导航栏顶层分区平台管理。
是什么:前面三块是"干活的地方",平台管理是"决定谁能进来干活的地方"。它自己不是一个页面,点开是三个二级目录:系统管理(账号、角色、菜单、组织这四件事的配置台)、租户管理(多租户能力)、调度中心(定时任务的运行视图)。本章 2.4 讲的所有角色、菜单、数据范围概念,配置动作都落在这个分区里。
系统管理下辖九个页面,各解决一件事:
| 页面 | 这个页面解决什么问题 |
|---|---|
| 用户管理 | 建账号,把账号挂到部门、岗位、角色上。"给某人授角色"这个动作实际就在这一页做(编辑用户抽屉里的「角色」多选框),不在角色管理页 |
| 角色管理 | 定义角色、给角色勾菜单。一个人能看见哪些菜单、点得动哪些按钮,归根到底就是这一页勾出来的 |
| 菜单管理 | 维护整棵菜单树(目录 / 页面 / 按钮)和每一项的权限标识。平台上线一个新页面,先在这里登记,角色才勾得到 |
| 部门管理 | 维护组织树。它同时是数据范围的地基——"本部门""本部门及以下"这两档算的就是这棵树 |
| 岗位管理 | 维护岗位字典,挂在用户身上当标签用。岗位不参与菜单下发,也不参与数据范围计算,别指望用它控权 |
| 字典管理 | 维护下拉框取值。角色状态、菜单是否显示这些开关的中文标签就来自这里 |
| 参数设置 | 平台级参数的键值维护 |
| 文件管理 | 附件的上传下载。这是平台管理里唯一被大量业务角色用到的能力(见下方说明) |
| 客户端管理 | 维护登录客户端(客户端标识、授权类型、超时时间) |
租户管理下辖两个页面:租户管理(开通 / 停用 / 删除租户)与租户套餐管理(把一组菜单打包成套餐,决定新租户的管理员能看到什么)。这两页的详细讲解见 2.4.11。
说明: 当前有十一个业务角色被授了文件的查询 / 上传 / 下载三个按钮权限,但都没有被授「文件管理」这个页面本身。所以这些人在侧边栏里看不到文件管理,却能在别的页面里正常传附件——这是有意为之,不是漏配。
重要提示: 当前环境里,用户 / 角色 / 菜单 / 租户这几页只有超级管理员进得去——没有任何一个业务角色被授予
system:user/system:role/system:menu/system:tenant/system:dept这几组权限。也就是说,普通用户在侧边栏里根本看不到「平台管理」;要加人、改角色,得找持有超级管理员的运维或实施人员。
2.4 你能看到什么,由角色决定:角色体系总览
场景:知道了"菜单按角色下发",下一个问题自然是"那平台一共有哪些角色、我这个岗位该拿哪个"。
是什么:平台不给每个人配一堆零散权限,而是按"模块全权 + 细分职责"两层发角色,再加上管理员的套餐驱动。整体走的是"少量固定角色 + 资源级授权细化"的路子,而不是按职能拆出几十个角色。
为什么这么设计:零散权限逐项勾选,既难维护又容易配错、配漏。两层角色的好处是——需要一整块模块能力的人,一个"模块全权角色"就够用;只负责某一类事的人,拿一个可叠加的"职责角色";而真正"能看到哪张表、能不能写",交给更细的资源层授权去决定(见第 2.5 节)。这样"哪块、多深"两个维度就拆清楚了。
命名约定:角色 key 采用 role_<模块>_<范围> 的写法,用两个维度表达粒度——
- 哪一块:不带子域表示"整个模块全权",带子域表示"只负责那一小块"。
- 多深:默认可读写;带
_ro后缀表示只读。
角色体系可分三支来理解:模块全权角色、细粒度职责角色、以及 admin / superadmin。下面逐支说明。2.4.1 至 2.4.4 先把这三支的设计意图讲清楚;2.4.5 起是"逐项清单"——平台内建的每一个角色分别覆盖什么、数据范围的每一档分别怎么算、菜单和租户上每一个开关选了会发生什么,配角色时对着查即可。
说明: 命名刻意不用"高级"二字。除模块全权角色与 2.4.2 举例的那几个职责角色外,平台已建有一批子域细分角色(数仓工程师 / 指标开发 / 流程编排 / 风险规则 / 数据产品 / 测试等),并已按岗位分配用户在用(如数仓工程师
role_dwh_engineer分配给数据管理部数仓组、流程编排role_flow_orchestrator分配给信息科技部工作流组)——它们在"整块模块"之下再按一小块子域收窄粒度,供只负责某一细分环节的人使用。
2.4.1 模块全权角色(粗粒度,role_*_all)
是什么:给"需要整块模块全部菜单"的人用的三个角色。
| 角色 key | 覆盖范围 | 典型使用者 |
|---|---|---|
role_data_all | 数据中台全模块(141 条菜单绑定 = 9 个目录 + 23 个可见页面 + 3 个隐藏详情页 + 106 个页内按钮),但剔除"数据安全"里定红线的那几页 | 数据管理部数仓组工程师 |
role_decision_all | 决策引擎全模块(58 条 = 2 个目录 + 6 个可见页面 + 50 个按钮;6 页里含附带的一页「权限中心」) | 风险管理部建模人员 |
role_gateway_all | 数据网关全模块(37 条 = 1 个目录 + 5 个可见页面 + 31 个按钮) | 信息科技部网关工程师 |
怎么用:把对应模块的全部菜单一次性授给角色,用户拿到一个 role_*_all,即可进入该模块的所有页面。例如数据管理部数仓组的工程师拿 role_data_all,就能从数据源接入一路做到数据资产编目。三个角色均建在主租户 000000,数据范围 data_scope=4(本部门及子部门)。
注意:
role_data_all虽覆盖数据中台"全模块",却明确剔除了"数据安全"里定红线的那几页——数据授权、安全等级、敏感类型、数据识别、脱敏规则、数据脱敏,以及操作审计与治理工单,它一页都拿不到;唯一给了的是「数据安全 → 权限中心」,用来给自己提数据申请。也就是说,拿到模块全权,并不等于拿到"定安全红线"的权力——全局安全策略一律受管理员收口。这是"能建能改"与"能定安全红线"之间有意划出的一道界。要与 2.4.2 的
role_data_owner_share分清:后者开的不是"安全策略"的口子,而是"把我自己的表给谁用、遮哪几列"这件属主本职的事,并且被归属守卫牢牢限制在自己的资源上。集中收口的是红线,下放到属主的是自己那份数据的处置权。
2.4.2 细粒度职责角色(可叠加)
是什么:只负责某一类事、可以和模块全权角色叠加的资源角色。下表举例说明几个常用的:
| 角色 key | 中文名 | 管什么 | 典型使用者 |
|---|---|---|---|
asset_governor | 资产治理员 | 标准、资产、质量三类元数据的登记与治理 | 数据治理岗 |
asset_consumer | 资产消费者 | 浏览、订阅、收藏资产 | 需要"查数据"的业务/分析岗 |
security_auditor | 数据安全审计员 | 合规审计岗,持有"全平台授权视图"(授权列表不做收敛);另可按需登记进脱敏白名单换取免脱敏 | 合规/审计岗 |
gov_approver | 治理审批人 | 审批"建表/指标/标准/资产"的发布工单与跨部门数据申请 | 部门内的审批负责人 |
role_data_owner_share | 数据中台-属主分享 | 打开数据授权页,把自己是属主的表分享给别人,并在分享时对指定列配脱敏 | 建过表、需要把数据给同事用的人 |
role_data_read | 数据中台-消费分析 | 数据中台里"只查不建"的那一档:检索资产、看元数据、跑自助分析 | 只需要用数、不建表的业务/分析岗 |
role_data_dept | 数据中台-部门自治 | 部门内自建自管:建表用数之外,还内含 role_data_owner_share 的整套分享菜单 | 在本部门内既建表、又要把表分享出去的骨干 |
怎么用:按岗位职责授予,并可与模块全权角色叠加。例如一位既要建模、又兼任审批的人,可同时持有 role_data_all 与 gov_approver;一位建了表又要把表给别人用的人,叠加 role_data_owner_share(部门自治角色 role_data_dept 已内含这套菜单,不必重复挂)。
说明: 上表是举例,不是全量清单;开发演示环境里实际存在的每一个角色,连同它覆盖哪些页面、当前挂了几个账号,见 2.4.5 的逐条清单。这一层的角色会随平台演进增减,划分口径也不止一种(有的按职责切,有的按覆盖面切),因此不必记数量——具体环境里有哪些角色、各自覆盖多少菜单,以角色管理页的实际列表为准。2.4.1 末尾提到的那批子域细分角色(数仓工程师、指标开发、流程编排等)同属这一层。挑角色时按"这个岗位实际要做哪几件事"对号入座即可。
注意:
role_data_owner_share只是"门",不是"墙"。拿到它并不等于能授权任何表——服务层还有一道归属守卫:非超管发起授权时会核对这张表是不是自己建的,不是就直接拒。所以这个角色授给谁都不会扩大越权面,详见 2.5.1。
说明: 细粒度职责角色的边界是"职责本职"而非"全模块"。举例来说,
asset_governor只覆盖治理本职(标准 + 资产 + 质量)数十项菜单,而不含静态脱敏这类安全动作——这处仍归管理员。asset_consumer是"只想查一下"的最小消费角色。
注意: 免脱敏白名单是按角色 + 按库登记的,不是"挂上某个角色就全平台明文"。开箱状态下,对中台数仓全库放行的白名单只有超级管理员一条;
security_auditor要在某个库上免脱敏,得由管理员把它连同那个库一起登记进去,否则该角色读中台数仓与常人无异(按 2.5.2 的三档判定)。排查"审计岗为什么还是掩码"时,先核对白名单里那条记录的库名对不对得上。
重要提示:
gov_approver这个角色 key 与后端审批逻辑存在耦合——多个业务(数据元、建表、资产、指标)的"发布审批"是按该 key 去定位审批人的,且脱敏白名单也是按角色 key 匹配放行的。因此,若运维在某环境只改了代码却未同步角色 key 的落库对齐,会出现"发布工单提交后静默找不到审批人"的现象。普通用户无需处理这一点,但排查"提了单没人能审"时,可提示运维核对该角色 key 的一致性。
2.4.3 管理员:admin 与 superadmin
平台里有两类"管理员",作用范围与放过机制不同,极易混淆,单独讲清。
admin(租户管理员):每个租户固定一个管理员角色 admin。它的菜单不是逐项手工绑定的,而是由租户套餐自动下发——套餐里勾了哪些菜单,admin 就有哪些菜单。好处是:平台新增一个菜单,只需改套餐这一处,用该套餐的所有租户的 admin 会自动同步,不必逐库手改。数据安全策略也收口在 admin,不再单拆角色。
superadmin(超级管理员):开发运维用的最高身份,处处放过、零绑定——菜单走全量加载(连隐藏页和停用项也一起下发),权限视同"通配全部"。它不参与日常业务的权限演示。
说明: "加一个新菜单是不是每个人都要手工授权"——不是。
admin跟套餐走、模块全权角色跟模块走,自动生效;只有细粒度职责角色需要单独配。
注意: 这两个标识是保留字:新建角色时不允许占用
admin/superadmin,改名时也不允许改成这两个。另外要分清"账号名"和"角色 key"——演示环境里那个叫admin的账号持有的是superadmin角色,主租户000000里根本没有admin这条角色记录;它是开通新租户时才自动创建出来的。
注意: 租户开通时自动创建的
admin角色没有设数据范围,落库为空,运行时按"仅本人"处理(见 2.4.6)。新租户的管理员如果反映"列表里只看得到自己建的东西",就是这个原因,需要运维在库侧把数据范围补上。
2.4.4 两级放过机制:superadmin 与租户 admin 的区别
理解这一点,能避免把"某人看到了明文"误判成"脱敏失效"。
| 维度 | superadmin | 租户 admin |
|---|---|---|
| 菜单/按钮层 | 全量放过,看到所有菜单 | 不放过,菜单严格来自套餐下发 |
| 业务数据守卫 | 放过(含授权归属守卫) | 单独放过(如表权限、数据源、文件等业务守卫处) |
| 应用层的可见性判定(哪些表 / 哪些列出现在页面上) | 放过 | 放过 |
| 引擎级列脱敏(值本身是明文还是掩码) | 免脱敏(被登记在脱敏白名单里,按角色对整个中台库放行) | 不免,按 2.5.2 的三档口径判定 |
重要提示: 这两行是两件事,别并成一件。应用层已经不做任何脱敏改写——历史上那条"平台替用户改写 SQL、把敏感列换成掩码表达式"的腿已整体拆除,应用层如今只回答"这张表 / 这几列能不能出现在你面前",值长什么样一律由数仓引擎按人裁定。所以"应用层放过"放过的只是可见性,放不出明文。
说明: 演示环境的
admin账号本身持有superadmin角色,所以它走的是上表左列——读中台库为明文,这是有意保留的口子,不是脱敏失效。一个只有租户管理员角色、没有superadmin的账号则走右列:它不是属主、也没人给它配过列脱敏,看到的就是"该列有没有被登记成敏感列"的兜底结果。
注意: 授权动作上还有一层与角色无关的收口:非超管只能对自己是属主的资源发起 / 修改 / 撤销授权(归属守卫)。也就是说,拿到再大的模块角色,也不能替别人把别人的表授出去。
2.4.5 内建角色逐个说明:各覆盖什么、什么时候挂
场景:给新同事配账号时,面对角色下拉里十几个名字,最实际的问题是"这几个到底差在哪、该挂哪个"。这一节把开发演示环境里实际存在的角色一条条摊开。
是什么:平台内建 19 个角色,全部建在主租户 000000。下面按用途分五组,每条标出数据范围(见 2.4.6)、菜单绑定条数、以及当前挂了几个账号,再讲清"覆盖什么 / 什么时候用 / 要注意什么"。
说明: "菜单绑定条数"是页面、目录、按钮一起算的总数;真正决定侧边栏长什么样的是其中的可见页面数,所以下面两个数都给出来。这些数字随环境演进会变,以角色管理页的实际列表为准;此处给出具体值,是为了让"这个角色到底给得宽不宽"有个可比的量级。
第一组:模块全权(整块模块一次给全)
role_data_all· 数据中台全模块(本部门及以下;绑定 141 条:23 个可见页面 + 106 个按钮 + 9 个目录,另含 3 个隐藏的详情页;当前 1 个账号)- 覆盖:数据源管理、表模型、主题域、分层配置、维度设计、数据元 / 数据字典 / 词根管理 / 分类方案 / 资源目录配置、质量规则、数据地图 / 资产治理 / 我的数据、指标定义 / 数据集、任务开发 / 任务编排 / 参数管理 / 调度管理 / 运行记录、Query 自助分析,加一页「数据安全 → 权限中心」。
- 什么时候挂:需要把数据中台从接入一路做到编目的人,例如数据管理部的骨干。
- 注意:数据安全里定红线的那几页拿不到,但「权限中心」是给了的(用来自己提数据申请)。当前由
data_admin持有。
role_decision_all· 决策引擎全模块(本部门及以下;绑定 58 条:2 个目录 + 6 个可见页面 + 50 个按钮;当前 2 个账号)- 覆盖:内容管理、规则集、规则流、模型管理、策略实验室五页全给,另外附带一页「数据安全 → 权限中心」,方便建模人自己提数据申请。
- 什么时候挂:建模、写规则、做策略实验的人。
- 注意:它不含数据中台的建模 / 建表能力,连数据源管理这一页都不给,所以持有者的侧边栏里没有这个入口;真去调数据源列表接口,会因缺少
data:source:list权限标识被直接拒,而不是返回一个空列表——这是预期,不是故障。当前由model_zhao、risk_liu持有,这两个账号另外还挂着role_data_read,但那个角色同样不带数据源管理,叠上去也不改变这个结果。
role_gateway_all· 数据网关全模块(本部门及以下;绑定 37 条:1 个目录 + 5 个可见页面 + 31 个按钮;当前 2 个账号)- 覆盖:路由管理、上游服务管理、客户端管理、密钥管理、插件模版。
- 什么时候挂:负责把能力发布成对外 API、管应用与鉴权的人。
- 注意:当前由
gw_ma、tech_huang持有。
第二组:数据中台细分(可与上面叠加)
role_data_read· 数据中台-消费分析(本部门及以下;绑定 41 条:14 个可见页面 + 18 个按钮,另含 3 个隐藏的详情页;当前 15 个账号)- 覆盖:数据地图、我的数据、Query,加表模型 / 主题域 / 分层配置 / 维度设计、数据元 / 数据字典 / 词根管理 / 分类方案 / 资源目录配置、指标定义 / 数据集;按钮基本都是列表与查看这类只读动作。
- 什么时候挂:只需要查数据、不建表的人。当前它是各部门工程师的统一基线角色,分配面最广。
- 注意:菜单给得再宽也不等于看得见数据——具体能看到哪张表,仍由 2.5 讲的资源层 OWNER/READ 决定。
role_data_dept· 数据中台-部门自治(本部门及以下;绑定 98 条:17 个可见页面 + 75 个按钮;当前未分配)- 覆盖:数据源管理、表模型 / 主题域 / 分层配置 / 维度设计、数据元 / 数据字典 / 词根管理 / 分类方案 / 资源目录配置、指标定义 / 数据集、任务开发 / 任务编排、调度管理、质量规则,以及「数据安全 → 数据授权」这套分享菜单。
- 什么时候挂:在本部门内既建表用数、又要把表分享出去的骨干。
- 注意:两点。一是它不是
role_data_read的超集——数据地图、我的数据、Query 这三页它没有,要让人既能建又能检索,得把这两个角色叠在一起挂;二是它已内含分享菜单,不必再叠role_data_owner_share。当前是建好待用状态,一个账号都没挂。
role_data_owner_share· 数据中台-属主分享(本部门及以下;绑定 10 条:1 个可见页面 + 7 个按钮;当前 1 个账号)- 覆盖:只干一件事——把「数据安全 → 数据授权」这一页打开,附带新增 / 修改 / 删除 / 释放 / 续期等按钮。
- 什么时候挂:建过表、需要把自己的表分享给同事的人,叠加在别的角色之上用。
- 注意:它只是"门"不是"墙",能不能真授出去由归属守卫逐条判(见 2.5.1),授给谁都不会扩大越权面。当前由
dev_engineer持有。
第三组:岗位职责(按一小块子域收窄)
role_dwh_engineer· 数仓工程师(仅本人;绑定 56 条:9 个可见页面 + 41 个按钮;当前 2 个账号)- 覆盖:数据源管理、任务开发、表模型 / 主题域 / 分层配置 / 维度设计、Query、权限中心、治理工单,外加一个隐藏的「任务定义」页及其增删改与运行按钮。
- 什么时候挂:数仓组里负责接入、分层、发起建表工单的人。当前由
dwh_lin、dwh_zhou持有。 - 注意:它被授了「平台管理」这个顶层分区,而分区下被授的又都是隐藏页,所以侧边栏会多出一个点开是空的「平台管理」——这是授权配置的表象,不是页面加载失败。
role_metric_dev· 指标开发工程师(仅本人;绑定 19 条:3 个可见页面 + 14 个按钮;当前 1 个账号)- 覆盖:指标定义、数据集、数据源管理,仅此三页。
- 什么时候挂:只负责定指标口径的人。当前由
metric_xu持有。
role_risk_rule_eng· 风险规则工程师(仅本人;绑定 51 条:5 个可见页面 + 45 个按钮;当前 1 个账号)- 覆盖:内容管理、规则集、规则流、模型管理、策略实验室五页全给,但不带数据中台任何页面。
- 什么时候挂:专做规则集 / 规则流的人。当前由
strategy_feng持有。 - 注意:与
role_decision_all的差别只有一处——不带「权限中心」,所以提不了数据申请。要让这个岗位能自助申请数据,得另外叠一个带权限中心的角色。
role_flow_orchestrator· 流程编排工程师(仅本人;绑定 74 条:8 个可见页面 + 59 个按钮;当前 2 个账号)- 覆盖:数据中台的任务开发 / 任务编排 / 参数管理 / 运行记录四页,加数据网关的路由管理 / 上游服务管理 / 客户端管理 / 密钥管理四页,以及大量任务流按钮(新增 / 修改 / 删除 / 运行 / 发布 / 复制模板 / 节点与依赖增删改)。
- 什么时候挂:把模型与规则编成打分流、再发布到网关对接下游的人。当前由
dev_engineer、flow_zheng持有。 - 注意:网关五页里不含插件模版,要配插件模版得另挂
role_gateway_all;同样会多出一个点开是空的「平台管理」分区。
role_data_product· 数据产品经理(只读)(仅本人;绑定 68 条:22 个可见页面 + 36 个只读按钮;当前未分配)- 覆盖:横跨数据中台 12 页(表模型 / 主题域 / 分层配置 / 维度设计、指标定义 / 数据集、数据源管理、任务开发 / 任务编排 / 参数管理 / 运行记录、调度管理)、决策引擎 5 页、数据网关 5 页,按钮以列表和查看为主,是覆盖面最广的只读角色。
- 什么时候挂:需要通览三大模块但不落地改动的产品 / 需求岗。
- 注意:它不含数据地图、我的数据、Query 这三页,要"通览 + 能自己查一下",得叠一个
role_data_read。当前未分配给任何账号;同样带空的「平台管理」分区。
role_tester· 测试工程师(仅本人;绑定 22 条:4 个可见页面 + 11 个按钮;当前未分配)- 覆盖:模型管理、策略实验室、指标定义、任务编排四页,按钮以查询和运行为主。
- 什么时候挂:只需要跑一跑、看结果的验证岗。
- 注意:当前未分配;同样带空的「平台管理」分区。
role_biz_requester· 需求方(只读)(仅本人;绑定 7 条:1 个可见页面 + 4 个按钮;当前 4 个账号)- 覆盖:唯一可见页面是「数据安全 → 权限中心」,主要动作是提交数据申请;另持有文件的查询 / 上传 / 下载三个按钮权限。
- 什么时候挂:业务线只读需求方——能登录、能提数据申请,但不建模不建表。
- 注意:它连数据地图都没给,所以只持有这一个角色的账号访问数据源列表这类接口会直接被拒(缺权限标识),而不是返回空列表。当前
credit_biz、credit_he、market_luo、stock_biz四个账号持有,并且同时挂了role_data_read,实际可见面以两者并集为准。
第四组:治理与安全
asset_governor· 数据资产治理员(本部门及以下;绑定 57 条:11 个可见页面 + 40 个按钮,另含 3 个隐藏的详情页;当前 2 个账号)- 覆盖:数据元 / 数据字典 / 词根管理 / 分类方案 / 资源目录配置、数据地图 / 资产治理 / 我的数据、质量规则、数据源管理、Query。
- 什么时候挂:专职做元数据登记与治理的岗位。当前由
admin、gov_wu持有。 - 注意:不含数据保护(脱敏规则、敏感列绑定、静态脱敏)这类安全动作——那一档只在
security_auditor与超级管理员手里。
asset_consumer· 数据资产使用者(全部数据权限;绑定 28 条:6 个可见页面 + 14 个按钮,另含 3 个隐藏的详情页;当前未分配)- 覆盖:数据地图、我的数据、资产治理、Query、数据授权、权限中心,定位是"只想查一下"的最小消费角色。
- 什么时候挂:只需要检索资产、订阅收藏的业务 / 分析岗。
- 注意:它的数据范围是全部数据权限,比很多建设角色还宽,挂之前先按 2.4.6 想清楚影响面;当前未分配给任何账号。
security_auditor· 数据安全审计员(全部数据权限;绑定 46 条:7 个可见页面 + 36 个按钮;当前未分配)- 覆盖:数据安全整棵子树——数据授权、权限中心,以及数据保护下的安全等级、敏感类型、数据识别、脱敏规则、数据脱敏;其中包含全平台授权视图,即授权列表不做"只看自己相关"的收敛。
- 什么时候挂:合规 / 审计岗。
- 注意:持有它不等于免脱敏。免脱敏白名单是按"角色 + 库"登记的,开箱状态下只登记了超级管理员一条,所以这个角色读中台库仍按 2.5.2 的三档判定。当前未分配。
gov_approver· 治理工单审批者(本部门及以下;绑定 7 条:1 个可见页面 + 5 个按钮;当前 1 个账号)- 覆盖:唯一可见页面是「数据安全 → 治理工单」,动作是提交 / 审批 / 查询。
- 什么时候挂:部门内负责审批建表、数据元、资产、指标发布工单的人。当前由
data_admin持有。 - 注意:这个角色 key 与后端审批逻辑存在硬耦合(多处按
gov_approver这个字符串定位审批人),改了 key 会出现"提了单没人能审"。排障时先核对 key 的一致性,详见 2.4.2 末尾的提示。
第五组:服务账号与管理员
role_scoring· 打分服务角色(仅本人;绑定 1 条,而且是个按钮;当前 1 个账号)- 覆盖:整个角色只绑一条——决策引擎 → 模型管理 → 模型执行。没有任何页面,持有它的账号登录后侧边栏是空的。
- 什么时候挂:专供打分服务账号
svc_scoring使用;已发布的对外打分 API 被调用时,平台切到这个身份去执行模型。 - 注意:它是最小权限身份,不是特权身份——要读中台的哪张表,仍要像普通受让人一样被显式授权到那张表(见 2.1.3 的提示)。
admin· 租户管理员(保留标识;主租户000000当前没有这条记录)- 覆盖:菜单完全来自租户套餐,套餐里勾了什么就有什么。
- 什么时候挂:多租户部署时,每个租户内部的管理员;单租户 / 演示环境用不到。
- 注意:详见 2.4.3 与 2.4.11。演示环境那个叫
admin的账号持有的其实是superadmin角色,别把账号名和角色 key 看成一回事。
superadmin· 超级管理员(全部数据权限;二十余条历史绑定,但不起作用;当前 1 个账号)- 覆盖:菜单全量下发、接口鉴权旁路,详见 2.4.4。
- 什么时候挂:运维与实施用的最高身份,用来开租户、改菜单、排障,不参与日常业务演示。
- 注意:它在角色管理页里还能看到一批历史菜单绑定,那些绑定完全不起作用——全量放过在前,勾不勾都一样。
注意: 一个人可以同时挂多个角色,菜单是各角色的并集(谁都不减);但数据范围不是并集,而是"取最宽的那一档"(见 2.4.6)。叠角色时这两条规则要一起想:叠上去的角色只会让人看得更多,不会让人看得更少。
2.4.6 数据权限(数据范围):六个选项分别怎么算
场景:两个人挂着同一个角色,打开同一个列表页,看到的行数却不一样——差别通常就在这里。
是什么:角色除了"能看到哪些菜单",还有一个正交的维度叫数据范围(也叫数据权限、权限范围),它决定列表页按部门过滤到什么程度。入口在角色管理页某一行的「权限」按钮,弹窗里是一个下拉;选「自定数据权限」时,下方还会再出现一棵部门树。
各取值的算法与适用场景如下,逐档看:
| 取值 | 选了之后怎么算 | 什么时候选 |
|---|---|---|
| 全部数据权限 | 一个过滤条件都不加,查询走全表 | 确实需要跨部门通览的角色,例如审计。当前 superadmin、asset_consumer、security_auditor 是这一档 |
| 自定数据权限 | 把查询限制在一组显式指定的部门上;这组部门就是选这一档时在部门树里勾的那些 | 某个角色要跨若干个不相邻的部门看数据时。当前无角色使用 |
| 本部门数据权限 | 限制在该用户所属的那一个部门,不含子部门 | 作业范围严格限于本部门、不需要看下属组的岗位。当前无角色使用 |
| 本部门及以下数据权限 | 先取用户所属部门,再把该部门的全部子孙部门一起算进来 | 部门负责人,或需要看本部门下各小组产出的骨干。当前 8 个角色是这一档,是建设类角色的主流选择 |
| 仅本人数据权限 | 只看自己创建的记录 | 只应看到自己那份产出的岗位。当前 8 个角色是这一档 |
| 部门及以下或本人数据权限 | 不要选。这一档在下拉里能看到、选了也不报错,但实际执行时落不到任何分支,最终按"仅本人"处理 | 想要"本部门及以下"的效果,请选本表第四行那个「本部门及以下数据权限」 |
重要提示: 下拉里的最后一项「部门及以下或本人数据权限」名不副实——它的实际效果是"仅本人",与标签写的完全不同。配角色时避开它;发现某个角色"明明配了部门及以下却只看得到自己的记录",先回来核对是不是选中了这一项。
关于这几档,还有四条规则必须一起记住,否则很容易配出"看起来对、实际不对"的结果:
- 多角色时取最宽,不取交集。 一个人挂多个角色,系统把这些角色的数据范围收成一个集合,按"全部 → 本部门及以下 → 本部门 → 自定 → 仅本人"的顺序命中第一个就返回。叠一个宽的上去,原来窄的那档就作废了。
- 「自定」的优先级排在「本部门」之后。 一个人同时有"本部门"和"自定"时,生效的是"本部门",自定的那组部门不起作用。
- 它不是全局过滤器,只在挂了数据权限的列表上生效。 平台不是给所有查询自动加部门条件,而是逐个列表接上去的:角色 / 部门 / 用户列表、调度任务与实例、任务流与任务实例、以及数据中台的表模型、主题域、分层、维度、数据元、数据字典、词根、分类方案、指标数据集、安全防护等列表。排查"某人为什么看得到别人的记录"时,先确认那个列表挂没挂数据权限,再怀疑角色配错。
- 没配就是"仅本人"。 数据范围留空时按"仅本人"处理。角色列表里数据权限一列显示为空的,就照"仅本人"理解——通过界面新建、以及租户开通时自动创建的管理员角色,落库都是空值。
重要提示: 当前版本的「权限」弹窗保存不生效——弹窗能打开、能选、能点保存,但服务端没有对应的接收能力,改动不会落库。所以库里现有的那些数据范围值都是实施时刷进去的。需要调整某个角色的数据范围,目前得找运维在库侧改,不要在这个弹窗里改完就以为生效了。
注意: 「自定数据权限」还有一个容易踩的地方:取部门集合时,系统是把该用户所有角色上配过的部门并起来的,而不是只取那条"自定"角色上的。另外,选了"自定"却一个部门都没勾,结果不是"不过滤",而是一条都查不到(安全侧的失败即拒绝)。同理,"本部门"这一档在解析不出用户部门时也是一条都查不到。
2.4.7 角色上的另外两个开关:角色状态、父子节点关联
新建或编辑角色时,除了名称、权限标识、排序,还有两个开关值得单说——它们的实际行为和字面意思有出入。
角色状态(新增 / 编辑抽屉里的单选,也是列表「状态」列的开关):
| 取值 | 选了之后会怎样 | 什么时候用 |
|---|---|---|
| 正常 | 角色可用,是新建时的默认值 | 常规 |
| 停用 | 服务端会先数这个角色分配了多少用户,只要大于 0 就直接拒绝,提示"角色已分配,不能禁用!";只有一个用户都没挂的角色才停得掉 | 临时封存一个还没投用的角色 |
重要提示: 别把"停用角色"当收权手段。 一来分配了用户就停不掉;二来即便真有一个停用角色挂在人身上(例如先停用、后分配),下发菜单和算权限标识这两条路都不看角色状态——菜单照出、按钮照放行。要收权,只能在用户管理里把角色解绑,或者把角色删掉。
菜单树上的「父子节点关联 / 父子节点独立」开关(在角色抽屉的菜单树右上角;选「自定数据权限」时,部门树上也有同样一个):
| 取值 | 选了之后会怎样 | 什么时候用 |
|---|---|---|
| 父子节点关联 | 勾父自动勾全部子、勾子自动补上父。这是常规做法,库里现存的角色全部是这一档 | 按整块功能授权时,也就是绝大多数情况 |
| 父子节点独立 | 勾父不带子、勾子不补父,勾了什么就是什么 | 要做"给页面但不给某几个按钮""给按钮但不给页面"这类精细控制时 |
注意: 配成"只给按钮不给页面"要知道后果:下发菜单时按钮类型是被跳过的,不会把它所在的页面顺带拉进来——结果就是权限有、菜单里却找不到那一页。真想让人点得到,页面那一条也得勾上。
重要提示: 新建角色时,先把菜单树上的这个开关拨一下再保存(拨过去再拨回来也行)。这个开关在新增抽屉里没有默认值,不碰它就不会带上来,落库是空值;而再次点开这个角色的「编辑」时,空值会导致菜单树回显失败。已经建出来的角色若出现"编辑打不开菜单树",就是这个原因,需要运维在库侧把这个值补上。
2.4.8 角色管理页与用户管理页:哪些入口能用、哪些点了没结果
场景:第一次配角色的人,常在角色管理页上被几个按钮带偏——点了没反应,又不确定是自己权限不够还是操作不对。这一节把当前版本的实际情况说清楚,免得白花时间。
能用的:
- 角色管理页的新增 / 编辑 / 删除 / 状态开关,以及抽屉里的菜单树勾选——这是配角色的主路径,勾完保存即写库(生效还要看 2.4.12 的缓存)。
- 用户管理页的新增 / 编辑 / 删除 / 状态开关,以及左侧部门树筛选。
- 给人授角色:走「用户管理 → 编辑用户 → 角色」多选框。这是当前唯一顺畅的授角色入口。
当前点了没有结果的(知道即可,不必反复尝试):
| 入口 | 实际情况 |
|---|---|
| 角色管理 → 「权限」弹窗的保存 | 服务端未提供对应能力,数据范围改不了(见 2.4.6) |
| 角色管理 → 「分配」按钮 | 跳转地址与该页实际注册的路由对不上,点了会落到找不到页面。给人授角色请走用户管理 |
| 分配用户页 → 「批量取消授权」 | 服务端未提供批量取消,逐个取消可用;何况这一页当前从角色管理也进不去(见上一行) |
| 角色 / 租户 / 租户套餐 / 用户 / 岗位 / 字典 / 参数的「导出」 | 平台管理这一片没有导出能力,按钮是占位,点了不会有文件产出 |
| 用户管理 → 「导入」「重置密码」 | 同上,当前未提供对应服务端能力;重置密码请走编辑用户改密码 |
说明: 这些按钮对超级管理员始终可见,是因为前端把超管当"全部放行"处理、不再逐个比对权限标识,并不代表功能存在。判断一个动作到底有没有,以本节表格为准。
注意: 删除角色有两道拦截:已分配用户的角色不允许删除;超级管理员角色不允许操作(编辑、停用、删除都会被拒)。要删一个在用的角色,先在用户管理里把人一个个解绑。
注意: 还有一条与角色本身相关的限制,注意它的适用范围。"不允许修改当前登录用户自己的角色"这道校验只长在角色管理的「分配用户」页上(给该角色批量加人 / 取消授权那两个动作),而那一页当前从角色管理进不去(见上表第二行)。走本节推荐的「用户管理 → 编辑用户 → 角色」这条路,给自己加减角色是允许的。真正到哪条路上都拦得住的是另一条:超级管理员角色只能加在本来就是超管的账号上——给一个非超管账号(包括自己)勾上超管角色,保存时那一条会被静默剔除,若剔除后一个角色都不剩,还会直接提示"必须增加一个除了超级管理员之外的角色"。
2.4.9 菜单管理:三种菜单类型与四个开关
场景:平台上线了一个新页面、或者要把某一页从侧边栏收起来,动作都落在菜单管理页。这一页的每个选项都直接影响所有人的侧边栏,改之前先看清各取值的实际效果。
是什么:菜单管理维护的是整棵菜单树——511 条菜单记录,其中目录 29 条、页面 77 条、按钮 405 条。新增一条菜单要填:上级菜单、菜单类型、图标、菜单名称、显示排序、路由地址、组件路径、是否外链、是否显示、菜单状态、权限标识、路由参数、是否缓存。下面把几个取值型的说清楚。
菜单类型(三选一,决定这条记录是什么):
| 取值 | 是什么 | 授权后的实际表现 |
|---|---|---|
| 目录(M) | 一组功能的分区,点开是子菜单不是页面 | 撑出侧边栏的一层。只授目录不授页面,会留下一个点开是空的分区 |
| 菜单(C) | 真正能打开的功能页面,必须填组件路径 | 页面出现在侧边栏。只有它自己被授权才会出现,授父目录或授页内按钮都带不出来 |
| 按钮(F) | 页面内的一个操作,没有路由和组件,只有权限标识有意义 | 前端据此显示按钮、后端据此放行接口。授按钮不会把页面带出来;按钮行上也不提供"新增下级"操作 |
是否显示(控制这条菜单在侧边栏里露不露脸):
| 取值 | 选了之后会怎样 | 什么时候用 |
|---|---|---|
| 显示 | 正常出现在侧边栏 | 绝大多数页面 |
| 隐藏 | 路由照样注册,只是从侧边栏里过滤掉,直接敲地址仍然进得去 | 详情页、带参数的子页面(如表详情、指标详情、字典数据、文件配置),或暂时下线又不想删的页面 |
重要提示: 「隐藏」不等于"禁止访问",拿到地址就能进,不要把它当权限手段用。要真正挡住一个人,得从角色的菜单授权里把这一条摘掉。
菜单状态:
| 取值 | 选了之后会怎样 | 什么时候用 |
|---|---|---|
| 正常 | 菜单可用,默认值 | 常规 |
| 停用 | 库里记下了这个状态,菜单管理列表和授权树上会显示成"停用"——到此为止 | 想给一条已废弃的菜单打个标记时 |
重要提示: 「停用」名不副实:抽屉里的提示写着"停用后不会出现在菜单栏, 也无法访问",实际两件事都不成立——下发菜单不按状态过滤,算权限标识也不按状态过滤,已被授权的用户照样看得到、点得进,接口照样放行。要真下线一个页面,把「是否显示」改成隐藏,并且从各角色的授权里摘掉,两步都要做。
是否外链(菜单类型不是按钮时才出现):
| 取值 | 选了之后会怎样 | 什么时候用 |
|---|---|---|
| 是 | 路由地址必须写成 http(s):// 开头的完整链接,点击时新开浏览器窗口打开;此时组件路径与路由参数两个输入框会被禁用 | 要在菜单里挂一个第三方系统的地址,并且希望新窗口打开 |
| 否 | 默认值。路由地址填普通字符串就是平台内部页面;若填 http(s):// 开头的地址,则会在平台内部嵌一个页面框显示 | 平台自己的页面选它;想把外部页面嵌在平台里显示,也选它并把地址写成 http 开头 |
注意: 选了"是"却填了非
http开头的地址,表单会直接拦下来;另外路由地址开头不要带斜杠,同样会被校验拦住。
是否缓存(仅菜单类型为「菜单」时出现):
| 取值 | 选了之后会怎样 | 什么时候用 |
|---|---|---|
| 是 | 页面被保活,切走再切回来时保留滚动位置、表单填写、展开状态。库里绝大多数页面是这一档 | 列表页、画布类页面,来回切换不希望丢状态 |
| 否 | 每次进入都重新挂载,状态清空 | 每次都要拉最新数据、或状态残留会造成误解的页面 |
注意: 这个开关只影响页面保活,和权限缓存完全是两回事——"改了角色不生效"要清的是权限缓存(见 2.4.12),不是这里。
几个操作上的注意:
- 在某一行上点「新增」可以直接建它的下级;按钮类型的行不提供这个操作。
- 删除时,工具栏上有一个级联删除开关,打开后会连同所有子菜单一起删掉——批量清理历史菜单时才用它,平时保持关闭。
- 双击标题可以整棵树折叠 / 展开。
重要提示: 菜单管理页有一道额外门槛:只有持超级管理员或租户管理员角色才渲染这一页,其他人打开是无权提示;而且页内的增删改按钮只对超级管理员显示,租户管理员进得去、看得到,但改不了。
2.4.10 权限标识怎么写:三段式与各种动作后缀
场景:新增一个按钮、或者排查"为什么点了提示没权限"时,都要回到权限标识这一层对照。
是什么:权限标识是 模块:资源:动作 三段式,例如 standard:element:add(数据标准—数据元—新增)、security:authorization:list(数据安全—数据授权—列表)、system:tenantPackage:query(平台管理—租户套餐—查看)。登录时系统把这个人所有角色绑定菜单上的标识收成一个集合,请求进来时做精确字符串比对。
最后一段的动作后缀,按性质分四类,授权时的取舍完全不同:
| 动作后缀 | 是什么 | 授权时怎么取舍 |
|---|---|---|
list / query | 列表与查看,纯读动作。全平台出现 101 次 / 71 次,页面本身的标识通常就是 list | 只读角色至少要有这两类;少了 list,页面往往直接打不开 |
add / edit / remove | 新增 / 修改 / 删除,写动作。分别出现 66 / 64 / 70 次 | 建设类角色才给 |
run / execute / start / publish / release / deploy / terminate | 运行与发布类,有实际副作用(跑任务、发布 API、终止流程) | 配只读角色时要特意把这几类摘掉——它们和 list/query 混在同一个页面下,一路勾下来很容易带上 |
export / import | 导出 / 导入 | 数据中台侧可用;平台管理这一片是占位,见 2.4.8 |
注意: 权限标识不支持任何通配写法。写
system:*或*:*匹配不到任何接口——后端是逐字比对的。超级管理员之所以处处放行,是因为它在比对之前就按角色旁路了,不是靠某个通配串。
2.4.11 租户与租户套餐:开通一个租户会发生什么
场景:多租户部署时,给一个新客户开一套隔离的空间;单租户 / 演示环境用不到这两页,可以跳过本节。
是什么:租户是一套相互隔离的数据与配置空间;租户套餐是"一组菜单的打包"。新建租户时选哪个套餐,该租户的管理员角色就自动拿到套餐里的菜单——以后平台加了新页面,只改套餐这一处,用该套餐的所有租户的管理员会自动跟上。
怎么做(开通一个租户)
- 进入平台管理 → 租户管理 → 租户管理,点新增。
- 填企业名称、联系人、联系电话、管理员账号与密码、租户套餐、过期时间、用户数量、绑定域名等。
- 提交。系统随即自动做完五件事:生成一个 6 位租户编号 → 按所选套餐建一个管理员角色并绑上套餐里的菜单 → 建一个与企业同名的根部门 → 建管理员账号并设为该部门负责人 → 把主租户的字典与参数整套复制过来。
- 把租户编号、管理员账号与密码交给对方,即可登录。
新增 / 编辑租户抽屉里,几个取值型字段的实际行为如下——其中有三个是"只存不校验"的,不要按字面理解:
| 字段 | 取值与实际行为 | 什么时候用 |
|---|---|---|
| 用户数量 | 填 -1 表示不限制数量(输入框会显示这个提示),默认租户就是 -1;填正整数 N 则只在"新增用户"这一个动作上校验,租户内用户数满了就拒绝创建,删了用户名额会自动回来 | 按坐席售卖时填 N,内部部署 / 演示环境填 -1 |
| 过期时间 | 新增时默认为一年后,不填则显示"无期限"。只存不校验——到期后登录、鉴权、接口调用一律照常 | 记录商务上的到期日,不能当作技术手段 |
| 绑定域名 | 可填域名或 ip:端口。只存不用——平台没有任何一处按域名去路由或识别租户 | 备注用 |
| 租户套餐 | 新增时必选,决定给这个租户的管理员角色绑哪些菜单 | 开通时选 |
| 租户状态 | 「正常」= 可用;「停用」= 库里记下状态,同步字典 / 参数时会跳过这个租户 | 见下方提示 |
重要提示: 「停用租户」不阻断登录。 登录链路上没有任何一处检查租户状态或过期时间,登录页的租户下拉也是把所有租户原样列出的。所以停用只是一个标记,真要让一个租户的人进不来,得从账号层面处理。另外默认租户不允许停用、也不允许删除。
重要提示: 租户套餐在"编辑"时改不了。 编辑租户只改得动企业名称、联系人、电话这些;租户编号与套餐在保存时会被强制忽略,在抽屉里换了套餐保存也不会生效。确实要换套餐,需要运维在库侧改完,再用列表行上的同步按钮把菜单刷过去。
租户套餐管理这一页解决的是"这一类租户该看到哪些菜单"。新增套餐时填套餐名称、在菜单树里勾关联菜单、写备注即可。它的状态开关:
| 取值 | 选了之后会怎样 | 什么时候用 |
|---|---|---|
| 正常 | 套餐出现在「新增租户」的套餐下拉里 | 在售 / 在用的套餐 |
| 停用 | 从「新增租户」的套餐下拉里消失;已经用这个套餐开通的租户不受影响,菜单照旧,停用不会回收任何已下发的菜单 | 下架一个套餐但不想删除 |
套餐里的菜单改了之后,有两种传播方式,行为不同,要分清:
| 方式 | 做了什么 | 注意 |
|---|---|---|
| 自动传播——编辑套餐并保存 | 保存成功后系统自动找出所有用该套餐的租户,逐个同步一遍。这就是"平台新增一个菜单只改套餐这一处"的实现方式 | 只改库,不清权限缓存,相关用户要重新登录才看得到新菜单 |
| 手动传播——租户列表行上的「同步」按钮 | 对该租户的管理员角色:清空原有菜单绑定,按套餐整批重写;对该租户内其他所有角色:把"不在套餐里"的菜单绑定删掉 | 对非管理员角色是做减法——原本给某个业务角色单独加的菜单,只要不在套餐里就会被删掉;同样不清缓存 |
重要提示: 上面这条减法要特别当心:如果租户内给业务角色单独配过套餐之外的菜单,一次「同步」就会把它们清掉,且不可撤销。同步前先确认套餐里的菜单是不是当前的全集。
注意: 删除套餐时,已被租户使用的套餐会被拦下(提示"租户套餐已被使用"),需要先把用它的租户改到别的套餐。
注意: 租户管理与套餐管理这两页只有超级管理员能进,非超管打开是空白无权页面,相关接口也一律拒绝。工具栏上的「同步租户字典」「同步租户参数配置」两个动作,是把主租户的字典 / 参数补齐到其他正常状态的租户,只补缺、不覆盖已有值。
注意: 租户套餐页的编辑、状态开关、删除三个按钮存在权限标识不一致的情况——菜单上配的标识与接口要求的标识不是同一个串。超级管理员靠角色旁路不受影响;但如果给某个非超管角色按菜单授了这几个按钮,会出现"按钮显示出来了、一点就提示没权限"。需要修正时请联系运维统一命名,不要只改一边。
2.4.12 改了权限却不生效:三条路径分别怎么处理
场景:管理员刚给某人加了角色 / 改了菜单,对方刷新半天没变化。这是上手阶段最高频的一类求助,原因几乎都在缓存。
是什么:平台会把每个人的权限画像缓存起来以提升性能,不同的改动对缓存的处理方式不一样,分三种情况:
| 改了什么 | 缓存怎么处理 | 需要做什么 |
|---|---|---|
| 在菜单管理里增删改菜单 | 自动把所有用户的权限缓存整体清掉,下次访问自动重建 | 让用户刷新页面即可 |
| 在角色管理里重新勾菜单(改角色的菜单绑定) | 保存成功后自动刷新持有该角色的每一个用户的权限缓存 | 让相关用户刷新页面即可 |
| 在用户管理里改某人的角色 | 不刷缓存,只改库。该用户的按钮显隐与接口鉴权仍按旧角色判,直到缓存过期(24 小时)或本人重新登录 | 让本人退出重登。这是"改了没生效"最常见的一种 |
说明: 上表第二行和第三行为什么处理方式相反,值得多说一句:侧边栏菜单本身不走缓存——每次请求都现查库,所以"菜单看不见"通常不是缓存的锅;真正被缓存住的是按钮显隐与接口鉴权用的那份权限画像,有效期 24 小时。改角色的菜单绑定时,平台会顺手把持有该角色的人的画像都刷一遍,刷新页面就行;而在用户管理里给某人加减角色,这一刷没有做,所以要靠本人退出重登(退出会清掉自己的缓存,重登即按新角色重建)来立刻生效。
重要提示: 如果是在数据库侧直接改的角色或授权(实施、批量刷数据时常见),平台不会知道——必须先清掉对应用户的权限缓存,再让用户重新登录,否则改动看不出来。这一条与 2.2 末尾的提示是同一件事。
说明: 排查顺序建议固定成这样:先确认角色上到底勾没勾那条菜单(角色管理页看得到)→ 再确认那条菜单是不是"隐藏"或只授了按钮没授页面(2.4.9)→ 最后才怀疑缓存。反过来先怀疑缓存,常常绕远路。
2.5 为什么"我看到的"和同事不一样:资源层授权与脱敏
场景:新用户(尤其是业务岗)第一次进入时常撞见一个困惑——某些页面的数据源下拉是空的,或者数据地图里"什么都没有"。这一节解释原因,并把两条相关机制讲透:资源层授权、引擎级脱敏,以及决定"脱敏能不能挂上"的两条数据流。
2.5.1 资源层 OWNER/READ 授权模型
是什么:平台真正的可见/可写控制点,不在"菜单"层,也不在"SQL 语句"层,而在资源层——某一张表、某一个数据源。资源默认私有,并提供两级授权:
- OWNER: 对资源可建、可写、可管(建表、落库、授权他人)。属主 = 这张表是平台为你建出来并已发布落地的——认的是模型表上登记的创建人。挂接别人已有的表、或在查询工作台手敲
CREATE TABLE出来的表,都不会让人变成属主。 - READ: 对资源只读;读到的是明文还是掩码,由授权时怎么配决定(见 2.5.2),不是"READ 就一定掩码"。
成对理解:OWNER 与 READ、当前账号与他人账号——把这组反义概念放在一起,就能建立起心智模型:自己建出来的资源自己是 OWNER;用别人的数据,得先拿到 READ。
怎么拿到 READ:有两条路,方向相反,由谁发起是唯一的区别。
路一 · 用数据的人来申请(申请 → 审批)
涉及该操作的功能权限:数据申请工单的新建与提交。
- 用数据的人对不属于自己的数据源,发起一张数据申请工单。
- 该资源的审批人审批(提单人不能审自己的单)。
- 通过后,系统自动写入授权,把 READ 授给申请人,并可设有效期,到期自动/手动回收。
授权工单沿「提交 → 审批 → 通过后授权生效」推进;审批未通过则驳回,已生效的授权可因到期或被回收而失效。
路二 · 属主主动把表分享出去(属主自助分享)
涉及该操作的功能权限:数据授权的新增 / 修改 / 删除 / 释放 / 续期(角色 role_data_owner_share,或已内含它的 role_data_dept)。
- 属主进 数据中台 → 数据安全 → 数据授权,在左侧资源树里点中自己那张表。
- 在授权维护里填被授权对象(选人)、勾授权动作、按需设到期日。
- 在字段脱敏区,给需要遮住的列各选一条脱敏规则——不配的列对被授权人就是明文。
- 保存。受让人随即在自己的数据源下拉与数据地图里看到这张表。
这条路不走审批:数据是属主自己的,给谁用由属主自己决定,系统只做留痕。
验证:完成任一条路后,用受让人账号登录,前往数据地图查看该资源,可见原先为空的目录/详情/血缘已出现内容,即证明 READ 已授。
说明: 业务需求方(只读角色)在很多页面看不到数据源下拉,数据地图、详情、血缘也可能是空的——这是设计使然的隔离,不是缺陷。可见性的总开关在"数据源源级授权":没有授权,这些视图就是空的。属主分享时平台会自动补上数据源可见性,不必再单独配一次;走申请工单的那条路同理。
注意: 分享只能分享自己是属主的资源。服务层的归属守卫会逐条核对:非超管发起授权时,若这张表不是自己建出来并发布的,直接拒("只能分享自己是属主的表");数据源型授权同理,须是该数据源的 OWNER;库级授权一律只有超管能做(平台没有"库属主"这个口径,想给就按表给);查不到归属的一律按无权处理。同理,授权列表里也只看得到我收到的 + 我发出的 + 我自己资源上的三类,看全平台授权需要审计角色。
重要提示: 配了列脱敏的分享,保存成功不等于对方马上能查。 平台会刻意先让脱敏规则在数仓引擎侧生效、再放开读权限——顺序反过来的话,对方在规则追上来之前那几秒读到的就是明文。所以新分享会先落库、暂不放权,通常几秒后自动放开。这期间受让人查不到数据是正常且安全的表现,不要反复删了重建。属主这边看不到这个中间状态:授权列表页面不展示放权进度(它在列表接口里以
engineSyncStatus字段返回,pending= 还没放权、synced= 已放权),所以属主判断"到底通没通"的实用办法只有一个——让受让人隔几秒再查一次。若十几分钟后对方仍然查不到(超过 10 分钟平台会把这条判为失败),说明引擎侧策略没能就位,请联系运维查数仓引擎与平台的连通性,不要自己反复重建授权。
注意: 走申请工单那条路,授权同步是最终一致的——1. 首轮同步通常只落下申请记录;2. 第二轮才真正发放授权(由定时对账器补齐)。现场演示要立即看到效果时,可连续触发两次同步。此外,删授权若"删不掉",多因对账器会按工作流历史实例重建申请与授权,须先清理对应的历史流程实例再删。
2.5.2 引擎级列脱敏:默认明文、属主明文、分享时配才脱敏
场景:数仓组的同事建了一张含身份证的明细表,自己一查是明文,于是来问"脱敏是不是没生效"。答案是:没生效才不对,属主看到明文正是设计如此。
是什么:平台的字段级脱敏是引擎级列脱敏,只对中台自建的分析型数仓生效,外部数据源一概不归它管。每个用户在数仓引擎里对应一个独立账号,引擎在查询时按人决定这一列给明文还是掩码。判定顺序只有三档:
| 查这张表的人是谁 | 引擎给什么 |
|---|---|
| 资产属主本人 | 明文。属主对自己建出来的表有完整视图,不需要授权。 |
| 被分享者,且分享时给这一列配了脱敏规则 | 按规则掩码。配什么规则就掩成什么样,一列一配。 |
| 被分享者,但这一列没配脱敏 | 落到表级兜底策略:该列若被登记为敏感列(在数据脱敏页做过绑定),仍然掩码;没登记过,就是明文。 |
说明: 第一档有一个极少出现的例外:如果有人反过来给属主本人也发了一条授权、并在上面给这一列配了脱敏,平台取严——按那条配置掩码,而不是按属主明文。方向是有意选的:有人明确点过"这列给他打码"这个动作,不该被一条从建表记录推断出来的属主身份悄悄推翻。真遇上了,把属主自己身上那条多余的授权删掉即可。
为什么反过来做:早期口径是"配了脱敏对所有人生效、少数白名单免脱敏",看似更严,实际有两个毛病——属主查自己的表也被掩码,只能绕道导出;而"给谁看什么"这件事只能由安全管理员集中配,离数据最近的属主反而说不上话。改成"默认明文 + 分享时配脱敏"之后,决定权回到属主手上:数据不分享出去,别人根本没有表权限、连表都看不见;一旦要分享,就在分享那一刻当面决定"这几列给他遮住"。
为什么放在引擎层:把脱敏做进数仓引擎的列访问控制里,而不是靠应用层拼 SQL,就能挡住各种绕过手法(改列别名、套函数、聚合等历史高危已修),做到"谁来查、以什么写法查,该遮的列都遮"。改造完成后,应用层那条 SQL 改写腿已整体拆掉——今天平台侧只判"这张表 / 这几列能不能给你看",值本身是明文还是掩码,全部由引擎裁定,不存在第二套口径。
两种脱敏:
- 动态脱敏(读时): 按规则在读取时处理,不改底表。常见效果:证件号
330106199201011953 → 330106********1953(前 6 后 4 保留)、手机号15863794026 → 158****4026(前 3 后 4 保留)。 - 静态脱敏(落库): 生成一份不可逆的副本表(以脱敏表达式落库)。目标表须预建且列覆盖源表,源与目标应同引擎;不可逆场景退化为哈希摘要。
验证:同一张已配敏感列的明细表,用属主账号查,证件号是完整的 18 位;用被分享且配了脱敏的账号查,同一列呈 330106********1953 形态。两个结果同时成立,才说明按人判定确实生效了。
重要提示: 看到明文时,先确认自己是不是属主,再怀疑脱敏。 三种"看到明文"都是正常的:① 我是这张表的属主;② 分享给我时没给这一列配脱敏,且这一列也没被登记成敏感列;③ 我持有超级管理员角色(在免脱敏白名单里)。真正该报的异常只有一种:分享时明明给某列配了规则,查出来却还是明文——那才要找运维。
说明: "表级兜底"这一层(即数据脱敏页上的敏感列绑定)是过渡期的安全网,保证历史授权不会因为口径切换而一夜之间全变明文;它在完整形态里会退化成纯粹的"敏感列标记"。运维可以整体关掉它,但关掉前必须把每一条既有分享的列脱敏补配完整,否则没配过的人会静默地从掩码变明文。日常使用不必关心这个开关,只需记住:要让某人看不到某列,唯一可靠的做法是在分享时给那一列配规则,不要指望兜底。
2.5.3 两条数据流:建模流 vs 同步直用
是什么:平台里有两条并存的数据流,它们决定了"脱敏与质量能不能挂上"。
- 标准建模流: 接入 → 主题域/分层 → 逻辑模型 → 发布工单建表 → 加工 → 挂标准/质量/脱敏。能力完整,治理、血缘、审批一应俱全。
- 同步直用流: 接进来直接建表搬数直查,省事,但挂不上脱敏与质量。
为什么分两条:让"值得治理的核心表"和"只想搬来查一下的边角表"各走各路,避免为一张临时表也强上全套建模。要治理/血缘/审批/指标,或对目标库无 OWNER,走建模流;只要快、只需搬来直查并进目录、且对目标库有 OWNER,走同步直用。
注意: 同步直用有两个边界:1. 平台不自动建目标表(目标表须 OWNER 先建);2. 无整库一键同步(一个任务同步一张表)。
重要提示: 对一张走"同步直用"、没有模型的表点击配脱敏,系统会提示"未找到表模型"。这是引导用户"要脱敏就先补建模型"的设计信号,不是 bug。两条流不隔离,可先同步、后补建模型把表"晋升"进治理体系。
2.6 跑一遍就懂:用五部门的代表账号感受权限边界
场景:讲了半天角色与授权,最快的"上手即懂"办法,是拿几个跨部门的演示账号各登一遍,亲眼看到"同一套系统,不同身份看到的边界完全不同"。
是什么:演示环境按五个部门预置了一批账号,密码统一为 <初始密码>。下表选取每个部门的代表账号,它们既是新人理解权限边界的最短路径,也是标准案例封版前必须"全绿"的验收对照。
| 账号 | 部门 | 定位 | 登录后能做什么 / 看到什么 |
|---|---|---|---|
data_admin(韩梅) | 数据管理部 | 数据源 OWNER + 审批人 + 治理规范 | 掌管数据与治理,审批他人的数据申请与建表工单;持有 gov_approver + role_data_all |
dwh_lin(林伟东) | 数据管理部·数仓组 | 数仓建设(接入、分层、发起建表工单) | 建数仓表、配库到库同步;对他人数据持 READ 时敏感字段是掩码;持有 role_dwh_engineer |
model_zhao(赵雪) | 风险管理部·建模组 | 建 ML 模型(算通过概率) | 训练导出模型文件并在平台加载执行;对别人的数据持 READ,已登记的敏感列是掩码;持有 role_decision_all |
dev_engineer(孙浩) | 信息科技部·工作流组 | 编排打分流(串模型 + 规则)、对接下游;并且是几张信贷表的属主 | 把模型与规则编成决策流 / 打分流并发布;查自己建的那几张表是明文,查别人的表按分享时的配置;持有 role_flow_orchestrator + role_data_owner_share(可自助把自己的表分享出去) |
stock_biz(张伟) | 金融市场部 | 平台只读需求方(role_biz_requester) | 可登录平台只读浏览但不建模;在本流程中作下游消费方,经金融市场侧网关应用凭据 STOCK-CONSUMER-001 调用对外 API 取分 |
credit_biz(李强) | 信贷业务部 | 平台只读需求方(role_biz_requester) | 同上,经信贷侧网关应用凭据 RISK-CONSUMER-001 调用对外 API 消费信贷相关的评分 |
怎么做(逐条验证权限剧情):分别登录上述账号,按下表逐条核对"预期结果"。这一遍跑下来,权限边界就从抽象变具体了。
| 账号 | 操作 | 预期结果 |
|---|---|---|
stock_biz(张伟) | 调用金融市场评分接口 /score/stock | 正常出分 |
stock_biz(张伟) | 调用信贷评分接口 /score/credit | 被拒(403)——应用只绑定了自己的路由,不能跨应用互调 |
credit_biz(李强) | 调用信贷评分接口 /score/credit | 正常出分 |
model_zhao(建设者) | 访问数据源列表 /datasource/list | 直接被拒(缺少 data:source:list 权限)——决策引擎全模块与数据中台-消费分析这两个角色都不带数据源管理,侧边栏里也没有这个入口 |
业务消费方(stock_biz/credit_biz) | 访问数据源列表 /datasource/list | 同样直接被拒(code=500,缺少 data:source:list 权限)——不是返回空列表;前端应对业务角色隐藏该入口以免报错 |
model_zhao | 申请前查风险建模所需的数据源 | 无权 |
model_zhao | 申请后查加工层(DWD)明细 | 证件号 / 手机号脱敏(这两列已登记为敏感列,兜底策略生效);即便用其落库生成副本,副本表里也是掩码 |
dev_engineer(该表属主) | 查同一张 DWD 明细 | 明文——属主对自己建出来的表看完整值,这是设计如此,不是脱敏失效 |
dev_engineer | 在数据授权页把自己的表分享给他人,并给证件号列配规则 | 保存成功,但先不放权;几秒后引擎侧脱敏就位才放开读权限——判断办法是让受让人隔几秒再查一次,页面上看不到这个中间状态 |
dev_engineer | 在数据授权页试图分享一张不是自己建的表 | 被拒——"只能分享自己是属主的表(须是平台为你建出并已发布的物理表)" |
| 任何非超管 | 在数据授权页做库级授权 | 被拒——"库级授权仅超管可操作",请按表分享 |
| 打分流程内部 | 已发布打分 API 被调用 | 以打分服务账号的真实身份执行(取不到画像即拒绝,不回落超管);该账号读中台表同样要被显式授权,看到明文还是掩码按 2.5.2 判定 |
| 任何人 | 在授权页配行级过滤 | 页面上没有这个入口;即便通过接口写进去也不生效、不报错,请勿依赖(见第三章 3.7.2) |
dwh_lin / 任一建设者 | 建表 / 数据标准 / 建指标 / 资产发布 | 均生成工单,审批通过前不生效 |
| 非 OWNER 用户 | 在工作台执行 CREATE TABLE | 被拒——建表须对目标库有 OWNER |
验证闭环:以 model_zhao(赵雪)为例,完成一次"申请 → 审批 → 再查"的闭环后,前往数据地图查看该字段预览,可发现证件号已呈 330106********1953 形态;再用该表属主账号查同一列,应为完整明文。两个结果同时成立,才证明"READ 授权 + 按人的引擎级脱敏"两条链路都已生效——只看到一边,说明判定没落到人头上。
说明: 上表中按账号归类的对外调用(如
stock_biz/credit_biz取分),底层由对应网关应用的X-APP-ID与X-API-Key鉴权,与用户登录 Token 无关——业务账号能否登录平台,与其消费方身份是两回事。
说明: 业务线部门向建设部门"提需求"属于组织流程,平台不为它建假工单;只有"申请数据 / 建表 / 数据标准 / 建指标 / 资产发布"这类数据中台侧动作,才走系统里的真实工单;决策引擎的规则流 / 模型发布则由内容层属主写权限直控、发布即刻生效,不走审批工单。且提单人不能审自己的单(职责分离),例如由建设者提单、由
data_admin审批。
注意: 演示时若希望"申请一提交,授权立刻生效",需知道授权同步是最终一致的——1. 首轮同步通常只落下申请记录;2. 第二轮才真正发放授权(由定时对账器补齐)。因此现场演示要立即看到效果时,可连续触发两次同步。
2.7 上手排错备忘:环境、入口与"三个网关"别混
场景:施工或调接口时,新人最常翻车在"把请求发错了网关",或"在错误的服务上找模型接口"。这一节把入口关系理清,当排错备忘用。
是什么:平台由多个后端服务组成,请求经统一网关按前缀路由到各服务。名字里带"网关"的东西有三样,职责完全不同:
| 网关 | 职责 | 什么时候用它 |
|---|---|---|
| 平台统一网关 | 内部统一入口,按前缀去掉一段后转发到各服务 | 施工、调设计态 API 时经它 |
| 对外业务网关 | 只放行动态注册的业务路由,绝不透传内部服务前缀 | 下游消费方调用出分接口时经它 |
| 网关管理后台 | 管路由、上游、应用的配置后台 | 配路由、发 apiKey、绑应用时进它 |
平台统一网关的前缀 → 服务映射(排错时对照,判断请求该落到哪个服务):
| 前缀 | 指向 |
|---|---|
/auth | 认证服务 |
/system | 系统服务(用户/角色/菜单/部门) |
/datasource | 数据源服务 |
/resource | 文件服务 |
/workflow | 工作流服务 |
/scheduler | 调度服务 |
/content | 决策引擎-内容服务 |
/model | 决策引擎-运行时服务 |
/lab | 决策引擎-实验室服务 |
/gateway-admin | 网关管理服务 |
/data-management | 数据管理服务 |
/data-governance-executor | 数据治理执行器 |
注意: 有两处
model分属不同服务,别撞车:1. 数据中台的建模端点在/data-management/model/...;2. 决策引擎的运行时模型在/model/...(经统一网关去掉一段前缀后落到运行时服务的/model/{name}/execute,故对外看到的是双段/model/model/{name}/execute)。若误发裸/model/table/list,会撞到决策引擎运行时服务,而不是建模服务。
说明: 上表的前缀是路由约定,可照抄;而具体地址与端口随部署环境而定,以运维《运行说明》为准。数据存储采用列式分析型数仓引擎(引擎级脱敏依赖它);网关配置库独立、与业务库分离;资产扫描、数仓加工等定时任务由内置调度每天自动跑。
2.8 上手小结
至此,第一次进入需要的全局认知与三步操作已经走通:
- 看懂全局——平台是一条"数据中台 → 决策引擎 → 数据网关"的流水线:中台保证"有数据"、引擎保证"会判断"、网关保证"安全地对外",下游只感知一次 HTTP 调用。
- 登录——用户名 + 密码换回一枚 Token,Token 承载身份,菜单随即按角色下发。改了权限没生效,先想到"重新登录 / 清权限缓存"。
- 看懂角色——两层设计:
role_*_all给整块模块,细粒度职责角色(asset_governor/asset_consumer/security_auditor/gov_approver/role_data_read等)可叠加;admin由套餐驱动、superadmin处处放过;安全策略收口在管理员。要配角色时,对着 2.4.5 的角色清单和 2.4.6 的数据范围逐档说明挑,挑完记得按 2.4.12 处理缓存。 - 理解"看到什么由谁决定"——菜单由角色决定,数据可见性由资源层 OWNER/READ 决定,敏感字段由引擎级脱敏决定;而脱敏能不能挂上,取决于走的是建模流还是同步直用流。看不到、点不动、下拉为空,先按这几层自查,多数不是故障。
理解了这几层,用户就具备了走进任意一个模块、并读懂"为什么这里能做、那里不能做"的基础。接下来的章节,将顺着"数据中台 → 决策引擎 → 数据网关"这条流水线,带用户完成第一个真正端到端的任务。
说明: 本章出现的账号、密码、租户号、端口及接口示例均取自开发演示环境,仅用于说明与验收对照,不代表生产配置;实际环境的地址、端口与账号以运维《运行说明》及管理员分发为准。