Fluid 是云原生基金会 CNCF 下的云原生数据编列和加快项目，由南京大学、阿里云及 Alluxio 社区联合建议并开源。本文首要介绍云知声 Atlas 超算渠道依据 Fluid + Alluxio 的核算加快实践，以及 Fluid 是如何为 Atlas 带来全新的数据集办理办法的。

Atlas渠道介绍

云知声是一家专注物联网人工智能服务公司。云知声的 AI 技能栈涵盖了信号、语音、图画、文本的感知和表达才能，知识、理解、分析、决策等认知技能，并朝着多模态人工智能体系方向发展。云知声 Atlas 超算渠道作为底层根底架构，支撑着公司在 AI 各个领域的模型练习与推理服务的开展。云知声很早就开始布局建造业界领先的 GPU/CPU 异构 Atlas 核算渠道和分布式文件存储体系，该核算集群可为 AI 核算供给高性能核算和海量数据的存储拜访才能。

云知声团队依据 Kubernetes 开源架构之上，进行了相应的中心功用研制，成功构建了浮点处理才能超过10 PFLOPS（一亿亿次／秒）的 AI 超级核算服务渠道。该渠道支撑主流机器学习架构，开发者可以完成语音、言语、大数据、多模态等中心技能的高效研制。渠道也开放了相应的算力与存储，为中小微企业和院校组织供给定制化核算服务。

问题与挑战

Atlas 核算渠道选用是核算与存储别离的架构，现在整个渠道的存储服务器、核算服务器之间以及核算与存储服务器之间的底层网络架构是由 100GB 的 InfiniBand 进行互联。

核算渠道的模型练习数据存储体系由多套 PB 量级的高性能分布式文件体系 Lustre 组成。Lustre 分布式文件体系兼容 POSIX 接口，多种深度学习结构可以直接进行数据读取。核算与存储别离的架构使核算跟存储可以独立进行扩容，全体架构较为灵敏。可是之前渠道也遇到了数据拜访功率低与底层存储带宽瓶颈等问题：

存储宽带瓶颈

在存储资源相对固定的情况下，随着渠道用户的添加，其带宽、元数据负载以及服务器的负载都呈现出来较大的上升。集群存在多个单机使命运转在同一个 GPU 节点，形成 IO 资源的竞赛，由于 IO 的竞赛导致了整个练习周期拉长了，大大下降了研制影响功率。

海量小文件

第二个问题是模型练习数据集自身的特色问题。在降噪场景中有用户的使命存在挨近 TB 量级的小文件，导致底层分布式文件体系的的元数据服务压力很大。很多的小文件使得程序自身读数据的功率较低，数据读取缓慢形成 GPU 大部分时刻在等数据，全体 GPU 的全体运用率较低，延长了模型的练习周期。

数据种类多

由于渠道支撑的事务类型较广，用户的数据类型较多，文件巨细类型也不同，很难经过调优一套存储的参数来适配多种事务类型。结合用户的事务类型分析，咱们发现渠道数据首要仍是用来做模型练习占的比重比较大，其余部分首要进行模型的推理与 CPU 密集型数据生成使命。

数据冗余

在渠道中存在数据集堆叠的问题，同一个组内或许不同组有运用到相同的数据集，可是却存储了多份，形成了存储空间的浪费。

前期处理计划

如何经过最小的预算与架构改动来应对存储总带宽的瓶颈以及减少元数据服务器的压力，云知声 Atlas 也进行一系列的探索与研制。

宽带约束

考虑到很多的并发读取会形成存储带宽达到极限，形成存储卡顿或许存储体系瘫痪。渠道经过约束每个核算节点的客户端带宽以及每个用户的 UID/GID 约束带宽，可是该办法存在不行灵敏、没办法充沛运用 GPU 的核算才能的问题，当有 2 个大 IO 的练习使命分配到了同一个节点，由于节点的带宽约束，2个练习使命的 IO 都有上限，数据读取的速度约束导致 GPU 没办法充沛发挥并行读取的优势，经过监控发现该类型的 GPU 运用率在 40% 左右，严峻浪费了硬件资源。

聚合大文件

考虑到渠道的小文件太多，会对元数据形成较大的压力，咱们进行了相应的措施，首要经过检测每个用户的 inode 数量与存储总量判别用户的小文件数量，约束用户小文件的数量。第二是推行一系列数据聚合的东西，让用户将小文件聚组成 lmdb、tfrecord 之类的大文件格式。

使命调度器重构

为了防止使命都聚集在同一个节点上，咱们经过定制使命调度器插件，添加调度战略，判别节点的核算资源的运用情况，优先将使命调度到闲暇节点，防止多个使命跑在同一个节点形成的 IO 竞赛，可是该计划在渠道的核算资源呈现满载的情况下仍是不可防止。

多级缓存

为了充沛运用闲暇的硬件以及减轻底层存储体系的压力，在最前期渠道研制了第一版本的缓存计划作作为过渡。该办法可以一定程度缓解存储的压力，可是其关于数据的办理仍是不行自动化,这只能作为咱们过渡到新架构的一个暂时替代处理的计划。

全新的架构

云知声在 2020 年开始调研 Alluxio并进行了一系列的测验，包含功用的适配与性能测验等，发现 Alluxio 可以满足现在云知声需求，可以较为快速并且以较低的本钱处理咱们存在的几个痛点：

• Alluxio Fuse 供给了 POSIX 文件体系接口，用户可以无缝的运用分布式缓存，程序无需做更改；
• Alluxio 支撑对多种文件体系的支撑，包含分布式文件体系、对象存储等，当咱们渠道后续引进新的存储，Alluxio 缓存都能很好的进行支撑，确保咱们整个缓存架构的稳定性；
• Alluxio 供给较好的缓存办理，Alluxio 的层次化存储机制可以充沛运用内存、固态硬盘或许磁盘，下降具有弹性扩张特性的数据驱动型运用的本钱开支；
• 支撑以 Kubernetes 或许容器的办法布置到渠道中，与现有的技能栈较为共同；
• Alluxio 供给了 HA 支撑，确保了分布式缓存体系的高可用性。

相比早前的核算与存储别离的架构，Alluxio 在核算与存储之间引进一层 Cache 层，将底层存储的压力转移到各个核算节点的内存或许本地硬盘中，用户的使命能享用本地存储带来的速度进步优势，整个渠道可以兼容分布式文件体系与本地硬盘两者的优势。

在运用 Alluxio 进行事务端整合时，咱们遇到了权限操控、以及数据挂载等问题。Fluid 供给了一种愈加云原生的办法来运用 Alluxio, 其供给了一种全新的数据集办理办法，缓存数据集跟云原生的资源相同，可以被 kubernetes 进行相应的分配与调度，有用的处理前期缓存与 kubernetes 运用办法独立的问题。

终究咱们的架构是运用 Alluxio 作为 Fluid 的缓存加快引擎，其担任做底层分布式文件体系到核算节点本地缓存介质的数据搬迁以及缓存的办理，为渠道的运用程序供给了数据加快的功用。而 Fluid 担任缓存与运用的编列，依据 Fluid，渠道可以感知缓存，将之前需求很多人工的缓存操作，转移到渠道层智能化处理。

引进新架构后，咱们在自研的模型练习使命提交东西 atlasctl 将 fluid 功用进行集成，尽可能的为用户屏蔽一些复杂的概念，用户经过 atlasctl cache create 并指定添加一些参数信息例如缓存的巨细，缓存介质等即可创建缓存数据集。该东西的集成为用户屏蔽了负载的缓存机制信息，让他们愈加重视与数据与事务自身。

事务适配

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 缓存智能化调度功用。

戳原文，检查 Fluid 开源项目 github 主页！！

本文作者：

吕冬冬：云知声超算渠道架构师， 担任大规模分布式机器学习渠道架构设计与功用研制，担任深度学习算法运用的优化与 AI 模型加快。研讨领域包含高性能核算、分布式文件存储、分布式缓存等。有多年的云原生开源社区经历。

刘青松：云知声算法研讨员，担任机器学习渠道和运用算法研制，研讨领域包含云原生架构研讨、高性能核算、语音和视觉运用、机器学习算法等。