AI存储底座为什么是HDD？从容量成本到工程实践

最近在给某跨平台系统的存储底座做容量评估，规划报表里那一串数字从TB一路涨到PB，最后不得不按EB量级去预留扩展空间。这种体验放在几年前很难想象，但AI存储进入PB/EB时代之后，一个很有意思的现象出现了：真正扛起海量数据存储的，不是天天被热议的SSD，反而是一度被认为“夕阳产业”的HDD。

做存储这行的人都清楚，AI工作流里的数据量远比外界想象的夸张。训练样本、推理日志、Checkpoint、数据清洗中间态，再加企业积累的历史业务数据，每一条流水线都在源源不断地产数据。而这些数据里，真正需要毫秒级随机访问的占比其实很小，绝大部分属于写一次、偶尔读、长期保留的状态。这类数据恰好是HDD的主场。

这篇文章我会从数据需求、介质原理、工程落地、运维排障几个层面聊清楚一件事：为什么AI时代存储底座的核心角色是HDD，以及怎么把这些盘用好。

1. AI存储需求拆解：数据从哪来，又该往哪放

1.1 训练数据与企业数据的容量密码

先算一笔账。一个中等规模的模拟项目X，参与训练的样本可能要上亿条，图像切完之后单份原图加增强变体轻松翻五到十倍。假设一条样本平均500KB，一亿条原始数据就是5PB，增强后按五倍算又是25PB。这个量级，还没算测试集、验证集、推理服务的历史请求日志以及用户行为埋点数据。

我的一个习惯是：评估AI存储需求时，不能只看“训练集有多大”，要把整条数据链路的上下游都看清楚。数据采集端会有原始数据落盘，清洗端有中间结果，训练端有Checkpoint和日志，上线之后还有持续增长的线上样本和模型版本管理。这些数据加在一起，往往是训练集体量的三到五倍。如果规划时只盯着核心训练集，后面扩容的频率会让你很崩溃。

这也是为什么PB级别在AI存储里已经稀松平常。很多团队提到存储就默认“全部上全闪存”，但这种思路在PB/EB量级面前，预算和功耗都扛不住。真正合理的思路是数据分层：不同类型的数据，用不同特性的介质去承接。

1.2 热、温、冷分层存储的本质

存储分层不是新概念，但在AI场景里尤其重要。整个AI数据链路天然就分出了热度：

• 热数据：训练在线读取的样本、高频访问的标注集、频繁读写的临时中间结果，这类数据需要高IOPS和高吞吐，SSD或NVMe是主选。
• 温数据：已经清洗完但还会经常回放的数据、近期推理日志、模型历史版本，这类数据访问频率不高，但需要一定的读写性能，大容量HDD非常适合。
• 冷数据：原始数据归档、离线备份、历史业务日志、合规留存数据，写进去后基本只读。这类数据追求极致的单位容量成本，HDD也是唯一合理的选项。

有意思的是，AI数据里温、冷部分通常占总量80%以上。训练样本虽然叫“训练集”，但真实训练过程中同一个样本会被反复读取，这块热度其实集中在训练阶段；训练结束后的全量样本、中间版本、衍生数据，全都滑向温冷段。也就是说，AI存储海量容量的主要构成是温冷数据，这些数据天然适配HDD。

提示：别把“训练需要高性能”等同于“所有AI数据都需要高性能”。数据访问是分时分段的，训练期再热的样本，训完就是归档对象。

1.3 介质选型背后的经济学

数据存储本质上是一门经济学。性能好、容量大的介质不是没有，但价格高；价格低的介质，性能又不够。用一张表能看得很清楚：

这张表揭示了一个核心事实：当容量需求从TB走到PB/EB，成本敏感度会急剧上升。买全闪存堆到PB级别，设备采购成本还能扛，但机房电力、散热、机柜空间会同步爆炸。而HDD在单位容量成本和单位容量功耗两个维度都有明显优势，这才是它成为数据底座的根本原因。

2. HDD凭什么是数据底座：从磁记录到成本账

2.1 主流HDD技术路径：CMR、SMR与HAMR

很多人对HDD的印象还停留在“老技术、慢速、快淘汰”，但实际上近几年的HDD迭代一点都不慢，只是大家都被SSD抢了风头。目前市面上主流的大容量盘，技术路线可以分三类：

• CMR（传统磁记录）：盘片的每条磁道独立写入，性能稳定可控。常见的16TB~20TB企业级盘基本都是CMR，适合作为通用存储底座。
• SMR（叠瓦式磁记录）：磁道像瓦片一样重叠，通过牺牲部分随机写入性能换取更高的面密度，在冷数据归档场景很有优势。但要注意，SMR盘对随机写很不友好，小文件频繁覆盖会触发磁头反复搬移数据，性能惨不忍睹。
• HAMR（热辅助磁记录）：用激光局部加热盘片介质，使磁性颗粒可以在更高的各向异性下稳定记录，是下一代超高密度HDD的关键技术。单盘容量可以做到30TB以上，而且还在持续爬升。

从演进趋势看，大容量HDD并没有“技术停滞”，只是技术重点从“更快”转向“更大、更省”。AI存储要的是容量底座，这个赛道正好就是HDD的主场。

2.2 每TB成本的量化逻辑

我常用一个很朴素的指标做介质选型：每TB裸容量成本。当前市场上，消费级NVMe SSD每TB大概在中高价位，企业级更高；而大容量CMR HDD的每TB价格往往只有前者的六分之一甚至更低。如果你规划的未来三年数据增量在10PB以上，这个差距会直接转化为千万级的采购预算差。

但成本账不能只看硬盘价格。同样做成一个存储节点，SSD节点在控制器、CPU、内存、网络和功耗侧的花费更高，机柜密度也受限于发热。HDD节点的单位成本优势是全方位的，这也是云厂商和大型数据中心在存储层普遍采用HDD混闪架构的原因。

2.3 使用寿命与故障率的事实对比

还有一层很多人忽视的因素：真实寿命。SSD颗粒有PE周期，写多了会老化，而且在断电后数据保存期会受影响；HDD的磁记录介质本身没有写次数限制，只要机械结构不坏，数据就能一直稳定保存。

单盘可靠性方面，机械结构带来了一定故障概率，但企业级HDD的MTBF（平均无故障时间）通常做到200万小时以上，年故障率控制在0.5%到1%之间。通过分布式存储的多副本或纠删码机制，单盘故障的影响完全可以被屏蔽。

注意：企业级HDD和消费级HDD在振动容忍度、错误恢复、持续运行设计上是两套标准。做AI存储底座，别省这个钱，消费盘在密集部署场景下故障率会明显偏高。

3. 真实工程实践：把HDD底座搭得又稳又省

3.1 存储架构选型：对象存储与分布式文件系统

既然确定用HDD做底座，下一步是选承载它的系统架构。AI场景里最常用的是两类：

一是对象存储，典型如Ceph的RGW、MinIO这类轻量方案。对象存储天然适合海量非结构化数据，支持S3协议，AI框架和数据处理引擎对接非常顺。我的经验是，训练样本、图像数据、备份归档这类“文件多、目录深、并发大”的场景，对象存储比传统文件系统省心得多。

二是分布式文件系统，典型如CephFS、GlusterFS，或者各种商业并行文件系统。这类适合需要POSIX语义、随机读训练数据、多节点共享挂载的AI训练集群。团队习惯把数据集当文件系统路径用的，建议走这条路线。

从HDD底座的角度看，两者并不冲突。一个常见的架构是：训练集群通过分布式文件系统读热数据集，全量原始数据和归档数据统一进对象存储。对象存储底层用大容量HDD做数据节点，文件系统底层也可以把冷目录分层到HDD节点。关键是，无论哪种架构，HDD数据节点都要按“容量优先、扩展平滑、故障自愈”的原则去设计。

3.2 数据冗余策略：副本与纠删码的取舍

HDD单盘容量大，意味着故障恢复窗口也大。一块18TB的盘写满了，如果系统只有两副本，坏一盘要重灌18TB数据；如果是三副本，同时要补的也是18TB。容量大了，数据重构的压力同样变大。所以冗余策略不能简单沿用小容量时代的拍脑袋配置。

分布式存储里最常用的做法是纠删码（Erasure Coding）。以EC 4+2为例：每4份数据块计算2份校验块，总冗余率只有50%，而三副本的冗余率是200%。同样的物理容量，EC能把可用容量提高一大截。代价是重建和写入时需要额外计算，但对HDD底座的温冷数据来说，这个计算开销完全可接受。

EC参数怎么选，我一般按这个思路来：

• 数据可靠性要求极高、随机读多：用副本，或EC 2+1这种低配比。
• 一般温数据：EC 4+2，兼顾容量利用率和重构速度。
• 冷数据归档：EC 8+3甚至EC 10+2，容量利用率更高，但重建时间更长。

在Ceph里，这些参数都是通过存储池的规则集配置的。实际规划时要预留重建带宽，别把集群为了高利用率而长期顶着90%容量跑，否则任何一盘故障都可能拖垮延迟。

3.3 关键配置参数与运维基线

基于我的实操经验，HDD存储节点的参数配置有几条值得写下来：

• 容量水位线：对象存储或文件系统的使用率控制在70%以下，最高不要超过85%。超过这个线，重平衡和数据重建的速度会肉眼可见地变慢。
• 每节点盘数：一个存储节点搭配8到12块大容量HDD比较合理，密度太高会导致故障域扩大，太低则浪费机柜空间和CPU资源。
• 系统盘与数据盘分离：系统盘用SSD，数据盘全部交给HDD。混在一起会对故障诊断造成不必要干扰。
• 网络规划：HDD顺序读能跑到250MB/s左右，12块盘全速输出就是3GB/s左右，万兆网会成瓶颈。建议数据网络走25GbE起步，不要用千兆做底座。
• 数据校验：开启块校验或文件校验，定时扫描静默数据损坏。HDD虽然不像SSD那样容易掉数据，但坏道和位翻转依然存在，定期巡检是底线。

这些参数看起来平淡，却是大量故障现场总结出来的结果。存储底座出问题往往不是硬盘本身，而是配置水位、网络瓶颈、故障域设计这些“看不见的地方”。

3.4 实操示例：Ceph对象存储的HDD数据池配置

直接给一个我在模拟项目X中验证过的配置思路。假设有3个存储节点，每个节点12块18TB HDD，用于对象存储的温冷数据池。

首先要做的是创建块设备：

# 创建OSD，每块HDD对应一个OSD，建议用整盘方式 ceph-volume lvm create --data /dev/sdb --db /dev/nvme0n1p1 ceph-volume lvm create --data /dev/sdc --db /dev/nvme0n1p1 # 按此规律遍历所有HDD，每个节点都单独执行

为什么要把HDD的WAL/DB放到NVMe上？因为HDD的随机写性能很弱，而Ceph的OSD在写入时需要在WAL和DB上记录元数据。把这些组件移到NVMe上，能显著提升小IO性能，HDD只负责主要数据落盘。这是Ceph部署中一个很基础但很重要的优化。

然后是创建存储池：

# 创建存储池，pg_num先按公式估算，后续再调优 ceph osd pool create ai-cold erasure ceph osd pool set ai-cold erasure_code_profile ec_4_2 ceph osd pool set ai-cold size 4 ceph osd pool set ai-cold min_size 3 # 设置PG数 ceph osd pool set ai-cold pg_num 128 ceph osd pool set ai-cold pgp_num 128

pg_num的初步估算有个经验公式：总OSD数乘100再除以副本数，向上取整到2的幂次。假设36个OSD，EC 4+2相当于两个副本域，按100个PG每OSD算，大概需要3600个PG。但实际部署时小集群不需要这么多，128到512之间可以先跑起来，再根据均衡度调整。

这些配置不是死的，但有一个原则：纠删码池一定要设置min_size，保证冗余度在任何时刻都不会降到极限以下。

4. 数据中心部署与能耗现实

4.1 部署密度和振动控制的现场经验

HDD底座在机房里很怕两样东西：高温和振动。大容量盘的存储密度高，单机柜功耗密度同步上升。3.5英寸企业级HDD工作功耗普遍在8~12W，一个满配12盘位节点就是100多W，整个机柜批量部署后，散热必须提前规划。

振动控制经常被忽略。HDD内部有精密的磁头和盘片定位系统，外部振动会直接导致寻道性能下降。所以存储节点机箱的刚性、硬盘托架的减震设计都很关键，高密度部署场景下还要控制相邻节点的同步共振。

我见过一个现场：某个存储节点机柜风扇共振明显，结果该节点HDD的IO延迟比同机房其他节点高了近一倍。排查了半天，发现就是机柜螺丝松了几分，上紧后性能恢复。硬件部署的细致程度，直接影响存储底座的品质。

4.2 功耗优化和UMA（单位容量功耗）

单位容量功耗这个指标，在SSD对比HDD时经常被忽视。NVMe SSD功率不低，跑满时单盘功耗甚至比HDD高，而且容量越大贵得越离谱。HDD的优势在于：同样做到PB级容量，HDD整体功耗更低，每TB的W数要好看得多。

更进一步，温冷数据存储可以启用HDD的待机或空闲减速机制。大容量HDD在空闲时可以让磁头卸载、电机降速，功耗能降到几W以内。但要注意，频繁启停对HDD寿命不友好，适合那种长时间无人访问的归档存储，不适合经常回放的温数据。

4.3 故障率曲线与运维换盘节奏

HDD故障概率不是一条直线。大量返修统计显示，新盘在首批三个月内会有早期失效高峰；之后进入稳定的低故障期，能连续工作五六年；接近设计寿命末端时，故障率又会快速抬升。这个曲线决定了换盘策略：新盘上线后要密集巡检，中段保持常规监控，后端逐步分批替换，而不是等它一块块坏完。

实际运维中，我会给每批硬盘建立独立的故障台账。同一个批次里如果出现两块盘故障，那就要关注这一批的潜在风险了；如果只是单点故障，大概率是概率事件。这个判断能帮你提前规划备件，而不是被动救火。

5. 常见问题与排查技巧实录

5.1 容量规划与扩容的坑

容量规划最常见的坑是只按当前数据量预留，没算冗余和元数据开销。比如你预计要存5PB数据，选择EC 4+2时，实际物理裸容量至少要在5PB基础上乘以1.5，达到7.5PB以上，再考虑水位线再乘1.25到1.4，实际规划要到9.5PB甚至更多。

扩容时也有坑。分布式存储加节点后，数据不会自动均匀分布，需要触发rebalance。这个过程会消耗大量带宽和CPU，我不建议在业务高峰扩容。一个稳妥的做法是：新节点先加进来，观察两周的稳定性，再手动调整PG分布或让系统慢慢自平衡。

5.2 慢盘问题的识别

HDD节点最常见的性能问题是慢盘。一盘慢，拖的是整个OSD进程，进而影响所有副本或EC分片的数据写入。识别慢盘不能只看平均延迟，要看P99延迟和峰值延迟，持续高于正常盘两倍以上的就要重点关注。

排查动作三步走：先看系统日志有无IO错误和坏道重映射；再用smartctl查SMART属性（Reallocated_Sector_Ct、Current_Pending_Sector是关键指标）；最后做单盘读写测试，确认是物理坏道还是固件问题。多数慢盘在SMART属性上已经露出端倪，只是平时没人去读。

5.3 当SSD缓存命中率失效时

很多存储系统喜欢在HDD底座之上加一层SSD缓存，用来吸收热点读。但AI数据的特点是“阶段热点”：训练期间某些数据集的热度极高，训练结束立刻变冷。如果缓存策略还是按传统LRU，训练切换后缓存里的数据全部失效，命中率骤降，后端HDD的压力会瞬间拉满。

遇到这个问题，我的做法有两个方向：一是缓存预热，在训练启动前把即将用到的数据主动灌进缓存；二是调整缓存回写策略，对AI场景采用“写直通+读缓存”的组合，避免训练数据反复在缓存层刷脏。当然，最底层的逻辑还是文章开头那件事：AI数据99%的体量是温冷数据，别指望SSD缓存能兜住所有访问模式，它的作用是削峰值，不是当主存储。

6. 一些关于HDD底座的个人体会

在AI存储规划这件事上踩过几次坑之后，我越来越确定一个判断：未来的主流数据底座一定是“SSD做性能层、HDD做容量层”的混闪架构，而不是某种介质独霸天下。HDD之所以能成为数据底座，说到底就是四个字：容量便宜。AI时代的数据增长速度远快于存储采购预算的增长速度，只有HDD能在单位成本这个维度上接得住这种爆发。

如果你正在规划AI存储架构，我给的建议是：别被“全闪存”的浪潮带着走，先把你数据里热、温、冷的比例统计清楚，再算一笔每TB成本账。大概率你会发现，真正决定你存储预算上限的，就是那些被你日常忽略的温冷数据，而它们最适合的归宿，就是大容量HDD。

每块HDD在机柜里嗡嗡转的时候，那才是整个系统最可靠、最实在的部分。SSD在前面冲速度，HDD在下面扛容量，各干各的活，这大概就是存储最健康的形态。