弹性扩展不求人：Doris 分布式架构与水平扩展方式全解析

从 3 节点到 300 节点，揭秘 Doris 在线扩缩容背后的技术密码

前言：当数据增长成为常态

做大数据的人都有一个共识：数据量只会越来越大，永远不会变小。

今天你的 Doris 集群可能有 10TB 数据，运行得风生水起；明天业务一爆发，数据量翻倍，节点就开始告警了。这时候你最需要的是什么？不关机、不停服、业务无感知地加机器——这就是水平扩展的魅力。

Doris 从设计之初就秉承 “Shared-Nothing” 的分布式架构理念，将水平扩展作为核心能力。今天，我们从架构原理到实操命令，再到最佳实践，完整拆解 Doris 的水平扩展机制。

一、架构全景：FE + BE，各司其职

要理解 Doris 如何扩展，首先要搞清楚它的核心组件。

架构图：Doris 分布式架构

1.1 FE（Frontend）：集群的"大脑"

FE 负责元数据管理、SQL 解析、查询计划生成和调度。FE 节点有三种角色：

关键规则：Master + Follower 的总数必须是奇数（如 1+2=3），这样才能通过 Paxos 协议保证元数据一致性。

1.2 BE（Backend）：集群的"肌肉"

BE 负责数据存储和查询执行。数据以Tablet为单位分布在各 BE 上，每个 Tablet 有多个副本保证高可用。扩容 BE 时，系统会自动进行负载均衡，将部分 Tablet 迁移到新节点上。

二、扩展方式全景图

Doris 支持两种扩展维度，以及两种扩缩容路径。

流程图：Doris 扩展决策树

三、FE 扩展：提升查询并发能力

3.1 什么时候需要扩展 FE？

• FE 节点的 CPU 使用率持续偏高
• 查询响应变慢，尤其是大量小查询
• 需要提高 FE 层的高可用性（从单节点扩展到 3 节点）

3.2 扩展 Follower（推荐生产环境）

Step 1：启动新 FE 节点

# 在新机器上，以 helper 模式启动./bin/start_fe.sh--helper<leader_fe_host>:<edit_log_port>--daemon

edit_log_port默认是 9010。

Step 2：注册为 Follower

-- 在 MySQL 客户端执行ALTERSYSTEMADDFOLLOWER"<new_fe_host>:<edit_log_port>";

Step 3：验证加入成功

SHOWPROC'/frontends';

3.3 扩展 Observer（纯读扩展）

Observer 不参与选主，只从 Master 同步元数据，适合纯读场景的水平扩展。

ALTERSYSTEMADDOBSERVER"<observer_host>:<edit_log_port>";

实践建议：

• 一般场景下，3 个 FE（1 Master + 2 Follower）即可满足大多数业务需求
• 如果查询并发极高（如 QPS > 50000），可增加 Observer 节点分担读压力
• FE 节点数量不宜过多（建议 ≤ 5），因为元数据同步会有网络开销

四、BE 扩展：提升存储和计算能力

4.1 扩容 BE：在线添加节点

这是最常用的扩展操作，业务无感知，不中断服务。

Step 1：启动 BE 进程

./bin/start_be.sh--daemon

Step 2：注册 BE 节点

ALTERSYSTEMADDBACKEND"<be_host>:<be_heartbeat_service_port>";

心跳端口默认是 9050。

Step 3：观察数据均衡

添加完成后，Doris 会自动开始数据均衡。可以通过以下命令查看进度：

SHOWPROC'/backends';

关注TabletNum字段，它会随着数据迁移逐渐增加。

4.2 数据自动均衡机制

扩容 BE 后，Doris 的负载均衡器会做两件事：

1. 识别负载不均：检测各 BE 的 Tablet 数量差异
2. 自动迁移 Tablet：将部分 Tablet 从高负载节点迁移到新节点

均衡时间估算：

• 每迁移 1TB 数据大约需要 1-2 小时
• 整个集群均衡完成可能需要数小时到 1 天

调整迁移速度：

-- 调整迁移并发度（默认 5）ADMINSETFRONTEND CONFIG("balance_slot_num_per_path"="10");

五、BE 缩容：安全下线节点

缩容比扩容更需要谨慎，因为涉及数据搬迁。

5.1 DECOMMISSION 方式（强烈推荐）

安全下线，数据先迁移，完成后自动删除节点。

ALTERSYSTEM DECOMMISSION BACKEND"<be_host>:<be_heartbeat_service_port>";

特点：

• 异步操作，数据会逐步迁移到其他 BE
• 迁移完成后节点自动下线
• 不会丢失数据

监控进度：

-- 查看该 BE 的 TabletNum 是否在减少SHOWPROC'/backends';

取消下线（如果需要）：

CANCEL DECOMMISSION BACKEND"<be_host>:<be_heartbeat_service_port>";

5.2 DROP 方式（不推荐生产使用）

ALTERSYSTEMDROPBACKEND"<be_host>:<be_heartbeat_service_port>";

⚠️ 警告：DROP 会直接删除节点，其上的数据将无法恢复！ 除非你确定该节点上没有数据，否则不要在生产环境使用。

5.3 两种方式对比

六、扩展最佳实践

6.1 容量规划黄金法则

6.2 扩展时机建议

扩容信号：

• BE 磁盘使用率 > 80%
• BE CPU 平均使用率 > 70%
• 查询延迟比正常高 50% 以上

缩容信号：

• 集群长期利用率 < 30%
• 业务调整，数据量大幅减少

6.3 注意事项清单

• FE 节点数保持奇数：Master + Follower 总数必须为奇数，否则选主会出问题
• 扩容 BE 选业务低峰期：数据迁移会占用 IO 和网络带宽
• DECOMMISSION 前检查容量：确保剩余 BE 有足够空间容纳迁移的数据
• 监控迁移进度：使用SHOW PROC '/backends'观察 TabletNum 变化
• 缩容后清理节点：手动删除已下线 BE 的数据目录

七、监控命令速查

总结

Doris 的水平扩展能力，是其作为一款企业级 MPP 数据库的核心竞争力之一。

核心要点回顾：

1. 架构分层：FE 管元数据，BE 管数据，各司其职，独立扩展
2. FE 扩展：加 Follower 保证高可用，加 Observer 提升读并发
3. BE 扩展：在线添加节点，数据自动均衡，业务无感知
4. 安全缩容：用 DECOMMISSION 而非 DROP，先迁移后下线
5. 黄金配置：3 FE + N BE（N ≥ 3），奇数个 FE 是铁律

一句话口诀：

• FE 要奇数，Follower 保 HA，Observer 扩读能力
• BE 在线加，数据自动搬，缩容用 DECOMMISSION

记住：Doris 的扩展不是"能不能"，而是"什么时候需要"。掌握了这套方法论，你的 Doris 集群可以从 3 台机器一路扩展到 300 台，从容应对任何数据增长挑战！