自动驾驶训练如火如荼，网络带宽跟不上怎么破？

当前， AI、大数据、云计算等技术逐渐成熟，5G 网络大规模建设等各种趋势共同推动了通信网络的代际演进。与此同时，企业通信网络数字化转型也面临着一些挑战：业务越来越复杂、基础网络越来越繁琐、连接数的增加和带宽的快速增长问题等。

焱融科技以自动驾驶行业为例，分析近年来各家自动驾驶企业发展受限的因素。在上一篇《精选案例 | YRCloudFile 引领自动驾驶存储技术新趋势》中，基本已经覆盖了自动驾驶企业目前所遇到的问题，但是还有一个核心限制发展因素，我们还没有探讨，那就是万兆网络已经不足以匹配当今主流的算力及 NVMe 性能。

自动驾驶训练对网络环境要求极高，然而很多自动驾驶厂商现有的万兆网络在带宽和延迟上无法满足高速的自动驾驶需求。因此，焱融科技针对自动驾驶厂商的网络带宽问题方面，提出了相应的解决方案。

焱融科技将分享基于国内无人驾驶商用、集装箱物流人工智能全局化等领域领跑市场，业务已遍布海内外 80 余个节点的的某全栈式人工智能创新公司的产品落地案例。本次分享集中在“网络带宽受限”这一行业焦点，从“挑战分析、解决方案和行业案例”三个方面提出观点和建议，希望能为更多关注自动驾驶，以及相关从业者提供破解思路。

自动驾驶的网络带宽挑战

此前，国内某国内全栈式人工智能创新公司在自动驾驶车辆训练过程中，随着训练时间逐渐增多，出现网络数据量暴涨、应用程序激增等情况，致使该公司对网络带宽和存储性能的需求变得越来越高，原有的网络带宽和存储方式已经不适配于当前场景。主要原因有以下：

1. 万兆网络似“小水管”，传输过程易拥堵

该公司使用的万兆网络带宽成训练瓶颈，导致底层堆砌再多磁盘，存储性能也无法得到提升，从而使得上层 GPU 服务器性能无法得到充分发挥。同时，随着业务量的提升，原有存储网络无法很好的支撑大规模并发访问，致使频繁出现性能问题。

2. 海量文件需存储，性能衰减超乎想象

在自动驾驶训练过程中，数据呈现出几何式增长。小数据集达到十万级别，大数据集达到百万、千万甚至上亿级别。而且数据类型繁多、数据大小变化大，往往极易产生上亿级的海量小文件，给元数据管理、存储效率和访问性能等方面带来巨大挑战。

3. 难以解决存储产品与容器平台对接问题

存储产品对容器平台的兼容性差，块存储挂载操作复杂，NAS 存储无法细粒度管理存储等等，无法适应上层敏捷的应用需求。除此以外，还会面临对接容器编排管理平台后，存储维护复杂，流程繁琐，导致容器业务中断等问题。

YRCloudFile 助力自动驾驶冲刺“最后100米”

为了解决该公司在自动驾驶训练场景所面临的问题，焱融科技进行了一些系列的分析，并从网络改造、存储部署、容器化支持、智能分层等方面提供了一整套高性能、高可用、高扩展的方案。

1. 全面升级网络带宽，迈向自动驾驶下一个台阶

在正式改造以前，焱融科技深度研究了该公司的网络架构和原有存储体系，发现原有网络带宽成为影响存储性能提升的关键之一。

网络拓扑图

焱融科技推荐新增 25Gb 交换机的方式，让该公司做到存储内部数据交互，克服网络带宽限制带来的存储性能瓶颈，充分发挥 GPU 服务器的性能，达到训练效率翻倍提升的要求。

在存储改造升级完毕后，焱融科技还发现，该公司现有集群的性能虽然已经超过原有存储系统，但却没有达到预期的数值。因此，焱融科技再次针对现场环境进行分析，提出以下几点优化措施：

• 增大节点上的 socks 数量，获得更大的连接数；
• 调整线程数 workers，以匹配访问的数量；

通过上述两个步骤，调整以后的 YRCloudFile 性能得到了大幅的提升，在一定程度上保证了存储性能，减少了网络带宽对存储带来的影响。

2. 海量小文件场景下，元数据处理能力是关键

针对客户海量小文件性能问题，焱融科技通过可水平扩展设计的 MDS 架构，实现 MDS 集群化。这主要考虑到以下三方面：

• MDS 集群化有利于缓解 CPU，降低内存压力；
• 多个 MDS 有利于企业存储更多元的数据信息；
• 在实现元数据处理能力水平扩展的同时，提升海量文件并发访问的性能。

目前，焱融 YRCloudFile 主要采用静态子树 + 目录Hash两者结合的方式搭建可水平扩展设计的 MDS 架构。此种架构方式有两种好处，首先元数据的分布存储，通过扩展元数据节点，即可支持百亿级别的文件数量；其次，保证了元数据的检索性能，减少在多个节点上进行元数据检索和操作。

3. 整合 K8S 平台，为容器化训练无缝提供数据支持

该人工智能创新公司在车辆测试过程中，选择了以容器为应用运行载体的 K8S 平台，运行 AI 训练和推理任务。然而，在存储系统在对接容器场景时，遇到了以下难题：

• 采用 in-tree 类型的存储代码，使得 K8S 和存储厂商的代码紧耦合；
• in-tree 存储代码中的 BUG 会引发 K8S 组件不稳定；
• in-tree 存储插件享有与 K8S 核心组件同等的特权，存在安全隐患；
• 仅支持部分 AccessModes、PV 管理、故障等方面的特性。

焱融 YRCloudFile 针对容器化场景的功能进行了优化：

• 企业级功能：通过 YRCloudFile 管理界面对 PV 进行读写带宽、IOPS 等性能分析，实现 PV 热点定位功能。同时，支持 PV Quota、Resize、QoS 等功能；
• 多种读写模式：YRCloudFile 支持 ROX、RWO、RWX 等多种读写模式；
• 有状态容器的跨节点重建：数据在整个 K8S 平台各个计算节点上，都随时可用，重建过程无需人工干预，实现数秒内完成；
• 实现 CSI 对 PV 的智能调度: YRCloudFile 具有 CSI 故障智能感知功能，K8S 创建需要持久化存储的 Pod 时，CSI plugin 容器异常，以及与存储集群连接异常的节点会被自动过滤；

YRCloudFile 容器存储

4. 客户端多级智能缓存，提升训练整体性能

自动驾驶训练数据有很多类型，例如视频、图片等。针对于数据的格式也很多，例如：json、txt、jpg 等等。不同的数据信息相应的存储数据量也是不一样的，所以普通文件缓存容易出现只提供内存缓存的情况，导致容量有限，通常一台 GPU 服务器可用的内存缓存数仅 10GB。

因此，YRCloudFile 通过私有客户端，可以提供多级智能缓存：

• 内存缓存 + GPU 服务器 SSD 缓存：在 GPU 服务器上，YRCloudFile 可配置一定容量的 SSD 缓存，实现训练程序优先从客户端内存缓存中加载；
• 对训练框架、应用程序完全透明；
• 在整个训练中，数据集加载速度实测提升幅度超过 500% 。

YRCloudFile 多级智能缓存

YRCloudFile 全面解决自动驾驶存储问题

对于大多数自动驾驶企业而言，数据具有阶段性热点访问的特点，超过一定时间后，80% 以上的数据逐步转冷。热数据的访问性能要求较高，经过一定时间周期之后，热数据逐渐变冷，应用访问这些冷数据的频率会变得很低。因此，自动驾驶企业在整个冷热数据分层的过程之中，常常遇到以下问题：

• 在对接对象存储过程中，如若进行冷热数据分层，容易面临上层业务接口是否改变，以及数据访问路径是否改变的问题；
• 针对不同业务类型是否可以区别定义；
• 冷数据下刷以后，性能是否存在下降；

针对上述问题，YRCloudFile 文件存储系统提供了智能分层功能，实现根据用户需求，自定义冷热数据策略，冷数据自动流动至低成本的公有云对象存储，并完成压缩。向上仍然为业务提供标准的文件访问接口，并保持目录结构不变，实现数据在冷热数据层之间流动对业务完全透明，有效针对成本和性能平衡问题。主要优化方式如下：

（1） 标准文件接口，数据访问路径不改变

上层应用无需任何改造，焱融存储对外提供标准的文件接口。冷热数据自动分层无需管理员进行干预，实现按照自定义策略下刷至对象存储，对外仍然暴露统一的文件系统命名空间。用户在使用过程中，并不会受到对象存储层影响，访问路径仍旧符合用户存储习惯。

（2） 目录级智能分层

YRCloudFile 可以自定义不同业务、不同数据类型的冷数据。对于数据中心而言，不同的应用，对冷数据的定义是不同的，对数据存放的要求也不同。例如数据安全要求高的冷数据需要存放在本地；数据安全要求低的数据可以存放在公有云。或者训练数据在被频繁的训练 2 周之后就不再访问，而训练结果数据则会在很长的时间段内一直需要频繁访问。

（3） 冷数据性能不降级

高效读写，保证冷数据读写性能。可配合各类调度策略，实现数据的预热，进一步减少计算时的 IO 等待时间。

（4） 分层镜像双活

• 数据冗余保证数据安全；
• 优先本地读保证读写性能；
• 对象存储故障保证业务连续性；
• 对象存储故障自动恢复；
• 优先本地读减少公有云对象调用费用。

通过冷、热数据智能分层的方式，YRCloudFile 可以满足绝对大多数企业在自动驾驶训练过程中，对于存储高性能和数据长期保存的需求。

YRCloudFile 分布式文件存储架构图

目前，在 YRCloudFile 的帮助下，该人工智能创新公司顺利解决了存储网络带宽成为性能瓶颈的问题，并且存储平台与上层容器进行无缝整合，实现资源平台的统一调度与管理。