📚 课程目录第1章 Lakehouse权限管控概述

1. Lakehouse 权限管控概述

数据治理这个话题，说起来挺大的。但落到咱们工程师手上，核心就一句话：谁，能对哪些数据，做什么操作。我做了十几年数据平台，从传统数仓一路走到 Lakehouse，感触最深的就是权限管控这块的变化。

今天咱们先聊聊背景。为什么要搞细粒度权限？Lakehouse 和传统数仓到底差在哪？把这些理清了，后面讲具体实现你才能理解为什么这么设计。

数据治理不是一天建成的。我把它分成三个阶段，你对照一下自己团队在哪个位置。

阶段	典型时期	管控粒度	典型问题
第一阶段	2010 年前	库/表级别	粗放，一人有权限全库都能看
第二阶段	2010-2018	表/列级别	Hive/SQL-on-Hadoop 时代，靠 Ranger/Sentry 做列级脱敏
第三阶段	2019 至今	行/列/文件级	Lakehouse 要求细到“某用户只能看某分区某几列”

第一阶段说白了就是“管住大门”。那时候我在一家电商公司搭 Hive 数仓，DBA 给个库权限，整个团队都能 select *。后来出了个事故——实习生误删了分区表，恢复了两天。从那以后，我们才开始认真思考：权限能不能再细一点？

第二阶段有了 Ranger 和 Sentry，能做到列级脱敏了。比如手机号中间四位用 *** 代替。但行级过滤还是得靠视图，维护成本很高。我记得有个金融客户，光视图就建了 200 多个，每次表结构变更都要改一遍视图，苦不堪言。

到了第三阶段，Lakehouse 架构普及后，情况变了。数据存在对象存储上，计算引擎可以分离，权限管控必须下沉到文件级和元数据层。说白了，不能再靠“建视图”这种笨办法了。

核心变化： 数据治理的粒度从“库→表→列→行→文件”一路细化。管控越细，合规越容易，但实现复杂度也指数级上升。

你可能会问：库表级权限不够用吗？嗯，看场景。我举三个真实案例。

合规审计场景：某银行客户要求“客户经理只能看自己管辖客户的交易记录”。表级权限做不到，必须行级过滤。GDPR、CCPA、中国的《数据安全法》都要求这种粒度。
多租户场景：SaaS 平台的数据湖里，不同租户的数据混在同一个表里，靠 tenant_id 分区。如果权限只到表级，租户 A 就能看到租户 B 的数据。这显然不行。
数据脱敏场景：运营人员需要分析用户行为，但不能看到真实手机号和身份证号。列级脱敏 + 行级过滤，才能既保证业务可用，又保护隐私。

我曾经帮一个互联网公司做数据安全改造。他们的数据湖里有 5000+ 张表，但权限策略只有 30 多条——全是库级。结果审计发现，一个普通运营就能看到全量用户手机号。嗯，这种问题不出事还好，一出事就是公关灾难。

我的建议： 细粒度权限不是“要不要”的问题，而是“什么时候做”的问题。如果你的数据湖超过 100 张表、有 3 个以上业务方，就应该开始规划行/列级权限了。

传统数仓（比如 Teradata、Oracle、Greenplum）和 Lakehouse（比如 Delta Lake、Apache Iceberg、Apache Hudi）在权限管控上，思路完全不同。我画了张图帮你理解。

从图上你能看到，传统数仓的权限引擎是“内置”的，和数据库绑死。而 Lakehouse 的权限层是独立的，可以统一管控多个引擎。具体差异我列了个表。

这里有个关键点我想强调：Lakehouse 的权限管控，本质上是把“数据权限”和“计算权限”解耦了。你想想看，传统数仓里，数据存在哪、计算跑在哪、权限配在哪，全在一个黑盒里。而 Lakehouse 里，数据在对象存储上，计算引擎可以换，但权限策略始终统一。

注意： 这种解耦也带来了新问题——权限策略的“传播延迟”。比如你在 Ranger 里改了策略，Spark 可能 5 分钟后才生效，而 Presto 可能 1 分钟就生效了。我在项目中遇到过因为策略生效时间不一致导致的数据泄露风险。后面章节会专门讲怎么解决。

好，咱们把今天的内容串一下：