做游戏自媒体视频网站,大连建设银行网站,ppt现成作品,佛山网站建设公司点精小胡在早期阶段#xff0c;vivo AI 计算平台使用 GlusterFS 作为底层存储基座。随着数据规模的扩大和多种业务场景的接入#xff0c;开始出现性能、维护等问题。为此#xff0c;vivo 转而采用了自研的轩辕文件系统#xff0c;该系统是基于 JuiceFS 开源版本开发的一款分布式文件…在早期阶段vivo AI 计算平台使用 GlusterFS 作为底层存储基座。随着数据规模的扩大和多种业务场景的接入开始出现性能、维护等问题。为此vivo 转而采用了自研的轩辕文件系统该系统是基于 JuiceFS 开源版本开发的一款分布式文件存储方案。
本文将介绍 vivo 轩辕文件系统在 JuiceFS 基础之上开发的新特性。以及 vivo 针对一些关键场景如样本数据读取速度慢和检查点写入环节的优化措施。此外文章还将介绍 vivo 的技术规划包括 FUSE、 元数据引擎及 RDMA 通信等方面希望能为在大规模 AI 场景使用 JuiceFS 的用户提供参考与启发。01 计算平台引入轩辕文件存储的背景
01 计算平台引入轩辕文件存储的背景
最初vivo 的 AI 计算平台 使用 GlusterFS 并由该团队自行维护。在使用过程中团队遇到了一些问题。一是处理小文件时速度变得非常缓慢二是当需要对 GlusterFS 进行机器扩容和数据平衡时对业务产生了较大的影响。
随后由于早期集群容量已满且未进行扩容计算团队选择搭建了新的集群。然而这导致了多个集群需要维护从而增加了管理的复杂度。此外作为平台方他们在存储方面的投入人力有限因此难以进行新特性开发。
他们了解到我们互联网部门正在研发文件存储解决方案经过深入交流和测试。最终他们决定将其数据存储迁移至我们的轩辕文件存储系统。 轩辕文件系统基于 JuiceFS 开源版进行了二次开发支持多种标准访问协议包括 POSIX、HDFS 以及 Windows 上的 CIFS 协议。此外我们还提供了文件恢复功能该功能参考了商用解决方案能够按照原路径进行数据恢复。
同时我们的系统支持客户端热升级这一功能在开源版本中也已经实现。另外我们还支持用户名权限管理默认使用本地 uid/gid 进行鉴权。在此基础上我们还参考 JuiceFS 企业版实现了用户名鉴权功能。
下图是轩辕文件系统的架构图与 JuiceFS 类似。在底层基座方面我们使用 TikV 存储元数据而数据则存储在我们自研的对象存储系统中。特别值得一提的是在 Windows 场景下我们在 Samba 中开发了一个插件该插件直接调用 JuiceFS API从而为用户提供了一个在 Windows 上访问我们文件存储的通道。 目前的 AI 计算平台存储流程如下首先获取原始数据并通过一个包含 4 万个批处理任务的系统进行处理生成样本库。这些样本库随后在 GPU 上训练产生模型文件这些模型文件被传输至在线系统用于推理。原始数据及处理后的样本库直接存储在轩辕文件系统中由于其兼容 HDFS APISpark 可以直接处理这些数据。模型文件也保存在轩辕中并通过其提供的CSI插件使在线推理系统能直接挂载并读取这些文件。 02 存储性能优化
训练阶段涉及存储的主要有两个重要方面样本读和训练过程中的检查点 checkpoint 保存。 环节1加速样本读
为了提升样本加载的速度我们开发了一个分布式读缓存层。在训练模型前我们借助JuiceFS 提供的 warm up 功能优先将本次训练所需的数据预加载至读缓存层。通过这种方式训练数据可以直接从读缓存层获取而无需从对象存储系统中拉取。通常情况下直接从对象存储中读取数据需要花费十几至几十毫秒但通过读缓存层则可将读取时间缩短至 10 毫秒以内从而进显著提高了数据加载到 GPU的 速度。 环节2检查点 Checkpoint 写入
在检查点写入方面我们参考了百度的方案。具体而言检查点数据首先被写入一个临时缓存区域我们称之为“协管”区域但此处可能指的是某种形式的中间缓存或暂存区然后再逐步刷新到对象存储中。在这个过程中我们也采用了单副本模式因为检查点本身就是每隔一段时间保存的即使某个时间段的检查点丢失对整体训练的影响也是有限的。当然我们也制定了一些策略来确保关键数据的安全性并非所有数据都会进入这个中间缓存区域。通常只有检查点文件和训练阶段的日志文件会被写入。如果训练中断检查点文件可以从这个中间缓存区域中读取。 此外当数据被写入并刷新到对象存储中时我们并不会立即从检查点缓存中清除这些数据。因为训练过程中随时可能中断如果此时检查点缓存中的数据被清除而需要从对象存储中重新拉取将会耗费较长时间。因此我们设置了一个 TTL生存时间机制。例如如果检查点数据每小时刷新一次到对象存储中我们可以将 TTL 设置为 1.5 小时。这样即使训练中断我们也能确保检查点缓存中有一个最新的备份可供使用。
在开发写缓存的过程中我们遇到了一个挑战。由于我们的客户端与写缓存之间的通信采用 gRPC 协议该协议在数据反序列化时会重新申请内存以存储解析后的数据。在特定时间段内如果写操作非常集中例如在几十秒内会导致大量的内存申请和释放。由于我们使用的是 Go 语言开发其垃圾回收GC机制在这种情况下表现较慢可能会导致写缓存的内存耗尽。
为了解决这个问题我们调研了其他数据反序列化的方案。最终我们采用了 Facebook 的 flatterbuffer 方案。与 gRPC 的 Pb 反序列化不同flatterbuffer 在反序列化后可以直接使用数据无需额外的解析步骤。通过这种方式我们减少了内存的使用与 Pb 相比内存节省达到了 50%。同时我们也对写性能进行了测试发现使用 flatterbuffer 后写性能提升了20%
环节3在线推理模型加载流量大
在用户进行在线推理时我们注意到模型下载产生的流量极大有时甚至会占满对象存储网关的带宽。深入分析这个场景后我们发现存在众多实例每个实例都会独立地将完整模型加载到内存中并且这些实例几乎是同时开始加载模型的这一行为造成了巨大的流量压力。
为解决此问题我们借鉴了商业解决方案采用了在 Pod 中实施逻辑分组的方法。在这种策略下每个分组仅从底层存储读取一份完整模型而分组内的各个节点则读取模型的部分文件并通过节点间的数据共享类似于 P2P 方式来减少总体流量需求。这种方法显著降低了对底层对象存储带宽的占用有效缓解了流量压力。 03 技术规划
libc 调用绕过 FUSE 内核提升读写性能 下面这份图表来源于 ACM 期刊中的一篇论文。文中指出在使用 FUSE 挂载时请求的处理流程会先从用户态转移到内核态然后再返回用户态。在这个流程中上下文切换所带来的消耗是相当巨大的。
柱状图较高的部分代表原生的 FUSE而柱状图较低的部分则代表经过优化的方案。
小文件场景原生的 FUSE 相较于优化方案其上下文次数切换的数量差距达到了 1000 倍大文件场景原生的 FUSE 与优化方案之间的上下文次数切换的数量差距约为 100 倍混合负载场景同样显示出了巨大的上下文次数切换的数量差异。 在论文中提到链路消耗的主要来源是上下文切换。因此我们计划在 FUSE 这一层进行优化主要针对元数据和小文件场景。目前我们正在进行方案选型工作。
自研元数据引擎文件语义下沉
我们还计划开发一个自己的元数据引擎。当前我们使用的元数据引擎是基于 TiKV 的但 TiKV 并不具备文件语义所有的文件语义都是在客户端实现的。这给我们的特性开发工作带来了极大的不便。
同时当多个节点同时写入一个 key 时事务冲突也会非常频繁。近期我们还遇到了进程会突然卡住的问题持续时间从几分钟到十几分钟不等。这个问题一直未能得到解决。
另外TiKV PD 组件为主节点 Active 模式请求上 10 万后时延上升明显PD 节点112核CPU 使用率接近饱和。因此我们正在尝试一些方案来降低主节点的 CPU 利用率以观察是否能改善耗时问题。我们参考了一些论文如百度的 CFS 论文将所有的元数据操作尽量变成单机事务以减少分布式事务的开销。 缓存层实现 RDMA
通信关于我们机房的 GPU 节点它们目前使用的是 RDMA 网络。与缓存层的通信仍然使用 TCP 协议。我们有规划开发一个基于 RDMA 的通信方式以实现客户端与缓存之间的低延迟、低 CPU 消耗的通信。 通过观察客户端的火焰图我们发现 RPC 通信的耗时仍然非常明显。虽然写缓存的处理数据只需要一两毫秒但客户端将数据上传到整个链路的耗时可能达到五六毫秒甚至十毫秒。在客户端 CPU 非常繁忙的情况下这个时间可能会达到二三十毫秒。而 RDMA 本身并不怎么消耗 CPU内存消耗也比较少因此我们认为这是一个值得尝试的解决方案。
