很多AI项目立项后，很快就会卡在数据准备环节。模型和GPU已经就绪，训练数据却散落在多套存储中。

算法团队需要的图片、视频、点云、文档和日志，可能已经在不同部门积累了几年。有的放在NAS里，有的放在对象存储里，还有一部分留在旧存储或数据湖中。数据量大、文件数量多，直接搬迁要占用网络和生产存储；不搬，训练服务器跨设备读取时又容易卡在I/O上。

深信服EDS 5.3.2 开始支持的 数据流动2.0特性 提供了一种比较务实的处理方式：先读取并管理外部存储的元数据，业务需要哪些数据，再把哪些数据预热到全闪层。旧存储可以继续保留，AI项目也能更快进入验证和训练阶段。

一、数据流动解决的是什么问题

数据流动2.0 支持通过NFS v3或S3接入外部存储。首次接入时，EDS扫描外部数据的目录、对象和相关元数据信息。真正的数据仍保存在原存储上，等上层应用访问或管理员提前执行预热时，再把指定目录的数据加载到全闪存储。

用户可以从三个角度理解这项能力。

第一，减少项目启动前的全量迁移。AI团队可以先使用已有数据，不必等整个数据池复制完成。

第二，把有限的全闪容量留给正在使用的数据。训练结束后，结果可以回刷或导出，其他冷数据继续放在容量型存储中。

第三，减少上层应用对不同存储的适配工作。底层数据可能来自文件存储或对象存储，上层可根据方案选择文件或对象方式访问。

二、五类具体业务场景应该怎么用

场景一：工业视觉质检复用历史图片

图：产线持续采集数据，历史质检图片保留在原存储，选定数据集经全闪层加速后供GPU训练。

一家制造企业已经积累了数年的产线图片。原有质检系统每天继续向NAS写入新图片，算法团队准备训练缺陷识别模型，希望调用其中一部分历史数据。

如果直接迁移全部图片，项目要先经历长时间的数据复制，NAS也会承受持续读取压力。全量数据长期放在全闪上，成本同样不合适。

这类项目可以采用透明加速模式：

1. 通过NFS v3纳管原有NAS；
2. 按产线、产品型号、缺陷类型或时间范围选择训练目录；
3. 在训练开始前将对应目录预热到EDS全闪；
4. GPU服务器从EDS读取训练数据；
5. 质检系统继续向原NAS写入，不改变现有生产链路；
6. 训练结果和模型文件按企业规范写回指定存储。

透明加速模式下，外部存储仍是主要数据源。同名文件发生冲突时，系统优先保留外部存储侧的数据，EDS侧冲突文件会被重命名保留。用户需要提前检查标注软件和训练脚本是否会在原目录覆盖文件，避免读取到错误版本。

场景二：机器人训练使用视频、点云和轨迹数据

图：机器人现场数据继续写入原存储，训练任务只把所需的视频、点云、轨迹和遥测数据预热到高性能层。

具身智能的移动机器人、机械臂和无人设备会持续产生视频、点云、传感器日志、动作轨迹、IMU数据和任务回放数据。这些数据通常按日期、设备、场地或任务批次分散保存。算法团队每次训练只会使用其中一部分。

适合的做法是按训练任务建立数据清单，将确定要使用的路径预热到全闪。比如本轮只训练某一仓库内的避障模型，就预热该场地、指定机器人型号和目标时间段的数据。下一轮训练抓取或导航模型时，再切换数据范围。

这套方式可以让全闪层跟着训练任务走。项目组还可以通过eds-ctl命令行工具，把预热动作接入训练流水线：任务排队后先预热，状态确认完成再分配GPU，训练结束后归档输出。这样能减少GPU已经分配、数据却还没准备好的等待时间。

对于点云、大量JSON日志和碎片化传感器文件，测试时需要同时关注元数据性能和吞吐。单纯复制一个大视频得出的带宽结果，无法代表真实训练效率。

场景三：企业知识库和RAG调用已有文档

图：左侧为企业文档解析和知识库构建，右侧为历史视频选取与智能分析，两类业务均按任务调用存量数据。

企业建设知识库时，原始资料往往分散在文件服务器、归档存储和对象存储中，包括Office文档、PDF、图片、录音和业务附件。项目初期经常花大量时间复制文件、修改采集程序和维护多套访问接口。

可以先通过数据纳管把目标文件库纳入统一管理，再由文档解析、OCR、切分和向量化程序从EDS访问所需数据。新增知识库只需预热对应部门或项目目录，不需要复制整个企业文件库。

场景四：智能安防调用历史视频进行二次分析

园区、交通和公共安全系统会长期保存监控视频和抓拍图片。新上线的人车识别、事件检测或轨迹分析应用，需要读取既有数据，但原视频平台仍要持续录像。

这类场景同样适合透明加速。录像业务继续写原存储，EDS将指定区域、摄像头和时间段的数据加载到全闪，供AI分析任务集中读取。分析完成后，结构化结果可以写入业务数据库，关键片段和模型输出再按要求归档。

场景五：AI数据平台逐步接管旧存储

有些企业希望AI项目上线后，逐步把访问入口迁到EDS，并将旧存储变成后置容量层。这种情况下可以考虑业务接管模式。

应用切换后，新数据先写入EDS，再按照回刷策略同步到外部存储。用户可以配置最短5分钟的异步回刷，也可以选择不自动回刷，通过数据导出将数据写入其他存储。

业务接管适合明确由EDS承担主要读写的项目。切换前要梳理所有仍在访问旧存储的客户端。如果旧系统与EDS继续同时写入同一数据范围，发生同名冲突时，业务接管模式会优先保留EDS侧数据，外部存储侧冲突文件被重命名。对依赖固定文件名的应用，这种变化可能直接影响程序处理结果。

三、业务接管和透明加速怎么选

可以从“谁负责主要写入”来判断。

判断项	业务接管	透明加速
主要访问入口	EDS	原外部存储仍保留
新数据主要写到哪里	先写EDS，再按策略回刷	主要写外部存储
适合的项目	新AI平台准备统一接管数据访问	既有业务不改，只给训练或分析任务提速
冲突时优先保留	EDS侧数据	外部存储侧数据
用户重点检查	客户端是否全部完成切换、回刷窗口	增量发现速度、两侧同时写入行为

如果项目只是临时训练、阶段性分析或不能改动原系统，优先评估透明加速。新平台已经完成应用改造，准备由EDS统一承载读写时，再考虑业务接管。

四、用户上线前应该怎样验证

测试的目标是确认项目能不能按期上线、会不会影响现网、训练效率能提高多少。以下检查应使用用户自己的数据和业务流程完成。

1. 先算清楚首次纳管需要多长时间

用户应从生产数据中抽取一个有代表性的目录，记录文件总量、平均大小、目录层级和外部存储负载，再测算扫描速度。测试案例中，极端条件下2亿文件，10个层级的对象存储（MinIO）全量扫描可能接近三天。这个结果受源设备性能和数据结构影响很大，只能用于提醒项目组预留窗口。

2. 用一次完整训练任务衡量加速效果

先让训练任务直接读取原存储，记录数据加载时间、首个Epoch耗时、GPU利用率和训练总时长。完成预热后，在相同数据集、并发和模型参数下再运行一次。

最终关心的是训练周期缩短了多少、GPU等待是否下降，以及并发任务增加后性能是否稳定。

3. 检查增量数据多久能被发现

支持Snap Diff的设备可以快速识别变化；普通NFS v3设备主要依赖目录Mtime扫描。某些原地覆盖写不会更新上层目录Mtime，系统会通过周期性全量扫描兜底。

用户应使用真实程序执行新建、追加、覆盖、重命名和删除操作，分别记录EDS侧看到变化的时间。S3场景还要确认对象存储的事件通知是否兼容，以及事件丢失后如何补偿。

4. 验证预热能否赶上任务计划

测试环境在25Gb网络下，文件预热带宽曾达到不低于4GB/s，对象预热不低于1.5GB/s。用户现场的10Gb网络、旧存储读取能力、副本策略和小文件比例都可能降低实际速度。

5. 故意制造同名文件冲突

在测试目录中让EDS和外部存储分别创建、覆盖同名文件，观察重命名规则、应用读取结果和后续回刷行为。用户需要确认冲突文件能否被业务人员识别、告警和处理，避免冲突长期积累后才被发现。

6. 检查权限和应用兼容性

用管理员、普通用户、只读账号和服务账号分别访问测试目录。验证目录遍历、文件锁、特殊字符、长路径、软链接及应用依赖的协议行为。协议能够连通，只能说明接入成功，应用能否稳定运行还需要单独验收。

五、项目设计时需要保留的边界

• 外部文件存储按NFS v3能力接入，项目应核对具体设备与版本兼容性；
• S3增量感知依赖外部对象存储的事件通知机制；
• 异步回刷存在时间窗口，不能按同步双写理解；
• 全量扫描会给外部存储带来读取和元数据压力；
• 文件与对象的统一访问仍需验证权限和协议语义；
• 统一视图、向量存储和数据分支管理应以未来正式发布版本为准。

结语

AI项目常见的现实条件是旧存储不能停、历史数据不能全部搬、全闪预算也有限。EDS数据流动2.0提供了一个渐进式方案：保留现有数据池，根据业务任务把热点数据送到全闪层，再通过回刷、导出或归档完成后续管理。

方案是否有价值，要看用户自己的训练周期、GPU利用率、现网影响和数据一致性结果。先用一批真实数据跑完整业务，再决定接入范围和最终架构，通常比直接做大规模迁移更稳妥。

---

相关阅读

• 深信服EDS海量非结构化数据解决方案
• 信服云高性能文件存储EDS

版本说明：文中数据流动功能边界依据EDS 5.3.2版本材料整理。项目交付应以对应版本用户手册、兼容性清单和现场POC结果为准。