【统一存储技术专栏】AI时代，企业级存储的协议互通能力，到底有多重要？

AI时代，企业级存储的协议互通能力，到底有多重要？

在回答这个问题之前，先给大家分享1条重磅消息↓

今年4月，Amazon Web Services(AWS)推出S3 Files——以EFS 作为托管的高性能存储层，在S3对象存储之上提供文件系统视图，使S3存储桶能够以文件系统形式直接访问。

此前，AWS已发布S3 Express One Zone，并引入Directory Bucket（目录桶），目标直指交互式分析、AI训练等高性能负载场景。S3 Files的落地，打破了对象存储与文件存储的协议壁垒，把对象存储进一步推向更通用的文件工作流。

由此可见，当对象存储从海量、低成本的容量层走向更通用的数据底座时，挑战已不再局限于吞吐、时延等基础性能指标，还在于语义和接口能否支撑得起更为复杂的生产工作流。

一、业务工作流日趋复杂，协议互通成为企业级存储必选项

过去，非结构化数据存储面对的工作流相对简单。数据通常在同一类应用体系内流转，单一访问接口就满足需求，文件归文件、对象归对象，两类存储边界清晰可见。

现在，无论是传统业务的持续升级，还是新兴数据与AI平台的快速扩张，最后都会落到同一个架构上——同一份数据要被不同阶段、不同类型、不同协议的应用持续访问。

因此，当数据底座承载日益复杂的业务工作流时，协议互通不再只是兼容性问题，而是决定存储底座能否继续扩大承载边界的先决条件。

传统场景：业务升级难以一步到位，多协议长期共存是常态

在传统行业场景中，协议互通首先是一个工程现实问题。

在内容归档、医疗影像、文档留存等具体场景中，对象存储已经大规模替代文件存储，但应用改造从来不是一次性完成的。企业既希望改造后可以免迁移、就地访问历史数据，又必须面对过渡阶段新老应用并存、不同协议共同访问同一份数据的现实。以医疗PACS为例，云胶片更匹配对象协议，而门诊阅片、临床工作站仍旧依赖文件访问。

新兴场景：AI数据湖放大接口异构问题

在湖仓一体的趋势下，高性能对象存储正演变为最佳数据底座。然而，训练框架、数据预处理、实验管理、推理服务并不使用同一种接口：有的原生支持S3 API，有的依赖POSIX文件接口。

一旦对象存储缺乏高效的文件接口兼容能力，企业只能把同一份数据再存到文件存储里，需要额外承担带宽、同步、一致性和生命周期管理成本。

因此，协议互通的价值在这里得到充分体现——它关系到同一份数据能否真正支撑得起统一的AI生产工作流。

二、业界如何实现协议互通？

从业界实践来看，传统场景的核心诉求通常是以文件为底座，向上提供对象访问接口；新兴场景的核心诉求则是以对象为底座，补齐文件访问能力。两者都叫协议互通，但实现逻辑和技术难度并不在一个层面上。

传统场景：以文件系统为底座，提供对象访问接口

这类需求更多出现在传统业务升级过程中。企业原有的数据、流程和应用体系，建立在文件语义之上。此时引入对象接口，主要是为了让新应用、新平台以对象方式接入同一份数据，底层数据组织无需重做。

因为文件系统的路径结构可以直接作为对象名使用，无需额外设计，所以从文件路径体系映射到对象命名空间是更容易的。反之，要在扁平对象命名空间之上补齐目录层级和文件语义，代价就要高很多。



这一场景下的业界方案相对统一：以文件系统为底座，通过对象网关或协议转换能力，将文件目录导出为对象存储桶。这里解决的是兼容问题，底层语义并没有被改写。



新兴场景：以对象存储为底座，提供文件访问能力

在AI数据湖、湖仓一体、非结构化数据底座等新兴场景中，难点在于对象存储底座并不天然具备文件语义。

企业希望以对象存储为主底座，同时支撑不同工作流对同一份数据的访问。文件存储是分层目录结构，目录、路径、重命名、随机写、追加写都是原生能力。而对象存储是扁平索引，这些能力都需要额外补齐。

正因为“文件转对象”容易，“对象转文件”却更为困难，业界才逐步分化出不同的技术路线。

技术路线一：以 S3 Files 为代表，在对象之上“长”出一层文件结构

这类方案是在对象底座之上增加一层文件式分层结构，让对象底座对外呈现接近文件系统的使用方式。

这种方案也存在一些问题：文件语义并非对象原生能力，许多操作需要额外转换；对象层和文件层并存后，一致性维护变得更复杂；一些文件操作会被明显放大。例如，目录重命名往往意味着更新该目录下所有对象，文件随机写也常常退化为整对象读改写，性能容易受限。



技术路线二：以开源 Ceph 类方案为代表，在对象之上增加文件协议网关

这类方案不深度改造对象底座，而是在访问层增加文件协议网关，将文件访问请求翻译成对象操作。

它的问题在于：网关可以做协议转换，但不能补齐底层缺失的文件语义。因此，这类方案的语义兼容性通常较弱，很多关键能力都无法完整实现，甚至连随机访问、目录重命名这样的核心能力都不具备。

技术路线三：以 Directory Bucket 类思路为代表，重构对象底座本身

这类方案直接重构对象底座，使其从底层开始更接近文件语义，从而满足复杂工作流的要求。

但是，底座一旦向分层结构靠拢，传统对象存储依赖的扁平索引能力就需要重新取舍。为了换取更强的文件语义，或者更适配新兴工作负载的能力，部分对象特性往往难以完整保留。以 AWS S3 Directory Bucket 这类方案为例，通常无法完整支持多版本、对象级标签，以及 ListObjects 字典序返回等传统对象特性。

三、新兴场景最优解：接受对象特性的取舍，重构对象底座本身

在传统场景中，以文件为底座提供对象接口已是一条比较成熟的路径。

但在新兴场景中，以对象为底座补齐文件能力，难点主要在于文件语义与底层结构。

三条技术路线对应三种不同取舍：路线一牺牲性能与一致性，路线二牺牲语义完整性，路线三则需要接受部分对象特性的取舍。

对企业级存储来说，协议互通不是追求一套统一方案，而是针对不同场景给出边界清晰、取舍明确的实现路径。如果建设目标是AI数据湖、湖仓一体等场景，技术路线三通常更为契合。原因很直接：这类场景要求对象底座具备更强的语义能力和更稳定的高性能表现，单纯在对象之上叠加一层文件结构或一个协议网关，难以满足需求。


▲深信服与业界方案在关键语义方面的对比情况

深信服基于技术路线三进行工程化实践，其中有两大关键突破——

重构底层索引

高效兼容文件语义： 引入一套轻量级的目录分级索引，将目录层级关系与叶子对象索引分离存放。得益于此，目录重命名等文件语义操作只需在轻量级的目录索引内完成，无需触碰到海量叶子对象。

索引效率更高： 目录分级索引仅记录目录层级关系，不包含叶子对象索引，整体占用空间很小，可以全量缓存在内存中；同时目录索引缓存按全路径作为Key组织，访问长路径对象时直接命中，无需回退到文件系统逐级递归查询。



实现高效的随机写

AWS S3 Files支持通过NFS接口随机修改对象数据：在覆盖写文件场景下，最后将数据持久化到对象存储时，需要先将整个对象读取到EFS，修改后再写回S3存储桶。这种机制在小I/O操作下会带来严重的读改写放大问题。因此，更合适的方案是：将对象数据切割为更细粒度的数据块进行跟踪，仅记录被修改的数据块，从而只对这些块执行读改写操作。


▲覆盖写：S3 Files对象粒度 vs 基于细数据块粒度

没有统一方案，只有贴合场景的取舍。对于同时要求S3接口和POSIX语义的高性能AI数据湖工作流，重构存储底座是当前工程中实现语义完整性与性能表现最可控的路径——这也是深信服产品设计的选择。