超级访谈：对话毕玄_15_09统一调度只是问题非常多而已摔出来就行了
你好，我是叶谦。
上一讲呢，我们聊到一六年碧须园，拆完运维之后呢，去带了系统软件事业部和研发效能部的经理。
对于高层根本不感兴趣的研发效能团队啊，定位是一个大问题。
在做了一通现状分析之后呢，玉璇终于找到了清晰的发力点，短期做代码智能化，长期解研发模式和环境干扰的问题。
但是对于另外一个团队系统软件部，虽然高层当时给了明确的目标，但是他却说做的也很不顺利，最后能做成也很难讲。
可能时机比较巧，作为自己在阿里十四年里的第三大亮点啊，统一调度的成功呢，它居然归因于时机到底发生了什么呢？让我们跟着这位亲历了这个集团级项目的总架构师，一起听一听。
当时他分析有哪些障碍，又是怎么处理的。
呃，研发效能之外就是去做了统一调度。
那当时这个目标是什么？嗯，本质也是成本。
阿里内部啊以前有好几套调度系统，这次呢想做成一套统一的，我们叫西格玛啊，向bog的下一代欧米伽致敬调度我们做了很多年嗯，一一年做容器，t four就是嗯核心目标就是为了去控制成本。
当时呢我们是做了两三年，大概知道了这方面google的bog做的非常好。
那个时候呢是传闻说google认为自己的核心竞争力是什么？就是最早他又做搜索啊，他认为自己最重要的竞争力呢是一我排序的结果的准确度要比大多数的公司要好。
嗯，二呢是同样的效果，我付出的成本呢是你的十分之一啊，这确实是如果成本能够差这么远的话，商业上感觉就没有办法做下去了。
哎，这里面google是觉得调度系统bog是承担了很大的角色啊，类似它的page rank算法啊，是整体竞争力的一个部分。
所以说呢外部是很少有bog的信息，保密性是做的非常好。
那来我们才做了一点点。
那一五年google发表bog论文，那其实几年前就写好了，只是内部一直摁着不让发，绝大可能对业务的这个核心竞争力有影响。
所以你们一三年那个时候了解到那个信息是什么呀？那个信息就是个思路，就是我们知道了以后都觉得哇这个思路简直太完美了。
那其实大家都能想到，但是我们就需要有人给信心。
因为这个思路啊大家都觉得太难了啊，那这个思路是什么？是这样哈，就是呃因为大多数公司的机器啊会分成很多个池子。
那最典型的一个机器池子用来跑在线业务啊，另外的一个用来做大数据的业务。
那大数据这个软件的核心设计思想呢就是尽量并行化啊，把一台机器的资源全部给吃光。
所以大数据特别吃资源，能够把池子啊用的特别满。
然然后这个在线的业务呢不是不想吃资源，那它必须去考虑的是什么呢？啊，是稳定性啊，因为如果出了问题，我最好要有足够的冗余啊，那加上呢AT啊，还有很多不确定的高峰。
所以我机器的余量一定是为高峰去准备的利用率啊，就没有办法很高。
那像在线的机器量，嗯，可以说根据高低峰来做伸缩吗？嗯，这实际上是一个悖论，因为对在线来讲稳定性是最重要的啊。
如果你不断的去伸缩啊，万一出问题了，可能得不偿失。
嗯，因为很多的高峰它是无法预测的。
你看即使呃淘宝看起来是做大促才有高峰。
但是如果有个社会热点，那除了微博淘宝也是会受影响的。
以前比如说呃谁出了名啊，有一件衣服同款啊，那就立刻就爆了。
那这种事情其实没有办法去预测了，除非呢说呃你可以做到秒级以下的伸缩。
那可以啊，我后来带这个调度也给了人去探索这个方向，但必须说真的是挺难。
但至少说呃目前我们觉得技术上很难讲突破啊，伸缩的风险不那么可控啊，所以是一方面大数据的机器是用满的。
然后另外一方面呢是在线的机器比较空闲，但是在线呢也不太好去做伸缩。
哎，很多公司到了一定的规模，在线的机器增长就其实还好，因为跟在线业务基本是成正比，就是QPS嘛。
那比如说现在一百啊，明年你希望做到两百，那我就加机器啊。
同时因为每年的机器比上一年更好，所以从预算的角度来讲，公司觉得是合理的那业务增长百分之二十。
那你机器的增长，比如说百分之十五，当然可以以那至年你没多机钱可以接受，但是大数据就有问题了。
通常呢这个大数据机器啊只要开始用了，每年的增速就会越来越快，因为存储量一直在那。
而大家想采集的数据的细节会越来越多，这样才能够去更精准的画出特征。
嗯，所以大数据的机器就会多啊，另外公司的这个经营一定会越来越难以前增长，是比较容易获得，可以粗放式。
但是后面你肯定是要去做精细化的，但是精细化对大数据的要求又越来越高，所以机器会越来越多。
那这个时候呢呃技术层面让大家就很容易去想到一个方案啊，既然在线这边这么混，大数据这么满，那能不能合在一起让这个大数据用在线啊，这就是当时bog给大家的核心思路啊，就是说把在线跟离线去做混固。
对，但其实bog自己压根就不是这样。
那诞生的时候啊，就认为这两个本来就应该在一起。
我们以为啊一组机器去跑大数据，一组机器去跑在线。
嗯，那他开始他一开始就会认为干嘛要分啊，所以这就是google啊，所以是他拟练非常先进，就是说都是机器啊，我只是时而去跑在线，时而跑离线。
哎，这个你说对了，就是google觉得反正我的机器在这儿了啊，该跑啥就跑啥，能有什么机啊，这个机器只能用来跑这个的。
没有。
那google当年有一个高管跳槽到百度啊，他第一次看预算的时候，发现哎还分大数据机器和在线机器。
那他就很疑惑说为什么还要分机器类型的？他说我们从来不分。
那后来百度是做了metrics,那拿了两次一百万美金的百度最高奖啊，其实百度的metrics的思路就来源于google.嗯，所以这个思路倒是很直白的那这个思路大家确实也是能想到，那google反应该这么干。
嗯，那多多就就问了，为什么不这这么干？那那定定是有这因的那首先啊从技术上讲哈，大数据跑到在线确实是有很问题啊。
首先以前机器就跑的最典型的就是通常在线的机器是一块盘。
那大数据的机器是十二块盘，因为它跑的时候需要算非常大的数据嘛。
但在线以前的数据量非常小大，数据上去跑的时候呢存储不够啊，大家觉得没法搞。
另外呢物理的这个基础设施的条件有要求。
第一呃，在线的机器和大数据的机器，它得在同一个城市。
比如说a到b的网络，我们叫成绩带宽。
那如果说不在同一个地方，那意味着要走这个。
但成绩带宽的这个网络带宽非常贵，你如果跑大数据就不得了了啊，就是要求非常高，所以这条路是不可能的。
所以首先要的呢就是大数据和在线搬到同一个机房。
而且当时这个物理设施除了机房，还有网络的问题。
以前我们的网络是千兆啊，对于这个大数据来讲是不够用的。
第如要网兆以及更高千兆，就要搞各种各样的限制，所以也很痛苦。
我们一四年只能在上海的方搞个小的测试的的试验环境，嗯，去做一些试验啊，除了这个基础设施呢还有干扰的问题。
因为大数据任务会吃光所有的资源啊，如果你在线也同时跑，会不会影响到在线业务的稳定性？如果被干扰了，导致你响应的时间下去了就完蛋了。
那在线的业务会不惜一些代价去保稳定性。
你想你业务都挂了，省钱有什么意义吗？对不对啊？那像以前就是呃机房分开，这个也是出于成本的考虑吧。
对中国这个西部城市，比如说内蒙古电非常充足，那电费就非常便宜，加上温度呢通常是比较低，所以建机房就很好，很省钱。
但是问题是互联网的出口呢通常通常又是在这个一线城市。
比如说北京、上海这一个点要做在线的业务啊，是需要互联网出口的。
我必须在这些城市或者是附近。
那这就奠定了以前大数据在线啊都在不同的机房。
所以google这个思路呢，一开始在中国就做不了。
那当时我们面临的第一个挑战是这个呃怎么说服高层的阿里高层去建一个大的机房啊，在线和一线搬到同一个地方去啊，但这对任何一家公司都是一个非常大的选择。
建一个大机房是几十亿的投入啊，要找到一个地方，电费便宜，也要在这个互联网的出口附近也要去探讨清楚RI到底是什么。
因为开始肯定要增加投入，嗯，以前没有这些这些，那现在砸好些钱，你到底能不能省回来啊，这就是那个论证的问题啊，所以机房问题只能等公司。
那没办法，现在阿里是建在张北、南通等等几个地方。
但你看这个几个地方显然都不是大城市，但是离大城市呢又不远啊，既享受了电费气候，又享受到的互联网出口啊，这就是非常好的选择。
百度呢最早在阳泉呀是啊建了一个三十万台机器大机房。
然后阿里是一五年建的，张北啊，腾讯也开始了，然后后来思路呢就全部统一了。
嗯嗯，后来阿里建的是因为说服了高层，还是说看别人百度也做的那倒不是阿里有很多原因，主要还是因为云起来了。
那对我们来讲，就是小机房的效率不是很好。
那所以后来统一调度能做也很难讲，可能说是时机比较巧，反正嗯后期走这个方向的公司都很痛苦。
因为你前期走物理设施不是按照这个来的。
嗯，啊像google是一开始就这么来的，所以他根本就不存在这个问题。
我们后来走这些路的都很尴尬。
那当时问题非常多啊，有这么多问题感觉都没有解法。
那你当时做的时候有信心吗？信心是有的，因为呃统一调度啊，说实话跟做意义多活不一苦。
这一次呢是有参考对象，只是资料不公开而已。
但是大的思路是在的，所以说你的这个大的方向是有的。
那异地多活是没有大方向的，纯靠自己去摸索，完全不知道能不能走得通，很可能会走挂了。
但是调度啊我们觉得呃google能干成，那至少这条路走下去应该没有问题，不会走不通，只是说要解决的问题肯定非常多而已。
嗯，啊但在阿里呢必须说我们就做这件事情的难度比百度更大。
百度呢是高层去push大家这样走，而且大数据团队有很强的动力。
嗯，在阿里我们有很强的动力。
但是因为我们是在线业务团队，不是大数据团队。
那这个事情想做成很多工作呢，是需要去给大数据团队去做的那当年呢他们是还有很多别的事情要干，觉得这不是我重点。
嗯，所以各种原因呢，尽管我们是从一四年就开始做了啊，呃这展一直是比较慢。
那物理上的限制是等一五年建了大机房才有的可能性啊，然后网络要升到万兆啊，上面升级到二十五g四十g一百g那到了一六一七年那个时候网络都具备了，也就没有问题了。
那剩下要解的这个核心问题呢，就是大数据对在线的干扰，还有两边机器的磁盘不一样啊。
呃磁盘问题。
后来网络因为比较好了嘛，是不是就解决了这个问题？网络升级之后呢，我们就可以去走这个计算存储分离。
嗯，但计算存储分离内部当年的争论也非常大。
原因呢就是大数据软件一开始的这个核心设计思想。
那除了是高度并行充分去使用资源，还有一个呢就是存储和计算一体化。
就是调度的时候呢，会尽量让这个任务和存储啊在同一台机器上这样算起来最快。
但是你现在告诉大数据团队，不要放在一台机器上啊，这其实是挑战了大数据的很多思想。
所以内部的这个争论是非常巨大的。
但是我们反正可以逼着你必须走这条路嘛，比如说卡预算啊，各种啊，就是跟当年一地多活一样，不给你分机器。
对，因为我所有的机器都是没有磁盘的，你必须走分离，否则我在线给你机器你也跑不了。
嗯，啊所以说基本等一六年阿里开始大力去提统一调度啊，也有了正规军，很多问题呢才慢慢的去被解决。
一是物理条件具备了啊，其实是一八年才具备的。
但是大家在一六年开始探讨，觉得这个方向可行，嗯，基础设施呢就去配套准备，所以大机房网络就都在那那两年完成了。
嗯，那个时候大家的认知也都统一了。
我觉得很大的原因是预算上大数据对成本的压力已经非常大，必须要控制哦。
但是这个控制的思路呢，我们是探讨了很久巨大最好，最完美的仍然是google.你想哈在线呢有一大堆的机器在手上，但是如果能把大数据跑上去，相当于是不用花钱的。
嗯，啊大家拍拍脑袋都会觉得哎能省好多钱，是个好好的方向。
嗯，所以现在网络问题解决了，那现在就剩下干扰的问题。
对，就是阿里的操作系统团队。
那系统软件部嗯在我一开始组建的时候呢，操作系统团队可能是只有十个人左右，人很少。
然后到一八年的时候，大概有一百个人，主要就是为了去解决干扰的问题。
嗯，那当时你们做的时候有具体的方案可以参考吗？嗯，没有google,尽管在论文里提及一两句啊，但是不会去讲更多的细节。
他的论文的风格一般是这样，只是说告诉你我很牛，但是要怎么做到这么牛。
不会讲，你只能去自己去实践，那我们就必须靠大量的人力去堆。
那在这个过程中啊肯定会出问题。
那只要是出了问题之后，有专业业人，那就可以把问题啊去迅速的解决掉，那就能做啊，所以我们其实是这样摔出来的啊，也没有什么。
那这近微软一方面是公司信任啊，另一方面是我们的在线业务有回滚容灾等等更多的策略。
那也有异地多活可以去切流量，相对来讲呢是在一个比较安全的情况下去做尝试。
那所以我们也不太在乎啊，出了问题就把流量切走。
那呃当时尝试的结果怎么样？嗯，从一六到一八，我们大概是跑了一万台机器，相当于是在线有一万台可以给离线用。
那一年离线是少采购了五千多台的机器，一台假设是十万的话，那你看一年省了五个亿啊，关键关键是不光这一年啊，下一年我只要继续扩大在线的规模，就是继续省钱。
嗯，那到后面每年省的钱会越来越多，因为技术已经是成熟，可以被复用的了。
嗯，那方案上技术层面上肯定不会有太大的问题，剩下全是工程啊，工程是很缓慢的。
你就算是技术走通了，把工程上的完全落地也要一个周期啊。
那这里呢可以用一个指标去直接体现，那就是公司所有的服务器全天的平均利用率。
像google就只看这个指标，嗯，啊，大部分的公司应该都小于百分之十啊，阿里一六年刚开始做的时候是百分之八，然后google发表论文的时候利用率大概是百分之五十。
那就这就意味着哈google只用了五分之一的机器就可以做。
同样的业务比他讲的核心竞争力是非常接近了。
为什么差距会这么大？呃，中国公司更难的是因为我们不是全球化的大数据是很高。
但是网上没有在线流量啊，那就是零嘛，所以你平均一下就完蛋了，利用率就很低，所是国外很多公司会好一点。
以前我们问facebook这个问题啊，就是因为facebook没有学googook走统一调度啊，我们为为什么像facebook说呃，我在线业务全天流量都还挺高的？因为它是一个国际化的网站啊，全时序的覆盖。
那我们没有啊中国公司这一点却是个问题。
所以那个之后利用率就成为你们重点关注的一个指标。
阿里每年就在不断的去推进这个利用率指标啊，我们甚至讲到连财务都理解了。
嗯，啊财务去挑战研发线的服务器成本，他不关注其他啊，只要看利用率要拉上去。
那你看啊以前这个研发的服务器投入啊，财务现在人是没有方法去挑战的。
你说要采购一百台啊，财务说太多了，你说业务有多少，需求量多大，所以需要采购。
然后财务完完晕倒了，因为他没有办法去反驳你们，因为你们是在拿业务说事对。
但是后来我们的财务就说，哎，看看你们的利用率才多少啊，为什么要采购不给批啊？我们训练了，他怎么去挑战研发啊，就很好，连我们的CFO都走。
那阿里现在利用率是做到多少了呀？嗯，我是一九年年初不带这个团队了，当时是从原来的小于百分之十是做到了百分之二十左右啊，相当于是翻倍了。
那这就意味着成本有可能减半。
嗯嗯，啊google这两年据说是已经推到了百分之六十，我们以前以为百分之五十是天花板了，不可能再多。
以前财务也问了哈，就是说你们利用率率以低低，但但是得告诉我多少合理的，我们总不能说小于百分之十是合理理。
那这解释不过去，那技术上也得编个理由。
但是呃百分之五十我们说是可以解读的那一呢是这是全天的平均。
如果说百分之五十，那就意味着高峰期肯定会比较高了，平均一下就已经很少了。
第二呢，是多数的这个CPU的设计原理啊，都是超线程。
你看到两个核，那物理上只有一个核，只是说软件层面上具备了跑出类似两个核的能力，但实际上是不可能跑得出来的。
所以我们就说打个折啊，当然是有点忽悠啊。
但是呃财务线非IT的人可以理解，觉得比较有道理啊，但是现在又说不过去了，没想到google现在又要突破了，做到了百分之六十啊，左右还是很稳定。
所以我们觉得他就是天花板了。
那现在阿里这个团队还在做，去年呢是做到了百分之三十左右，天花板是百分之六十。
阿里规模这么大啊，我们假设百分之五十是天花板，那百分之三十到五十也还有很大的空间值得努力。
然后哎呀还是非常高的。
所以呢这个团队的评价一直都非常好。
后来西格玛应该是转移到KBS那个生态上了，那个时候是为什么？嗯，那是后来了，嗯，我们一六年做的时候呢，docker最火k八s还没有起来。
嗯，啊当时在调度上竞争非常激烈，因为调度其实会把下面的容器给屏蔽掉。
嗯，那hadooer觉得自己不往上做调度就很危险，就开始做所有。
然后mesal所是另外一家啊，google刚开始把这个k八s去开源出来，而且google以前也不做开源，他的套路呢就是发论文，然后什么都不干啊。
但但是呢他在这个大数据上的伤害啊比较大啊，之前他发了这个三驾马车的论口嘛，就是MPREUS那几口。
哎，对，然后他发现自己啥也没得到嗯，什么hadoop公司全部起来了啊，关键是后来他做云啊云上放m mar RDCS,但是所有的开发者的接口全部是hadoop的接口，而致google不得不去兼容hadoop的接口。
啊，这个就太搞笑了啊。
嗯他们觉得内部啊我MARREDCE做的比hadoop好太多了。
我是一个成熟很牛的东西，你们竟然不用。
那之后呢是google才发现重要的不是发论文啊，是做开源抢占开发者。
嗯，啊所以在k八s上呢，google啊就吸取了教训，开始对新套路有点概念了。
我先发论文啊，占占领这个影响力，然后呢再发一个论文实现的开源产品。
但是google不擅长做开源，就找到这个呃擅长开源玩法的red hat.那联合起来做k八s因为book啊跟内部的很多系统搅在一起了，没办法开源，所以只能重做。
嗯，那因为k八s没有起来嘛，那一六年你们用的是什么？呃，我们当时选择了所有我们做西格a但是一八年的时候k八s就基本垄断了。
嗯，啊我们很多业务的方向呢是k八s的API.那访问西格玛呢就不通，那导致我们必须兼容k八s的API.但是在金融上面呢，我们在很多的开源路线上都犯过错误。
一开始呢其实是有一个开源的东西，但是我们先自研，然后等开源的那个拥有了最多的用户啊，我们就不断的去兼容。
但是你兼容啊会越来越痛苦。
因为开源啊一旦起来之后呢，就是一个很健康的社群，有非常多公司的合作会做的越来越好。
嗯，到那个阶段呢，你是抗衡不了社区的，但以兼容这条路啊，它其实是走不下去的。
我们就决定啊不做兼容，把西格玛给扔掉。
那基于KYS把西格玛做的有些东西放到里面去，就是ASI啊。
呃，那你这里说兼容的痛苦具体是指什么？因为社区的关键问题啊是控制不住啊，我们当年是经历了很多次这个过程。
比如说啊一开始我我来讲啊这个阶段有非常重要的需求啊，对他来讲呢可能一点都不重要。
那我们肯定会觉得开源做的不好，需求又很急嘛。
那我们就大量的去自研，做了很多派的东西。
但是后面发现开源一旦起来节奏太快，他增加了很多东西，其实就覆盖掉了。
我们以前做的很多的改进啊，这个时候就很尴尬了，到底是升级成它呢还是保留自己？那我们后来就觉得应该尽快的升级成开源，因为他一把被拉的越来越大啊，所以从这个理论上来说，嗯，后来西格玛事情大家也都能接受，大家能理解也能接受啊，确实有些人会很不舍啊，毕竟做了几年，而且业务效果也在啊，最后不得不扔掉了啊，后但这确实是我们当年的判断的失误。
如果是更早的去选择k八s会更好。
但是一六年的时候啊，我们看所有m和metholes,再加上k八s不成熟啊，不觉得开源有绝对的优势，觉得自研是有优势有机会的。
所以我们后来去反思说呃做技术选型的时候，如果开源界已经有了一个很成功的东西，自己呢又没有什么很颠覆性的思想，还是拥抱开源比较好，没有必要去挑战。
嗯，啊阿里在这个开源这条路上吃过很多的亏。
嗯，因为嗯以前都自研HSF和double也是典型啊，这个是只是呃HSF啊，是我们自研的产品啊，double是开源的对，那在整个的开发者群体里肯定有最多的用户。
嗯，但阿里一收购完一家公司呢，就会告诉他啊，你把dob换了，换成HSF,很多公司呢就觉得很尴尬啊。
你们进来之后业务啥也没干，就先把技术给换掉了。
阿里以前就经常这么做啊，我们后来说像这种就不应该让别人给换掉，应该把我们自己换掉。
所以HSF呢后来的新版本的目标呢就是换成以double为核心啊，支持内部HSF的协议的解析。
那这样是以后的收购呢就非常简单了。
但是当时啊你们判断开源不成熟，然后你们选择的是去建sigma,是不是？因为比如说大厂不可能说等两年我去等那个开源成熟不可能的。
而且大厂的挑战也确实比较大要解决问题很多。
所以如果开源不是很成熟，很难说我一开始我就去选择开源。
嗯，但是开源如果成熟了，已经成熟了，然后你们才开始用，是不是说明你们之前没有看到这个方向有问题呢？大厂很有可能就是比开源看到更快啊，所以确实就是你说的嗯很尴尬。
那现在大厂的自研呢是走上了这一条很尴尬的路线。
那开源去反噬自研啊，这是之后业界的长期的问题。
以前呢很多公司都是自研，但现在开源已经被玩的太多了，什么都开源。
那之前的自研到底是应该怎么办？反正呢我们的判断就是啊，如果开源的东西已经是主流了。
比如说像spring cloud,那没有必要去做一个新东西再跟他竞争。
因为呢我们也只能靠开源去争。
但是如果没有革命性进步，关键竞争也打不过他。
所以后来我们做了spring cloud阿里巴巴，那就是觉得哎我竞争不过你跟你一起玩就好了。
啊，策略就是这样，总体还是拥抱开源。
因为你要么就是自己去做一个开源，要么就用开源做啊，就这两条路今天的对谈呢到这里就暂时结束了。
我们重点聊的是碧璇当年做统一调度的经历。
虽然这些年啊碧璇换了不少领域，但是从他对成本的关注这条线来讲呢，之前做的所有事情又能大概串联起来。
最早呢做的是容器t four,然后到后来的益利多活到今天的统一调度。
后面他创业选择的方向也是做企业云成本控制fean opps,那这么看，成本可能是一个企业始终关注的话题。
Goole当年分析自己的优势也提到这一点，一是排序结果的准确度比多数公司要好。
二呢是做同样的效果，付出的成本是别人的十分之一。
那分析自己所在的团队或者公司啊，你觉得优势是什么呢？关于统一调度的技术选型呢，我们也聊到了资源和开源的问题。
必选的反思是如开源界已经有一个很成功的东西了下，你讲又没有什么很颠覆性的思想，还是拥抱源源比较好。
那你是怎么看的呢？如果你有更感兴趣的话题，也欢迎在评论区留言。
如果觉得有启发，也欢迎分享给身边的朋友一起讨论。
今天呢我们的时间线已走走到了二零一年。
今天选马上就要从阿里离开了，下一讲，我们会聊聊这个话题，下一讲，再见，拜拜。