共计 6017 个字符，预计需要花费 16 分钟才能阅读完成。
简介：本文次要介绍云知声 Atlas 超算平台基于 Fluid + Alluxio 的计算减速实际，以及 Fluid 是如何为 Atlas 带来全新的数据集治理形式的。
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 缓存智能化调度性能。
本文作者：
吕冬冬：云知声超算平台架构师，负责大规模分布式机器学习平台架构设计与性能研发，负责深度学习算法利用的优化与 AI 模型减速。钻研畛域包含高性能计算、分布式文件存储、分布式缓存等。有多年的云原生开源社区教训。
刘青松：云知声算法研究员，负责机器学习平台和利用算法研发，钻研畛域包含云原生架构钻研、高性能计算、语音和视觉利用、机器学习算法等。
原文链接
本文为阿里云原创内容，未经容许不得转载。
