大家好,首先,感谢大家参加我们的线上分享。今天分享的主题是如何帮助COVID-19中的积极学习和大数据应用,有效的解决数据访问的复杂度,性能和稳定性的问题。我是来自阿里云容器服务团队的工程师,我的名字叫车养,同时也是福路的社区的联合创始人。另一个演讲者是县远东,他是福路社区的核心贡献者,他目前是腾讯云的开发工程师。我们两个从这个项目开始之初就一直工作在这个项目上,一直努力在把这个项目做好。首先,带大家了解一下今天分享的内容。我们会先介绍一下福路的项目的背景,包括它的起源。为什么要创造这样一个项目,以及我们要解决什么样的问题,福路的有什么样的特性。远东会介绍一下福路的整个技术架构,包括这个架构背后的思考。我们也会通过一个demo去展示如何用福路的加速深度学习。最后我们会分享一下福路的社区的规划,以及小伙伴们如何参加到这个社区来和社区共同成长。首先我们来看一下,过去10年IT领域的发展如火如荼试图非常迅猛。在这个10年中出现了非常多的概念,产生了很多新的技术,软件和硬件都在起头并进。其中大家都认同的有三个很大的,最大的趋势或者是主流性的技术,分别是容器技术,大数据,人工智能。根据Gatner的预测,70%的AI的应用都会在2023年的时候运行在KBS平台上。同时,根据Newstack的报道,Google正在计划将通过Cognitive来调度Spark,而不再使用传统能量。而GoogleSpark operator也在业界非常的流行,从这些现象中我们可以发现这样一个规律。大数据和AI更多的偏向的是应用层,它们分别处理的是结构化和非结构化的数据。但是其中有一个共同特点就是海量数据的高性能处理,多核和GPU处理引擎的主流。对于数据读取的严实是非常的敏感,而Google Natives关注于底层基础架构的低成本和规模化部数,它能够加速整个的应用的开发和交付效率,而我们发现这三者的融合,特别是大数据和AI应用更好的运行在融系化平台上,实际上变成了一个非常重要的趋势。而当各个领域都发展到一定成熟的阶段的时候,他们的融合去构成一个更大的生态,当然这也会引发新的问题和挑战,但其实也是新的机会。我们来一起回顾一下整个数据驱动技术的变迁。2010年,主要是Maple Reduce任务运行在HDFS上。其特点是任务类型和存储类型比较单一,并且是静态部数。数据和计算是几米偶和,计算部数在存储节点上。这就需要数据本地化,像Hadoop和Maple Reduce都是本地图。到了2015年,我们看到一个很大的特性是,计算任务逐渐的丰富,扩展到了Spark,Flim,甚至是Tenseflow。而存储类型也逐渐丰富,包括HDFS,SIF,还有S3,各种各样的存储。于此同时,计算和存储进行分离。这主要是为了解决计算能力和存储能力,能先扩展的问题。但是,此时的计算应用还是一个静态部数模式,没有弹性和融西化的能力。由于计算部数的位置不变,类似像Election这类的软件,就可以去做缓存和路由,热数据就可以被不断的访问到。到了2020年,任务和存储的类型就更加多样。像有了新的Petouch,Flink,甚至还有更多的一些像Rate这些的出现。计算和存储分离已经变成了主流。同时,运行时的环境也变成了混合云和混合NetX。这是一个最典型的特征,就是弹性伸缩。资源的弹性伸缩,计算不再固定在某些节点上。如何在原生的环境下,最大化的去实现数据访问的附用,实现应用调度的数据感知,就变成了互补NetX社区需要去面对和解决的问题。总结一下,数据驱动的变化主要有三个维度。第一个是计算和存储关系的变革。第二个是存储和任务类型之间的多样性的变化,以及他们之间多对多的调用和认识关系的变化。第三个就是计算的布什模式,由静态的逐渐变成了弹性的。随着这些应用,开始布什到互补NetX的环境中,这种发展的趋势,应用维护带来了诸多的便利。但是与此同时,也带来了许多新的技术挑战,包括访问一购数据员的复杂性,计算存储分离导致的数据访问的IO问题,以及不感知应用和数据亲合性的状态变化,导致了整个像K8s调动的这种低效。而这些挑战制约了数据密集性应用,在云原生平台上的推广和演技。我们来仔细分析一下这三个挑战。第一个挑战就是在混合云场景下的多数据员访问。随着业务场景发展、新的机器学习模型,需要各个业务部门不同的数据来联合使用,这就导致了一购数据员的复杂性。我们看到许多的AI公司和大数据公司,他们的不同部门在勾结自己的存储系统的时候,可能它首先是分布在不同的地域,比如纽约、上海、东京,有的不同的平台,有的是自己的IDC,有的是公有云,使用的技术也不禁相同,有的部门使用了HDFS,有的部门使用了SIF,有的部门使用了公有云上的S3,这就导致这个数据读取的协议是非常多样的。但是当业务逐渐发展到今天的时候,我们发现我们有些新的模型,开发的时候需要访问不同业务部门的数据的,这就导致我们编写新的这种,比如像TensePro这种程序的时候,当我要统一使用数据的时候,就发现非常的困难,首先我需要把这些数据是不是要挪到同样一个位置,第二呢,我当我去访问他们的时候,我到底是用Process协议,还是用HDFS,还是用S3,这样就导致我这种程序的编写难度非常大,而且后期维护成本也非常高,因此我们抽象出了data set的这个定义,对于应用来说,它需要使用的是data set,访问的协议可以统一到Process或者是HDFS,这就大大的简化了开发者的,开发这种数据密集性应用的一个复杂度,第二个挑战是什么呢?它就是一个缓慢的数据iO,首先我们看到,计算存储分离导致了数据访问性能斗降,远程和跨数据中心的数据访问,引入了巨大的网络延时,现在计算和存储和数据集群通常会分布在不同的地域,比如说像纽约、上海、东京,用户虽然尽可能会使用地理位置,相近的计算和存储集群,但是在实际使用过往发现,计算集群相比于存储集群会更加动态,比如这里就会出现全局的计算自然调度,还有临时的计算自然分配这些问题,导致了很多情况下,计算和存储不一定会在同一个地理位置的集群中,而这些场景下就导致数据读取的性能有显著的下降,比如同一个集房的数据的访问,比本地数据的访问,它延时要增加3.1倍,而同一个地域又比同一个集房去访问的时候,时间延时增加了4.2倍,而如果是在同一个国家不同地域是1.25倍,但是更可怕的是有些是跨大洲的数据性能,数据访问,它性能的延迟就更加明显了,这是第一件事情,第二件事情,应用的无状态性和节点的这种弹性伸缩的特点呢,就导致这个缓存重用是非常困难的,我们发现很多像深度确先应用,它会访问海量的小文件,实验表明,如果没有本地的配置cash这些能力,读取海量小文件的性能会有近百倍的差距,但是由于这种节点创建和销毁的随机性和调度的不确定性,我们现在发现节点上数据的缓存负用是非常低的,而第三件事情,单一的一个数据存储,单一的一个分布式存储,被多个训练任务同时访问的时候,它会导致这个存储成为一个性能平静,它的并发效率会非常的低,我们说通过实验我们就发现,多个作业同时访问一个远端的数据员的时候,相比一个单任务的训练访问,二十个任务同时并发的时候,它在读取性能会下降到两到三倍,然后其实在一些更大的一些集群中,比如说有几百个GPU节点,它同时去访问一个last集群的时候,它可能最后导致的性能下降会更加明显,甚至有十倍的性能下降,同时如果有因为一个客户端访问,导致这个中心化的数据存储出现荡机,也会影响整个集群的一个稳定性,这是第二件事情,缓慢的数据IO,而第三件事情就是covenanted的调度缺乏数据感知的能力,它也无法与应用协同去实现一些智能的数据运热,根据我们观察,以AI应用为代表的特点就是,它的数据的负用比例还是比较高的,首先是不同任务之间的数据重用,其实是比较普遍,比如说对于一个训练集群,我们通过观察发现,许多用户会提交,许多这种使用相同输入数据的任务,例如相同模型,相同输入,不同超三的作业,然后模型微调,它的输入就基本上完全相同,还有包括一些AutoML的一些作业,而这些作业其实都会去大量的使用相同的数据,同时还有一种基于这种数据流水线的一些操作,其实也存在着大量的数据重用,第二件事情就是,周期性比较长的一些周期性任务的数据方法,就一个训练集群来说,它其实70%的训练任务在一个月内会有超过14个重复提交,众多训练任务都呈现了一个强周期性,而很多任务你固定的周期性去提交,其实读取的数据呢,其实很大程度上也会有非常多的类似,也许是仅仅有日期的不同,因此结合这种历史任务的调度信息,来提前对于一些任务的访问经历势均预热,其实会有明显的效果,然后进一步在调度时刻的时候,当我们的调度任务确定了,我们的炮子将在某些节点运行的时候,我们可以结合这些调度信息,对数据进行一些提前的预热,而遗憾的是,我们发现现有的Kubernetes,调度缺乏这种数据感知的能力,也不能够通过根据调度的决策进行一种智能性的预热,这就导致整个KBS里面有大量无效而且重复的数据工具,你来了应用的运行效率降低,以及GPU和CPU的资源利用率也不高,而Flu的希望,实际上就是来构建这种数据亲和性的调度能力,帮助Kubernetes上应用,可有效的感知数据位置,来降低IO的延时和提升资源利用率,因此为了解决前面提到的问题,我和南京大学PASA实验室的顾鲁老师,Alexio社区的副总裁范冰博士,一起设计和开发了Flu的,只在通过对于数据访问的一些抽象,将分布实缓军系统类似Alexio,GindleFS, GooseFS,Kubernetes的可扩展性能力,想结合,那我们具体来看一下,Flu的本质上是一个什么样的系统,它提供了什么能力,它有三个核心能力,第一个就是数据抽象,提供DataSight这个概念,实现易购数据员的抽象,方便用户以一个透明的方式,来联合起来,去访问不同地区和不同村主协议的数据,而应用的访问协议可以支持,类似Posix, HDFS这样的标准接口,这就不必需要那些数据功能师花费大量的时间,去开发这种数据类型相关的IO接口,而底层的数据协议和村主地点的变化,对于这层,通过这层抽象也进行了屏蔽,降低了整个程序的维护的成本,这是第一件事情,数据抽象,第二件事情,数据加速,通过DataSight这个对象,我们可以实现这种,数据算不是缓存的一个可签议型,这种potability,它的自动扩缩容,弹性的这种伸缩能力,以及一些像这种自动的数据预热,这种perfect的能力,来优化及取内数据缓存的这种可复用性,和应用的访问的性能体验,第三件事,就是数据的感知调度,对于DataSight的,使用DataSight的应用来说,可以根据数据的缓存节点信息,进行调度选择,我们会选择一个更合适的节点让它去运行,同时在应用调度的时刻,也可以根据这个调度信息,我们进行一些智能和数据预热,Fluid的目的实际上是让,大数据和深度学习的应用,在Fluid的环境下,能够运行的性能更好,帮助计算集群的资源,利用率更高,而整个的过程对于用户是透明的。Fluid要说一句,Fluid是于2021年4月份,成为了CNCF的三报项,目前已经有105个开发者参与和贡献过代码,有11个核心的开发者,他们分别来自阿里巴巴,腾讯,然后向微博,以及还有云之声一系列的公司,而使用Fluid的互联公司,也包括向阿里腾讯,还有向微博B站,还有向Boss执聘,这一系列的比较领先的互联公司。下面我们欢迎,腾讯云的谢远东,分享一下Fluid的技术架构,使用方式,以及他会有一个单目的展示,还有我们其他发展的路线图。好,现在我们欢迎远东。大家好,我是来自于腾讯云容器产品中心,云原生液的谢远东。首先感谢这样为大家讲解了Fluid是什么,以及Fluid到底解决了什么样的一个问题,下面有我来给大家介绍一下,Fluid的整体架构,包括Fluid社区的一个发展。我们看一下Fluid整体架构图,大概分为三层,第一层是用户层,第二层是Fluid这边的operated层,第三层是KBS,以及存储的技术设施的层。首先我们看一下用户层,有前面的内容我们可以了解到,Fluid这边抽象了两个概念,第一个概念叫Discite,第二个概念叫Runtime,Discite是为了解决多数据员复达管理的一个问题,Runtime是为了通过分布式款捐引擎来解决IO吞吐的一个问题,目前Fluid社区支持多种这种分布式款捐引擎,比如开源的Eloxio,分布式款捐引擎,还有Jose Data的JoseFS的款捐引擎,同时我们也支持运涨上的分布式款捐引擎,例如京斗包括GhostFS,下面我们看一下Fluid operator,Fluid operator主要分为两个组件,左边的是Fluid Control Manager,他负责调度Discite,在Fluid的中我们是将数据的调度问题转化为数据加速款捐引擎的一个调度问题,通过数据加速款捐引擎来缓存数据,调度到我们期望的一个节点上,它大致分为三个组件,第一个组件是Discite Control,Discite Control它是来管理Discite整个的生命周期,包括与Runtime的绑定,包括解绑,然后第二个是Runtime的Control,Runtime的Control主要是来管理分布式款捐引擎的生命周期,包括创建,删除,还有横向的拓展分布式款捐引擎的一个缓存能力,同时提供数据域存还有清理的一个能力,第三个是Volume Control,Volume Control主要是和Community API进行通信,主要是为了创建这种KBS原生的一些资源,例如Posited Volume,还有Posited Volume Claim,第二个部分是Flowed Schuyler,Flowed Schuyler是一个应用调度器,它主要是来负责根据缓存的一些信息,就将你的负载的Pod分配到一个合适的几点,它主要分为以下两个部分,第一个部分是Carticle Locality Plugin,也就是这种联合调度的插件,它主要是能够智能的调度作业到已经有缓存的几点,还不需要用户去显示的一个指定,第二个部分是预取的插件Profits Plugin,也就是说在调度期间,调度器会通知这种控制器将数据预存到作业即将调度的一个几点,通过这种Pipeline流水线优化的方式来节省这种数据读取的时间,下面我们来快速地介绍一下Flowed的使用,Flowed的使用是很简单的,因为Flowed这边是抽象了一个核心的概念,它的本质上是一个CRD,就是制定义资源类型,它提供的是这种对于数据的抽象,所以创建DataSight是非常简单的,就是我们可以通过写这样一个压抹文件来定义我们的数据的来源,同时我们也可以定义数据的一个可签一信,下面我们看一下这个例子,这个例子是来自于一个真实的科化案例,它的训练数据是比较大的,已经完成了这种数据脱敏,放在了这种云上的对象存储上,但是验证级就比较敏感,不能够放在云上,只能够放在这种云下的IDC,所以我们这边Flowed一方面通过提供这种统一的释出来对接不同的这种数据的来源,而另外一方面也提供了这种分布式缓震加速的能力,那我们可以通过这种node affinity的这种清和性的一个机制和反清和性的精致,我们可以动态的来移动数据,举个例子就是说我们可以在训练的时候将数据保证在云上的GPU的实力来加速这种数据的访问,当不需要训练的时候,我们可以将数据欠一道更低成本的这种CPU的节点,然后避免了这种GPU节点的一个浪费,包括这种网络专线的一个浪费,当我们创建了这样一个data-side之后,我们可以通过这种数据级的一个可观的性来观测到这种数据级的一个种的数据量,包括你的整个缓存的能力,包括已经缓存的这种百分比,通过这种缓存的比例,我们在后面可以根据缓存的比例,这些数据来触发一些谭医生说,通过这种谭医生说,我们可以达到SkyOnFlight的一个效果,也不是说当我们已经部署了这样一个data-side之后,我们的应用如何去使用这样一个缓存的一个能力,其实很简单,我们只需要在我们的应用的Volume的PPCClaimName,直径刚才创建的data-side的Name,我们的控制器会自动的识别,你的Vocalode要去使用这样一个缓存,我们会自动的将你的复杂调度到已经存在缓存的一个节点,同时我们会触发一个perfect指令,让你的即将调度Vocalode的节点,能够来预热这样的一个缓存。第三个是我们刚才提到的一个outscaling的一个能力,就比如说我们在创建data-side的时候,可能没有办法预知到我们的数据,最终的一个总的大小是多少,所以我们可能会设一个中间值,所以在业务运行的过程中,我们的数据可能在不断的增长,在默认情况下,如果缓存的比例达到一阵比例的时候,就会触发这种数据驱逐,从而影响到数据的一个访问的吞吐。所以我们这边提供一个这种扩展的能力,当数据缓存到一定的百分比,一定的数量的时候,我们可以来动它的扩展这种分布式缓存的POD,来提供这种更大的一个缓存的能力。下面我们来演示一个,这个demo主要是通过FluidLine加速机器学习训练任务。我们通过对比,直接通过云上的对象存储来训练生动学习任务,和通过FluidLine加速训练生动学习任务的一个效果对比。首先我们看一下直接通过云上的对象存储来训练的一个效果。我们首先去创建一个云上对象存储访问的一个PV和PVC,然后我们可以通过CubeFlow社区的一个分布式任务提交工具而Rena来提交一个分布式任务。这个分布式任务是四个节点,然后每个节点有八张GPU的卡,来训练这样Imaginate的一个数据集。我们看一下任务的一个日字。我们可以看到任务的存储大概是638张图片每秒在每个GPU上面,然后我们看一下准确率。准确率在整个任务结束之后,我的Top1的准确率大概是75.2%,然后Top5的准确率大概是92.26%,我们看一下整个的运行时间大概是在一个小时左右。下面我们来看一下通过Flow的加速训练的一个效果。首先我们去定义这样一个data side。这个data side需要指定一下数据员的一些信息。我们这里的数据员是一个对象存储。这里其实和在云上使用对象存储的方法是一致的。我们会去创建这样一个data side。data side在整个机群的概念类似于一个PVC,然后我们可以通过Arena的运行使用相同的方式来启动一个分布训练任务。我们看一下在训练过程中的吞吐大概是2800张图片每秒,在每个GPU上面。相对于之前的训练任务有了400多的一个提升。同时我们看一下在速度提升的同时,准确率也没有下降,反而是有所提升。我们看一下总的训练时间。我们通过Fluid的加速使整个训练的时间从一个小时缩短到24分钟。我们介绍了如何使用Fluid之后,我们可以看一下社区目前来发展的一个情况。首先我们介绍一下社区的一个roadmap。截止到目前我们已经发布了0.6.0版本,主要是满足这样一个user case,让数据基础设施功能师能够简单有效地使用缓存加速,来加速这种AI的业务。然后在1.0版本发布时,我们希望可以满足数据基础设施功能师,包括数据基础设施团队,能够在无需关心数据管理的情况下,来实现这种大数据以及AI业务的一个性能加速。为了实现这样一个目标,我们需要在1.0版本之前去实现这样几个特性。第一个是在AI应用的基础上,我们需要通过fluid来进一步加速cabinetism上大数据的一个应用。第二是通过调度的优化来提升数据本地性,进而能够提升数据访问的一个效率。主要是通过这种调度器的增强,将数据和工作负载进行这种联合的调度。第三是在cabinetism环境下,我们需要通过性能的优化,来保证在大规模的应用场景下,这种数据皮,包括分布式缓存引擎的生命丘区的一个管理的能力。介绍完这种RoleMap,我们可以把计划进一步的进行这种细分,然后大致分为这种以下6个部分。第一个部分是能够自动的运为,还有这种可观测性。因为为了保证这种系统的整体的稳定的运行,我们需要一些组件能够自恢复,同时我们通过这种DOMAS的支持,以及平滑升级的支持,让我们的分布式缓存引擎能够达到一个高可用的状态。我们这里通过各种生命式的CRD,例如这种原数据备份,原数据备份包括恢复,以及数据的潜移,数据的预热,我们都通过这种CRD的方式,来达到这种自动运为的一个目的,然后我们通过对接PromiseOS,能自动的采集数据的一些指标,同时包括对接Golf,这种Dashboard,能够提升这种系统整体的一个监控,以及报警的一个能力。然后第二个部分是编排的部分,我们通过定义数据及调度的策略,例如Finnity,或者说Talleration,将缓存调度到期望的基地,此外通过缓存位置信息的上报,进一步能够直到工作负载的调度,能够调度到有缓存的基地,然后进一步来加速这种数据的一个访问。第三个部分是多个缓存引擎的支持,目前社区已经支持了Lokeshow,京东FS,以及GhostFS缓存引擎,目前社区也在积极推进GhostFS的缓存引擎的介入,第四个部分是Flowed Agent,我们既可以通过AgentPull,或者Pull去的模式来获取到极点的信息,通过极点的信息来进一步直到我们的调度,同时我们可以通过Agent来实现缓存清理的一些操作。第五部分是ElecScale Scaling,我们通过定义弹性伸出的一个策略,来实现缓存实力横向,包括纵向的一个策略,来适应工作负载弹性的一个强景。第六个是Application Access Model,就是我们目前支持的基于Fuse,也就是Fill In System的一个接口,包括这种ACFS,一个Hydrop的一个接口,让Flowed能够在AA以及大数据的场景下发挥它的作用。前一个部分,我希望能够通过介绍Flowed的项目的Rotemap,能够吸引更多的开发者,包括用户。因为Community Overcode,健康的这种社区,原来要比幼学代码要更重要,所以也给大家简单的介绍一下,社区目前的一个发展,目前社区正在稳步的发展,目前有超过80名来自不同的公司和组织的贡献者,包括阿里云,然后腾讯云,南京大学,Loccio,Juice Data,还有中国电信,包括第四番试,都在社区里积极的贡献。如果你有兴趣,或者有疑问,可以通过sincefslike,来搜索Flowed的这个频道,通过搜索Flowed的频道来联系我们,也可以通过gethub,来靠我们取得联系。同时,我们会在每两周的北京时间周三,举行这种社区会议,会讨论一些项目的进展,包括一些demo,还有一个proposal的一些分享。与此同时,你也可以访问我们的网站,来获取更多的一个信息。目前,很多公司都已经在生产环境上使用Flowed,例如云AI公司云制生Unit上的,这种价值AI公司草膜,还有就是微博,包括中国电信,都在使用Flowed,来对AI进行一个加速。同时,3600也在使用Flowed,来加速这种大数据的应用。同时,阿里云腾讯云,也基于communities的容器平台,一级生的这种Flowed加速的一个服务。然后,最后,感谢大家参加我们这样一个技术分享。如果有什么问题的话,我们非常欢迎大家,能够提出来,然后我们,可以在这里给大家做一下解答。