大家下午好,我是来自OPPO存储技术组的胡瑶今天我跟大家分享的主题是云烟生存储库牌FS助力AI加速我将会从下面四个方面来进行分享首先是库牌FS的一个基本介绍然后是在这种大模型应用的存储的一个需求和挑战第三部分我会介绍库牌FS在OPPO的一个大模型存储的一个实践以及库牌FS未来的一个规划库牌FS是一个新一代的云烟生开源的存储产品它托管于CNCF目前是处于孵化阶段也很高兴地告诉大家我们在今年已经提交了毕业申请也在和CNCF的TOC成员一起来推动库牌FS的毕业它是国内首个具备完整的文件存储和对象存储能力的系统在我们的官网上我们也提供了库牌FS的一个代码解读以及它的一个应用实践大家可以去官网上查看这里我们讲一下库牌FS的一个发展历史它是在2019年的3月开源的在2019年年底的时候我们成为了CNCF的杀伤项目在2022年的7月我们成为了它的一个孵化进入到孵化阶段然后在今年的8月我们提交了毕业申请在整个2023年我们对库牌FS做了大量的一个优化和改进以及功能的一个加强包括它的一个审计日制目录配额以及PorscheX接口的原子信等方面以及通过我们在线网环境的大规模的运营经验我们也对整个库牌FS产品的稳定性做了很多的一个优化以便大家可以更好地去使用我们来看一下库牌FS的整体架构首先是像左上方这一块是它的一个多协议客户端客户端支持这种基于Fuse的一个文件系统挂展同时它的Object node能够支持S3接口同时我们也能支持Hadoop的一个HDFS价包然后第二部分是它的一个资源管理指系统我们也叫MasterMaster是维护整个集群的数据节点和原数据节点的心跳以及它的一个容量信息同时Master指系统也会维护整个集群的一个拓虎结构以及它的卷信息和数据分辨和原数据分辨Master是由多个节点组成通过LOV的协议来保证它的强一致以及高可用第三部分是它的这个左下方这一块是它的一个原数据指系统原数据指系统是采用节点到分辨再到文件的I know的Denture的方式来管理右边的话右下方是它的一个数据指系统数据指系统包括了它的多副本引擎和它的九三马引擎我们再来看一下CoopFS的一些关键特性第一是它的这个多协议的客户端支持并且它能做到不同协议间的一个数据互通也就是说我通过对象存储把数据写下来能够以文件挂载的方式去读取以及它的一个多引擎刚刚也讲到它的数据指系统是由多副本和九三马两种引擎第三是它的一个多诸护管理这里要说到就是有一个卷的概念卷在文件存储上是对一个卷是对一个文件系统在对象存储场景的话一个卷则是对应它的一个统通过我们在创建卷的时候要指定它的一个诸护ID这样一个诸护能够管理多个卷我们通过卷的一个隔离性数据和原数据的一个隔离性来保证了这个诸护间的一个隔离还有就是它的一个高扩展性高扩展性的话表现在我们的这个数据节点和原数据节点都可以进行水平的扩展并且通过增加节点能够线性的提升我们的一个IOPS和它的一个吞吐能力还有它的一个多级缓存我们提供了两级缓存其中LEcash是在客户端本地的一个本地盘和它的一个内存LEcash则是通过这种SSD的多幅本卷来加速它的一个纠三马冷卷还有它的这个高性能高性能主要表现在因为我们的原数据是采用全缓存的形式也就是说你去读取原数据的时候是不需要从尺半读取的所以它的一个实验会非常低同时前面也讲到这种多级缓存的方式能够提升我们整体的一个性能还有我们在对大文件和小文件是采取不同的方式存储这种也提升了我们整个的一个存储集群的性能最后是它的一个云元身特性我们通过CSI能够很方便的在K8S上部署我们的KubeFS集群下面我们来重点讲一下这几个特性多协议客户端多协议客户端前面也说过了我们支持S3 POSIX接口以及HDFS内部我们是通过一套统一的SDK来共享它的数据和云元数据这样就能做到只需要一份数据能够在提供给多个应用来使用避免了它数据的一个重复利用同时我们在这种数据混就是混合应用的一个数据存储上我们通过它的一个珠户集的QAS来保证了不同应用之间的它的一个IOPS的带宽能够最大化利用通过上面的这些设计的话使得我们数据能够在整个客户端能够更高效的以及生态互通的方式进行共享和存储下面我们再来看一下它的元数据指示系统元数据指示系统也是整个QoOFS的最核心的设计像一般的文件系统的元数据组织方式都是采用静态指数像HDFS以及7FS的这种组备模式静态指数存在的问题就是在这种单点的一个瓶颈在文件不断增多的情况下比如达到了一个比如说11到21的一个规模它的一个元数据系统就会成为整个集群的一个瓶颈导致它的一个访问性能下降所以说在设计整个元数据指示系统的关键就是我们怎么均匀地把文件的元数据打散在不同的元数据节点上下面我们来介绍一下CubeFS是怎么来实现的右边这个图的话是整个CubeFS的一个元数据组织方式它是通过元数据节点以及元数据分辨和文件的iNote的灯垂这种三层的一个管理模式元数据分辨我们在创建元数据分辨的时候会较均匀地打散到不同的节点上同时我们在Client在创建文件的时候会去创建iNote的我们也会以一种轮寻的方式保证整个不同文件的元数据是落在不同的分辨上这样的话在每个元数据分辨上的文件iNote是相对均匀的同时在所有的节点上它的元数据分辨也是相对均匀的所以整个集群的iNote则是相对会比较均匀同时我们在扩容的时候在扩容一个元数据节点的时候我们会新创建的元数据分辨也会被分配到这个新的元数据节点上这样保证它扩容以后的一个数据性能的一个线性增长第二点的话是它的一个强一致每个元数据分辨我们都会维护一个love的实力当文件被创建或者修改的时候也就是它元数据发生变化的时候我们是通过love的协议来保证它的一个高可用和强一致在可靠性方面元数据分辨的数据我们是采用这种快照加love的日致的方式来进行本地化存储这样当一个节点发生故障进行恢复的时候我们首先是去加载它的一个快照然后再去重做它的love的日致这样就可以恢复整个权量的一个元数据了在高性能方面每个元数据分辨它都会维护一个I know的去和它的一个denture去并且I know的去和denture去都是以全内存的这种方式来保持的每个denture的话它会对应一个复募路的ID以及它的一个文件名通过这两个我们能够索引到它的一个文件然后我们在做目录便利优化的时候我们的思路是将文件的denture我们前面已经说过了它的I know的是均匀的打审在不同节点上但是denture的话我们是会保存在它的一个复募路I know的所在的分片上这样我们去做目录便利的时候就只需要发起一次请求到它的复募路I know的分片就可以拿到完整的目录下的文件信息而不用去便利整个集群通过以上的这些设计的话保证了我们整个原数据指系统的一个可扩展以及它的强一致和它的一个高可耗和高性能我们再来看看数据指系统数据指系统的话是包括多副本引擎和纠杀马引擎这里是多副本引擎的话它又包含了多种协议顺序协我们使用的是这种主重复制协议主重复制协议的好处是它的副本只需要写它每个副本都只需要写一次避免了double write的问题在这种大文件连续写的场景的话它的整个吞吐是非常高的在修改写的场景下我们是使用的larved协议通过larved的高可用以及强一致来保证了修改写能够成功在整个数据的组织方面也是采用三成的方式数据节点 数据分辨和extentextent的话其实就是对应一个数据节点本地磁盘的一个文件extent也分两种类型有normal extent和tint extent这里的话对于大文件的话我们是会拆分成多个normal extent每个normal extent的最大大小是128兆然后通过拆分到不同的分片打散在不同的节点上来保证了我们大文件的一个并发独显能力同时在小文件方面我们会将多个小文件以append的方式就是最佳写的方式写到tint extent上并且把我们在tint extent上的一个偏移和大小会记录在小文件的ino的元素据中通过这种小文件的聚合方式的话能够有效地减少整个数据节点上的文件数量来提升它的数据的一个利用率最后再讲讲我们小文件它的一个回收机制小文件的回收是利用了本地文件系统的一个打动机制通过打动的这种方式的话既能够回收小文件的空间同时也不会影响其他小文件的一个位置信息下面是数据指示系统的joshama引擎我们的joshama引擎能够提供高可靠能够提供高可靠低成本的一个在线EC服务它包括以下几个层次一个是它的一个接入层接入层的话是负责数据的一个分片以及它的一个计算同时在这个接入层我们对小文件也做了优化小文件不会被打散到多个分片里尽量是保存在一个分片中这样对于小文件的读取的话只需要一次请求就够了同时我们在这一层实现了它的一个curring机制确保了一个调代中部分的一个分片可能由于节点故障导致无法读取但是整个的调代仍然能够正常的一个读写操作这样的话对整个系统的一个可用性方面是比较好的第二部分的话是它的一个资源管理和调度系统这里首先是它的一个原数据中心原数据中心负责它的一个空间分配和资源管理并且也是通过larft来保证它的一个高可用和强异制那这个后台调度模块的话则负着整个集群的一个数据均匀分布以及它的一个故障制域和它的一个寻检工作第三部分是它的一个存主词存主词存主词的话是底层会存储不同的trunk文件我们会把上层的一个文件会印射到底层trunk的一个一部分中并且通过它的一个单机的logsDB来维护上层文件到底层trunk的一个印射关系同时在这个存主词上我们也做了很多这种可靠心的一个设计包括它的一个本地CRC的教验以及它的一个数据恢复和它的一个寻检功能我们再来看看Josemar引擎的多AZ设计我们提供了多种AZ的一个配置给用户用户可以根据自己的一个应用场景的一个实际需求来进行灵活的选择包括单AZ 两AZ 和三AZ这样当某个可用预议发生故障的时候数据不但不会丢失而且能够正常的一个提供读写的访问能力同时我们也支持多种编码模式像这个RS和它的LRC以及它的一个数据快和教验快的一个配比用户也可以根据自己的一个实际需求去灵活的使用第二部分我们来看看在大模型应用场景下的存储的一个需求和挑战我们都知道现在大模型应用已经是当前的一个乐点而且在不断地去提高我们的一个效率我现在从这几个从整个大模型全链路的一个拆分来看看它对于存储的一个需求和挑首先是原始数据的一个存储和处理阶段这个时候它要求我们的存储系统能够具备大容量同时具备一定的扩展性而且我们的原始数据可能来自不同的上层应用所以也对我们存储系统要求它的能够做到这种多引擎的支持以及它的一个数据的生态互通在这个模型训练阶段因为模型训练阶段的话在大模型场景下它的一个对算力要求非常高以及它的一个训练周期的话是比较长的所以我们需要通过中间的一些checkpoint来存主它的一些中间态的信息这样的话当整个训练如果发生中断的时候就不用去重新开始了所以它也需要我们存储系统的一个读写能力就是整个的一个读写性能要求比较高它需要有像低实验以及它的一个高吞吐在第三块在这个在线推理的话我们需要把这个模型文件去分发到不同的应用上这样也对我们存储系统需要能够支持这种高并发的高并发以及高吞吐的一个读写能力来保证它的一个分发的效率中上所述的话整个大模型的一个训练对我们存储的要求的话有以下几点吧一个是它的一个大规模和可扩展性第二是它的一个生态互通第三点的话是整个这个高性能包括它的一个低实验和它的高吞吐以及由于数据整个的训练周期长对存储的这个稳定性也有较高的要求最后只是我们希望既能够提供一定就是较高的性能的同时也能够以一种低成本的解决方案根据这些存储需求我们也总结了它的一个一个挑战在不同的这个阶段如何做到它的一个数据的一个流通以及在我们在训练的过程中如何加快它的一个文件的这个访问性能以及在训练在训练过程中它的中间态的一个checkpoint我们怎么高效的去把它保存下来还有在整个的这个全链路的流程中如何维护维持一个叫一个稳定的存储系统并且保存它的一个高并发最后则是我们既能够保证一定的性能的同时同时能够给出一个低成本以及数据不会丢失第三部分的话我来介绍一下就是库牌FS在OPPO的AI存储的一些实践在OPPO的话AI存储的整个眼睛过程主要有以下几个阶段第一阶段是使用的SafeFS存储第二阶段使用的是SafeFS和库牌FS混存的方式第三阶段就是使用库牌FS统一存储在第四阶段我们采用的是库牌FS加多级缓存的策略我们先来看一下第一阶段第一阶段的话因为SafeFS它的一个这种主重模式的话MDA主重模式的话前面也说过它是静态指数所以当文件数量达到10亿到20亿级别的时候一个集群的存储性能就会比较差这就导致我们整个的一个训练周期被拉长同时它的一个在这种某个数据级可能文件数量非常多就是大目录的这种场景下在我们再去做目录便利的时候经常会出现这个原数据符的一个OM如果符的OM的话只会导致整个集群对外不可用所以它的一个稳定性是比较差的这个时候我们想到的一个解决策略就是说把一个较大的SafeFS集群拆分成多个小集群拆分成多个小集群后确实在一定程度上它的稳定性是变好了但是多个小集群的话它的一个存储的一个使用率是比较低的同时集群数量过多的情况下对于SRE的一个运为负担也是相当重的第三点的话就是在这种大模型的场景下单个小集群可能不能满足大模型的一个训练要求因此在这个阶段我们也将CubeFS恢度上限来作为一个新的存储解决方案在第三阶段的话CubeFS的一个可扩展性以及它的一个高性能稳定性等方面得到了充分的验证并且满足了我们AI存储的一个需求所以我们在第三阶段我们就采用CubeFS作为整个AI平台的一个统一存储但在这个时候新的问题又出现了就是在这种混合云的场景下首先我们在私有云的话是已经提供了一个相对稳定的一个GPU算力但是在应对一些突发的情况我们也会去采用公有云的一些算力资源但是我们发现通过公有云来访问我们私有云的这个CubeFS首先它的一个机房的网络实验要达到2毫秒这会导致它整个的一个训练周期大概要会有个2-3倍比相对私有云的一个训练所以整个的训练效率是非常低的主要也是因为它的一个性能实验较差的一个原因经过前面三个阶段我们总结了这就是AI存储的一些痛点第一个是它的一个实验敏感性在这种训练场景下实验越低的话它整个训练效率是越高的实验越高肯定整个训练周期就会越长第二是它的大目录的一个特性因为这个训练级的一个不确定性我们一般一个训练级都会保存在一个目录下面所以说它的训练级不确定性的话可能这个目录下的文件数量会非常的多以及我们要支持多个训练级任务的时候他们可能会共享的去用到同一个训练级这样也会造成它的一个热点目录以及我们前面提到的在混合音场景下的一个跨机房访问的一个一个实验较高的问题那么我们看一下CubeFS是如何解决以上的几个痛点前面我们已经提到了就是我们整个元数据是采用全内存的方式而就是你在访问的时候是不需要去持判读取的所以它的一个元数据访问的实验是非常的低第二我们的元数据设计本身就是一个全节点的所有节点的一个均匀打闪在这种热点目录的场景下其实它的访问也是打闪到多个节点上的而不会像静态指数那种只会所有请求都会发到一个元数据节点上第三点就是我们做了这个目录便利的一个优化保证了所有的文件的灯穴是存在它的一个负目录的I-Note的这个节点上面这样你的请求你的便利请求就只需要发到只需要发一次就能拿到全部信息了通过以上的一些设计的话整个CubeFS的元数据单目录的话可以支持到这种千万的一个级别然后单级群的话可以支持到这种百亿的一个级别我们再来看一下CubeFS它的一个多级缓存策略我们提供了两级的一个缓存而一开始是客户端的一个本地盘和内存本地盘是负责这个数据的缓存内存责负责元数据的缓存我们通过LECash会在AI训练的时候因为AI训练有个特点它就是对同一批数据集反复的读取这个时候我们通过LECash可以把这个数据集的数据和元数据都缓存在客户端本地所以它的整个一个训练效率是非常高尤其是在这种前面说的这种公有云的痛点上面因为数据已经在公有云它的客户端本地了这种跨机房的这种访问 评次将会下降所以整个公有云的一个训练的一个性能得到了一个较大的提升然后LECash就是下面蓝色的部分它是一个全局的一个缓存我们通过这种SSD的多副本卷来对它整个底层EC冷卷的一个缓存加速这是我们对比了开了缓存加速以后的一个性能收益可以看到图中这个公有云场景下它的一个训练效率提升了两到三倍跟原来相比在即使和私有云的训练比的话也提升了17%左右下面介绍一下我们新的一个缓和存储方案在这个新的缓和存储方案里我们会将整个存储资源进行抽象抽象的资源包括公有云的资源私有云的资源以及它的一个多副本和EC引擎的资源同时包括它不同的存储介制的一个资源我们通过一个统一的虚拟文件程来统一管理所有的资源在这个数据智能分成方面我们是以卷的力度来配置然后在整个数据迁移的过程是以文件的力度来进行迁移的我们也用户提供了一个生命周期管理功能用户可以自定义它的一个生命周期管理策略来实现数据的一个链式降冷同时当请求在这个缓存在读取数据的时候如果缓存未命中的话系统也会一步地将这个数据从冷卷中迁移到它的一个缓存程上面最后再来介绍一下整个QubeFS未来的一些规划首先是在应用方面的话我们会在手机端进行QubeFS的一个挂载来解决用户的一个手机端一个存储容量不足的这个痛点然后在混合音方面我们已经实现了这种多级缓存同时我们也会做进一步的一个眼镜和优化以及在这个相量检索方面我们会对元数据元数据只是一种去做存购来支持它的一个相量数据库性能方面的话也是针对整个AI场景下我们会做这个数据从GPU到存储的一个直通来提升它的一个性能这也要求我们要支持内核态的一个客户端以及RDMA也通过RDMA我们可以有效的降低CPU和数据拷贝的一个开销再来看一下架构优化方面首先前面说过我们元数据采用的是全缓存的方式但确实因为在这种百亿级的存储上面内存还是相当昂贵的这种全部缓存在内存里面的话成本的要求是比较大的所以我们也考虑采用部分缓存的方式加元数据存储在这种单级的存储引擎上然后以这种缓存的形式提供出来第二是把会将这个多副本引擎跟就三马引擎进行合并现在是两个独立的一个直系统第三部分前面说到了原数据直系统的重构来支持它的一个项量数据库的一个接口在医用性方面的话我们支持了dashboard的2.0增加了很多可视化的功能包括部署的可视化和数据迁移的可视化以及在我们的官网3.0版本我们会支持这种大模型的问答用户可以就是可以自行去去我们官网上去提问会有AI去做相应的解答同时我们提供了一个迁移数据链来负责跨集群的数据的迁移最后我们再来看一下整个我们的官网以及github地址还有slag地址左边是我们的一个微信公众号基本上每周都会有一到两篇的发文像有原码解读的有这种应用实践的一般多个厂商像小米还有网易OPPO京东都会有相关的一些应用实践的发文右边的话是我们的一个微信小助手他会拉你们到我们的运营群里面在运营群里面能够做进一步的一个沟通和交流就这样谢谢大家你好我有三个问题第一个问题是我看这个QFS它就是你们内部还要做这种EC吗这些但我理解的是面向运营生的话其实它后端的Block device其实都已经提供了这种副本或者这种很可靠的存储在我看你来好像这个不知道你们是怎么考虑这个问题的就从价格上来设计第一个问题第二个问题是我们有没有一些性能数据来看一下我们做大模型训练的时候它能达到的一些带宽的我理解应该主要是带宽的一些要求对吧第三个问题是我看这个原数据的设计里面我们用的是多分片里面应该是用QV存储的对吧目前是没有用QV存储目前就是全缓存是以B数的形式缓存在内存力的但是它因为有多分片就会涉及到做一些比如说性命啊这种操作它其实是本质上需要一个操作需要涉及多个节点对吧对所以这里面可能会涉及到一些分母式事物的一些对 所以我刚刚提到了我们今年已经增加了Rename操作的一个Porsche接口原子信通过事物来保证的OK那正常的比如说你创建一个文件其实它在这种价格里也涉及到的分母式事物因为你要在一个点上创建一个Anode在另外一个点上创建一个Denture是的但是在这种情况下因为开了事物的话它其实对性能是会有一定选号的对啊在这种情况下其实即使出现了一些不一致的问题因为我们经过先往那些运营发现确实这种情况也有可能比方说在Client的故障或者说是网络中断的一些情况下可能你写完了一个Denture然后你的Anode没写成功但这种环境这种情况只会有数据残留不会导致用户的一个使用上的一个问题我们也做了这个保证我们的Porsig接口的原子器你可以看看它的一个特性它是一个开关可以对整个卷卷设置它的某一个操作以及所有的操作我们建议是把Rename这个操作打开因为Rename一旦出现了不一致的情况很有可能它的数据的数据元素和数据不一致的会导致你的读写问题对但在其他场景下目前我们还没发现这个问题你可以灵活地打开和关闭都可以了解然后你刚刚说的那个性能问题的话我们在官网上是有它的一个性能测试的这个数据的但是在大模型的这个数据的话可能现在现在我们好像还没有提供出来如果你感兴的话可以去我们的这个github上提一个英雄我相信会有我们会很快地去把这部分的数据拿出来好的谢谢对然后第一个问题就是那个面向的这种云烟圣的存储我不知道就是QBFS后面会有这种考虑吗因为我理解好其实这种很多这种功能可能都在这一层是不需要实现的是这样的我们虽然是可以通过CSI在这个就是可以在QBIT上部署但是可能有很多其他场景下我们也就是直接就是在物理就是没有没有经过QBIT来部署的这种场景我们也要考虑它的一个这个多引擎的一个支持好谢谢可以用英文问吗我英文回答不来如果我能听懂的话可以你可以用中文会问题是what happens when the note breaks offhow do you reconcile the datawhen is it actually written to this你知道我的意思吗有人可以帮我问吗谁能翻译一下我好像没听懂好 良心when is the data written to thisand what happens when the notewhen a QFS note breaks offthe cluster或者你方便可以通过slack来进行一个进一步的交流也是可以的那我先提个问题就是刚才提到这个Pattles和这个后面是加这个Qubes Fs这个是Pattles里面就已经有的吗我们需要做一些配置还是需要再做一些其他工作可以这样用的前面讲了什么就是Pattles然后后面是接这个Qubes Fs这个是Pattles里面就已经做好的呢还是说我们需要做一些额外的配置你是说大数据的那种场景吗还是你前面讲AS训练的时候不是是用Pattles然后后面不是是接这个Qubes Fs它应该是以本地的目录的挂载的这种方式你看到了其实是个本地目录所以相当于是把这个Qubes FsQubes Fs付出好然后呢对对对也就是说Pattles对它是无感的对吧对对对Pattles看上就是文件目录对对就是一个跟本地目录一样的一个目录好谢谢