销售只能看自己区域的数——报表权限和行级隔离怎么设计？

-- 第1步：权限维表——用户能看什么，集中一张表说清楚
CREATE TABLE dim_user_data_scope (
  user_account STRING COMMENT 'BI登录账号',
  scope_type   STRING COMMENT '权限维度: region / channel / all',
  scope_value  STRING COMMENT '可见范围值，如 US、EU',
  valid_date   STRING COMMENT '生效日期',
  expire_date  STRING COMMENT '失效日期，离职/转岗自动失效'
) COMMENT '行级权限映射表｜来源：HR系统每日同步';
 
-- 第2步：语义层统一注入——BI数据集里配置一次行级过滤
-- 伪代码：WHERE region IN (SELECT scope_value
--   FROM dim_user_data_scope
--   WHERE user_account = CURRENT_USER()
--     AND '${bizdate}' BETWEEN valid_date AND expire_date)
 
-- 第3步：管理员豁免走 scope_type='all'，同样走表，不走后门

-- 引擎层RLS示例（PostgreSQL系，Hologres同理）
CREATE POLICY sales_region_policy ON ads_sales_daily
  FOR SELECT
  USING (region IN (
    SELECT scope_value FROM dim_user_data_scope
    WHERE user_account = CURRENT_USER
      AND CURRENT_DATE BETWEEN valid_date::date AND expire_date::date
  ));
ALTER TABLE ads_sales_daily ENABLE ROW LEVEL SECURITY;
-- 效果：不管从BI、JDBC还是临时SQL进来，看到的都是过滤后的行

我的选择逻辑：只有BI一个访问入口时，BI语义层够用且最省事；开放了自助分析、JDBC直连的（第12篇那种场景），必须下沉到引擎层RLS，否则语义层就是马奇诺防线；物理拆分只用于合规硬要求的场景（不同法域的数据不能同库之类）。

列级权限和脱敏

行级管“看哪些行”，列级管“看哪些字段”。典型需求：运营能看订单量和金额，但成本和毛利只有管理层能看；客服能查订单但手机号要打码。列级的实现比行级简单：BI数据集里按角色隐藏字段，或者建带脱敏逻辑的视图分角色授权：

-- 脱敏视图：同一张表，不同角色看不同版本
CREATE VIEW v_order_for_cs AS   -- 客服版
SELECT order_id, order_status, amount,
       CONCAT(SUBSTR(phone, 1, 3), '****',
              SUBSTR(phone, 8)) AS phone   -- 手机号脱敏
FROM dwd_trade_order_di;
 
CREATE VIEW v_order_for_mgmt AS  -- 管理层版：多出成本毛利列
SELECT order_id, order_status, amount, cost, gross_profit
FROM dwd_trade_order_di;
-- 原则：敏感列的可见性在视图/数据集层解决，明细表本身不开放

面试高频追问

追问一：权限维表谁来维护？数据团队自己维护不是成了瓶颈？

数据团队定机制，不做日常审批——这是权限体系能不能持续的关键。正确的分工：权限映射的“事实来源”是HR和组织架构系统，每日自动同步进权限维表，入转调离自动生效失效；超出组织架构的特殊授权（比如某分析师临时要看全球数据）走工单审批，审批人是数据owner（业务负责人）而不是数据开发；数据团队负责同步链路的稳定和季度权限审计（拉一遍“谁能看什么”的清单给各owner确认）。数据开发一旦变成人肉审批节点，要么成为瓶颈，要么为了效率放水，两个结局都是失败。

追问二：行级权限上了之后，用户导出Excel再转发，不就全泄露了？

要分清权限体系的边界：技术手段管到“系统内可见性”，导出转发属于数据流转管理，靠技术+制度组合。技术上能做的：敏感报表禁用导出或者导出加水印（谁、何时导出，泄露可溯源）、导出行为进审计日志、超大额度导出触发审批。制度上必须有数据分级规范和保密协议兜底——这不是推责，任何公司的安全体系里，技术控制和制度约束本来就是两条腿。面试时能说清“技术管边界内、制度管边界外”，比吹嘘技术全能更专业。

追问三：行级过滤会不会拖慢查询性能？

会有影响，但可控。权限子查询本质是给每个查询加了一个小表JOIN/IN条件，优化手段：权限维表做成引擎内的小维表（几千行级别，走Broadcast）；scope_value上建索引；BI侧把用户的权限范围缓存进会话变量，避免每个图表查询都重复查权限表。实测下来行级过滤对查询延迟的影响一般在毫秒级，真正的性能杀手反而是权限设计不当——比如给某人配了几百个scope值导致IN列表爆炸，这种要改成范围编码（配“EU”而不是27个国家逐个配）。

实战踩坑：转岗三个月，还能看到老区域的数

在某出海硬件品牌踩过权限时效性的坑。早期的行级权限表是运营同学手工维护的Excel导入，有次内部审计抽查发现：一位从美区转岗到欧区三个月的同事，账号还能看到美区的全部销售数据；更尴尬的是还有一个离职员工的账号仍然有效（SSO停了但BI本地账号没停）。没有造成实际泄露，但审计报告很难看。整改就是上面那套机制：权限表对接HR系统每日同步，带valid_date/expire_date；BI账号统一走SSO，禁止本地账号；每季度自动生成“账号-权限”清单发给各业务owner签字确认。手工维护的权限表，从它建立那天起就在腐烂——这句话我后来跟每个新团队都讲。

教训：权限体系的失效模式不是“配错了”，而是“没人更新”。设计时就要把入转调离的自动化同步做进去，否则上线即巅峰，之后逐月失控。

总结

报表权限体系：功能权限用BI角色管理，行级权限用“权限维表+统一注入”（BI语义层起步，有直连场景下沉引擎RLS），列级用脱敏视图/数据集字段控制。权限数据来源对接HR自动同步，审批权交给业务owner，数据团队管机制和审计。面试时讲出“权限彩蛋vs权限体系”的区别和转岗失效的坑，就能证明你真的运营过权限而不只是配置过权限。

下一篇聊报表的免疫系统：别让老板先发现数不对——报表的数据质量监控怎么建？

你们公司发生过越权看数的事吗？权限表是自动同步还是手工维护？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长