个推TechDay | 如何提升IT资源效率，显著降低IT总投入？原创

大家好。我是来自贝联珠冠的大数据团队的杨少华。呃，非常感谢各位的邀请，让我来分享一下被人主管在呃降本提效方面的一些工作。好。呃，这是我次本次分享的一个一个提纲，这个提纲主要是会从这几个方面来做一个分享，第一个是会介绍一下呃，全球的it资源的一个效率，效率的一个现状，另外一个会针对这个现状介绍一下被人主办这家公司，他究竟是，呃为什么成立一家这家公司，究竟是来做什么事情的。第第三个事情就是会分享一下我们在。呃，降本提效方面的一些核心的技术，这里面，呃包括这对像大数据任务的一些优化，呃，还有一些混部计算里面的一些核心技术。

好，首先我们来讲一下现在全球it资源的一个效率的一个现状。呃，麦肯锡有一个报告称，全球的服务器的全天的平均利用率只有不到10%。呃，这个可以说是一个相当低的一个水平。但是有几家公司是做的不错的，做的不错的第一家公司是谷歌，谷歌大概平均的全天的服务器的利用率大概能做到百分超过50%。另外像阿里、百度等。这几家公司可以平均利用率可以做到30%。呃，当然这几家公司都是，呃，全球头部的互联网公司，他们本身，他们本身的业务需求，对资源的优化跟利用率的提升，有非常大的一个诉求。

另外。呃，所以他们本身的机群的数量非常的庞大，所以他做这样的优化可以带来非常呃，非常高的一个一个ROI。呃，另外从我们的经验来看，如果服务器的利用率从10%能够提升到20%，那这样的一个水平，相当于我们的利用率可以提升一倍。呃，这样的话能带来如果对一家公司来说，他总的ID投入大概能降低30%左右，呃，之前我们在阿里的经验大概也是能做到30%的一个成本的降低，呃，这这个比例在一个公司来说还是一个非常大的一个比例。对，这是全球服务器的一个利用率的一个现状。呃，第二个事情像呃，因为现在企业上云也是一个趋势，很多公司也希望通过上云的方上云能够降低企业的it成本的降低，但其实呃。

呃，上云后，其实并不是说it成本能得到很好的下降。呃，Flex的美国有一家创业公司做了一个做了一个分析，他访问了很多的创业这云云上的一些企业。他们发现这个企业上云之后，其实并没有成本的下降，反而呃，有可能会更高。呃，大部分有很多企业他上学后，他呃利用率的呃，平均浪费了30%的云的支出。呃，云成本的优化其实是二一年很多企业最想做的一个事情，在这个报告也显示的，呃，他访问了很多云上的企业，他最最想做的三件事情，其实前面的两有两件事跟云的呃成本缩减相关的。

对，然后另外一个角度，对于云厂商来说，其实他呃并没有去做这种资源优化的一个动力，因为云厂商本身它的一个生意模型就是希望大家能共享他的资源，所以其实企业用这资源越空闲，对他来说越有利。呃，基于这样的一个背景，呃，我们成立了贝林珠冠这样的一家公司，呃大家听这个名字也很怪，这是呃，这是一个成语，就是说被被珠连贯在一起，非常整齐，整漂亮，形成这个排列的非常整齐，这个我们为什么会起这样的一个名字呢？因为呃我们想如果能通把这个服务器的资源跟服务上面，服务器上面跑的这些业务能够去很好的去做一些编排。那可以得到一个更好的一个利用率的，利用的一个效率，呃，就基于这个我们起的这样的一个名字，当然也另外一个原因是因为起个名字真的是挺难的，呃，要起个好名字还是不容易，然后这些公司的本质上我们是想，呃是一家这个为。

为降能够显著的降低客户在在it方面的一些投入的这样的一家科技公司。呃，下面简单介绍一下公司的这个一些情况，第一我们从下面看，大家看下面的这张图。呃，这个这个图示意的就是说一家业务公司，他通常会有两个方面，呃业务的发展通常会关注两个方面，第一就怎么去外部去拓展自己的客户，第二会关注自己的内部的效率，呃内部的效率通常会分为两个方面，一方面就是组织人员的一些效率，第二方面就是我们的服务器的效率，就我们叫it资源的效率。呃，然后对于服务器的效率，通常会有一个核心的指标去衡量这个服务器的效率，它就是这个这个资源在全天的平均的利用率。

呃，它是衡量这个资源的一个效率的一个核心指标。嗯，那这个这个平均的利用率，其实直接决定了我们在it方面的一些总的投入。然后贝林猪冠就是这样的一家公司，他希望通过一些呃产品技术方案，能够帮帮助客户去降低他在it方面的总投入，呃核心的手段就是帮助客户提升他资源的使用效率。呃，这个是我们成立这家公司的初中，初中那这家公司很年轻，他是去年才成立的，二一年才成立的，呃，核心的团队包括有六位像阿里的，呃技术专家，呃有我们有六位P8到P10的技术专家，我们这个团队其实是完整的经历了阿里巴巴it资源效率的完整的一个过程，包括怎么去把大数据的集群的利用率从百分之低于40%提升到70%多。

然后从阿里巴巴整体的服务器的效率从低于10%提升到20%几，这当然就是呃，给阿里巴巴带来了非常大的一个呃，大概近10亿的一个成本的节省。呃，在这半年多的时间，我们成立一个50个人的一个技术团队，这个技术团队覆盖了像操作系统的内核。呃，在线的资源调度，大数据平台，还有多云产品等。几个技术领域。这是我们公司的一个简单的一个介绍，和我们一个公司的一些核心团队的一些成员的一些介绍。好，那下面进入我们的一个正题，就是呃，讲一下我们在it资源技术，It资源效率提升方面的一些核心的技术，跟大家分享一下。呃，我们首先来看。

呃，现在企业对服务器资源去使用，它有哪些特征？呃，我们可以把我们公司的，呃，把一些典型的一些公司，它的机器资源的分布可以分为这几个方面，第一有大数据离线计算的集群。第二是有大数据，就非离线的一些集集群，还有在线业务集群，大数据离线计算的集群，主要会就是经常是来做一些ETL的一些大的数据的一些呃分呃呃加工整理。呃，这里面呃通常是一些像Spark or Mr的一些任务，还有一些像机器学习里面的模型训练等等，呃，那他们使用的开源的呃底座像一样。呃，一个一个复制资源调度的一个一个组件，还有像test flow或排等等，呃，最底下是像分布式文件系统，像SDFS，然后在这之上还会有像FS、卡班等等这种任务的调度系统，那这些组成了我们整个大数据离线计算的这样的一个集群，通常大数据极限计算的集群在一家公司里面占到的比例会分非常的高，有的甚至会将近50%的一个占比。

那除了大数据领域，除了离线计算，还有其他一些非离线的计算，非离线的计算点像包括我们像实时计算的一些集群，实时计算，还有交互式分析，以及呃，大数据在线的数据库，还有像算法的在线集群等等，这些它跟离线计算有很明显的一些不同的特征。呃，而且现在像实时计算很多公司他是呃越来越看重，呃很很多是从离线慢慢的转向这个实时计算。那实时计算现在典型的呃，一些开源组件，像卡夫卡，像link等等。呃，交互式分析现在是百百花齐放，比如像呃，K house，还有dori，还有包括以前的那个呃，还有P等等，这些属于交互式分析集群。

呃，当我们数据加工好之后，还要把它这变成一个在线服务，就在线服务包括像1SEARCH啊，H base啊，漫DB啊等等，呃，还有一些算法在线的一些特征的一些服务等等。呃，这些组成的一个非离线的集群，非离线的集群虽然没有离线的群那么大，但是它其实也是很呃，在很多公司，有些公司里面，它占比其实也不小。那另外一个就是在线业务，在线业务像电商有电商的，呃，服务端啊，APP的服务端等等，呃，这些是跟公司的业务是紧密相关的。呃，这三我们把这个服务器资源就做这样的一个划分，因为在很多公司里面其实也是这样的划分，而且他们都有对应的独立的独立的这个集群。呃，其实从特征的角度来说，离线计算它通常是有很高的负载，比如这个这CPU可以跑到将近100%等等，那另外一个它它的峰值主要是在呃，凌晨。

呃，甚至有些公司可能全全天都很繁繁忙。然后另外一个就是他对作业的延时其实不太敏感，就是稍微晚一点，他可能对业务的影响其实并不大。呃，另外一个就是容错性比较高，因为大数据软件本身它会考虑容错。呃，另外第二个是大数据非离线的集群，像这部分机群的话，它负载也是比较高的，呃，它延时相对离线来说也比较敏感。另外一个就是它呃部分的这些离线的集群，它部分的高峰跟业务，跟我们的业务是会有重叠的，有可能白天某个我们业务的分高峰时段，那对应的这个大数据非离线的这些集群，它可能也是个峰值。呃，所以他就就高峰就是这个这些集群，它的高峰跟低峰低谷，呃，这个时段往往是比较明显的。然后另外一个就是在线业务，在线业务的话，他的延时敏感是非是非常敏感，因为在线业务有可能直接呃直线面向业务呃客户，所以他的延时敏感性很强。

对，如果这个另外一个就是它的高低峰也是明显的，因为我们很多业务可能都跟我们的业务相关，比如说呃，早上某个时段或中午下午或者晚上某个时段，他的这个业务是高峰。呃，但是他整体的全整放到一整天来看，他全天的利用率往往是偏低的。所以我们把呃，服务器资源往往就是说离线计算，大数据的非离线和在线业务，呃，在很多企业里面，这些机器它往往也是独立去部署，相互之间是分开的，分离的。那我们再看一下福利服务器，现在呃，刚刚讲的全球的这个it资源，It的资源的使用效率都不超过10%，呃，那么他整体效率低的原因主要只有有这几个方面，第一，从单个集群来说。

他可能达到的资源的瓶颈，这里面包括一些这样的一些问题，像包括这种任务的应用的，它的并行度不够高，可能比较低，处于比较低的水平，所以没把这个机器的资源给使用上去，但是如果把这些任务或者应用把它并行度提升上去的话，那可能会导致一个稳定性的降低，所以这方面有技术风险，很多公司呃，其实在做这样的决定的时候，他也不敢很冒险去提升这个并行度。是第二个事情是，如果对于多个集群来说，因为多个集群是分开部署的。那整体的利用率会比较低，因为因为我们在准备一个集群的时候，往往会根据业务的高峰去准备这个服务器的资源。那所以他在低谷的时候，这个服务器资源往往会比较空闲。呃，当这个集群被分开部署，然后被某个业务去独占的时候，他也没办法把他低谷，低谷的时候的资源去共享给其他的业务。

当然就是这里面大家可能很容易就想到这个混合部署，所以混合部署也是一个有效的手段，包括这些大大厂，像谷歌，还有阿里、百度，其实他都在做混合部署。但是我要部署现在也比较高的这技术门槛，需要解决不同业务之间相互影响的问题，嗯，所以现在也是仅仅有这几家大的互联网公司才能做到说很好的去混合部署。呃，而且他们需要有很高的技术投入。呃，当我们了解呃分析一下呃效率低的原因和单曲情的原因，还有多剧型的原因，那我们针对这样的一些呃问题的话，呃，我们想到的一些几个大的解决方案啊，包括这些解决方案，我们也在，也在阿里的时候也呃也是用这几个呃方案去提，把阿里的这个计算集群做了很大的提升。那首先我们来看一下单集群的方案，就是我们先关注于大头，就是离线计算的这样的一个集群，对这样的一个集群来说，如果要提升他的效率，通常有主要的手段有两个，第一个就是我们把我们的计算引擎去做升级，升级到新的版本，或者升级到更更优秀的集群，譬如像have到升级到10SPARK等等。

呃，这样的一个版本升级，其实涉及到业务上的一些改动，还有呃，大家呃呃主要是业务方，业务上的一些要做一些变化，那其实这个这样的一个升级的方案，通常是由企业自己来主导完成。第二个事情就是怎么去提升我们任务的并行度，因为刚刚我们也提到，呃，提升任务的并行度其实是有技术风险的，他可能降低了你这个集群的稳定性。所以其实我们其实是要有一个比较安全的稳妥的一个方案去提升这个，呃任务的并行度，那这里面有几个重要的一个技术，呃，就是我们在用的一个一些技术，呃一个像叫HBO，就是HP，叫history based，就基于历史统计的优化，就是我们知道说我们的任我们大数据，像离线的任务，他其实每天都在运行。

每天都在运行，他每天处理的数据量也是呃差不多的，呃，只是说我今天处理金钱的数据，他只是处理的数据是发生了一些变化。那但是他计算的呃规模或计算量其实是差不多的，那我们通过它历史运行这些数据，呃，历史运行数据进行挖掘，然后去得到针对这个任务有没有更优的一个配置参数，通过这个配置参库的一些优化，可以让他的并行度可以可以更高，但是因为我们考虑的通过历史的方式去挖掘，所以我们设置这个参数的时候，可以通更个性化一些，对每个作业我们可以去设置一个一个不同的呃适合他的一个一个参数，那这样的一个方式，其实对于运行这个作业来说，它其实是会呃更更稳妥的一个方案，所以他不容易造成这个作业失败。

另外一个就是我们要把这一套，呃，从历史运行挖掘到最后呃去把这个生参数去生效，整个过程变成一个自动化的一个调优的一个过程。呃，所以我们这里是支持说。嗯，能够通过运行时，运行时注入的方式去自动优化我们的大数据的那个作业。那另外一个角度就是我们在做这样的事情的时候，需要需要去优化验证之后要逐步的能够灰度。而且能支持多重的保护机制，PU这个作业失败了，我们能够呃Q用原来的参数进行运行。呃，这样的话就尽量避免我们因为提升提升这个任务的并行度导致的这个作业的一个失败。呃，当我们大幅就通过这样的一些手段，我我们可以大幅提升离线计算的一个执行效率，根据以往我们的经验，呃，机器利用率的提升通常可以通过这样的手段，可以提升到70%以上。

呃，70%这样的一个水平，其实是一个很很高的一个水平。呃，通常现在很多的公司的离线计算这一块的资源利用率可能只有40%~50%。对，呃，这个右边这个图是我们产品的一个一个架构图了，就是作业通过一个客户端的H或者JDBC的方式提交，提交，其实提交的呃，最终还是提交到客户的那个样的一个集群。但是在这个提交过程中，我们通过户口的方式把我们自动自动的把这个参数下发注入进去，但是这个户口的这些参数会通过一个比较历史方学习挖掘的方式去。去得到，呃，通过获取这些任务它历史的运行数据，然后进行分析，通过一些规则去生成新的那个配置参数，然后这个过程也会不断的在迭代优化。

那这个是产品层面的，呃，一个架构。对，当这个离线计算的集群的效率提升提升了之后，其实我们需要考虑说。啊，那我们可以考虑说离线计算跟其他的集群，呃，怎么去做混合部署，比如包括大数据内部的，大数据内部的非离线的，像交互式分析，在线数据服务等等，呃，考虑我们怎么把离线的作业调度到这些非离线集群的集群上，呃，这里包括像在线的业务应用。这样的话，我们如果把离线的作业跟他这些其他的业集群进行混合部署的话，那其实我们可以做到错峰的使用，但是要做到错峰使用的话，需要解决两个比较大的一个技术问题。第一个技术问题就是我们。

那这个混合部署在一起的话，那我们整体的资源怎么去做调度。就要分配给哪些资源，比如说哪些哪些业务也可以得到更多的资源，这个是需要我们去解决的一个，就整体的一个资源调度的一些，问一个问题，当资源都业务任务都调度在单机上，那我们需要解决在单机层面的这种资源的隔离。就说我们需要说去保障，说更优先保障这种优先级更高的业务，然后这个低优先级的一些呃业务，呃，可以可以给那个高优先级的业务去出让一些呃资源包括。呃，QOS也会更更低一些。呃，那这样的话，第一那这两个核心的问题，第一个核心的问题是集群资源调度，那我们现在是围绕着K8S生态去做的，呃，其实在在K8上面以插件的方式能够部署到，呃能够能够进行部署，这样的话对整体的轻重性会非常的小。

嗯，左边这是我们整个技术架构的一个一个图，呃，那我们可以看到最底下，最底层的话是，呃，操作系统层面，操作系统层面其实更多的是我们会利用这个内核的资源隔离的一些技术，然后保障说我们在单机层面不同的业务，它的任务相互之间，呃。呃，可以，相互之间的影响会更小一些，那同时它整体的利用率也会更高。然后在这样的利用这资源隔离这些技术，我们会有我们的A上面会每台机上会部署我们的agent，呃，这个agent是以K8S DEMO set的方式去部署的，它其实也是一个插件化的一个一个方式，呃，那部署了这个agent，它可以采集一些数据，然后在一些极端的情况下可以做一些。

可以一些动作来保障这种呃，更高优先级的任务可以得到更好的保障。然后在这上面就是我们运行的各种各样的业务了，呃，通常另外一个就是我们在资源调度方向，我们会定制一个KS的一个调度插件。然后这个调度插件会去，呃，去动态去调节。在在离线混部场景里面，这个在线跟离线，呃，他们之间的资源的呃配合。另外一个到了单机，单机资源隔离的层面，那我们会根据不同的负载的情况去调整不同的隔离策略，这其实本质上也是一个呃定制，然后不断优化的一个迭代的一个过程。呃，当然这里面我们会先通过手工调优，然后自动调优，最后我会通过AI的方式去做调优。对，当解决这两个技术，这两个大的一个技术问题之后，按照我们以往的经验，往往一台在线的机器混合部署之后，相当于可以提供出来0.5台大数据机器的一个能力。

呃，当然这里面在线机器我主要是说它的，呃，它的规，它的规格跟这个大数据的机器的规格要一样了。对，如果是能做到这样的话，其实对于我们整体的大数据机器预算来说，它可以降低，因为你可以不不需要去购买新的大数据的机器了。然后你只要去复用说现有的非离线的这种在非离线的机器，也包括在线业务的机器。刚刚讲到就是单机层面的任务，任务的一个弹性隔离，呃，这这里再具体讲一下。就是如果这里面，这其实是一个很大的一个技术挑战，之前在呃阿里的工作其实也遇到了，在做这个事情的时候遇到非常多的问题。

呃，因为呃不同，我们想想不同的任务调度上来，它其实特性都很不一样，像在线的业，在线的任务，它其实呃，你比如我们像Java的呃，Spring的那些呃任务，Java的一些任务，或者是go啊等等，它其实它更多是一个web服务。呃，它的延迟敏感非常高，但是大数据任务往往他一一起来的话，它这CPU内存它就会占的非常高，他有可能有可能会把这个机器跑死，也有可能把这个呃大数把在线业务的那些进程给给呃。呃，把他的他的刺眼，把它字眼也吃掉。所以我们在刚开始在做这个事情的时候，其实也出现了很多很多稳定性方面的问题，包括这个机器宕机啊，系统挂失挂死，呃，系统系统系统焊住啊，包括内存呢，呃，网络还有流量等等这样的一些问题，其实就是在在把大数据的任务跑到跟在线业务在一起的时候，往往大数据的任务就会把这个机器跑的非常非常的满。

但然后内核或者哪个地方哪个策略处理的不够好的时候，那就有可能是呃，甚至会宕机。然后另外一个就是即使即使没有宕机，但是这个业务业务的那个进程就呃业务业务的应用，他往往的QPS会受影响，就用QBS，可能原来是呃100毫100毫秒，但是如果大大数据的作业，离线的作业跑过来，那有可能很快就是呃150毫秒是两毫米等等，它其实还有像业务一些毛测，因为像IO的一些IO一些控制，如果控制的不好，不够好的话，那当离线这个IO涨上来之后，他的业务的类，它有很多的毛厕。呃，那另外一个角度，这是对在线的影响，那另外一个角度来说，如果我们把这个隔离或者对策略做的对，呃对离线非常不友好的话，那离线本身他的作业的完成度也会降低，所以他其实是一个平衡，怎么去平衡说在线跟离线之间的，呃，这个影响。

嗯，这个这个这里面也其实有很多经验，有很多场景在这里面。呃。那这样的一个就是我们需要一个好的一个弹性隔离的一个技术啊，既能保证在线业务不受影响它的呃，RT它的类是稳定的，另外一个对离线的任务来说，他也能有比较好的完成度。啊，这里面的话就是涉及到呃如何去做隔离，那这里面当然就是Linux操系统现在也在不断的发展，呃，像做隔离里面最核心的技术，像group技技术啊，这方面我们会做去利用和改进这个，呃这样的一些技术，然后呢，我们会模拟各种混部计算的各种场景，去求解最优的这种隔离跟共享的策略。另外一个就在极端的情况下，我们优先级高的或者核心的任务，我们需要有一个好的一个保护机制。就是说当。

这个呃离线呃高优先级的任务，呃在在在这个集群，在这个机器呃负载非常高的时候，我们能够去驱逐这个低优先级的这个任务，这这这样的话就对整体呃就比较安全。对，刚刚讲的就是我们在呃在做混部，还有大数据任务优化的几个核心的技术，呃下我们稍微总结一下，呃呃本次的分享。呃，首先我们看就是呃，提升it资源的利用率，它其实是一个降本提效的一个非常有效的一个手段。呃，然后我们公司提供了呃，跟这个相关的两个前产品解决方案，一个是大数据任务优化的一个解决方，另外一个就是混合部署的一个呃技术方案。当然就是说这两个不同，呃，我们会在不同对客户他有不同的阶段，不同的阶段会有不同的一个解决方案，呃，譬如在离线，如果他离线任务的集群，离线集群它的利用率呃水平还没有那么高的时候，那我可以用我们的这个离线任务优化的一个方案。

呃，那通过这个通过这样的一个优化，把大数据，把大数据的离线的集群的利用率可以提升的比较高，比70%以上，然后呃，也是这样的一个过程，也是一个影响比较小的，然后收那个见效比较快的一个方案。呃，当我们这个离线的集群的利用率提升到一定的程度之后，那我们可以考虑把离线作业跟其他的任务去做，做混合部署跟分享，包括我想非离线的作业，包括像实时计算啊，交互式分析啊，在线大数据啊等等去做分析，呃，混合部署跟共享。然后在当我们整体的大数据的呃，机器的利用率达到更高的水平的时候，那我们其实可以考虑说我们大数据跟我们的在线的业务怎么去混合部署，呃，那其实这呃，那到在线业务的话，那就。

呃，会更呃从每个阶段来说，其实从技术难度来说，它其实是呃更高的，呃另外一个它也是一个逐步逐步递进的一个过程，但但是从收益的角度来说，他这三个方案它的收益都是会比较大的一个收益，就看说我们每个企业，它它处于一个哪个阶段。好，呃，从从整体来看的话，我们希望说我们通过我们的这些技术，能够帮助客户把他的机器的利用率有一个呃上成倍的一个提升，那对于他整体资源的呃成本来说也会有比较大的一个下降。好，本次分享，呃。到此结束，谢谢观看。