我先做一下自我介绍吧就是我的名字叫朋友我买资源IBM看了的然后我们提不出要做资源调度和能力我们有自己的一个offering叫做container forconductor for container这是一个文学免费的版本所有的它是一个GMSO's Kubernetes还有Dalker Registry的一个轻量级的PES平台所有的组件都是基于Dalker ImageDalker Container安装起来也非常方便然后在会后的这个news later会给大家就是share这些问个令看到有兴趣的试一下然后我们也有自己的论坛还有slap channel欢迎大家来提问今天这个session主要是说一个就是Spark Satisfied这是我们基于Messus开发的一个Metal framework来对这个Spark或者类似于Spark的这种DAJ的Fremark和Workload提供一个更细腻的调度同时也支持资源的共享然后旁边这个就是Satisfied的主要的研发购价时是IBM北京office高级国家时报小明然后今天就我俩来给大家介绍一个这个我先大概说这是真的就是我先大概回顾一下当前这个在Messus平台怎么支持Spark的然后那些问题包括最新的进展然后Tim Chen应该是这个主要做Spark和Messus这个维护者然后他今年也做了很多错的这个Quantation无论是在Spark SummitMessus Summit然后也有一些遗憾然后我也会大概介绍一下他们现在的工作还有我们看到的一些更多的挑战和一些我们从我们企业级的客户收集的需求稍后我会更详细的介绍这个由这个宝小明来介绍这个Satisfied测试的结果这是我大概介绍一下我们这个team我们这个名字叫做Spectrum Computing Team我们成立于1996年然后主要做那时候做HPC然后后来做ClusterGreat包括VM的平台OpenStack然后现在做容器的管理我们是2012年时候被IBM acquired我们这个team我这个team在这个这个公司呢主要是更多的参与社区的工作主要是希望依赖Lavage就是Lavage这些OpenSouth技术来构建来一方面是使用这些OpenSouth技术来帮助我们提供更好的solution来服务于我们的客户另外一方面我们也希望把我们20年来的时候在企业环境下的技术然后回馈给这个社区然后我们参与了这一系列的这个OpenSouth的工作包括最早的OpenStackHydroP到现在的MethalsparCuponitinsLERK这些然后今年我们Methals从去年就已经开始工作了然后然后今年游戏我们有两位同事是被Permoto成为committer然后我在我们现在就是回顾一下这是现在SparkMethals的状态吧大家都知道这是SparkMethals其实是一个共生的两个都来自于这个Ucfokli的实验室然后他们最早Spark作为Methals的独立的点心的freemort来体现Methals这样的功能他们也希望也是两个人士的调度由Methals来负责自愿的管理和调度由Spark来负责Ucfokli的调度最早出现在是所谓的fangry mode所谓的系列调度也就是说资源的分配是以Task为单位就是最小的资源分配调度单位是Task当有Task进入的时候Spark才从Methals获得资源来运行就Task当Task结束之后这些资源就被释放掉其他的负责或者其他的Task服务的但是系流调度当然听上去非常好因为更好的去解决资源利用率的问题但是在实际的实现过程中有或多或少的问题所以在今年的时候他们Spark社区已经希望把这个这个模式已经deprecated掉然后这些列了一些他们有哪些问题现在实际方认是当Methals当Spark有Orcl的时候当它从Methals破的一个Offer的时候然后它会检查这个Offer是在机器上有没有Exoter运行那如果有如果没有Exoter运行它就会Launch Exoter去运行这个Task那如果有Exoter运行的话它就去把这个TaskDescribe到这个上面去但是有这样的问题当所有Task结束之后这个Exoter被被Kill掉那这样的话S6所占有的内存其实是一直HOLD在那里直到Spark运行这个数然后还有另外一个问题就是说在一台机上只会有一个Exoter运行那大家都知道这个Java Program对内存管理其实特别大内存管理是有些举现性的同时这个时候吹得老如果内存过大的话你的Exoter运行过大的话在S6没有Task运行它会一直HOLD还有很多的资源的浪费所以这前面列到两个最主要的问题就是第一个它无法在一台机上其中多余一个的Exoter第二个问题就是说这个Exoter在没有Task的时候也不会被释放掉造成了很大的资源的浪费的情况还有一件事情就是第一个听到Overhead就是说我每当去运行一个Task的时候我都有很多次由Spark还有底层的这种交互要求获得资源并且在SparkTask的时候它还要去通过Massos所以有比较长的ExonPass特别是当Task时间非常短的时候调度所需要的Overhead相对于它Task之心也是不能被忽略掉的第四点就是说所谓的不可预测性就是因为你的Exoter的Side大小是取决于因为只有一个所以是突然变化的所以你没办法知道你在一次实验的过程中你Exot的分配的课数和资源量和你第二次运行时的课数和资源量有什么差异就造成了在某些情况下你的执行会非常多的快但在另外一些情况下你就会变得有变得很慢这就是所谓的在喜欢一下我把它叫做服务品质那你的服务品质是没办法保证的还有甚差两个是为什么在社区希望已经可以把这个File RemoteDeprecate的原因就是一个从Spark 1.25开始就有这个Cross Screen的这种Dynamic Education中Cross Screen的方式相对地去解决了一些资源利润的问题所以社区的同事们认为这个已经是比较成熟可以把它去掉了还有另外一个就是Manual Effort因为不同的模式有不同的Ext pass这就是在听证在对近期时间想出说明了为什么要把这个File RemoteDeprecate掉了然后下面我可以介绍一下就是在最新的Spark Commesse中我推荐的使用方式就是Cross RemoteCross Remote的顾名思义调动的单位就不是以它所谓的单位而是Extra的单位在之前的所谓的NewCross Remote的方式是这样子的你又不需要指定你的Extra的偷偷的可销CPU的个数还有你Extra的Mabery的个数这时候就是当Spark或者Over的时候它也会看你上面有没有Extra来执行然后去LaunchExtra那我拿到Extra的时候它就直接Extra上去而不通过Massage的Massage条路径那好处就是比较在这些每个Tas的时候它的Schedule overhead比较小一些但是通常有这样的问题因为因为是Cross Remote所以它的调动方式是跟Extra以为力度的所以当你的Extra没有Tas运行的时候Extra的CPU资源也不会被释放掉所以会造成一些资源的浪费那怎么解决这个问题呢就是我刚才说到从1.25开始有一个Dynamic Allocation这个Feature它可以根据你的Walker大小在动态调整Extra的个数但这个功能呢是一直在一样上有很好的支持但是在Spark上支持的不是那么好所以在今年又做了很多银行层的工序年底然后让这个第三条提到的Solid Dynamic Allocation在Spark上然后呢也有一些银行层你都可以在一个Extra微信多个Extra这样的整体的结果就是说根据我的角度它基本上达到了Spark on Young的一些behavior但是呢还有一些Taken Log就是说可以LeverageMessage的一些在调度的时候的黑功能但总体来说的话我觉得就是通过的感觉来说它基本上去matchSpark on Young的一些一些性能资源利用率还有非常适合的一些能力这里这时候呢我们就提出一个问题就是说那是不是这些就足够了呢那我们都可以看一下回头可以再review一下我们在接触我们的客户的时候说遇到一些一些需求来大家可以看一下是不是这个就足够了这是我们接触的从我们过来过去十几二十年的时候接触这些客户无论错那时候他们在一些其他的一些分布式的workload的时候他们所需要就是提出的一些要求第一个要求就是所谓的SRA就是刚才说的服务品质你的性能的预测性第一条就是不同的应用呢其他有不同的性能的要求有些是需要很快就结束有些是理解操作那只要能够我是好像为了ObsonObson我时候workload的那如果你有资源的话我就会寻找那如果没有资源的话我可以等待所谓的一些东西这是从应用的不同的应用角度还有一些是不同的为了Tinix不同的拥护的角度那有些是一些高优先机的拥护它的是已经一些非常所谓的Mation critical另外一些是第一优先机拥护它其实等待一些是一些是OK的这是第一条第二条就是有些是有些是优先机比较高的就是差需要用要有资源就会对它来使用它需要去强战那些低优先机的东西去使用就是我刚刚说第三条就是说你们需要强战是在保证SLA其实是必须的工作还有一点就是说这是所谓的property base不同的应用或者不同的Tinix它有不同的优先机的保护而另外一个所谓的就是Rinshow base它是根据整个total of other source在不同的部门之间去根据一定的比例关系来洗头资源第三个就是这两种police的混合场景所以说你可以看到一个SLA其实不单单这个是指定你的资源的需求而且是要根据资源的变化来组织它的调整所以有各种各样不同的这种所谓的比较复杂的这种策略或者是基于优先机或者是基于比例关系甚至是优先机比例人混合的场景是对整个SLA的要求第二条就是如何提高整体的资源利用率首先有两个场景一种两件就是说在cloud里面的环境下有很多很多的用户来使用那demon的邮件是在这种高清零的数据分析高清新生的领域里面所以要求肯定是要大过于可用的资源所以你要保证对资源利用率提高对资源利用率提高的一方面就会回到前面一个要求其实资源利用率越高你是越有可能尽量地挖退资源的潜力来满足用户的SLA然后第二个你也简单地减少你总取用户成本允许你的IT环境的机器的二数不会增加得太快然后因为机器的增加以后的成分也需要你来维护的成分还有第三条这是最近才出现就是说以前的计算所谓的计算大概只需要比如说CPU内存还有网络或者硬盘就可以了但随着DdemonDemons这种出现还有一些算法的开发GPU现在就变得越来越重要的一个资源要求特别斯坦克的调动调动GPU同时因为GPU在某些地方也可以和CPU通过一定的比例关卡等价你还需要考虑CPU努力比如说当我有GPU的时候我尽量使用GPU然后当我没有GPU的时候我通过一定的COS用比例关系来使用GPU这是我们收集到的一些用户的要求然后我们再根据这些用户的要求来回头看看我们现在的所谓的新的Cross-RemoteSpark-on-Messow是我们的满头对系我们的想法是比例关点是我们认为现在的Spark-on-Messow其实还是不能满头刚才说到这些无论是SRV还是对资源的请求甚至是GPUGPU的真实当然这并不是说是Messow的问题因为Messow最近我觉得做了一个非常好的工作它能够把新的资源抽象出来提供给上终的Scheduler那是不是Spark自己有问题呢其实我觉得Spark做的工作也很好因为它也这样的Tas的调度也发挥到了极致我们认为其实它才Tas Scheduling和Source Manager之间它确实了一层我们认为就是在Zovo Level或者Sethical Level的调度这是确实的意思然后我们再回头看看是不是Fan Grunt就有它原生的毛病一定要把Debrate it down来使用Cross Grunt其实也不是Fan Grunt还是有它的好处的只是实现的问题只有你做了更细致的调度你才能真正提高资源利用率你提高了资源利用率你才有工作的资源去服务那些SLA所以我们认为Fan Grunt还是非常必须的还有就是SLA怎么保证SLA这也是一个非常必须的事情比如说Results Reaction或者Result Usage比看过Results Application和Task Extension然后第三条就是要在Session Level做一些调度而不是完全把这个调度的资源共产能力去下放到资源管理层最后一点就是说我们要把GPU、CPU要同意的考虑这些调度我提出这些问题下面就有我们的中国的高级国家市这是Science Skyler这个主要的研发人员也介绍一下我们怎么用Science Skyler然后怎么follow我们刚才说的这些Galant来来设计我们的这个迷信Layer好谢谢弓弓那么我们我不知道就咱们在这有多少对这个Spark非常熟悉那么我现在大概也解开扣一下刚才那个弓弓介绍过了我再说一下在Spark里面有几个主要就是比如说现在SparkMessos它怎么work现在就是说我现在有一个底下有一个Messos的机群然后我们一个Spark application一个Spark driver它单独去找Messos需要资源然后这样就是说如果我有成千上万的Spark application的话那我实际上在Spark在Messos上会有成千上万的MessosMessos framework我们是想的就是说在这个Messos和Application之间Spark application之间I build this这样的Disk这样的Layer来提供的能力包括比如说我们能够paralyze所有的Application能够Dynamic Share然后Figuring能够支持Promise并且能够知道像企业这种组织结构这样的Feature那么这样弄出来之后我刚才提到就是说现存的Spark Application是所有的Messos所有Spark application都会去Connected Messos那么我们这样并度说我实际上这个所有的Application会去连到我们这个Spark Schedule Layer这样去做然后在这一种我们来保证它的比如高音器的相关程然后它们根据不同的Share的比率来做到一个更动它的一个比率分配然后并且是一个Figuring并且能够支持Promise但是这个我们是一个我们的一个愿景我们对于解决刚才那些企业的需求的想法大概大的比率就是这样子的那么我们再看一下就是我们在这个里面具体有一些是怎么来做的这个地方我换了把Messos的话比较小然后再换了几个比较大的与Spark相关的conference第一个就是说我们看看左边这边有三个Spark driver那么Spark driver实际上就是我们可以为它Spark application吧那么这边我只是换了三个其实上它可以是前前上完的然后它都会连到这个中间那个最大的块叫Spark 313格那个那个块它是一个severalty process然后这个Spark 313格它作为Messos client它作为Messos framework统一地向去Messos去申请资源那么这个时候实际上那个它从Messos拿到资源之后它就像一个中间的批发商一样从Messos批发的资源然后再连到它的Spark它可以聚集起这样的一个分配那么这个是它的一个主要的一个结构上的一个图那么在具体怎么样做的FindGrid呢FindGrid是我们这个地方在左边有一个Skeletback这个地方是FindGrid一个很重要的简单就是说这个Skeletback在Driver里面它能够看到Spark里面所有的这个就是我当前当前有多少Pending Task多少Running多少这个是不是还需要很多Slots那么这个时候我们第一步就是我们回去收集这样的TaskPending Task的信息然后去我就有这么多比如说我就有1000个FindGrid那我就会发一个Request到SenseGrid说我需要1000个然后SenseGrid根据它自己有个资源以及从Messos申请的资源它根据Priority根据Share的比率分配给Driver分配给Driver之后Driver然后再去发达命令给那个SparkSenseGrid然后再去通过Messos去把Spark SQL起起来然后 SQL再连回到Driver进行真正的运算那么这个就是一个起码过程那么当那个Task运输完之后就是我没有扔过Close了或者说我的Task的数量从1000减少到了比如说一个两个在这个减少的过程中间我不断地会去把我不需要的Slogs会Release给SenseGrid然后这个SenseGrid就可以去给其他人用或者是现在没有SenseGrid我就会去还给Messos那么整体是这样一个Work的一个流程那么在Spark里面有两种运行模式一个叫做DriverDeploy Mode叫Driver Mode叫Client Mode那么所以实际上我们选一双它就运行起来之后SenseGrid会运行在Messos看到两个FreeWork一个是for driverresource allocation另外一个是for SQLSpark SQL都是整个运行的样子然后再我们看一看就是说在SparkScanner里面我们实际上也designed了一个一个非常flexible的一个一个design我们在这个地方可以允许比如说我们这个地方是有一个plago的一个interface让用户去写它自己的这种就怎么样去分比如说怎么样去paragraphize这个application怎么样就是说怎么样把这个source分给哪一个application这样是一关键plago的一个policy那么在这下面这一块呢实际上我们也也是一个plago的一个allocator那么这个allocator现在我们跟Messos实际上我们可以底下也可以一样接也可以和其他东西去写这样就是会把这个整个实际上这样一个结构使我们愿意写的一个结构当然就是说我们也先把推到一些更多的拿到一些更多的feedback看是不是这样OK那现在也大概一个介绍就是这样一个结构结构是这样子的那么下面看一下就是说我们现在提供的一个主要sensuality主要功能那么第一个就是我们是fine grade这样的一个调度那么在我们刚才看到的有一个scalatorplago的这个policy那我们现在能够做到的policy尤其第一个是fifl就是现在的作业先服现在的application能够拿到所有能够优先拿到所有的这个资源那么这是第一个第二个就是说我们那个是叫priority的那个application每一个application会有一个priority然后比如说我的鲜奶的这个第一个fifl就是说主要功能第一个完成它不要需要任何resource了我才会分给后面的application第二个就是说比如说我一个loprity来了那么再来一个高priority的我会慢慢慢慢会把这个loprity的占有的resource会riscle或者perperity的那种mood到那个highpriority就可以进去那么第三个刚才我们提到就是有一些Dalamic resale的requirement那么这个我们提供另一个我叫做waited resale就是每一个application它可以有自己的wait然后来决定它能够在整个资源一个大有的resource比率再一个就是hierarchyhierarchy这个地方就是说是想达到一个什么目的就是说在一个公司比如说它的层次比较多比如说一个公司有一个大部分大部分有这个小部分小部分里面还有好多不同的application team那么实际上可能就是我出的钱多我能拿的资源更多别人出的钱少我可能拿的资源更少我们做这个hierarchy控制这个比率也就是说钱出的最多我能够更快地拿到资源或者拿到更多的资源去完成它的作业再一个就是说我们刚刚提的就是说resource的shape可以是grace load的还有就是说我有一种我可以让它去抢占抢占low priority的或者是它的不应该占要的一部分的但是额外占的那份资源还可以promotion回来给这个urgent的这个application去用那么还有一点就是说我们想在比如说把这个spark那个里面有application有两个角色一个角色是driver一个executor那么实际上这两个东西它的角色以及它的这个关键性是不一样的比如说这个driver太死了那么这个整个application就挂了但是这个applicationexecutor死的一个没关系它再起一个executor给wrong下去所以实际上这两种这个角色对机器的要求以及机器的稳定性或者什么感染度都是不一样的那我希望就是说我们希望做这样一个host selection哪怕这个Messus都提供了我会把它去问看就是哪个地方去转driver这个地方去转这个executor这样能够尽能够保呢这个driver它能够在比较稳定的机器上也行比如说这个机器上就只有driver没有这个executorexecutor因为也有Mamere什么都不可控而driver这一方还好它在对这种Mamere CPU的可控度比较高的executor就可控度可控度比较小那么再过我们就是也能够做这种GPU的schedule刚才发布的介绍说比如说CPU这个GPU不够的时候然后我们能够当然听个GPU它可能调动它就是说GPU比较多GPU不够的时候我们看着它在CPU和GPU上的Caust的比率去看看是不是使用CPU那么再一个就是我们有一个比较好的故意能够看到Source的相能变化然后我们可以做一个单纹去看看这个然后这个做完之后我们怎么去使用这个东西呢其实我们了解SVAC应该会比较熟悉这个东西义尚是想和SPAG Master就Standone Mode去比较有一个比较好的比较相近的User Experience所以义尚和那个SPAG的Standone Mode的Teclore的方式与域形的方式比较相似只是说底下的东西是不一样的而且那个Standone的Standone的调动一方面也不太能满足有很多企业的需求那么义尚用家只有两步第一步就是我们要把SenseCader在MassageMassage上先起来起来之后它就能够去接受作业的Submission那么在运行这个时候我们要取它因为它从SenseCader要去申请资源然后因为它可以主要是这样的Row然后我们要有一些Sense相关的配置给SenseCader去用那么第二个就是说如果我们这个期限的时候我们这个提到这个真正的Spark application然后它要指定这个我们的SenseCader的一个URF这个是URF实际上我们是为了保持为了想和这个SparkStandone比较兼容的话我是没有赶它这个Scamer还是用的Spark这样的Scamer然后我们如果这个这个Fint比较好的话我们就是说我们想着这种方式我们可以那么与上使用起来的话和Standone的这种模式是非常相像的但是它提供的能力是有比Standone要好太多那么这个是我们在Porsche有一个ProgramSpark是一个亨相的那边是我们这个SenseCader我们自己的一个Resource Manager上然后和MessusSpark Online和Spark Messus对一个亨相的对比那么我们还没有把我们这个SenseCader和Messus真正做完Pinchmark但是我们期待我们做完SenseCader和Messus然后和Spark on我们那个Resource Manager达到同样的能力实际上上一个没有基本上很一样那么我们看一下这个结果这个地方的结果这个横度是一个这是个有人说这个Pinchmark是第三方做的那么第二方做的就是说我去运行一大批连续的提供一大批Spark的application然后看它看它这个application完成的这个时间长短以及它这个是不是很集中是不是运行的是不是很多然后我们看到这个蓝色的是在运行的时间是最短的然后它的这个做以为最完成的时间的波动也是最小的这个这个红偏红色的是是让样的然后那个绿色的点是那个Omesos那么整体来看就是说尽论是在Surplus上面我们这个要为考一些大约3%就是3-14%再提升这是这个我们做的结果然后在我们再做这个在ScatterOmesos的时候是让我们也进行一个比较一些纠结的过程一些卡吧然后我们刚才看到就是说我们整个思想是说我们要把这个资源从Messos批发过来然后呢再去分给这个Spark application那么在这个批发的过程中间就是说我批发过来的时候我进了一个Omesos但是这个里面和Messos的这个有点像贝勒他的主要原因就是说我从Messos拿到资源之后我去装一个Starting TaskSparkMesson Task然后我这个我就不确定我这个Resource还能够分给我了这是和他贝勒一个一个邮件那我们为了做到我们那样的一个批发的那种效果的话我们就使用了MessosDynamicization叫做Feature就是说能够Mixure那个Stores哪怕它StartMessos Task之后还能够回来那么这样这个中间就是说我们会使用的有点我们搞了一堆技术才能把才把这个数记清楚这个地方是比较麻烦的但是其实我们花的最多的纪念的团ity就是说怎么样使用Dynamic Reservation的Feature来把我们那个那个想法那么并且我们在过程中也有一些其他的想法就是说如果我们能够从Messos设计能够到那些知识那么我们能够更好完成上面的一些工作那么第一个就是说Resign已经Start the container这个知识为什么需要这样就是Spark它是个特点就是说我一个Spark它执行器就在Spark Excluer里面它是一个多线程的就是一个Task这个excluer我可以指定它跑两个五个十个这样的Task可以随便指定的当然就是说但是我这个机机上我有可能拿到了一个CPU那我当然过一会我又拿了一个CPU在这个机器上我运在同一个Task同一个Spark Excluer但这个时候我就我希望把这个在Messos里面把这个CPU的CPU的这个Configuration给它加大那么这个时候实际上我们Messos现在那么第二个就是说我们刚才提到我刚才提到我们弄了一堆的技术咱们这个数咱们这个设整明白那么如果说我们在Messos能够提供就是说我们这个能够提供一个比较长久的这个offer提供给我之后它offer idea不变了因为现在就是说我去offer idea我还要去study container它这个如果这个result还给我的话它offer idea变了实际上这个时候我们不能对持一个这个长久的offer如果我们有一个长久的offer idea的话我们能够更好地去做这个resultreuse这个事情那么还有一个就是说我们希望这个在这个Messos之间能够做一些这个reuse的事情因为这样的话就是说我们在虽然我们在Messos有这个row之间的一个有这样的比率的控制当初它现在不是一个强制性的有可能就是我上面的我拿着这个资源有可能就是让非常长的这个进程期期来它一直不释放然后另外的可能就是拿不着它新得的比率再一个说我们也希望能够去如果说Messos能够offer这个result的时候能够把整个机器做offer给我那我能够在上面能够做更好的一些调度能够把这个机器再说说提供给我之后我能够把他怎么样切怎么说的实际都能够做更好的一些事情那么我今天就是说想讲的东西这个后面我们有一个这样的一个也有弹幕然后希望能够让成功因为我们这个还没有做到一个百分之百的环境稳定的一个一个东西那么我们先看一下这个是装的一个Messos环境Messos环境它现在我总共有6个机器一个机器是Massos机器另外5个机器是所有机器能够看到这个这个Agent有5个然后我把Sensual已经在Messos上已经start up起来了这个时候刚才觉得有时候有两颗 会有两颗分布Agent分布那么总共这个CPU的个数是160个然后我们可以当认为转换的数字就有160个sort然后起来之后我们可以看到这个可以看到这个我们SparkSensual对它的负义故意让我们就是有一些信息是说现在的这个run applicationrun application所占的资源这个是整个SensualTotal DemandTotal Addict这个就是分那个Application下面有这个run application这个是上面两个头是个动作的图表然后我现在是想去一下点想先想是往这个上面去提交三个Application每个Application是有1000个Spark Task这个Task实际上没有干净是一个Random的CPU0-10秒之间的这样子的一个操作那我会先run一下这个run我这个把这个提交的那个脚步比较长我们稍后再看一下说一下这个脚步这个脚步然后这个时候我们可以看到这个我们有一千个Task把一千个Task它RequireRequest是1000个而那这个实际上我们的Mapclass只有160个我们这个时候就看到就是说它这个这个地方是160对不了160然后这个Demand是1000个然后这样运行的时候然后Demand才会减少然后会这是一个Application我们就等它转换我们可以再去提一下我一次提一下我一个再起来一个然后我们看它这个资源的这个我们就看到这个时候头的Demand是2000个然后再看这右边的是比如说这个这两个颜色表示不同的这个ApplicationSpark Application然后他们现在实际上是一个1比1的关系因为我们它的Priority是我用Priority来控制了它的这个不这样的不接到那个位置然后我们再起然后它就可以这个时候我们看到3个3个Priority它的很快使得都就把这个机器已经Balance到成1比1比1然后运行完成的时候3个Priority不再运行但是总个这个现在像这样是代表整个所有PriorityDemand它的Task存在Priority的介绍然后它是这个真的分配成立的还是那么多的那么基本上就是这样一个运行完了的时间长就是因为我们刚才1000个Task现在是3000个然后它运行长时间长时间就比较长但是我们已经看到这个它所有的这个Demand是会介绍的然后我们就看这个地方有一个有一个这样的变化这个变化是我的这个这个颜色的运行已经完成了它把这个Resource就让出来给这个两个运行那么这个地方又看了一个变化是说这个这个颜色的它的Task又完成了一切然后它把这个运行让出给这个红色的这样整个就能看到一个它这个非常动它的运行的变化反正行的我的这个Demo就是这个然后下面就是QnA然后对起它那个那个我们右下我们的那个右下角有一个RMA那个RMA是导演我们的那个第一在像KeynoteDemo的那个那个RMA我们可以去试一个那个时候用Debronin去做的图片的一个个律风的转换的一个我想我可以去尝试一下同时有那个IMM系统中心的官方的微信我们可以去玩一玩那个东西那么这个那个东西就是这个后面的Teknology是用的DISPAC然后SenseGalRMA上去去弄了那大家有什么很多问题我们可以讨论一下如果举些例子的话都有一些什么样的一些应用可以在上面让我是比较适合的是CPU Intense还是Io Intense还是Native Intense就是说咱们这个用PFAC的方式上Spark拿到一些results然后Spark里面在做这种Fangrade这种Schedule这样的一个模式适合所有的这种应用场景来的适合一些特殊的成绩问题是就是在我们这种SenseSchedule模式下拿着Spark的Paner可以更好地发挥这个效能那我可以大概说明一下就是首先呢这个Schedule是以系列用的方式来调布的那它更适合那些我Club的Paner的资源变化是比较动态的如果你是衡定的话那你预先知道你的每一个Action的Size或者大小你就使用所谓的Cross Green的方式就可以比较好的完成更好的成绩已经比较好的使用的资源利用率那当你的我ClubPaner会变化比较大比如说一些Inactive当我把这个iPad从放上去我的ACO启动起来之后我并没有与任何Task那在传统的模式Cross Green的话那所有的CPU资源就会即便只有一个ACO那也会被浪费掉那在我们情况下只有当你有Task的时候我才真正会给你的资源这是一种方式另外一种方式就是我刚刚提到在企业环境下当你有这个不同的SLR不同的需求的时候并不是说所有的应用都是一样的服务品质的要求当有些高级GTA一些不合的场景的时候那有特别是还有企业环境下你的统治购物价是比较复杂的时候你用30次GTA可以更好保证你的应用的服务品质就是在两种比较典型的环境下这就是我们反映到我们这个的企业的要求和我们的实现的工作就是第一个LSA Reparment第二个Input Resource Relation那Demo并没有受JPU的资源的调度同时第三个当你更多的时候JPU资源的时候30次GTA是更比较适合这种场景因为只考虑CPU作为一个资源的一个比较要紧的资源的话它是这样子的我说对于其他的一些应用比如说它是对网络的带宽这种它是更加紧张的这种情况这个我觉得有一个问题挺好的就是说它实际上设计了一个S这样的一个多规的调度的问题那么实际上我们现在的Demo Code是CPU等线对Demo CodeCPU等线那么如果说我们想到变成那种多规的那种计考的一种CPU考虑Memory也考虑网络Disc的实际上上面也可以做一种这样的多规的调度也是可以的那样的实际上我们更希望从EOS能够批发到整个的host然后就这样的上面做一种多规的调度我想说明就是对于网络的控制首先Messos已经能支持多规的资源调度因为它提供更多的资源你也可以定义一些资源作为所谓的Consumer Code或者就是作为一个HPU第二条就是SenseScale自己它也能支持多规的调度如果你对网络有要求比如说你的Application你想保证它的带宽多少从分别的角度无论是Messos还是SenseScale都可以但是在保证它的网络资源的时候单单从分配其实是不予足够的对吧分配只是一个所谓的Dimension Control只是我允许不允许你对网络要求的搏扣的运行感头那机器上第二条就是所谓的Enforcement那还需要通过类似C控制控制来保证带宽的资源这时候这些无论是对Messos还是SenseScale都是有一些还需要还需要继续你好然后我问一个Spark调度开销的问题他说我比较关心就是Spark现在它的Task大概可以短到就是这个时间长度极限应该达到什么样子它可以有加速然后我比较关心这个然后第二个问题就是说你没有没有那种Walker它的时间是非常短的那个Task然后但是它的数量又是非常多的它对Scheduler的调度吞吐是要求是非常高的有没有这种场景如果如果没有的话能不能就说一下你们如果对这种场景这个场景就是说其实一个挺好的问题就是说Spark里面它既有这一种就是让几分钟了也让到几秒钟的或者是一秒钟的像那个我们以前特意的Business Regression里面那个一个战斗比如说Task还不到一秒那么这个时候实际上我们这个在Spark里面它自己有有一些Task Scandals它这个就是说我这个Slot分给这个Scrubber之后然后我就持续就使用了这个Slot然后它我给先进这个XQ这个MK能够使用上线并且保持它一个非常稳定或者够Property分够之后我可以比如说我一万个很短的Task然后我要为为一万个Task去申请一万个Slot我是不知道的我可能申请十个100个我就OK了那我也设置这个MK最大的Max那个Slot个数然后这样实际上我已经就是把这个升起少量的XQSlot起少量的XQ这种完全的事情我可以控制得住试试通过这种方式去做然后吊动吊动的你说那吊动的性能是吧吊动的性能这个地方就是说我觉得它取决两个方面一个方面是我们Scrubber从这个在这个从Massage拿资源以及再给多个给你分配之间那个分配的那个性能第二个是说我们在那个SparkDriver里面去拿到资源之后吊起XQ点并且分给这个真正的预讯Task的那一块那么第二个是Spark自己做的我们自己做了一些优化那么第一块呢就是SenseGa里面那个资源分配的能力那我们实际上有十几年的这个经验的积累在这个多线程处理怎么样把这个是有非常丰富的经验我觉得这个地方我们在比如其他产品里面每一秒能够比如说Scrubber几万个我们测试的里面就是大概达到几万个Task但是不是这个一面的不是这个一面的就是说这个地方的能力我们还没有测这样的事情因为我们没有那么大的因为这个地方SenseGa它主要是对于我们没有那么大的积蓄测这个也就是有几万个Sla然后它怎么样去调整这个事情那就是说我们再一个就是说能够配置的一个比率就是说你能够CPU和GPU比如说在GPU上一分钟然后在GPU上在CPU上十分钟然后它通过这个比率的控制如果说你在CPU运行的时间比如说小的通过小的这个比率那我就会去调整GPU上如果是大约一个月我就会去调整调整一个手工的一个配置