Doris数据网关限制

##############################################################################

1、租户并发控制,限制查询并发数,超限制进入队列等待

1-通过 Workload Group(工作负载组) 实现租户级别的并发控制和查询排队机制。

核心参数

max_concurrency Integer 2147483647 最大并发查询数。达到上限后,新查询进入队列等待

max_queue_size Integer 0 队列最大长度。队列满后,新查询直接拒绝。默认值 0 表示不排队

queue_timeout Integer 0 查询在队列中的最大等待时间(毫秒)。超时后向客户端抛出异常。默认值 0 表示不排队,立即失败

2-创建示例

CREATE WORKLOAD GROUP IF NOT EXISTS queue_group

PROPERTIES (

"max_concurrency" = "10",

"max_queue_size" = "20",

"queue_timeout" = "3000"

);

上述配置含义:最大并发数为 10,队列长度为 20,队列等待超时为 3 秒(超时后直接返回失败)。

注意事项

多 FE 场景:排队参数仅在单 FE 级别生效。

例如,若配置 max_concurrency = 1:

集群有 1 个 FE:整个集群同时只能运行 1 条 SQL

集群有 3 个 FE:整个集群最多可同时运行 3 条 SQL

3-查看队列状态

SHOW WORKLOAD GROUPS;

输出中关键字段:

running_query_num:当前正在运行的查询数

waiting_query_num:当前在队列中等待的查询数

##############################################################################

2、sql编译熔断,在sql规划阶段熔断,限制:扫描行数、分区数、分桶数

1-SQL 规划阶段熔断(SQL Block Rule)

创建语法

CREATE SQL_BLOCK_RULE <rule_name>

PROPERTIES (

, ...

);

扫描限制参数

参数 说明

cardinality 单表最大扫描行数

partition_num 单表最大扫描分区数

tablet_num 单表最大扫描分桶数

global true 对所有用户生效,false 仅对绑定用户生效

enable 是否启用该规则

2-示例

同时限制-单表扫描超过1000行时、单表扫描分区数超过30时、单表扫描分桶数超过 200 时,查询将被阻断。

CREATE SQL_BLOCK_RULE test_rule

PROPERTIES (

"partition_num" = "30",

"cardinality" = "1000",

"tablet_num" = "200",

"global" = "true",

"enable" = "true"

);

注意事项

估算逻辑:扫描行数、分区数、分桶数的计算在规划阶段完成,仅考虑分区裁剪和分桶裁剪,不考虑其他过滤条件(即按最坏情况估算)。因此,实际扫描量低于设定值的查询也可能被误拦截。

权限要求:创建 SQL Block Rule 需要 ADMIN_PRIV 权限。

临时禁用:将规则的 "enable" 设为 "false" 可临时禁用,无需删除规则。

3-绑定特定用户

1:创建规则时将 global 设为 false:

CREATE SQL_BLOCK_RULE rule_002

PROPERTIES (

"sql" = "select * from t",

"cardinality" = "1000",

"global" = "false",

"enable" = "true"

);

2:将规则绑定到目标用户:

SET PROPERTY FOR 'jack' 'SQL_block_rules' = 'rule_001,rule_002';

3:验证规则生效:

mysql> select * from t;

(1105, 'errCode = 2, detailMessage = SQL match regex SQL block rule: rule_001')

4:移除用户的所有规则-将规则列表设为空字符串:

SET PROPERTY FOR 'jack' 'SQL_block_rules' = '';

权限要求

创建 SQL Block Rule 需要 ADMIN_PRIV 权限。

执行 SET PROPERTY 绑定规则同样需要 ADMIN_PRIV 权限。

##############################################################################

3、sql运行熔断,在sql执行阶段熔断,限制:执行时长、内存占用、扫描行数、扫描大小

1-通过Workload Policy 在查询执行阶段进行实时监控并熔断。

支持的触发条件(Conditions)

query_time SQL 在单个 BE 进程上的运行时长,单位毫秒

query_be_memory_bytes SQL 在单个 BE 进程上的内存占用,并发执行时为累计值,单位字节

be_scan_rows SQL 在单个 BE 进程上扫描的行数,并发执行时为累计值

be_scan_bytes SQL 在单个 BE 进程上扫描的数据量,并发执行时为累计值,单位字节

支持的动作(Actions)

cancel_query 取消查询

set_session_variable 触发 set session variable 语句(仅由 username 条件在 FE 触发)

策略属性(Properties)

enabled 是否启用,取值为 true 或 false,默认值为 true

priority 优先级,取值范围为 0 到 100 的正整数,默认值为 0。值越大优先级越高,当查询匹配到多个 Policy 时,只有优先级最高的 Policy 生效

workload_group 绑定的 Workload Group 名称,指定后 Policy 仅对该 Workload Group 的查询生效。默认为空,表示对所有查询生效

2-创建示例

多条件组合(多个条件用逗号分隔,表示 AND 关系)并绑定到特定 Workload Group

CREATE WORKLOAD POLICY test_cancel_big_query

CONDITIONS(query_time > 1000, be_scan_rows > 10000 )

ACTIONS(cancel_query)

PROPERTIES('enabled'='true', 'workload_group'='normal');

重要注意事项

FE/BE 侧一致性:同一 Policy 的 Conditions 和 Actions 必须属于同一侧(FE 或 BE)。例如,set_session_variable 与 cancel_query 不能配置在同一 Policy 中;be_scan_rows 与 username 也不能配置在同一 Policy 中。

异步执行延迟:Policy 由异步线程按固定时间间隔(当前为 500ms)执行,因此存在一定延迟。运行时间极短的查询可能绕过策略检查。

优先级:一条查询可能匹配多个 Policy,但只有优先级最高的 Policy 生效。

不支持修改条件/动作:目前不支持修改 Actions 和 Conditions,只能通过删除后重建来修改。

权限要求:创建 Workload Policy 需要 admin_priv 权限。

##############################################################################

4、IO限速,内部表、外部表的读取限速

1-通过Workload Group可以对内部表(本地IO)和外部表(远程IO)的读取带宽进行限速。

相关参数

read_bytes_per_second -1(不限速) 限制读取内部表时的最大 IO 吞吐量(字节/秒)。

注意:该值针对目录而非磁盘,若多个目录在同一块磁盘上,实际最大吞吐为配置值的倍数

remote_read_bytes_per_second -1(不限速) 限制读取外部表(如 HDFS、S3)时的最大 IO 吞吐量(字节/秒)

2-配置示例

限制内部表读取 IO(100MB/s)

ALTER WORKLOAD GROUP g2

PROPERTIES('read_bytes_per_second'='104857600');

配置后,通过系统表可验证限速效果约为 98MB/s。

限制外部表读取 IO(100MB/s)

ALTER WORKLOAD GROUP normal

PROPERTIES('remote_read_bytes_per_second'='104857600');

配置后,远程读取 IO 吞吐量将被限制在约 100MB/s 附近(存在一定波动,属正常现象)。

3-监控当前IO使用情况

通过系统表 information_schema.workload_group_resource_usage 查看实时 IO 吞吐:

-- 查看内部表本地扫描速率(MB/s)

SELECT LOCAL_SCAN_BYTES_PER_SECOND / 1024 / 1024 AS mb_per_sec

FROM information_schema.workload_group_resource_usage

WHERE WORKLOAD_GROUP_ID = <your_group_id>;

-- 查看外部表远程扫描速率(MB/s)

SELECT CAST(REMOTE_SCAN_BYTES_PER_SECOND / 1024 / 1024 AS INT) AS read_mb

FROM information_schema.workload_group_resource_usage;

注意事项

read_bytes_per_second 针对目录而非磁盘:若 Doris 配置了多个数据目录,每个目录的最大读取 IO 均不超过该值。若多个目录在同一块磁盘上,该磁盘的实际最大吞吐为配置值的倍数。

Spill 磁盘也受限:内部表 IO 限速同样作用于 Spill 磁盘的文件目录。

远程 IO 存在波动:远程 IO 限速受算法设计影响,可能出现短暂超出限制的情况,属正常现象。

系统表与 Linux 工具的差异:由于操作系统和 Doris Page Cache 的存在,通过 Linux IO 监控工具(如 pidstat、sar)观测到的 IO 通常小于系统表中的值。

##############################################################################

5、资源隔离,内存、CPU、线程数硬隔离

资源隔离方式对比

Doris 支持三种资源隔离方法:

Resource Group BE节点级别,完全隔离 仅硬限制

Workload Group BE进程内隔离 软限制和硬限制均支持

Compute Group BE节点级别,完全隔离 仅硬限制

Workload Group 的 CPU 和内存硬隔离

Workload Group 是最灵活的隔离方式,支持在 BE 进程内对 CPU、内存、IO 进行细粒度管理。

CPU 硬隔离(MAX_CPU_PERCENT)

MAX_CPU_PERCENT:该 Workload Group 的 CPU 使用上限,无论当前 CPU 使用情况如何,该组的 CPU 使用率永远不会超过此值。

MIN_CPU_PERCENT:为该组保留的最低 CPU 带宽,资源争用时其他组无法占用这部分资源。

所有 Workload Group 的 MIN_CPU_PERCENT 之和不得超过 100%,且 MIN_CPU_PERCENT 不能大于 MAX_CPU_PERCENT。

Workload Group Core Concepts

示例:将某 Workload Group 的 CPU 硬限制设为 10%:

ALTER WORKLOAD GROUP g2 PROPERTIES('max_cpu_percent'='10%');

CPU Hard Limit Testing

内存硬隔离(MAX_MEMORY_PERCENT)

MAX_MEMORY_PERCENT:该组内请求的内存使用量永远不会超过总内存的此百分比。一旦超出,查询将触发磁盘溢写或被终止(kill)。

MIN_MEMORY_PERCENT:为该组保留的最低内存。当内存不足时,系统会按此值分配内存,并可能 kill 部分查询以释放内存,确保其他组有足够内存。

Workload Group Core Concepts

创建带硬限制的 Workload Group

CREATE WORKLOAD GROUP IF NOT EXISTS g1

PROPERTIES (

"max_cpu_percent"="10%",

"max_memory_percent"="30%"

);

CREATE WORKLOAD GROUP

关于线程数隔离

知识库中未明确提及 Workload Group 对线程数的直接硬隔离配置。Workload Group 主要管理 CPU、内存和 IO 资源。如需更彻底的进程级隔离(包括线程隔离),建议使用 Resource Group 或 Compute Group,将不同工作负载分配到独立的 BE 节点上运行。 [Workload Management Overview]

注意事项

CPU 管理依赖 CGroup 组件,使用前需配置 CGroup 环境。 [CGroup Setup]

在 Doris 4.0 中,原来的 CPU 软/硬限制概念已更名为 min_cpu_percent 和 max_cpu_percent,内存软/硬限制更名为 min_memory_percent 和 max_memory_percent。 [Workload Group]

生产环境建议使用硬限制,避免 CPU 或内存资源耗尽导致集群可用性下降。

##############################################################################

写入资源评估

使用以下公式逐步计算:

平均写入吞吐量 平均写入吞吐量 = 每日数据增量 / 86400 s

峰值写入吞吐量 峰值写入吞吐量 = 平均写入吞吐量 × 峰均比(默认 200%)

峰值写入所需 CPU 核数 CPU 核数 = 峰值写入吞吐量 / 单核 CPU 写入吞吐量(约 10 MB/s)

存储空间评估

存储空间 = 每日数据增量 / 数据压缩比 × 副本数 × 数据存储时长

数据压缩比通常在 3~10 之间(含索引数据)

Doris 默认使用 LZ4 压缩,压缩比约 0.3~0.5(即原始数据的 2~3 倍)

BE 磁盘空间需额外预留 40% 用于 Compaction 和临时数据

FE 建议预留 100 GB 以上 SSD 存储用于元数据

BE 节点数量计算

估算 BE 数量 = CPU 核数(写入) / 单台 BE CPU 核数 / (1 - 查询 CPU 预留比例)

实际 BE 数量 = MAX(副本数, 估算 BE 数量)

每台 BE 存储空间:

每台 BE 存储 = 热数据存储空间 / BE 数量 / (1 - 30%)

(30% 为预留存储空间)

建议每台 BE 挂载 4~12 块数据盘以提升 I/O 能力。

相关推荐
水火既济__2 小时前
大数据hive_mr压缩问题
大数据·hive·mr
一个数据大开发2 小时前
企业知识工程的三条路线:Neo4j 知识中台、Agent + Action 与本体原生 Runtime
大数据·python·neo4j
ZOOOOOOU2 小时前
云平台赋能门禁终端,打造智慧社区一体化管理
大数据·数据结构·架构
千瓜2 小时前
“小赛”掀“大浪”,小红书种草野生玩法
大数据·人工智能·数据分析·生活·新媒体
大数据流动2 小时前
OpenMetadata 1.13 正式发布!AI 数据治理开始进入语义上下文时代
大数据·人工智能
Bode_20022 小时前
AI时代下加速制造企业创新
大数据·人工智能·机器学习
OYangxf3 小时前
Git Conflict Resolution
大数据·git·elasticsearch
人工智能培训3 小时前
如何定义和测量“通用具身智能”
大数据·人工智能·机器学习·prompt·agent
青槿吖3 小时前
第一篇:Elasticsearch 入门踩坑记:从 “URL 拼写错误” 到跑通第一个搜索服务
大数据·elasticsearch·搜索引擎·spring cloud·微服务·架构·全文检索