运营同事不小心删了表——Doris权限管理和多租户实践
本文目录
先说结论
Doris的权限体系和MySQL几乎一致：用户 + 角色 + 权限三层模型。核心原则是最小权限——每个用户只给他需要的最少权限。生产环境至少要做到：查询用户只有SELECT权限、ETL用户有INSERT权限、管理员才有DDL和ADMIN权限。
多租户场景：不同部门创建不同的角色，每个角色绑定不同的库表权限。配合Workload Group做资源隔离，防止互相影响。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
在某元宇宙社交公司，有一次差点出大事：一个运营同事用Metabase连Doris做临时分析，不小心在SQL编辑器里执行了一个TRUNCATE TABLE。还好Doris有权限控制，他的账号没有DDL权限，执行直接报错了。但这次惊吓让我意识到权限管理的重要性。Doris兼容MySQL权限体系，用起来不难，但要设计合理。面试中大厂也越来越关注数据安全和权限治理。
用户和角色管理
权限粒度——从全局到列级别
| 权限粒度 | 示例 | 适用场景 |
|---|---|---|
| 全局权限 | GRANT ALL ON *.* TO user | 超级管理员 |
| 数据库级 | GRANT SELECT ON mydb.* TO user | 按部门分库 |
| 表级 | GRANT SELECT ON mydb.sensitive_table TO user | 敏感表单独控制 |
| 列级（Doris 2.0+） | 配合视图实现列级脱敏 | 隐藏敏感字段 |
列级权限的替代方案——视图脱敏
多租户资源隔离——Workload Group
这样即使分析师跑了全表扫描的重查询，也只能用20%的内存和10%的CPU，不会影响实时大盘。这是我在元宇宙社交公司被SELECT *拖慢集群之后落地的方案。
实战经验：我在某元宇宙社交公司的权限设计
| 用户/系统 | 角色 | 权限 | Workload Group |
|---|---|---|---|
| Flink ETL | etl_role | SELECT + LOAD（读+写） | etl（30% CPU） |
| Metabase大盘 | dashboard_role | SELECT（特定库） | dashboard（40% CPU） |
| 运营分析师 | analyst_role | SELECT（脱敏视图） | analyst（10% CPU） |
| 产品经理 | analyst_role | SELECT（脱敏视图） | analyst（10% CPU） |
| Wood（管理员） | admin_role | ALL | admin（不限制） |
实战踩坑：差点被TRUNCATE TABLE搞崩的故事
前面开头提到的那次惊吓：运营同事在Metabase的SQL编辑器里想执行一个DELETE语句清理测试数据，结果手滑复制了一段SQL包含TRUNCATE TABLE dwd_user_event。幸好他的账号只有SELECT权限，执行报错了。
事后加强措施：① Metabase连接配置用只读账号；② 所有分析类工具用专用只读角色；③ ETL操作只通过Flink专用账号执行；④ DDL权限只有admin_role有，且需要审批流程。
这次之后再没出过权限相关的问题。权限设计就像安全带——平时觉得没用，出事的时候救命。
面试高频追问
追问一：Doris的权限和MySQL完全一样吗？
高度兼容但不完全一样。Doris额外有ADMIN_PRIV（集群管理）、NODE_PRIV（节点管理）、LOAD_PRIV（数据导入）。核心的SELECT/INSERT/CREATE/DROP和MySQL一致。
追问二：行级权限Doris支持吗？
Doris 2.0+支持Row Policy（行级安全策略）。也可以用视图+WHERE条件实现行级过滤——创建一个带WHERE country = 'US'的视图给美国运营用。
追问三：怎么审计谁执行了什么SQL？
Doris自带审计日志（Audit Log），记录每条SQL的执行者、时间、扫描行数、执行时间等。通过FE审计日志插件可以把日志写入Doris自身的表里，方便查询分析。
总结
Doris权限管理面试讲三个层面：① 权限模型（用户+角色+权限，最小权限原则）；② 敏感数据保护（视图脱敏、行级策略）；③ 资源隔离（Workload Group给不同角色分配CPU/内存配额）。能讲出'分析师差点TRUNCATE TABLE'的真实故事和事后加强措施，面试官会觉得你不只懂技术，还有安全意识和运维经验。
Doris 面试通关手册
第16-20篇：高级特性与面试总结
Wood聊大数据
9年大数据老兵，聊技术、聊职场、聊成长