Doris BE存储路径迁移实战：从机械盘到SSD的性能优化指南

Doris BE存储路径迁移实战：从机械盘到SSD的性能优化指南

最近在帮几个团队做Doris集群的性能调优，发现一个挺普遍的现象：很多早期部署的集群，BE（Backend）节点数据盘还停留在机械硬盘（HDD）上。当数据量增长到TB级别，或者查询并发上来之后，IO瓶颈就变得异常明显。一个原本几秒就能返回的聚合查询，在HDD上可能要等上半分钟，业务方抱怨连连。这时候，把数据迁移到固态硬盘（SSD）就成了一个立竿见影的优化手段。但“迁移”二字说起来简单，做起来却涉及数据安全、业务连续性和性能验证等一系列问题。这篇文章，我就结合几次实战经验，聊聊如何安全、平滑地将Doris BE的存储路径从机械盘迁移到SSD，并最大化地释放硬件升级带来的性能红利。无论你是正在规划硬件升级的运维工程师，还是对Doris底层存储性能感兴趣的技术负责人，希望这些踩过的坑和总结的方法能给你带来一些实实在在的参考。

1. 性能瓶颈诊断与迁移必要性评估

在动手迁移之前，我们得先搞清楚一件事：当前的性能瓶颈到底是不是由磁盘IO引起的？盲目升级硬件可能花了钱却见不到效果。Doris作为一个MPP架构的OLAP数据库，其BE节点承担了数据存储和计算的双重任务。查询性能的链条很长，涉及网络、内存、CPU和磁盘IO等多个环节。

如何定位磁盘IO瓶颈？

一个最直接的信号是，在Doris的FE（Frontend）查询管理页面或通过SHOW PROC '/backends'命令查看BE状态时，发现某些BE节点的LastStreamLoadTime或查询响应时间显著高于其他节点，同时该节点的磁盘使用率（尤其是iowait）持续居高不下。这时，我们可以通过操作系统层面的工具进行更细致的观察。

# 使用 iostat 命令观察磁盘的读写吞吐量和延迟
iostat -x 1
# 重点关注以下指标：
# - %util：设备利用率，接近100%表示磁盘满负荷。
# - await：平均每次I/O操作的等待时间（毫秒）。HDD通常在5-15ms，若持续高于20ms甚至上百ms，则压力巨大。
# - r/s, w/s：每秒读写请求数。
# - rkB/s, wkB/s：每秒读写数据量（KB）。

除了实时监控，回顾历史慢查询日志也很有帮助。如果大量慢查询都伴随着高额的ScanBytes和ScanRows，且执行计划中显示OlapScanNode耗时占比极高，那么磁盘读取速度很可能就是罪魁祸首。

HDD与SSD的性能鸿沟

为了让大家对迁移前后的性能差异有个直观概念，我整理了一个简单的对比表格。数据来源于对同一套测试数据集（约1TB）在不同磁盘类型上执行典型OLAP查询的基准测试结果。