具身智能、AI 生物制药、低空经济和半导体分属不同产业，但它们的研发和生产都越来越依赖数据。数据需要长期保存，也会被反复用于训练、仿真、分析和生产决策。

机器人每天产生相机、激光雷达、关节控制和仿真数据；药物研发需要反复读取基因组、蛋白质结构、分子轨迹和训练数据集；低空业务持续汇聚视频、遥感、航迹与气象数据；芯片设计则同时面对海量小文件、EDA 工程目录、仿真结果和版本数据。容量增长只是表象，真正棘手的是：大文件、小文件和混合 I/O 同时出现，数据量不断扩张，而上层计算平台又不愿意等待存储。

非结构化数据进入生产系统后，存储就不能只看容量。混合 I/O 性能、扩展能力和可靠性，任何一项跟不上，都会拖慢上层业务。

深信服企业级分布式存储 EDS 的思路，是把文件、对象和块数据放进同一个可横向扩展的资源池。业务增长时，性能、容量和可靠性可以一起扩展，而不是简单地往原有阵列里继续加硬盘。

一、EDS 的分布式架构，解决的不是一个问题

1. Scale-out：扩容时同时增加容量和处理能力

传统 Scale-up 阵列主要依赖固定控制器。加硬盘可以增加容量，却不一定能同步增加控制器的 CPU、内存和 I/O 能力，规模越大，控制器越容易成为瓶颈。

EDS 采用 Scale-out 横向扩展架构，由多个通用服务器节点组成分布式存储资源池。新增节点时，容量和存储计算能力一起加入集群。随着节点增加，容量和性能可以同步增长，单集群能够扩展到数百 PB。节点失效或更换时，分布式多活架构继续对外提供数据服务。

对新兴产业来说，这种架构的价值很实际：项目初期不必一次性买到最终规模，可以先按当前数据量建设，再随着机器人数量、实验批次、飞行架次或研发项目增加而横向扩容。

2. 统一块、文件、对象访问，减少数据孤岛

EDS 在同一套分布式存储软件上提供块、文件和对象服务，支持 iSCSI、CIFS、NFS、CSI、S3、FTP 等访问方式，可以对接数据库、虚拟机、容器、Windows/Linux 文件共享和各类应用程序。

不同业务仍然使用各自合适的协议，只是底层资源可以统一管理：

• 数据库、虚拟化或部分云平台可使用块存储；
• 工程目录、训练数据集和共享文件可使用文件存储；
• 数据湖、归档和面向应用的数据服务可使用对象接口；
• 容器工作负载可结合 CSI 接入，但要核对具体版本兼容性。

把多类数据放在一套底座上，可以减少“一个应用建一套存储”造成的重复采购。资源调度、扩容、数据保护和日常运维也不必分散到多套系统中处理。

3. 凤凰架构：把协议、元数据、性能层和容量层拆开优化

EDS V5 使用全自研“凤凰架构”，系统分为协议层、服务层、性能层和容量层：

• 协议层面向 CIFS/SMB、NFS、FTP、S3 等访问方式；
• 服务层使用多活元数据服务；
• PhxKV 负责分布式元数据处理；
• PhxTier 作为大性能层，使用 NVMe SSD 承接热点和高频 I/O；
• 容量层负责数据持久化，并结合副本或纠删码提供保护。

其中，全局缓存负责吸收高频读写，多活元数据服务分担目录和文件元数据请求，全局追加写用于减少随机写入和介质磨损。几部分配合起来，主要解决小文件访问慢、混合 I/O 容易抖动以及存储介质长期可靠性的问题。

小文件性能会影响 EDA、软件编译和 AI 数据预处理效率；大文件吞吐则直接影响视频、遥感、训练集和仿真结果的读写速度。EDS 同时针对小文件高 OPS、大文件高吞吐和混合 I/O 做了优化。

4. 可靠性要覆盖故障、误操作和站点灾难

生产数据的安全不能只靠磁盘不出故障。EDS 提供多副本或纠删码、端到端数据校验、全局追加写、缓存多副本、快照、异步复制、文件回收站、WORM、访问控制、行为审计和防勒索等机制。

做方案时，可靠性要落到三个具体问题上：

1. 节点、硬盘或网络发生故障时，业务能否继续访问数据；
2. 文件被误删、篡改或勒索加密后，能否找到并恢复正确版本；
3. 站点级故障发生时，是否有异地副本和明确的恢复流程。

研发和生产数据需要的是完整的保护和恢复流程，单看一个可靠性百分比没有太大意义。

二、场景一：具身智能——让采集、仿真、训练和回放共享同一份数据

具身智能的数据链通常从真实世界采集开始。相机、深度相机、激光雷达、力矩传感器、关节状态和控制日志不断写入；随后还要进行清洗、标注、仿真、训练、评测和问题回放。

这条链路会同时出现三种负载：

• 多路传感器原始数据和视频，特点是大文件、持续写入和高吞吐；
• 标注结果、索引、轨迹切片和训练样本，特点是大量小文件与随机访问；
• GPU 训练和仿真任务，特点是多个计算节点并发读取同一数据集。

在这类项目中，可以用 NFS 或高性能文件服务向训练集群提供共享数据集，用 S3 承载数据湖和对象化结果，再用 CSI 对接容器化的训练、仿真和标注平台。数据量和计算节点增加后，通过扩展存储节点补充容量与吞吐。

这样可以减少采集区、标注区和训练区之间的大量数据复制。训练、评测和问题回放直接访问统一数据集，也能减少 GPU 因等待数据而空转。

在 100G IB 业务网、25G 私网的三节点测试配置下，AI 训练读吞吐上限为 19GB/s。（这个数值只对应当时的软硬件和网络配置，不能直接套用到其他节点规模。正式部署前仍要用实际数据集、训练框架和并发任务做测试。）

三、场景二：AI 生物制药——把测序、组学、分子计算和模型训练串起来

AI 生物制药的数据并不整齐。原始测序文件、显微图像、蛋白质结构、分子动力学轨迹和模型权重通常很大；基因组索引、样本清单、中间结果和实验记录又会形成大量小文件。研发团队还需要在同一批数据上反复执行比对、筛选、训练和复核。

落地时，可以按数据用途划分四个逻辑区域：

1. 原始数据区：保存测序、成像和实验仪器产生的原始数据，控制写入权限，避免源数据被覆盖；
2. 高性能分析区：向多组学分析、分子模拟和 GPU 训练提供并发文件访问；
3. 共享协作区：承载项目目录、结果文件和跨团队共享数据；
4. 保护与归档区：通过快照、异步复制、WORM 或分级策略保护长期数据。

小文件高 OPS、大文件吞吐和混合 I/O 能力，可以覆盖生命科学任务中差异很大的访问负载。随着测序批次和研发项目增加，再通过横向扩容补充性能和容量。基因测序也是 EDS 比较典型的高性能文件存储场景。

对药物研发而言，可靠性同样重要。模型可以重训，但原始实验数据、关键批次结果和可追溯记录一旦丢失，往往很难重建。因此，快照、复制、访问控制和长期保留策略需要在项目开始前就设计，而不是等容量快满时再补。

四、场景三：低空经济——从“存视频”升级为“支撑实时调度与事后复盘”

低空经济的数据来源包括无人机可见光和红外视频、遥感影像、点云、航迹、飞控日志、气象数据、地图和任务记录。随着飞行器数量、巡检频次和监管范围扩大，数据会从 TB 迅速走向 PB。

这个场景最容易出现两套互相割裂的系统：一套保存视频和影像，另一套支撑实时分析与调度。前者容量大但读取慢，后者性能高但空间昂贵，数据在两边不断搬运。

采用 EDS 时，可以这样划分数据流：

• 前端任务数据通过文件或对象接口汇聚；
• 热数据进入高性能存储池，供目标识别、三维建模、轨迹分析和应急回放使用；
• 任务结束后，数据按策略转入容量层或外部对象/云存储；
• 统一命名空间保留访问路径，减少应用因数据迁移而反复修改。

EDS 可以在热层、温层和冷层之间调度数据，同时查看分层状态、闪存占用和策略运行情况。这对低空业务很实用，因为热点数据并不固定。一次突发事件可能让几个月前的航迹、视频和遥感数据重新被频繁调用，系统需要及时把数据调回高性能层，而不是让业务人员去不同存储里逐一查找。

低空场景还应把数据保护与合规单独设计。视频、航迹和任务记录可能涉及敏感地理信息和执法证据，应结合身份权限、审计、WORM、快照和异地复制，明确谁能访问、保存多久、何时归档以及如何恢复。

五、场景四：半导体——小文件性能直接影响研发效率

半导体设计是典型的生产型非结构化数据场景。EDA 工具会频繁创建、读取、修改和删除海量工程文件；综合、布局布线、验证、仿真和代码编译既有大量小文件元数据操作，也会生成较大的波形与结果文件。

如果元数据能力不足，CPU 集群会在打开目录、检索文件和加载工程时等待；如果并发控制和文件锁语义处理不完整，多客户端共同访问工程目录还可能带来一致性风险。

针对这类负载，EDS 使用多活 MDS、目录哈希和分布式 PhxKV 提升元数据并发能力，并让元数据处理能力随节点扩展。在 SMB 场景中，系统通过协议语义合并并保留 NTFS OpLock 锁语义，避免多个客户端同时修改同一个文件造成损坏。

在落地上，可以把 EDA 工程目录、IP 库、PDK、仿真结果和归档数据按性能与保护要求划分不同存储策略：

• 活跃项目和共享 IP 库优先放在高性能层；
• 仿真波形和中间结果兼顾吞吐与容量；
• Tape-out 相关版本、签核结果和关键交付物启用快照、复制和不可篡改保护；
• 随研发团队和计算节点增加，通过横向扩容补充容量与元数据处理能力。

EDS 已在多类 EDA 工具和芯片设计环境中落地。不过，不同企业的 PDK、工程目录、工具链和并发规模差异很大，选型时仍要使用自己的业务数据做 PoC，重点观察目录遍历、工程加载、并行编译、仿真写入和多客户端并发访问表现。

六、落地 EDS 之前，先回答这六个问题

EDS 能覆盖很多负载，但“统一存储”不等于“不做设计”。项目启动前至少要回答下面六个问题：

1. 数据以大文件为主、小文件为主，还是混合 I/O？
2. 业务真正关心的是吞吐、IOPS、时延，还是元数据并发？
3. 计算侧使用 Windows、Linux、容器、GPU 集群还是虚拟化平台？
4. 热数据比例、保存周期和未来三年的增长速度是多少？
5. 哪些数据允许归档，哪些数据必须持续在线，哪些数据必须不可篡改？
6. 节点、网络、机房或站点故障发生时，允许的 RPO、RTO 分别是多少？

存储已经进入生产流程

具身智能、AI 生物制药、低空经济和半导体等行业都在把非结构化数据推向核心生产流程。此时，存储的角色也从“保存结果”变成“参与计算”：采集速度、文件检索、并发读取、故障恢复和数据流动都会直接影响研发与生产效率。

EDS 用 Scale-out 架构应对持续增长，用统一块、文件和对象服务减少烟囱式建设。凤凰架构针对大文件、小文件和混合 I/O 做了专门优化，快照、复制、访问控制和防勒索机制则负责数据保护。

用户在选型的时候不能只看功能清单。PoC 时应带上真实数据集、实际工具链和接近生产环境的并发量，分别测试数据采集、小文件遍历、GPU 并发读取、节点故障、快照恢复和扩容后的性能变化。测试结果达到业务要求，再决定最终的节点、网络和存储池配置。