在早期阶段,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 API,Spark 可以直接处理这些数据。模型文件也保存在轩辕中,并通过其提供的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,内存消耗也比较少,因此我们认为这是一个值得尝试的解决方案。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。