大家好 我们这个 我们的分享开始吧感谢今天在Coopercount的这些听众已经到下午最后一个话题了然后我是来自JuiceFest这个项目的合伙人苏蕊然后JuiceFest是一个面向云环境设计的分布式文件系统然后因为这个文件系统也在被很多AI场景的用户在AI训练 还有模型加载推理的场景去使用所以我们也积累下来了一些实践经验然后今天在这个话题上是想跟大家分享一些我们最近两三年在AI场景越来越流行的时候经常被问到的一些在存储 选型以及对于性能的一些问题还有大家的一些纠结的地方然后这是今天会提到的几个方面就是说我们会讲一下在AI上的背景挑战然后包括一些存储 选型的方案以及我们自己在性能问题上的一些看法实践和设计的一些思考对 还有一些实践的案例吧对 首先 AI是我们可能从2019年开始看到国内深度学习激活了计算机视觉也就CV领域了很多的应用当时最火热的应该是两大类一类是人类识别 加上自动驾驶然后就发现CV领域的数据级在快速地长大那我这里列出的开放的数据级其实才500G 900万张图片但我们实际向自动驾驶客户他们自己要管理的数据级单个的训练级可能是几千万小图片然后整个的数据一般会在50亿到150亿之间所以如果之前维护过一些存储系统的知道海量小文件在这个量级一直是存储系统非常难受的地方然后那最近可能一年左右的时间在大语研模型上也发展很快比如说GPD3它的原始的数据才45T还比较容易搞定但是到了GPD4做多摩泰的时候迅速扩张到EPB而且这还只是原始的数据级然后在它训练过程中其实你要持续的每隔一段时间要把你现在所有显卡显存的状态作为一个checkpoint存下来这样好让我整个集群出现一些故障的时候我能从最近的一个存盘点能够加载这个存档那个checkpoint的数量其实也非常大所以我们看到就是说数据级越来越大模型也越来越大checkpoint也越来越大所以这些长大其实就让我们在训练的环境里面单基存储基本必须变成了一个分布式存储单基的训练也就都转为了多基的训练对所以放在存储上的挑战我们觉得就有两大类第一类就是前面提到尤其在CV领域非常明显的就是海量小文件带来的挑战然后第二点就是说是存储系统吞吐性能在训练场景上的一些不足和平静如何解决那在今天的分享里第一点其实就不展开谈了我们重点来讲第二点因为每一个话题其实都得讲好长时间所以今天重点来讲性能不足的问题所以在性能不足的问题展开之前先要看在模型训练的这个过程中我们存储上面的选型大家肯定先面对的是这个问题只有选完型才能针对你的选型才遇到接下来的规模的问题和性能的问题所以我们今天在整个存储所有的产品里能看到的就这三大类就是框存储对象存储和文件存储框存储其实就是我们单机的硬盘那放在云环境里应该就是云盘比如说AWS上叫EBS国内的公共云一般会叫云盘然后我裸进数的物理机上也就是我SSD NVME的这些裸盘都是框存储那它最大的特点是说我是一个单机的盘不能过多机共享想共享的话你肯定要搭一些NFS的网关之类的才行那它的好处它是POSIX接融这已经是我们系统最原生的使用方式了对 放在Linux里面就是本地盘的使用体验放在所有的编程语言里都有原生的系统调用的API可以用你也不需要学习新的SDK但是这些单机存储的问题容量有上限就是我单块盘的容量肯定不能无限涨所以就没法满足我前面说的数据级越来越大的问题然后实验实验是最低的因为它就是一个裸的设备中间软件层加得非常非常薄所以如果对于一些低实验的需求那可能框存储还是你的最佳选择比如说交易型数据库比如说我的Oracle MySQL基本都还是一定跑在框存储上的然后吞吐其实我每一块盘能提供的吞吐上限是固定的它并不能有一个很理想的扩展那对象存储其实是从公共云出现以后才出现的新的形态在公共云之前其实没有这个形态存在那最有名的像公共云的服务就是S3那所有的公共云里一定都有对象存储的服务要开源的也会有像Miaio然后像Safe的RGW这样的开源项目可以选择那今天其实随着S3的越来越流行的这样的一个趋势其实我们面向很多开发者尤其是我们更关注业务的时候可能不太会详细地区分对象存储那和以前的NAS或者说分布式文件系统有什么区别对 那这里我们先把这些点先不完全展开像文件存储的话就像以前我们买的EMC、NetApp或者华为、OSISOL都有这样的NAS的产品都可以算作文件存储那在公共云上也有像EFS这样的产品然后像SafeFS是开源的那它可能相比块存储的好处是我可以多机访问然后仍然提供了POSIX接容然后我再如果是一个云上的文件存储还能提供一些弹性的能力包括容量的弹性吞吐的弹性对 但能看到它的实验已经不是最低的了对然后那文件存储相比对象存储有一个很大的不同就是在POSIX接容上对 S3所有的对象存储一定是基于一个HTTP API给你去访问那可能你可以直接访问API也可以用一个SDK然后方便你编程然后也会有像SFS像Goofy这样的开源项目它可以把你的S3的一个Bucket挂载成一个像本地盘一样挂载到你的机器上但使用起来体验不一样这个体验的差异在哪呢其实就来自于说这也是大家经常搞不清楚对象存储和文件存储到底有什么不同为什么有功能和性能上的不同所以在这里我画了一个比较形象的图在对象存储里面如果我打开一个命名空间它叫Bucket非常形象它就像一个桶你所有的对象就像这样都往桶里扔就行了它们之间没有任何结构没有相互关系随便扔对但是文件存储不一样我一定是以多层文件家的格式要组织我的文件家和文件我是有一层一层结构的所以展开是一个数这颗数在文件系统背后的实现里它也是一个类似的数据结构它要保存这些节点之间的关系所以它就会带来一些特性上的区别比如说在Palsix的所有的API的定义里其实是为这个结构去设计的比如说我SL列目录我是可以按照数形结构做便利的放在对象存储这边我想做一个便利的时候其实没有任何结构可以帮助我所以对象存储会做一件事就是把这些对象的名字建个锁引然后当你真的想便利的时候我就去锁引里做一个搜索它没有数据结构我就是按照搜索引擎一样去搜索所以性能可能会和文件存储之间一般会差一百倍是正常的然后还有一些结构就会比如说在对象存储里不能做追加写不能做覆盖写然后也很难做预读包括目录便利性能会大概应该是文件系统1%左右吧然后不能支持原子的改名这个原子改名是什么呢在文件系统里我们知道有用mv直接改一下目录的名字放在文件系统里如果我想把这个目录改个名字的话它会按照数据结构直接找到这个点所在的位置把名字改掉就OK了但是放在对象存储里的时候没有这个结构那所谓的目录名其实是我们所有对象那个key的前坠那也就是一个字幅创的前坠所以那如果我想在对象存储里做一次改名的话那我就要把所有的对象做前坠搜索找到所有符合这个前坠的那些对象然后呢把它们用新的名字考备一次这里要真的发生实际待遇考备所以你的改名动作有可能搜出来了一万个对象他要把这一万个对象真的复制一遍用新的名字然后再把旧的删掉这是对象存储里的改名的一个行为它就会和文件系统里有一个非常质的差别对那这些不同其实就会带来说它适用的场景不一样比如说对象存储是非常适合海量数据归党然后我要对单个对象做一些点查所以这也是我们看到对象存储最开始发布的时候它只有Gate,Pute,Delete这三个最简单的APIPute就是我要上传Gate就是要读一下对那比如说最早去它最早的创建是说想满足我们在互联网上用户创建的各种的内容比如说大段的文字图片视频这些我要做一个海量数据的存储我要有足够低的价格我要有足够强的横向的扩展的能力那对象存储是非常适合的但是当你想把这些海量数据想以一定的结构去做更多样化的计算的时候对象存储就会显出前面说的一些性能的问题甚至包括编程语异不接容的问题这时候就更需要文件存储来满足我们的科学计算AI的训练然后也包括一些大数据的ETL或者数仓的分析其实都在这样的一个适用范围内这也是说比如说在大数据的生态里面最早大家都用HDFS其实它也是一个文件系统是右边这样的结构设计的可能大家从HDFS如果直接换到对象存储的时候也会遇到一些不接容的问题和AI领域是非常相似的所以这样就在这样的一个选行里我们觉得在AI模型的训练上面快存储受到单盘容量和吞吐性能的限制已经不太适合今天越来越大的数据级和越来越大的模型了对象存储虽然在扩展性容量这些问题上足够强但是它又不太适合对这种复杂数据级去做计算分析的场景所以文件存储可以看到AI流行之后文件存储又迎来了它的新的蠢贴所以CIFFS还要包括相处CIFFS这些都在最近一年多其实变得更流行了很多然后在文件存储展开一下它其实也有一个非常长的历史发展的脉络最长的第一代产品我们看到的是像EMC、NetApp还有今天可能买到的很多存储的柜子这个产品的形态大概诞生在90年代然后当时都是以软硬件议体的方式出现的所以它也依赖于特定的硬件然后配合着一些软件去做今天碰到的问题就是它仍然能提供不错的性能但是在扩展性上其实带来了一些平静第一个是在它的硬件设计架构上可能它有一些单极群规模的上限比如说一个极群是支持16节点32节点还是128节点通常是有一个上限的它的横向扩展能力不是无限的第二是当你必须要软硬一体采购的时候它的供应链周期确实会变得更长因为你可能会涉及到一些运输的问题或者说个别一些硬件缺货的问题甚至包括说一些厂商的产品可能你不再能够买的问题所以第一个就是大概在2005年Google发了它的Google Fail System那篇论文然后也第一个提出来他们如何在标准的X86硬件上面构建了自己的Google Fail System第一次告诉世界的开发者说我们把软件和硬件彻底分离了你可以用最标准的硬件加上的软件这样能管理超大规模的极群而且这个规模远远大于以前软硬一体的方案在这个2005年的论文之后其实就有了一批第一代软件定义存储的分布式文件系统的开源实现比如说依照Google论文的最著名的实现就是HDFS也是解决大数据领域的那同时还有像Seth, Glaster, MooseFS还有当时那一代的并行文件系统比如说Laster, BGFS还有对这些项目基本都是在2005年到2010年这五年的时间窗口里诞生的都是想解决把软硬件去解偶对,然后它其实有一个时间背景就是当时是快带互联网流行在全球范围内流行之后其实数据量在快速的膨胀所以以前软硬一体的方案也很难再满足互联网的这个数据规模了但是这一代文件系统其实都有一个自己共同的特点就是当时都是面向机房设计的面向物理机设计的因为那个时间点根本还没有云所以今天到了公共云之上我们仍然可以把这些项目在公共云上开迅速机挂数据盘把它们部署起来但是无法用到任何云的弹性的能力然后可能它跟云上提供的一些计数设施的匹配度也不太那么契合了对,这是有它诞生的一个背景的所以我们从17年开始做这个项目就是想在云环境上面向云能提供的计数设施和云需要的能力设计一个更适合云环境的分布式文件系统然后同时它应该具备的一些原来文件系统具备的基础的特性比如说你的PulseX兼容的访问特性还有强一支性同时也应该有一些云上要求的能力比如说我要能弹性伸缩你像CfHDFS这些一定是有手工扩容的过程的对,然后我仍然希望能够继承像对象存储一样的便宜的价格OK,那在这个文件系统的几种不同的方案介绍完之后我们再提一下说iO的在AI训练里iO平净怎么产生的其实在存储系统里面那你所有的性能一定是底层的硬件先支持的我们比如说NVME的盘一块盘能够提供3GB的最大的读写带宽这个是硬件的封顶了对,所以我的软件写破天也超不过这个数字那我要能做的只是在分布式系统下如何尽量接近这个数值把更多的盘的聚合性能够发挥出来那这个图画了一个简单的分布式的系统我三个大个方块代表三个节点然后里面代表每个节点挂了两块盘然后在里面的方块三件代表数据所以在一个分布式系统里通常写一个数据可能会有三个副本为了提升这个数据的可靠性和可用性我写了一个圆圈有三个东西存在了三个不同节点上那这时某块盘坏了不会影响我的访问数据也不会丢,对吧但我想访问这个圆圈的时候性能谁提供呢一定是圆圈所在的这块盘提供的对,但这块盘不可能只存圆圈还要存三几二方块所以大家都去访问这些数据的时候那一块盘上的不同数据肯定要分享这块盘的性能所以那我一块盘比如三Gb的吞吐我要分享给所有上面的读的workload那就可能说遇到我的吞吐不够了能解决什么办法呢加更多的盘非常直接加更多的盘为了什么呢为了把这些数据更分散的放在不同的盘上这样的话我才有机会用到更多盘的聚合的吞吐能力,对吧那我把三角挪走了这个盘上只有圆圈了那就说明这块盘的性能我可以是不是都给圆圈当然实际过程中没有这么单纯但是它的逻辑是这样的所以我们会碰到在机房里面搭建一个分布式文件系统的时候我们会碰到一些客户当它有数据热点的时候它会告诉我我的存住系统容量还有很多但是吞吐不够用了所以我要扩容我要加更多的盘不是为了扩展容量是为了扩展吞吐对,比如说在量化投资的领域还有一些领域它的数据热点问题是非常明显的就是我的数据总量不大但是我上面的计算节点非常多大家都要读这份数据咋办呢盘不够为了性能加盘而不是为了容量对所以在这样的一个方案上也就是其实上一代像Self HDFS包括我们的并行文件系统比如说GPFS、Laster都是用这样的一个逻辑去做了,设计了自己的系统所以它有了一个问题就是我的容量和性能是绑定的所以甚至你在公共云上去看所有的文件存储产品比如说AWS的EFS比如说阿里云的NAS比如说各个公共云的产品你都能看到它有一个指标规格告诉你我的吞吐性能是每Gb容量提供多少吞吐或者每Tb容量提供多少吞吐那这个逻辑都是来自于这个就是你有了容量我才能分配给你更多的真正的盘这些盘的吞吐才能分配给你的访问所以这就是会给AI训练这种计算密集型的场景带来一个我IO平静的问题可能就是我的数据其实数据容量有限集中在了有限的盘上或者说我的计算的这个负载不断地增强早早超过了我现在现有的这些盘能提供的能力那怎么扩容呢所以这就带来了这个问题就是我更多的盘虽然能够提供更高的吞吐但是一直加下去的话为了提供这些吞吐我还要都用最快的盘对吧买最贵的盘为了提供的是性能但是它没有多空着没有容量所以那在今天AI这种算力越来越强的情况下我会不会买不起这是一个现实问题第二个是我做扩容的时候就像上面这个我要把三角从这块盘上搬走这并不是特别轻松的一件事情因为在这块盘上有非常多的计算负载然后我想把一个数据搬家其实也是有负载的它也要增强我其他计算的负载所以搬家这个事情可能会影响到你真正的计算业务所以那负责维护存储的运萎最头疼这个事情它就要很认真的选择时间比如说半夜大家都下班了没有任务跑的时候它才得起床干活做数据迁移还要保证你第二天大家上班之前迁移完因为这个过程它要做数据的打散重平衡的过程对所以它不是一个简单的工作所以在这个容量和性能有矛盾的时候我们今天看到目前的用户很多会选择用两套系统组装在一起这是一个无奈的方法就是我越来越大的所有的数据可以放在一个便宜的对样存储里然后哪个部分要用我再把它搬到一个高性能的文件存储里对那前面的文件存储提供高性能后面的对样存储提供一个便宜的海量容量但我要付出的代价就是要在两个系统里来回搬家然后更尴尬的是当你的真正业务团队越来越大的时候他们每个人都需要更多的他们都希望能够占占有更多高性能文件存储的空间所以你告诉他空间不够了谁能删点我不能我也不能对 谁都不想删对吧谁都不想下次用的时候还得搬要等那个时间所以就很无奈然后另外你看用户的workload可能也起伏不定对那我们没有办法按照这个弹性的workload去帮他规划资源去匹配高性能文件存储的容量我按最大指固对这是在这种系统下做容量规划唯一的办法我只能按最大指固因为我的文件系统没法弹性扩容我的扩容可能是若干小时甚至天级别的对所以在这种情况下那我的高性能文件存储的容量规划也一定要留足够的buffer还是仍然有不少成本的浪费所以就是SFS自己在这个问题上我们自己看到以后如何解决呢就是这是我们的一个架构设计能看到我们作为一个云上的文件存储首先你得提供一些文件存储的基础能力比如说我支持Posix HDFS S3这三种存储领域最流行的API他们都完全接容而且互通互通的好处就是你上面对接用哪种API写的程序签到这套系统里都不用改代码直接搬上来就可以了然后包括像和 Kubernetes的结合我们也提供了两不同的方式去在里面使用Hospass CSI、Setcar都可以适用不同 Kubernetes的部署方式然后第二点在数据存储和原数据引擎上这是分布式存储的两个重要的最核心的组件其实它也源自于当时Google File System那篇论文在这个图里表现就是我的数据存储是右下角的虚纤框原数据引擎是左下角的虚纤框那我两边其实都做了一个插件式的插拔设计那因为在开源的社区里面我们希望这个系统的定位是以最低的学习使用和维护的门槛提供给用户但是在我们开源之前我们有三年商业化的过程所以我们就发现文件存储支持的业务场景特别丰富但是不同的场景下大家对规模性能、成本、可靠性、可用性的要求排序都不一样所以我们认为在软件工程领域真的没有银带能靠一个设计搞定所有的场景所以大家也能看到说为什么在存储产品上有五花八门的那么多型号也是说背后可能有不同的硬件不同的软件优化想支持不同的场景那JuiceFest希望有一个插件式的方式让你能结合场景还能结合自己的一些使用经验去做一个插件式的选择那首先两边分别介绍一下像数据存储的引擎的部分在上一代的分布式文件系统里大家都是面向物理机和裸盘设计的所以你要先写一套系统把这些裸盘管理起来管理好他们的状态管理好你的数据副本怎么放置然后有盘坏了怎么做迁移怎么做恢复但这件事情在公有云上已经被对象存储做得非常完美了我们也不想重复造这个轮子所以我们既然主塞Fest是一个为云设计的分布式文件系统所以我们在数据存储引擎上直接用云提供的对象存储服务或者说在机房里你也可以搭建一个对象存储服务有非常多选择我们目前也都已经支持了三十多种接近四十种不同的对象存储了对所以这样的话应该可以更方便的适配用户现有的一些基础设施对象存储之间我们认为也是差别非常小的我们把它们都看成一个可以弹性伸缩的海量硬盘就像我们买的那块硬盘一样但是这块硬盘我们平时怎么写数据呢肯定是先放在操作系统里格式化一下格式化的过程就是要给它建立一个分区表在这个裸的物理设备上去提供一个管理数据的方式就是对用户来说更便捷的方式那这张分区表就是我们的原数据引擎它管理了文件系统里面的目录数的结构文件名、时间戳、权限这些信息方便你能够用Palsix或者HDFS这些API更方便的访问那在原数据的引擎里面呢我们仍然提供了不同的选择比如说有Redis、关系型的数据库有分布式的KV然后也包括我们在云服务里还有一个字眼的目前没有开源的引擎可能有十几种不同的选择然后那在上面客户端的话就是如何去支持好各自不同的访问协议那社区的版本我们是在三年商业化的验证之后21年开源的然后我们经过18个月发布了1.0的版本也是一个LPS的版本会有做24个月的维护然后呢又过了13个月我们刚刚这个月发布了1.1也是一个新的LPS版本对 目前在GitHub上还算比较流行可能是分布式文件系统这个细分领域内最近两三年全球最流行的项目了然后那同时1.0和1.1是两个双LPS版本的这个维护的方式就类似GoLang的社区因为我们整个项目也是GoLang做的开发OK 那在这个图里其实仍然没有回答前面说我们怎么解决L平静的问题我们希望的是把容量和性能解有对 那前面又有一页说我用对象存储做了底层的存储那能快吗大家对象存储的想法是说海量便宜但不快那这里个解有的方式就是我们希望在更靠近计算的客户端提供一个透明的catch层用对象存储提供你海量的持久化对 数据存在这不会丢但当你希望高性能访问的时候我的数据我的客户端会透明暗虚的或者提前预热的方式把你的热数据预热到离客户端或者说离算力更近的这种高性能的盘里面那这些可能我们会选择NVME的盘但是他们之间呢也不再需要一个复杂的系统去维护了都有ZivS客户端会负责维护那你客户端盘的增减都只是加个参数的问题就很简单嗯那这里比如说我每个计算节点上面的数据盘可以提供本机的一个缓存命重那如果本机的盘的容量毕竟有限那我可以提供一个在本机之外的缓存池这其实通过网络去传输它可以提供一个更大的高性能的缓存空间对 那在这个缓存池里面如果碰上了我的数据热点因为我的数据仍然存在盘上性能还是盘提供的比如说比如说呃举个例子那如果我有一份数据所有的团队都要访问那我这个盘怎么提供呢在这里我可以把缓存分组我可以按部门按业务按不同的方式灵活的改一个配置参数把这些盘分配给不同的业务呃用这样的方式可以更快的去扩展我呃用去扩展L的性能的需求对 然后当你不需要的时候这些缓存节点可以随时下线因为它只是缓存不会影响到你数据的可高性和移制性你随时下线之后就可以做缩容把你的MMA的这个成本省下来当然前提是它是云上的一个更方便扩缩的方式如果机房里的话它已经买了其实不存在缩容呃OK它说还有三分钟呃在这个Kubernetes里我们也提供了两种不同的方式比如说CSI的方式和Sidecar的方式那右边这种主要是针对云上ServiceKubernetes的使用它没有给我们Privileged的一个入的权限那我就通过Sidecar可以把我的挂载点注入进去那对于一个有全全部的权限的这个Kubernetes的环境呢更推荐用左边的这个方式嗯对呃然后两个案例第一个呢就是呃前两投资他们是一个做量化交易的呃基金对量化交易的数据级就是我们所有市场里面的这个股票期货这些标的数据量其实不大呃可能100T对到头了但是呢它上面的研究员可能越来越多大家的想法越来越多有不同的策略所以对于IO的吞吐其实有非常高的需求在这里他们就结合另外Sensef的一个开源项目Fluid去做了数据级的定义并且同时用Fluid管理起了Jusfx刚才提到这个缓存节点的扩缩容的能力它可以在云上自动的扩缩容这个缓存的部分然后那下面的话是通过Jusfx把数据持久化到对象存储里面然后呢他们的收益可以看到这边用10个Po的并发去取100G数据右边是100个Po的并发去取100个数据能看到说蓝色是传统上一代的这种高性能分布式存储Jusfx是右边这个橙色的那这里是加载的时间所以越短越好就能看到说当你的并发度越高的时候Jusfx其实得到的收益越大就是因为我的缓存可以更快地扩展起来去加速去满足你的这种更大并发的同时的加载如果是上一代的这个分布式存储的话可能已经碰到平静了那下面的话就是在因为靠Fluid做自动的扩缩容以后成本也可以得到一个很好的控制但它以前在没有Jusfx这个方案的时候可能我做一个workload需要9090块钱的时候那加上Fluid加Jusfx方式就优化到了原来的十分之一只有八块多它们是依赖这个阿里云上的Severlis的这个KBS的环境去做的测试然后另外这里举一个更大规模的比如说自动驾驶自动驾驶他们这个客户在生产上已经有150亿的文件平均都是100K的小图片这个放在以前的分布式文件系统里面比如说HDFS基本封顶是5亿Sive的话我们的经验值应该不超过10亿对所以到100亿这个规模其实都有很大的挑战然后在这个规模下他们在生产环境里面可以提供目前业务上实际会提供一个250GB的吞吐大概就是用中间的缓存机群去做这个吞吐的一个支持有30万QPS然后在这里还有一个特别的是他们不是在一个机房环境他们是一个跨城大概中间有1000多公里的距离一个跨城的双机房的一个方案那它的数据持久层对样存储只在机房的一边有然后另外一边是靠JuiceFS帮它自动去做镜像能满足1000公里之外那个机房的一个数据究竟的访问那它需要做的是原数据以及缓存数据的镜像那对于它的权量数据其实只在一边存一份就OK了这样的话既可以满足你的成本上的一个优化然后也能满足你对性能的在异地的要求OK所以最后也提一句这是这个异地机房的一个方案但今天其实很多AI的场景大家在一个云平台或者一个机房里的GPU是不够的那就被迫要选择更多的平台哪里有算力我就希望去哪完成我的计算任务那这一时我就被迫要把数据搬着走那数据搬着走的方法呢JuiceFS提供了一个全自动的方法帮你自动做镜像就不用手动党的去搞了好 最后回顾一下就是我们认为在今天AI数据级越来越大的时候分布式文件存储其实是一个刚需那第一代的分布式文件存储比如说像Ci-FFS他们在整个机群的规模运为还有成本方面有非常多的挑战也是因为他们就是要面向物理盘去设计所以容量和性能一直存在一个绑定的关系JuiceFS在运为云环境设计的时候我们利用缓存的方式把数据的容量与性能做了解偶这样的话能更轻松地来扩展我们在吞吐上面的这种性能需求同时当你有异地多云混合云这样的访问需求的时候我们也能帮助客户做好自动的数据进向帮助你能究竟地访问到这些数据OK 好 谢谢各位最后也留了我们项目的网址还有包括我们项目的公众号然后右边是我个人的微信如果大家对这个项目的细节有兴趣的话也可以加我的微信或者待会我们会后再交流好 谢谢各位