预计阅读时间: 45 分钟 前置阅读: doc-09, doc-14, doc-23 下一次阅读: doc-25(源码贡献与调试)
1. 为什么治理是专家能力
单人测试 Doris 时, 权限和治理似乎不重要。生产集群里, 真正的问题是:
- 多个团队共享同一集群。
- BI、ETL、Adhoc、应用 API 抢资源。
- 敏感数据需要隔离。
- 大 SQL 需要自动熔断。
- 审计要能回答"谁在什么时候查了什么"。
专家要把安全和稳定放在一起看:
身份认证
→ 权限授权
→ 数据域隔离
→ 资源隔离
→ 审计与熔断
参考:
- https://doris.apache.org/docs/4.x/admin-manual/auth/
- https://doris.apache.org/docs/4.x/admin-manual/workload-management/
- https://doris.apache.org/docs/4.x/admin-manual/workload-management/sql-blocking/
2. 身份与账号分层
不要让所有系统共用一个 Doris 账号。
推荐分层:
| 类型 | 示例 | 权限 |
|---|---|---|
| 管理账号 | doris_admin | 管理集群, 少数人使用 |
| 应用账号 | app_dashboard | 只读指定库表 |
| 导入账号 | etl_loader | Load/Insert 指定表 |
| 分析账号 | analyst_x | 受控查询权限 |
| 运维账号 | ops_monitor | 查看系统表和指标 |
原则:
- 一套应用一个账号。
- 导入账号不授予无关查询权限。
- 分析账号不授予 DDL 权限。
- 管理账号不开给程序。
- 离职、系统下线要回收账号。
3. 权限模型
权限至少按这些层级设计:
Global
→ Catalog
→ Database
→ Table / View
→ Column
常见授权:
CREATE ROLE dashboard_reader;
GRANT SELECT_PRIV ON db.report_view TO ROLE dashboard_reader;
GRANT dashboard_reader TO USER app_dashboard;
生产建议:
- 面向角色授权, 不直接给用户堆权限。
- 只暴露视图或脱敏表给普通分析用户。
- DDL 权限与 DML/Load 权限分开。
- 外部 Catalog 权限单独审查。
4. LDAP、Ranger 与企业集成
当团队规模变大, 本地账号会难维护。可以接入企业身份系统:
- LDAP: 复用企业账号和组。
- Ranger: 统一管理数据权限策略。
- Kerberos/Hadoop 生态: 湖仓访问时常见。
专家判断:
| 场景 | 方案 |
|---|---|
| 小团队 | Doris 本地用户和角色 |
| 企业统一账号 | LDAP |
| 多引擎统一权限 | Ranger |
| 湖仓外表 | 同时检查 Doris 权限和外部存储权限 |
不要只在 Doris 授权, 外部 Catalog 背后的 Hive、HDFS、S3、对象存储权限也要匹配。
5. 多租户资源隔离
Workload Group 是 Doris 多租户稳定性的核心之一。
CREATE WORKLOAD GROUP dashboard
PROPERTIES (
"cpu_share" = "1024",
"memory_limit" = "40%",
"max_concurrency" = "30",
"max_queue_size" = "100"
);
CREATE WORKLOAD GROUP adhoc
PROPERTIES (
"cpu_share" = "256",
"memory_limit" = "20%",
"max_concurrency" = "5",
"max_queue_size" = "20"
);
分组原则:
| 负载 | 特征 | 资源策略 |
|---|---|---|
| Dashboard | 高频、短查询 | 高优先级, 控并发 |
| Adhoc | 不可预测 | 限内存, 限并发, 可排队 |
| ETL | 大吞吐 | 独立窗口, 防止挤压在线 |
| MV Refresh | 可调度 | 独立组, 夜间或错峰 |
| API 点查 | 延迟敏感 | 小查询专用组 |
6. SQL Block Rule 与 Workload Policy
SQL Block Rule 在规划期拦截风险 SQL, Workload Policy 在运行时按资源指标熔断。
适合拦截:
- 没有分区条件的全表扫描。
- 超大扫描量查询。
- 禁止的函数或 SQL 模式。
- 超过运行时间的查询。
- 内存使用异常的大查询。
策略:
开发/测试用户: 严格拦截
分析用户: 扫描量和运行时间限制
核心应用: 保护低延迟, 不让长查询混入
管理员: 保留应急权限, 但审计更严格
熔断不能代替培训。被拦截的 SQL 要反馈给使用者, 告诉他应该加分区条件、改查询路径或使用汇总表。
7. 审计与数据治理
审计至少记录:
- 谁查询。
- 什么时候查询。
- 查询了哪个库表。
- 扫描了多少数据。
- 返回多少行。
- 用了多久。
- 是否失败。
用途:
| 用途 | 数据 |
|---|---|
| 慢 SQL 治理 | query_time、scan_bytes |
| 成本分摊 | user、workload_group、资源消耗 |
| 安全审计 | user、db、table、stmt |
| 热表识别 | table 访问频率 |
| 下线评估 | 长期无人访问表 |
将 audit log 汇入 Doris 自身也是常见做法, 但要避免审计表被所有人读取。
8. 数据分层与脱敏
专家不会把所有人都指向原始表:
raw 明细层
→ dwd 清洗层
→ dws 汇总层
→ ads / view 服务层
治理策略:
- 原始 PII 字段只给少数角色。
- 普通分析使用脱敏视图。
- 外部共享使用汇总表。
- 行级隔离用租户字段和视图约束。
- 高风险导出需要审批。
即使 Doris 支持高性能明细查询, 也不意味着所有明细都应该暴露。
9. 多租户验收清单
1. 是否每个系统有独立账号
2. 是否使用角色而不是直接授权
3. 是否区分读、写、DDL、管理权限
4. 是否接入企业身份或权限系统
5. 是否按负载划分 Workload Group
6. 是否有 SQL 熔断和运行时策略
7. 是否收集并保留审计日志
8. 是否有脱敏视图或服务层表
9. 是否定期清理账号和权限
10. 是否演练过大查询拖垮集群的保护
一句话总结:
Doris 治理专家要能同时回答"谁能看什么"和"谁能用多少资源", 因为数据安全和集群稳定本来就是同一个生产问题的两面。