企业官网建设流程全解析

先说我自己的经历。上个月线上一个实时报表集群，白天高峰期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：查询在队列里等待的最长毫秒数，超时就报错。

创建完之后，把指定用户绑定到这个Group：

SET 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÷4=75GB。这还只是数据本身，临时文件、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_networks=192.168.1.0/24 sys_log_level=INFO

priority_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_networks=192.168.1.0/24

storage_root_path支持多个路径，用分号分隔，可以按磁盘类型分介质。这里的capacity单位是字节，我演示的是约2TB和1TB。如果多个BE共用同一块物理盘，一定要在容量规划时把“多副本落在不同BE”的前提考虑进去，否则同盘多BE，故障时副本可能同时丢失。

FE启动：

cd /opt/doris/fe bin/start_fe.sh --daemon

BE启动：

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：

BE侧的核心参数在be.conf：

另外还有一点，如果服务器开了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会自动探测并采集集群信息。完成后就能看到集群的节点列表、角色、状态、版本信息。

我个人比较推荐的路径是这样的：

1. 先部署Doris集群本身，确认FE和BE状态正常。
2. 部署Doris Manager，连接到该集群。
3. 在Manager页面开启监控数据采集，这里会定期抓取Doris的metrics接口。
4. 配置告警规则，比如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_share'='20','memory_limit'='30%','max_concurrency'='5','max_queue_size'='10','queue_timeout'='3000');" 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能保证重复执行不会报错，但如果你改了参数再apply，local-exec不会自动识别“参数变化”，它只会再次执行命令。所以对于需要更新的资源，你要显式管理“应用更新命令”的逻辑，比如Terraform resource里放CREATE OR REPLACE风格的SQL。

第二个是并发安全。多个人同时跑terraform apply到同一个集群，可能会有冲突。团队小还好，团队大一定要约定“变更窗口”，或者在CI/CD里加锁。

第三个是密码安全。示例里密码直接写在变量里，实际生产建议用terraform的变量文件配合密钥管理服务，避免把密码提交到Git。配置里也可以考虑用环境变量注入，不让敏感信息落地。

5. CCR Syncer与跨集群数据同步的资源管理

5.1 CCR能解决什么问题

Doris的CCR（Cross 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 核心能力对比表

下面这个表是我做大致对比时常用的维度，适合先建立整体认知：

单看资源管理这条，Doris在Workload Group普及之后，查询隔离能力已经比较成熟，适合大规模多业务共用集群的场景；StarRocks在主键模型和实时更新场景上有自己的优势，如果业务重点是高并发point update/upsert，StarRocks的主键表方案是更直给的选择。

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运维里遇到过的几个典型资源问题，整理成一个快速排查索引，方便大家对照处理。

有一条排查建议想特别强调：遇到资源问题，先看监控曲线确认是“突然发生”还是“渐进升高”，这两种情况排查方向完全不同。突然发生大概率跟某条SQL或某个导入任务有关，渐进升高则普遍是容量规划问题。

7.3 我踩过几次坑之后总结出的几条经验

把“资源管理”落实到位，靠的不是某一个参数，而是一套组合动作。我自己是把这几条当铁律执行：

第一，Workload Group一定要按业务线分开，至少把ETL和在线查询分开。哪怕现在业务量小，也先建好，因为“先隔离再放宽”很容易，“全混在一起再拆”相当痛苦。

第二，所有新集群部署时就把监控接入Doris Manager，不要等到出问题才补。监控数据是历史证据，没有历史数据，出了问题只能靠猜。

第三，线上账号的权限要收敛，不要让所有人都能用root执行任意查询。权限管控某种意义上比Workload Group更前置，禁止了“坏人进门”，资源管理压力能少一半。

第四，容量规划不是一次性工作。数据量大的时候，每季度至少要重算一次磁盘、内存、CPU的余量，不要等到满负荷再临时扩节点。

第五，Terraform这类自动化手段尽早引入。手敲命令一时爽，配置漂移火葬场，资源定义版本化带来的收益，时间越长越明显。

我个人在实际操作中的体会是，Doris资源管理这件事，七分靠设计三分靠工具。Workload Group、Doris Manager、Terraform都是工具，真正的设计在于你清楚每个业务需要多少资源、能容忍什么延迟、相互之间能承担多大的干扰。把这些想清楚，再配合工具去落地，整个集群的稳定性会提升一个档次。最后再分享一个小技巧：每次调整完资源参数，记得在Manager里截图留存，等出问题时翻一翻，很多疑难杂症的线索都在历史的参数变更里。