数据量翻倍了加两台BE就行？——Doris集群扩缩容和数据均衡
先说结论
Doris扩缩容对应两种场景：加BE和减BE。扩容操作本身简单（一条命令注册新BE），关键是扩容后的数据均衡策略——什么时候触发、怎么控制速度、均衡期间怎么保证查询性能。缩容比扩容危险得多——必须先迁移数据再下线节点。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
在某元宇宙社交公司运营实时数仓一年后，数据量从几百GB涨到2TB+，3个BE节点的磁盘告警了。Doris的扩容操作很简单——启动新BE然后注册到集群里。但扩容后旧数据不会自动迁移到新BE上，需要触发数据均衡（Balance），而且均衡过程会影响线上查询。面试官问扩容，考的就是这些细节。
扩容BE的操作步骤
数据均衡（Balance）——扩容后的关键步骤
扩容的最佳实践
| 场景 | 建议 | 原因 |
|---|---|---|
| 磁盘告警（大于80%） | 尽快扩容，同时清理过期数据 | 磁盘满了BE会宕机 |
| 查询变慢 | 加BE提高并行度 | 更多BE = 更多并行计算节点 |
| 数据量翻倍 | BE数按数据增长比例扩 | 保持单BE数据量稳定 |
| 低峰期扩容 | 选晚上或周末操作 | Balance会占用IO影响查询 |
| 扩容后验证 | SHOW BACKENDS + 测试查询 | 确认数据均衡+查询正常 |
缩容BE的操作和注意事项
实战踩坑：扩容过程中的Balance风暴
在某元宇宙社交公司扩容时，我一次性加了2台BE（从3台扩到5台）。加完后Doris的自动Balance开始工作，同时迁移大量Tablet。结果Balance占用了大量磁盘IO和网络带宽，实时大盘查询延迟从800ms飙到5秒以上。
应急处理：降低Balance并行度——把max_scheduling_tablets从默认的10调到2。
优化方案：扩容在低峰期操作（凌晨），Balance速度调低让它慢慢迁移。白天高峰期暂停Balance，晚上恢复。整个均衡分3天完成，对线上查询几乎没有影响。
FE的扩缩容
面试高频追问
追问一：扩容后新数据会自动分到新BE吗？
会。新的数据导入会自动把新Tablet分配到包括新BE在内的所有节点上。但已有旧Tablet不会自动迁移，需要Balance过程。
追问二：Doris支持弹性扩缩容吗？
理论上支持但实际代价太高——每次缩容都要DECOMMISSION迁移数据。需要弹性考虑云厂商托管服务，支持算存分离和弹性扩缩。
追问三：Doris 2.0+的存算分离对扩缩容有什么影响？
存算分离后BE变成纯计算节点，数据存在对象存储。扩缩容只需加减计算节点，不需要迁移数据，秒级扩容。但目前生产环境大部分还是存算一体模式。
总结
Doris扩缩容面试讲三点：① 扩容操作（启动新BE、注册、Balance数据均衡）；② Balance策略（自动触发、控制速度、低峰期操作）；③ 缩容安全（必须先DECOMMISSION再DROP，绝不能直接DROP）。能讲出Balance风暴的处理经验，面试官会认可你的运维经验。