老张用 Workload Group 当"班主任"，把Doris集群治理得服服贴贴
数据库老张正呼呼大睡着，突然被告警电话吵醒：
"老张，快看监控，集群要炸了！“这已经是本周第三次了。
每次都是那个数据分析师的"神仙查询”，一跑就把内存吃光，害得其他查询都跪了。
正当老张抱怨"这日子没法过了"的时候，他发现了Doris有个救命稻草——Workload Group。
这个"资源管理老师"不仅能管住调皮的查询，还能让不同业务和谐共处。从此，老张终于能睡个安稳觉了。
今天，让我们跟着老张一起，揭秘这个让DBA摆脱"通宵值守"的法宝！
![[]](https://i-blog.csdnimg.cn/direct/4c33917eee6d436c8a02036dcc1c2db1.png)
Doris多租户战争中的和平使者
运维老李一大早就收到告警，气急败坏地喊来了数据库老张: “老张，快来看监控，那个大数据分析师又把集群跑挂了！”
"唉，又是这样。"老张叹了口气，“昨天是机器学习团队的特征计算把CPU打满，前天是BI团队的即席查询吃光内存，今天又是数据分析师的全表扫描…”
这种场景相信很多Doris运维同学都不陌生。
在一个共享的数据库集群里，各种查询好比一群贪吃的小朋友，都想抢占最多的资源。如何让他们和平共处？这就需要一个"资源管理老师" - Workload Group登场了。
![[tu]](https://i-blog.csdnimg.cn/direct/150f4bb20df84447928074e716342ccc.png)
Doris Workload Group好比一所特殊的"查询学校"的"班主任"管理员。
在这所学校里，不同类型的查询就像不同班级的学生：ETL作业是勤勤恳恳的实验班，报表查询是需要准时完成作业的重点班，即席查询则像个创新实验室，充满了不确定性。
每个"班级"都有自己的专属教室（CPU资源）、自习室（内存空间）和图书借阅配额（IO带宽）。学校里有两种管理模式：
温柔模式（软限制）：
- CPU教室：空教室可以借用给需要加班的同学
- 自习室：图书馆没人时可以多占几个座位
- 但一旦资源紧张，必须按原定计划让座
严格模式（硬限制）：
- CPU教室：只能用自己班的教室，不得超员
- 自习室：超出座位限制就请同学离开
- 图书借阅：每天固定配额，绝不超借
老张配置好Workload Group后，终于不用再担心"熊孩子"们打架了：
- ETL作业乖乖待在实验室做大规模计算
- 报表查询按时完成日常作业不受干扰
- 即席查询有了自己的创新空间又不会影响他人
最妙的是，这些规则都是自动执行的，再也不用半夜被告警电话吵醒了！
Doris资源调度指南
运维老李八卦地问道: “老张，我发现你最近都睡得挺好，不再有半夜被电话轰炸的情况了？”
“可不是嘛！自从给’查询学校’配好’课程表’后，日子清静多了。”,老张得意地晃了晃手中的咖啡杯: “我来分享下这套’教学管理系统’的配置经验。”
![[tu]](https://i-blog.csdnimg.cn/direct/96c023285e7a447c93cdae9ea5973dae.png)
"来，我们先给’查询学校’装修一下教室。"老张打开了终端，开始演示配置步骤:
环境装修
"首先要给每个班级划分专属区域。"老张解释道，“我们用CGroup来实现这个功能。”
# 详细步骤参考：https://doris.apache.org/zh-CN/docs/dev/admin-manual/workload-management/workload-group
# 创建cgroup目录（如果是cgroup v1就在cpu目录下新建）
mkdir /sys/fs/cgroup/cpu/doris
# 设置权限
chmod 770 /sys/fs/cgroup/cpu/doris
chown -R doris:doris /sys/fs/cgroup/cpu/doris
“这就像给学校划分好了教学楼和活动区，接下来就可以开始’招生’了！”
班级配置艺术
"现在来创建不同的’班级’。"老张熟练地敲击键盘：
-- 创建ETL实验班
CREATE WORKLOAD GROUP etl_group PROPERTIES(
'cpu_share' = '1024',
'memory_limit' = '40%',
'enable_memory_overcommit' = 'false'
);
-- 创建报表重点班
CREATE WORKLOAD GROUP report_group PROPERTIES(
'cpu_hard_limit' = '50%',
'memory_limit' = '30%',
'max_concurrency' = '20'
);
“看到了吗？ETL班用的是CPU软限制，像个开放的实验室；报表班用的是CPU硬限制，就像固定教室只给重点班使用。”
学籍管理妙招
"有了班级，还要给学生分配班级。"老张继续演示：
-- 设置用户默认组
SET PROPERTY FOR 'etl_user' 'default_workload_group' = 'etl_group';
-- 临时调整组别
SET workload_group = 'report_group';
“这样，ETL用户的查询就会自动进入ETL实验室，需要时还可以临时换到其他教室。”
监控巡查有方
"最后别忘了装个’监控摄像头’。"老张打开了监控面板：
-- 查看资源使用情况
SELECT * FROM information_schema.workload_group_resource_usage;
“这样就能实时看到每个’班级’的表现了：谁在偷懒，谁太活跃，一目了然！”
老李看得连连点头：“妙啊！这套系统既能让学生各司其职，又能灵活调配资源。”
"关键是要用对方法。"老张总结道，“好比带孩子，既不能太严厉，也不能太放纵。找到平衡点，整个’学校’就能和谐运转了。”
Doris"查询学校"实战演练记
"老张，临时有个业务需求，能给讲讲你们线上是怎么玩转Workload Group的吗？"某日，隔壁团队的小王找上了老张。
"正好我这儿有几个经典案例。"老张打开了他的"成功案例"笔记本。
![[tu]](https://i-blog.csdnimg.cn/direct/ce09ff7bc0744dde902dcfd1bbb1d063.png)
"说个我们遇到的典型问题。"老张喝了口咖啡，“之前有个数据分析师，喜欢写即席查询做数据探索，动不动就是全表扫描，经常把内存吃光。”
即席查询驯服记
"看看这个内存使用曲线。"老张指着监控图表，“每次他的查询一跑，内存就像坐过山车。我们是这样解决的：”
-- 创建即席查询专属组
CREATE WORKLOAD GROUP adhoc_group PROPERTIES(
'memory_limit' = '30%',
'enable_memory_overcommit' = 'false',
'max_concurrency' = '5',
'max_queue_size' = '10',
'queue_timeout' = '300000'
);
“这就像给他划了个小实验室，只能用30%的内存，最多同时跑5个查询，其他的要排队，等待超过5分钟就自动取消。”
监控显示，配置后内存用量平稳了，其他业务也不受影响了。
ETL任务的CPU之争
"再说个CPU管理的案例。"老张继续道，“我们有个ETL任务，每天凌晨要处理大量数据，CPU使用率经常90%以上，导致早上上班后报表查询特别慢。”
解决方案是设置CPU硬限制：
-- 配置ETL组CPU限制
CREATE WORKLOAD GROUP etl_group PROPERTIES(
'cpu_hard_limit' = '30%',
'read_bytes_per_second' = '104857600'
);
-- 配置报表组
CREATE WORKLOAD GROUP report_group PROPERTIES(
'cpu_hard_limit' = '50%'
);
“这样ETL任务最多只能用30%的CPU，主要算力留给报表使用。而且我们还限制了它的IO，防止疯狂读盘影响其他查询。”
…
小王听得连连点头：“这么看来，Workload Group就像个智能管家，给每个业务都安排得妥妥的。”
"对，关键是要理解各个业务的特点。"老张总结道，“比如即席查询需要内存控制，ETL需要CPU限制，数据导入要管理IO。配置合理了，整个系统就能运转自如。”
"最重要的是，再也不用半夜爬起来处理告警了！"老张得意地伸了个懒腰。
这就是老张的Workload Group实战经验分享，希望能帮助你解决Doris资源管理的烦恼。
下期，我们将一起探讨其它更有趣有用有价值的内容，敬请期待！
2257
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
