云知声 Atlas 超算平台: 基于 Fluid + Alluxio 的计算加速实践（下）

Posted 2022-01-01 Alluxio

业务适配

Fluid + Alluxio 为集群引入了全新的架构，但是在具体场景适配方面我们还是遇到了一些问题，这些问题我们第一时间与社区反馈，社区都第一时间解决了我们的需求，这里主要讲下几个比较重要的特性支持：

hostpath 与 nonroot 的支持

在 Atlas 平台中，我们对分布式文件系统设置了 nonroot,客户端的 root 是没有权限操作用户的目录的。如果在 Alluxio 缓存引擎使用 root 用户访问底层 UFS 会出现权限问题，Fluid 还提供了 nonroot 支持，支持在缓存引擎与数据集分别设置用户的 UID 与 GID，缓存引擎的用户信息保证 Allluxio 能够成功读取到底层 UFS 的数据，如果用户在数据集设置相同的 UID 与 GID 就可以实现任务端数据的读取，如果将数据集的 UID 与 GID 设置成别的用户信息，就可以实现数据集的共享，该特性很好的解决了平台遇到的权限控制相关的问题以及数据存储冗余的问题。

多个挂载点的支持

由于用户的任务的数据通常是由不同的数据集组成，这里的不同数据集可以是同一个存储系统的不同目录或者是不同存储系统。Alluxio 能够为应用程序提供统一命名空间。通过统一命名空间的抽象，应用程序可以通过统一命名空间和接口来访问多个独立的存储系统。相比于连接每个独立的存储系统进行通信，应用程序可以只连接到 Alluxio ，通过 Alluxiofuse 让用户能够使用 POXIS 接口访问不同底层存储的缓存数据。

透明命名机制保证了Alluxio和底层存储系统命名空间身份一致性。不同的底层存储的目录与文件名都能够在 Alluxio 进行映射。

基于该特性用户的可以同时在同一个训练任务中为 2 个存储系统的数据进行缓存加速。该特性能够避免用户进行大量的数据迁移工作，在 Atlas 平台中，TB 量级的小文件的压缩打包、迁移与解压需要耗费几个小时，运用该特性用户只需要更改下任务中数据的存储路径无需修改源代码，即可运行程序。

缓存预热

平台中计算资源往往比存储资源更紧缺，如果用户启动了 TB 量级的小文件训练任务，底层存储系统与缓存系统之间的元数据同步以及数据的同步需要耗费大量时间。Alluxio 提供了 loadMetadata 与 loaddata 的功能，Fluid 将 2 个功能进行了集成，用户能够提前将远程存储系统中的数据拉取到靠近计算结点的分布式缓存引擎中，使得消费该数据集的应用能够在首次运行时即可享受到缓存带来的加速效果。该功能能够有效的增加集群的 GPU 利用率，避免在首次缓存时进行元数据同步的时候，造成的耗时，使得程序一开始运行就具有较好的 IO 读取速度，整体的 GPU 利用率上升了。

参数调优

Alluxio 提供了较多的调优参数，平台根据业务的特点进行相应的参数配置与调优，针对几乎全是读的场景，进行了一些通用参数的调优以及一些针对不同数据集的调优。

通用参数：

打开 kernel_cache 以及将 alluxio.user.metadata.cache.enabled 设置为 true, 在客户端开启文件及目录元数据缓存。对于全读的场景可以配置 alluxio.user.metadata.cache.max.size 和 alluxio.user.metadata.cache.expiration.time以调整最多缓存文件及目录元数据缓存量和有效时间。

通过设置 alluxio.user.file.passive.cache.enabled=false 与 alluxio.user.file.readtype.default=CACHE 来避免频繁逐出（Cache Eviction）造成缓存抖动。

业务测试

我们将业务按照数据集的大小分成了 3 种，第一种是小文件，单个文件的大小在 1M 以下的。第二种是中大型数据数据量在几百 G 左右的，第三种是 T 级别大文件。

语音降噪场景

本次测试的模型是基于 Pytorch 框架搭建的 DLSE 模型，数据文件数在 50 万左右 ,数据总大小是 183 GB，采用内存作为 Alluxio 的缓存介质。
本次实验采用单机10卡的任务，基于 Pytorch 原生的 DDP 框架进行多卡的通信，对比测试了直接从分布式文件系统、从 Alluxio 缓存读取以及进行一轮预热之后再从 Alluxio 的实验。

通过第一轮的时间可以看出，进行了 warmup 的缓存任务相比于直接从底层文件系统读取或者 Alluxio 的第一轮读取速度有了接近 10 倍的提速。Alluxio 在第一轮训练的时候由于数据需要做元数据同步与缓存数据，因此在第一轮数据读取的时候缓存的优势还体现不出来。但是当第二轮读取的时候，由于数据已经全部落入缓存介质中，这时候考验的就是 Alluxio 本身的缓存命中率，通过上面的实验结果也可以看出，增速非常明显。

数据读取效率提升之后，整体 GPU 利用率也得到了提升，通过监控 GPU 的利用率发现采用 WarmUp 的 Alluxio 缓存，GPU 的利用率基本稳定在 90% 左右，同时我们看到数据缓存在内存中能够有效的降低底层存储的负载。

文字识别

本次实验采用基于 CRNN 的文字识别模型，采用 Pytorch 的框架进行模型的构建，数据源采用的是自采集的 125GB 的图像数据，图像数据转换成了一个 lmdb 的大文件，我们做了3 个对比测试，直接从底层文件系统读取、从没有进行预热的 Alluxio 读取以及采用进行了预热的 Alluxio 读取。

**我们发现采用预热的 Alluxio 节点的 IO 带宽流量相比于直接从底层分布式存储读取从 1300Mb/s 降为基本为0，**对于我们的平台收益是非常大的，在不增加底层存储硬件的情况下，这是最快而且相对廉价的降低存储系统带宽使用的方法。

读取缓存相对于直接读取底层存储计算节点 GPU平均使用率由 69.59% 提升到 91.46%，表明消除 I/O 瓶颈可以提高大文件训练任务资源使用效率。

结论

通过引入 Fluid + Alluxio 的新架构，平台取得了一系列的收益。

**加速模型训练：**通过上述的测试结果我们看到对于任务的提速效果非常明显，能够直接利用本地存储的速度优势避免因为网络传输与资源竞争，从而有效的加速模型训练过程中数据读取的耗时。

**降低底层存储负载：**新架构可以通过本地缓存分担底层存储系统的带宽与 IOPS 压力，大幅度减少底层存储系统的负载，有效的提高了底层存储系统的可用性。

**增加集群 GPU 利用率：**通过高效的 IO 读取，消除用户程序数据读取的瓶颈， 避免了 GPU 空转等待数据的现象，提高了 GPU 的利用率，从而提高了整个集群 GPU 使用率。

**避免同节点 IO 竞争：**新架构充分解决了我们早期遇到的同节点 IO 资源竞争、存储系统存在带宽瓶颈以及模型的训练效率不高的痛点。

**更加高效的缓存管理：**采用新架构以一种更加云原生的方式管理缓存，工程师从之前单纯将数据载内存到现在缓存转变成可以管理与监控的资源，Kubernetes 调度能够感知缓存，进行相应的策略分配，使得任务能够更加高效的运行。

后续规划

Fluid + Alluxio 为我们带来了很大的收益，目前我们也跟社区紧密持续合作中，后续我们将在以下几个方面继续深入研究：

持续反馈测试结果与问题以及提供更丰富的使用场景给社区，不断的迭代优化 Alluxio 的性能；

总结与测试更多的数据类型，提供参数调优实践反馈给社区；

增加 fluid 缓存智能化调度功能。