Doris资源管理与Workload Group实战：从查询隔离到自动化运维

先说我自己的经历。上个月线上一个实时报表集群白天高峰期CPU突然被干到95%业务反馈所有看板都卡成幻灯片。查了一圈罪魁祸首是一条凌晨跑的临时分析SQL同事图省事直接连了线上集群扫了一张近10亿行的大表把BE的线程池和内存吃了个精光。这件事之后我就想明白了Doris再快也经不起“有人不管不顾乱扔大查询”。所谓doris资源管理表面上是个配置项本质上却是一套“防止一条烂SQL拖死全家”的治理手段。这篇东西我想按我自己踩坑后的理解来写不贪多把Doris资源管理里最常用的几块讲透。内容包括Workload Group怎么做查询隔离、安装部署时怎么规划容量、Doris Manager怎么监控和运维、Terraform怎么把资源管理自动化顺带把CCR Syncer同步、Doris与StarRocks对比这些社区高频问题也放进来。适合正在部署Doris、被大查询拖垮集群、或者想把Doris资源管理纳入自动化运维体系的人看。先把整体思路捋清楚后面每一块都给了可以直接抄作业的配置和命令。1. 内容整体设计与思路拆解1.1 先把“资源管理”这几个字拆开看很多人一提Doris资源管理第一反应就是给集群多加点机器、把内存调大其实这只是最粗浅的一层。Doris资源管理按我的理解应该分三层看。第一层是集群资源规划即部署Doris之前就要想清楚的CPU、内存、磁盘、节点数、副本数直接决定这个集群能不能支撑预期的数据量和查询并发。第二层是查询资源管控这是Doris 2.0之后逐渐完善起来的能力通过Workload Group把不同业务的查询进行隔离和配额限制比如把ETL任务和线上报表分开把慢查询拒之门外。第三层是运维资源管理包括监控、告警、定期巡检、容量评估以及用Terraform这类基础设施即代码工具把资源定义变成可版本化的配置文件。这三层缺一不可。只做第一层属于“硬件堆砌”不做第二层就是“裸奔”不做第三层则永远在被动救火。所以这篇文章的章节也是按这个顺序展开的从设计思路到具体实操再到常见问题一层层往下拆。Doris作为一个MPP架构的OLAP数据库一次查询会拆分到多个BE节点上并行执行每个BE节点上又会启动多个实例处理分片。这套架构的好处是快副作用是如果某个查询特别“重”它会在每个BE节点上都吃CPU、占内存相当于从所有节点同时抽取资源。没有资源隔离机制时一个坏查询就等于把整个集群的算力全部耗尽其他正常业务只能排队干等。Workload Group要解决的就是这个问题它像公司食堂开了“大胃王专窗”和“普通窗口”让重查询和轻查询分开排队谁也不会把谁的饭抢走。1.2 Doris资源管理机制的整体演进脉络历史上Doris最早做资源管理主要依赖两个手段一个是用户级别的资源标签resource tag可以给节点打标签、把用户绑定到特定标签的节点上实现物理层面的粗粒度隔离另一个是依赖操作系统的cgroup限制进程资源。这两个方案都不是不好而是要么太粗、要么部署运维成本高。从Doris 2.0开始官方主推Workload Group方案把资源分组的粒度细化到查询级别。这不是说资源标签就没用了而是Workload Group能更灵活地做“软隔离”。什么叫软隔离就是同一个集群里不同Workload Group可以共享底层节点资源但通过CPU份额、内存上限、最大并发数、排队时间这些参数限制单个分组对资源的占用峰值。如果某个分组触发限制查询先排队而不是直接打死超过排队时间才拒绝这对用户体验更友好。我后来在多个环境里验证过设置了Workload Group的集群高峰期P99查询延迟能稳在一个可控区间而没设置的环境中一个跑批任务就能让在线报表集体超时。有句话说得很对资源管理的本质不是“多快”而是“可控”。Doris资源管理从粗粒度标签到细粒度Workload Group的演进核心目标也是这个。1.3 一条最简单的Workload Group配置长什么样在当前Doris版本里创建Workload Group的SQL大概长这样CREATE WORKLOAD GROUP wg_etl PROPERTIES ( cpu_share 20, memory_limit 30%, max_concurrency 5, max_queue_size 10, queue_timeout 3000 );这里的几个参数含义分别是cpu_share分组能拿到的CPU权重数值越大优先级越高不是绝对核数。memory_limit分组最大能使用的内存比例超过后会触发限制。max_concurrency允许同时执行的查询数超过这个数就排队。max_queue_size队列里最多能排多少个查询再多直接拒绝。queue_timeout查询在队列里等待的最长毫秒数超时就报错。创建完之后把指定用户绑定到这个GroupSET PROPERTY FOR etl_user workload_group wg_etl;如果你的Doris版本较老语法细节可能有差异但思路一致。看完这个示例再回头看1.1的三层理解应该就清楚了Workload Group管的是第二层也就是查询资源的配额和排队。2. 安装部署与前期资源规划2.1 部署前最重要的一件事把容量算了再动手Doris安装本身没有太多黑魔法真正考验人的是部署前的容量规划。很多团队装完Doris跑起来飞快等数据量大了才发现磁盘不够、节点不足最后只能推倒重来。我建议动手安装前至少把下面几个问题算清楚。第一是节点职责划分。Doris集群最小要两个角色FE负责元数据、查询解析和调度BE负责数据存储和查询执行。FE对硬件要求适中但它的元数据是类似Raft的高可用机制通常建议部署奇数个1、3、5生产环境至少3个FE。BE是资源消耗大户CPU、内存、磁盘都吃它生产环境建议至少3个起。如果你只有一台机器做测试FE和BE可以混部但生产环境一定要分开。第二是磁盘容量估算。Doris默认三副本意味着你要存的数据量大概是逻辑数据量的3倍再考虑压缩率Doris对多数列式数据压缩比能到3:1到5:1磁盘容量公式可以粗暴记成逻辑数据量 × 副本数 ÷ 压缩比。比如100GB原始数据3副本、压缩比4那么实际需要大约100×3÷475GB。这还只是数据本身临时文件、Compaction中间产物、日志都要额外预留空间我一般会再乘个1.5的冗余系数。第三是内存容量估算。BE的内存大头包括MemTable写入缓冲、查询执行、各种Cache。如果你有比较大的导入并发每条导入都会先写MemTable再刷盘MemTable没及时刷下去就会积压内存。经验值是一条导入并发大概占1-2GB内存批量导入高峰时至少预留10-20GB给导入缓冲查询侧则是根据Workload Group的memory_limit和并发数来推算。总之BE节点32GB内存起跳有条件上64GB别在这个地方省钱。2.2 Doris安装部署完整流程记录我自己常用的一套部署流程是这样这里用最简化的单FE、多BE场景演示生产环境照此扩展节点即可。下载对应版本的Doris安装包解压到统一目录比如/opt/doris然后按角色分配环境。FE节点配置fe.conf里几个关键项meta_dir/data/doris/fe/meta priority_networks192.168.1.0/24 sys_log_levelINFOpriority_networks建议主动指定不要靠自动探测否则多网卡机器很容易选错IP导致FE和BE互相找不到。BE节点同样在be.conf里配置storage_root_path/data1/doris/be;medium:HDD,capacity:2000000000,/data2/doris/be;medium:SSD,capacity:1000000000 priority_networks192.168.1.0/24storage_root_path支持多个路径用分号分隔可以按磁盘类型分介质。这里的capacity单位是字节我演示的是约2TB和1TB。如果多个BE共用同一块物理盘一定要在容量规划时把“多副本落在不同BE”的前提考虑进去否则同盘多BE故障时副本可能同时丢失。FE启动cd /opt/doris/fe bin/start_fe.sh --daemonBE启动cd /opt/doris/be bin/start_be.sh --daemon最后用MySQL客户端把BE注册进集群ALTER SYSTEM ADD BACKEND 192.168.1.101:9050; SHOW BACKENDS;SHOW BACKENDS输出里Alive列如果是true说明BE心跳正常部署成功。这里踩过最典型的坑就是FE和BE的priority_networks配置不一致导致BE显示Dead实际排查网络通了但心跳不来基本都是IP匹配问题。2.3 部署后必调的几个资源相关参数FE和BE跑起来之后有几个参数直接影响资源管理效果我在部署完成后会再检查一遍。FE侧的核心参数在fe.conf参数说明建议值query_portMySQL协议端口客户端连接用默认9030max_connection_scheduler_threads_num连接调度线程数按CPU核数调qe_max_connection最大连接数按并发预估默认1024已够BE侧的核心参数在be.conf参数说明建议值fragment_transmission_compression查询中间结果是否压缩传输推荐true省带宽省网络开销max_tablet_num_per_shard每个shard的tablet数量上限默认100做容量规划时关注min_max_dynamic_partition_num动态分区相关根据业务保留分区数设置另外还有一点如果服务器开了swap建议把swap调低或者直接关掉。Doris这类OLAP系统的查询性能高度依赖内存一旦发生swap慢查询会成倍增加而且排查起来非常隐蔽监控上看内存不高但就是慢最后才发现swap在作祟。这属于部署阶段就要处理掉的隐患。3. 用Doris Manager把资源管理平台化3.1 为什么要引入Doris Manager装好Doris、设好Workload Group那只是单机或小集群视角。等你集群规模上来比如几十个节点、多个业务线共用靠命令行一台台看资源显然不现实。Doris Manager在这时候就派上用场了。Doris Manager是Doris生态里的一个运维管理平台可以理解成Doris集群的“总控台”。它主要解决三个问题一是集群可视化FE、BE在页面上一目了然二是节点资源监控CPU、内存、磁盘、IO的使用率都有曲线三是集群变更比如BE扩容、FE节点添加不用再手动敲SQL往集群里加节点。用上Manager之后资源管理从“遇到问题开终端去查”变成了“打开页面看趋势提前预判”。3.2 Doris Manager的部署与接入流程Doris Manager本身也是一个服务部署方式比较友好。下载Manager安装包后解压配置好数据库存储一般用MySQL保存Manager的元数据然后启动Manager服务浏览器访问管理页面。首次使用需要添加需要管理的Doris集群。在页面上填写集群名、FE IP、MySQL协议端口、FE HTTP端口、管理员账号密码等信息Manager会自动探测并采集集群信息。完成后就能看到集群的节点列表、角色、状态、版本信息。我个人比较推荐的路径是这样的先部署Doris集群本身确认FE和BE状态正常。部署Doris Manager连接到该集群。在Manager页面开启监控数据采集这里会定期抓取Doris的metrics接口。配置告警规则比如BE内存使用率超过85%、磁盘剩余空间低于20%时告警。这里要提醒一句Manager所在机器不要和Doris节点混部否则一旦资源紧张连监控平台本身都卡死就失去意义了。3.3 Manager监控面板上重点看的几个指标有同学用上Manager之后每天就盯着CPU和内存这没错但不够。我建议至少重点看以下几类指标并形成日常巡检的手感。节点资源的指标里BE的CPU使用率、内存使用率、磁盘IO util、磁盘剩余空间是基础四项。查询性能指标里查询成功率、P99延迟、正在运行的查询数、排队查询数更关键。数据导入方面有没有Running状态的导入任务积压、MEMTable内存占用是否长期高位这些需要重点看。集群状态方面Tablet不健康数量、副本缺失数量这两个指标直接反映数据是否在正常自我修复。我自己的习惯是每天早上看一眼Dashboard重点关注P99延迟曲线有没有异常上涨以及BE磁盘剩余容量变化。很多问题在曲线一开始偏离的时候处理成本都很低等到业务反馈卡顿再去看往往已经晚了几个小时。4. 用Terraform把Doris资源管理自动化4.1 为什么想到用Terraform来管Doris资源Terraform是基础设施即代码IaC领域的事实标准很多人第一反应是拿它管理云服务器、VPC、Kubernetes。拿它来管数据库内部的资源比如Workload Group、用户、Catalog听起来有点跨界但实际操作下来非常有价值。举一个实际场景你的团队有测试环境、预发环境、生产环境多个Doris集群每个环境都需要创建相同的Workload Group、相同的用户权限、相同的外部Catalog配置。如果靠人工在每个集群上敲SQL两三套还行十套八套一定会出现配置漂移——测试环境改了参数生产环境忘了改新同事入职走的还是旧流程。把资源定义写成Terraform模板后所有环境的Doris资源都通过同一套代码创建哪里变了、什么时候变的全在Git提交记录里。当然要说明一点Doris官方目前没有像云服务那样成熟的Terraform Provider所以社区常见的做法是通过Terraform的null_resource配合local-exec执行MySQL命令或者调用Doris的HTTP API把这层“适配”自行封装。这种方式虽然不是最优雅但胜在能落地不需要等官方支持。4.2 Terraform管理Doris资源的HCL实例下面这个示例用Terraform创建一个Workload Group并把对应的用户绑定进去。为了执行SQL我这里通过mysql命令行客户端连接FE的query_port。variable fe_host { default 192.168.1.100 } variable fe_port { default 9030 } variable fe_user { default root } variable fe_password { default your_password } resource null_resource create_workload_group { provisioner local-exec { command EOT mysql -h${var.fe_host} -P${var.fe_port} -u${var.fe_user} -p${var.fe_password} \ -e CREATE WORKLOAD GROUP IF NOT EXISTS wg_etl PROPERTIES (cpu_share20,memory_limit30%,max_concurrency5,max_queue_size10,queue_timeout3000); EOT } } resource null_resource bind_user_to_group { depends_on [null_resource.create_workload_group] provisioner local-exec { command EOT mysql -h${var.fe_host} -P${var.fe_port} -u${var.fe_user} -p${var.fe_password} \ -e SET PROPERTY FOR etl_user workload_group wg_etl; EOT } }执行顺序上先跑terraform plan看变更再跑terraform apply执行创建。depends_on保证了先创建Group再绑定用户避免顺序错乱。这套模板可以随环境用变量覆盖测试环境传入测试FE的IP生产环境传入生产FE的IP其他逻辑完全复用。4.3 使用Terraform管理Doris的注意事项实际用下来有几个坑需要注意。第一个是幂等性。MySQL的CREATE WORKLOAD GROUP IF NOT EXISTS能保证重复执行不会报错但如果你改了参数再applylocal-exec不会自动识别“参数变化”它只会再次执行命令。所以对于需要更新的资源你要显式管理“应用更新命令”的逻辑比如Terraform resource里放CREATE OR REPLACE风格的SQL。第二个是并发安全。多个人同时跑terraform apply到同一个集群可能会有冲突。团队小还好团队大一定要约定“变更窗口”或者在CI/CD里加锁。第三个是密码安全。示例里密码直接写在变量里实际生产建议用terraform的变量文件配合密钥管理服务避免把密码提交到Git。配置里也可以考虑用环境变量注入不让敏感信息落地。5. CCR Syncer与跨集群数据同步的资源管理5.1 CCR能解决什么问题Doris的CCRCross Cluster Replication是跨集群数据复制能力核心组件叫ccr-syncer。它解决的问题很明确当你有两个Doris集群希望主集群的数据变更实时同步到从集群时不需要业务在上游和下游同时写入只需要把主集群的库表增量变更持续拉到从集群。最典型的使用场景是主从容灾和读写分离。主集群负责日常线上读写从集群作为灾备主集群出问题时切到从集群。或者主集群写、从集群读分散查询压力。这种场景用CCR比手动导数据高效得多它跟踪的是数据变更日志级别的同步不是简单的周期性全量复制。5.2 ccr-syncer部署与同步任务创建ccr-syncer是独立于FE、BE之外的服务部署相对简单。下载对应的ccr-syncer安装包后需要编辑一份配置文件里面声明源端集群和目标端集群的连接信息。核心配置项大体如下host 0.0.0.0 port 9170 source_cluster { host 192.168.1.100 port 9030 user root password source_password } target_cluster { host 192.168.1.200 port 9030 user root password target_password }启动ccr-syncer./ccr-syncer -c syncer.conf然后可以通过HTTP接口或管理命令创建同步任务把指定库表从源集群同步到目标集群。创建同步任务时系统会先在目标集群建好相同表结构然后开始全量数据同步完成后进入增量阶段实时跟踪变更。这个过程中需要关注的是同步任务对集群资源的占用。全量同步阶段会在源集群和目标集群都产生较大的CPU和IO开销特别是源端要扫描数据、目标端要写入数据建议在全量同步期间避开业务高峰。增量同步阶段的资源占用相对稳定但持续存在如果同步的表很多、变更很频繁ccr-syncer所在节点以及目标集群的BE都会吃到不少压力需要给这部分预留出资源余量。5.3 我建议的同步资源管理策略我自己在跨机房场景里通常这样控制同步对生产的影响把同步任务拆小不要把几百张表塞进一个同步任务而是按业务域拆成多个任务这样某个任务异常不会拖垮所有同步。然后给目标集群的导入并发设置Workload Group限流比如同步导入单独用一个Group限制它的内存和并发避免同步流量和线上报表查询互相抢资源。再配合Doris Manager的监控重点看目标集群BE在增量同步时段的IO util和内存曲线如果持续高位就要加大同步间隔或限制同步任务的并行度。CCR能帮你实现容灾架构但它本身是“吃资源”的提前规划别等同步任务把集群拖慢了才反应。6. Doris与StarRocks的差异与选型建议6.1 为什么这两个经常被拿来做对比Doris和StarRocks的名字经常被放到一起讨论想绕都绕不开。两者渊源很深StarRocks是从Doris早期版本分叉出去、再独立演进的项目所以很多基础设计有相似之处比如MPP架构、列式存储、MySQL协议兼容、支持丰富的数据导入方式。但分叉之后各自发展路线明显不同尤其在资源管理、存算分离、生态工具上的差异越来越大。我遇到不少团队在技术选型时都在这两者之间纠结。与其听厂商怎么说不如看自己在资源管理、数据规模、运维体系上的真实需求。这里不评价谁好谁坏只把我实际观察到的差异列出来。6.2 核心能力对比表下面这个表是我做大致对比时常用的维度适合先建立整体认知对比维度DorisStarRocks项目归属Apache基金会Linux基金会资源管理Workload Group、资源标签、查询队列Pipeline资源组、查询队列、资源隔离存储模型Aggregate、Unique、Duplicate明细表、聚合表、更新表、主键表主键更新Unique Key模型支持MOWPrimary Key模型upsert能力强导入方式Stream Load、Broker Load、Routine Load等大体类似也支持Spark/Flink写数据湖分析支持Hive/Iceberg/Paimon等Catalog支持Hive/Iceberg/Paimon等Catalog运维工具Doris Manager、CCR SyncerStarRocks Manager、工具链逐步完善社区活跃Apache社区版本迭代节奏稳国内商业化力度大功能落地快单看资源管理这条Doris在Workload Group普及之后查询隔离能力已经比较成熟适合大规模多业务共用集群的场景StarRocks在主键模型和实时更新场景上有自己的优势如果业务重点是高并发point update/upsertStarRocks的主键表方案是更直给的选择。6.3 我自己的选型观点在给团队做选型建议时我通常会抛三个问题第一你的数据模型是明细查询为主还是高频更新为主第二你的集群是多业务共用还是独立集群第三你的运维团队更看重社区活跃度还是更看重厂商商业支持如果业务以离线批量分析、明细查询、大宽表Join为主Doris是完全合适的尤其是已经在用Doris生态工具、也愿意接受Apache社区节奏的团队。如果核心场景是实时更新、需要强主键约束和点查更新StarRocks主键表的吸引力会更大。还有一点容易被忽略现有团队的技能栈。两个数据库的SQL语法都很接近但工具链、监控指标、调优手段有差别换一套核心数据库的学习成本不能小看。我见过不止一个项目因为临时性能问题就觉得“换一个数据库就好了”结果迁移成本远大于配置调优的成本。先把当前集群的资源管理做好再谈切换这个顺序不能颠倒。7. 常见问题与排查技巧实录7.1 Doris Duplicate模型是否支持条件删除这是社区里经常有人问的问题结合Doris的使用场景我说一下自己的理解。Duplicate模型是Doris的明细模型它的特点是数据按导入追加存储不去重、不维护主键约束。因为它没有主键你执行DELETE时不能用“按主键精准定位”的方式去擦除某一行Doris实际执行的是带条件的“标记删除”也就是把符合条件的数据打上删除标记查询时过滤掉后台再由Compaction机制清理。所以严格来说Duplicate模型不是“完全不能”做条件删除比如你可以写DELETE FROM table WHERE xxx一次把小范围数据删掉。但它不适合作为频繁、细粒度条件删除的载体。每次删除都会产生版本大量小版本会显著增加Compaction压力最终表现为查询变慢、磁盘IO升高、BE内存吃紧。如果业务需要频繁按条件更新或删除应该优先设计Unique模型的主键表使用Merge-On-Write方式删除语义会正常很多。我在实际项目中的判断标准很简单删除是否是高频核心路径如果是就不要用Duplicate如果只是偶尔清理数据用DELETE也不会有大问题。7.2 资源耗尽类问题速查表下面这些是我在Doris运维里遇到过的几个典型资源问题整理成一个快速排查索引方便大家对照处理。现象可能原因排查命令/日志处理建议查询全部卡住CPU打满大查询没有Workload Group限制SHOW PROC /statistic看活跃查询建Workload Group绑定用户BE内存持续高位进程被杀查询并发过高或MemTable积压查看BE日志中memory limit exceeded调低Workload Group内存限制导入并发磁盘空间告急副本多、数据增长快或Doris的trash没清SHOW BACKENDS看DiskCapacity关或调小trash清理过期分区节点间网络打满查询shuffle数据量过大BE日志、Manager网络曲线开启压缩传输优化SQL减少shuffle导入任务堆积导入频率过高或BE写入能力不足SHOW LOAD;SHOW ROUTINE LOAD;限制导入并发给导入单独建Group连接数满应用连接池配置过大FE日志中报连接超限检查qe_max_connection优化连接池有一条排查建议想特别强调遇到资源问题先看监控曲线确认是“突然发生”还是“渐进升高”这两种情况排查方向完全不同。突然发生大概率跟某条SQL或某个导入任务有关渐进升高则普遍是容量规划问题。7.3 我踩过几次坑之后总结出的几条经验把“资源管理”落实到位靠的不是某一个参数而是一套组合动作。我自己是把这几条当铁律执行第一Workload Group一定要按业务线分开至少把ETL和在线查询分开。哪怕现在业务量小也先建好因为“先隔离再放宽”很容易“全混在一起再拆”相当痛苦。第二所有新集群部署时就把监控接入Doris Manager不要等到出问题才补。监控数据是历史证据没有历史数据出了问题只能靠猜。第三线上账号的权限要收敛不要让所有人都能用root执行任意查询。权限管控某种意义上比Workload Group更前置禁止了“坏人进门”资源管理压力能少一半。第四容量规划不是一次性工作。数据量大的时候每季度至少要重算一次磁盘、内存、CPU的余量不要等到满负荷再临时扩节点。第五Terraform这类自动化手段尽早引入。手敲命令一时爽配置漂移火葬场资源定义版本化带来的收益时间越长越明显。我个人在实际操作中的体会是Doris资源管理这件事七分靠设计三分靠工具。Workload Group、Doris Manager、Terraform都是工具真正的设计在于你清楚每个业务需要多少资源、能容忍什么延迟、相互之间能承担多大的干扰。把这些想清楚再配合工具去落地整个集群的稳定性会提升一个档次。最后再分享一个小技巧每次调整完资源参数记得在Manager里截图留存等出问题时翻一翻很多疑难杂症的线索都在历史的参数变更里。