AIGCBot
中文Get the checklist
Doris architecture

ANALYTICAL DATABASE / SOURCE READING / LESSON 24

Security, governance, and multitenancy

Build a Doris governance model across accounts, roles, LDAP/Ranger, Workload Groups, SQL blocking, audit, and masking.

Reading
45 min
Track
Doris architecture
Source
Chinese source notes

The source notes for this track are currently maintained in Chinese.

预计阅读时间: 45 分钟 前置阅读: doc-09, doc-14, doc-23 下一次阅读: doc-25(源码贡献与调试)

1. 为什么治理是专家能力

单人测试 Doris 时, 权限和治理似乎不重要。生产集群里, 真正的问题是:

  • 多个团队共享同一集群。
  • BI、ETL、Adhoc、应用 API 抢资源。
  • 敏感数据需要隔离。
  • 大 SQL 需要自动熔断。
  • 审计要能回答"谁在什么时候查了什么"。

专家要把安全和稳定放在一起看:

身份认证
  → 权限授权
    → 数据域隔离
      → 资源隔离
        → 审计与熔断

参考:

2. 身份与账号分层

不要让所有系统共用一个 Doris 账号。

推荐分层:

类型示例权限
管理账号doris_admin管理集群, 少数人使用
应用账号app_dashboard只读指定库表
导入账号etl_loaderLoad/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 治理专家要能同时回答"谁能看什么"和"谁能用多少资源", 因为数据安全和集群稳定本来就是同一个生产问题的两面。