AI时代,企业级存储的协议互通为什么成了必选项?
这是一条不容忽视的行业信号
2026年4月,亚马逊云科技做了一件值得企业存储从业者高度关注的事——推出S3 Files,让S3对象存储桶能够以文件系统形式直接访问。
这不是简单增加一个接口。AWS表示,S3 Files是“一个为数据提供全功能、高性能文件系统访问的云对象存储”。用户可以通过文件系统和S3 API两种方式同时访问同一份数据,数据无需离开S3。AWS声称,相比在S3和独立文件系统之间往复搬运数据,S3 Files可降低90%的成本。
更值得注意的是,这不是AWS的孤例。2026年5月,HPE在北京发布新一代企业级文件和对象存储HPE Alletra Storage MP X10000,核心卖点正是“文件与对象原生双协议”。新华三也在2026领航者峰会上展示了AI原生存储产品,支持块、文件、对象和HDFS多协议互通。
全球头部厂商在同一时间节点集中押注同一方向——这背后一定有其必然性。
为什么协议不通,成了AI时代的大问题?
过去,文件存储和对象存储各司其职,边界清晰。文件存储服务传统应用,对象存储承担海量归档,两者井水不犯河水。
现在情况变了。
AI工作流从数据采集、标注、预处理、训练到推理,很少只运行在一种协议环境中。采集系统可能使用对象存储,标注团队可能通过SMB访问共享目录,训练任务可能运行在Linux或K8S环境并使用NFS,数据湖和平台工具又依赖S3。
每一次协议不互通,都可能变成一次数据复制。
数据复制带来的问题远不止容量浪费:
1. 版本不一致:训练那边跑完了才发现用的是三天前的旧数据;
2. 权限难继承:复制后的数据丢失了原有的访问控制策略;
3. 数据更新不同步:多份副本各自演化,无从追溯;
4. 人工搬运不可追溯:数据流转路径失控,合规风险上升。
算法团队看到的是数据准备慢,平台团队看到的是流程集成复杂,IT团队看到的是多套存储资源池难以统一管理。
为什么互通并不容易?
要理解协议互通的难度,首先要理解文件和对象存储组织数据的方式完全不同。
文件存储像一座带目录树的图书馆。数据按照目录、子目录和文件的层级组织,应用习惯使用路径查找,并执行重命名、追加写入和局部修改。
对象存储更像一个带唯一门牌号的集装箱码头。每个对象只有一个对应的Key(名称),适合海量堆叠和批量读写,但并不天然具备完整的目录结构和文件操作能力。
从文件存储增加对象接口相对容易——因为文件路径可以直接映射成对象名称。反过来,在扁平的对象命名空间之上补齐目录层级、重命名、随机修改等文件语义,代价要高得多。
两者都叫“协议互通”,但实现逻辑和技术难度完全不在一个层面上。
三类技术路线,各有取舍
目前业界在“以对象为底座、补齐文件能力”的方向上,探索出了三类技术路线:
路线一:在对象之上“长”出一层文件结构。 以AWS S3 Files为代表,在对象底座上增加文件式分层结构,对外呈现接近文件系统的使用方式。但问题在于:文件语义并非原生,一致性维护复杂。例如目录重命名需要更新所有相关对象的Key,文件随机写容易退化为整对象读改写。AWS的解决方式是:如果出现文件系统和对象接口同时修改同一份数据的冲突,以S3为事实源(Source of Truth)。
路线二:在访问层增加文件协议网关。 以开源Ceph类方案为代表,将文件访问请求翻译为对象操作。这类方案改造较轻,但网关无法补齐底层缺失的文件语义——随机访问、目录重命名等核心能力可能无法完整实现。
路线三:重构对象底座本身。 以Directory Bucket(目录桶)类思路为代表,直接调整对象存储的底层组织方式,使其从底层支持更多文件操作。但这种方案也可能需要对部分传统对象功能(如多版本、对象级标签等)作出取舍。
三类方案没有绝对的优劣,关键在于企业的工作流对文件语义的依赖程度有多深。
协议互通的真正目标:减少数据副本,而非增加接口数量
协议互通的最终价值,不是让产品规格表上多一个“支持S3”或“支持NFS”的勾选项。它的真正目标是:让同一份数据能够被不同工具链自然消费,减少因协议不同而产生的数据复制。
这意味着企业评估存储的协议互通能力时,不能只看“是否同时支持两种协议”,还要继续追问:
- 两种接口访问的是不是同一份物理数据?
- 目录重命名、局部修改和并发访问如何实现?
- 跨协议读写是否保持一致?
- 哪些功能会受到限制?
让数据从“系统间搬运”转向“底座内协同”
基于对上述技术路线的深入评估,我们的AI统一存储选择了更适配企业级AI场景的解法。
核心思路是:通过调整底层索引、统一资产身份ID、建立跨协议一致性规则,让同一份物理数据同时支持文件和对象协议直接读写。
具体来说,我们通过NFS、SMB、S3等标准协议,以及协议互通、目录桶和异构纳管能力,把不同业务环节的数据访问统一到同一数据底座中。对客户而言,这意味着数据不必因为协议不同而反复复制,也不必因为平台不同而形成多个不可治理的副本。
目录桶能力进一步融合了文件系统层级目录结构与对象存储扁平架构,使对象访问和目录语义能够在同一命名空间中结合。训练平台可以按目录组织样本,数据湖工具可以通过对象接口访问,标注团队可以沿用目录习惯,IT团队可以在统一视图下管理生命周期。
标准协议路线(NFS、SMB、S3)的价值在于兼顾易用性和性能。客户既可以保留原有访问习惯,也可以在训练热路径上通过RDMA、GDS、S3 over RDMA等加速能力获得更强数据供给。
AI工具链变化很快。训练框架、标注平台、数据处理平台、知识库平台和业务系统可能来自不同厂商。如果存储强依赖私有客户端,短期可能获得某些集成优势,但长期会增加适配和运维风险。
协议互通不是“多支持一种接口”的功能堆叠,而是让数据从“系统间搬运”转向“底座内协同”。当同一份数据能够被标注、清洗、训练、数据湖、知识检索和归档全流程自然消费时,AI项目的整体效率才会有质的提升。
企业评估多协议AI存储时,应关注真实流程:哪些团队产生数据,哪些平台消费数据,哪些阶段发生复制,哪些系统需要保留,哪些数据需要进入高性能层。我们的价值,正是在这些跨协议、跨系统、跨阶段的数据流动中体现。

