老张用 Workload Group 当"班主任"，把Doris集群治理得服服贴贴

❝

数据库老张正呼呼大睡着，突然被告警电话吵醒： 

"老张，快看监控，集群要炸了！"这已经是本周第三次了。 

每次都是那个数据分析师的"神仙查询"，一跑就把内存吃光，害得其他查询都跪了。

正当老张抱怨"这日子没法过了"的时候，他发现了Doris有个救命稻草——Workload Group。 这个"资源管理老师"不仅能管住调皮的查询，还能让不同业务和谐共处。从此，老张终于能睡个安稳觉了。 

今天，让我们跟着老张一起，揭秘这个让DBA摆脱"通宵值守"的法宝！

Doris多租户战争中的和平使者

运维老李一大早就收到告警，气急败坏地喊来了数据库老张: "老张，快来看监控，那个大数据分析师又把集群跑挂了！"

"唉，又是这样。"老张叹了口气，"昨天是机器学习团队的特征计算把CPU打满，前天是BI团队的即席查询吃光内存，今天又是数据分析师的全表扫描..."

这种场景相信很多Doris运维同学都不陌生。

在一个共享的数据库集群里，各种查询好比一群贪吃的小朋友，都想抢占最多的资源。如何让他们和平共处？这就需要一个"资源管理老师" - Workload Group登场了。

Doris Workload Group好比一所特殊的"查询学校"的"班主任"管理员。

在这所学校里，不同类型的查询就像不同班级的学生：ETL作业是勤勤恳恳的实验班，报表查询是需要准时完成作业的重点班，即席查询则像个创新实验室，充满了不确定性。

每个"班级"都有自己的专属教室（CPU资源）、自习室（内存空间）和图书借阅配额（IO带宽）。学校里有两种管理模式：

温柔模式（软限制）：

严格模式（硬限制）：

老张配置好Workload Group后，终于不用再担心"熊孩子"们打架了：

最妙的是，这些规则都是自动执行的，再也不用半夜被告警电话吵醒了！

Doris资源调度指南

运维老李八卦地问道: "老张，我发现你最近都睡得挺好，不再有半夜被电话轰炸的情况了？"

"可不是嘛！自从给'查询学校'配好'课程表'后，日子清静多了。",老张得意地晃了晃手中的咖啡杯: "我来分享下这套'教学管理系统'的配置经验。"

"来，我们先给'查询学校'装修一下教室。"老张打开了终端，开始演示配置步骤:

环境装修

"首先要给每个班级划分专属区域。"老张解释道，"我们用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的吗？"某日，隔壁团队的小王找上了老张。

"正好我这儿有几个经典案例。"老张打开了他的"成功案例"笔记本。

"说个我们遇到的典型问题。"老张喝了口咖啡，"之前有个数据分析师，喜欢写即席查询做数据探索，动不动就是全表扫描，经常把内存吃光。"

即席查询驯服记

"看看这个内存使用曲线。"老张指着监控图表，"每次他的查询一跑，内存就像坐过山车。我们是这样解决的："

-- 创建即席查询专属组
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资源管理的烦恼。

下期，我们将一起探讨其它更有趣有用有价值的内容，敬请期待！