|
按照惯例今天应该是继续讲三驾马车的BigTable，但是一则BigTable这东西不容易一下子说清楚。二则我觉得是时候停一下技术，多聊点八卦。所以我们来讲讲这个著名的活雷锋公司，以及Hadoop的早年。 活雷锋与风口上的猪 Yahoo作为互联网时代的第一股，曾经牢牢的占据了整个IT行业非常重要的位置。从.com时代存活下来，一直到最近穿出来卖给Verizon，又传闻Verizon变卦不想买。从天之骄子变成弃之如敝履的破鞋，也算得上是一个非常可悲的事情。我无意详细展开Yahoo这个公司的整个历史。但是业界有一个传闻，就是站在风口，猪也能飞起来。至于飞起来的是真的牛还是猪，只有等风停下来才能看明白。这话一次又一次在我的生活里被验证。所以通常来说聚光灯下的那些人头，到底里面有多少是真英雄，有多少是猪，只有拉长时间线才能看明白。 通常来说，大家默认的Hadoop起源是在Nuget这个项目。作为开源搜索引擎Lucene的姐妹的爬虫Nuget，始于Doug Cutting和Mike Cafarella。这两位在2003年开始做这个项目的时候，用的是手搭的几台机器。这个爬虫的东西很难scale，做inverted index更是麻烦。而Google的GFS和MapReduce于2003和2004年分别发表。于是到了2004年的时候这两位意识到需要重写这个Nuget系统了。他们用了几个月的时间做了一个简易版的HDFS和MapReduce，又把Nuget系统移上了这个新的平台。从此以后在几十台机器的范围内，可以非常稳定轻松的跑起来了。这大概就是互联网上能够听闻的Hadoop的最初起源。至于真相如何，我也不得而知了。但是有一点我是知道的，这code和Google的那个比，一定是不堪入目的。即使4年后的2008年，我在IBM Almaden Research Center实习的时候，不得不接触到当时的Hadoop系统，尽管我本人是学渣编程尤其的烂，依旧可以看得出来这个系统还是有不堪入目的感觉。那已经是四年以后了。 2006年注定是重要的一年，这一年Google发表了两篇重要的论文:BigTable和Chubby。前者导致了HBase，后者产生了Zookeeper。有关这些的东西留到以后再详细讲。这一年，也是Hadoop作为一个独立的系统从Nuget里面独立出来。这一年，还是Yahoo正式的招了Doug，从此开始了Hadoop的活雷锋时代。这一年，顺便插一句，也是我正式投出了人生的第一篇paper投出以后拿到拒信的时候，开启了我PhD的论文灌水生涯。 于是Hadoop就这样独立出来了，Doug在Yahoo搞Hadoop啊搞Hadoop，机器从几十台到几百台啊。大约是一年多以后的时候IBM也进来了，当然18摸（IBM）有着一贯的官僚和自毁长城的历史。这场Hadoop的盛宴，它们进来的早，却在内斗中赶了个晚集，基本上是一无所获了。Facebook那个时候也进来了。更有意思的事情是活雷锋不仅仅有Yahoo还有Google。当时的Google远不是后来的Evil的不得了，脑子很好使的那个Google，活脱脱的一个傻白甜。Google自己估计也是被MapReduce的风给吹得我得意的笑啊我得意的笑啊。一边是和数据库领域大佬，未来图灵奖的获得者Michael StoneBraker撕逼。一边Google和18摸一起买下了一个快要废弃的datacenter，弄进两千台机器，装上Hadoop，以便各地的PhD和Professor们可以好好的研究这个Hadoop，认认真真的膜拜MapReduce这个神话。 我想Google是一定看不上眼这个粗制滥造的Hadoop的，出来的版本里面没有资源管理器，当然这是Google刻意从论文里隐藏的结果。用Java这种毫无效率的语言写的。文件系统效率极低，而且metadata居然连基本的High Availability都没有。我知道各位看官可能觉得我在胡思乱想，以小人之心度谷歌之腹。其实不是的。我有非常铁的证据。 后世的Hadoop三大批发商分别是Cloudera，Hortonworks以及MapR。有关这三大批发商的故事以后我们慢慢八卦，但是前两者好歹是出身血统正宗。那个MapR的出身就非常的诡异了。CTO是个三哥，以前在Google里面搞GFS的。出来单干以后在印度乌压压的招了一群大小三哥们，用C++写了一个自己的版本的HDFS，自带High Availability。从此以后这个批发商走向了一条和其他人完全不一样的道理。用C++复制开源的项目，自己提供兼容的接口，卖不开源的自家的实现。而很容易查到的是Google Venture早年给这家投了不少钱。像这种不跟随开源走卖自己的东西的，虽然一开始的时候看起来很牛13，但是过些日子，乱拳打死老师傅，开源的要有的都会有的，比如High Availability，比如Resource Manager。一个小小的屁公司，怎么能够顶得住一个世界呢?而Google Venture早年却看好这个公司，只能说Google内部秉承了同样的理念。先支持Hadoop这个渣渣给大家见识一下MapReduce的威武，再展现一下Google高超的Engineering水准，于是全世界都要顶礼膜拜，Google从此封神了。 当然历史最终不是这样走的，这也就是为什么我觉得在某几年的时候从Jeff Dean到Google都被MapReduce的光辉给照瞎眼了。所以吹牛这个东西一旦吹起来就会飘飘然，觉得老子天下第一。周围的人再捧几下，就真的上天了。要不以袁世凯如此聪明的人，怎么也会想着去当皇帝呢？Google也不能免俗。其实类似的事情在Google身上不断发生，从Google Wave到Google Glass乃至Google Plus。好歹Google这几年终于清醒过来了，在tensorflow上的表现让我看起来完全不像以前那个250啊。当然拿着印钞机的250还是可以活很多年的，不论是微软还是Google，所以印钞机在手别无所求啊。 2009年同样发生了很多事情，Doug加入了新成立的承包商Cloudera，Mike PhD毕业去了UMichgen做了教授。2009年也是美国经济危机的第一年。那年我从我的学校滚蛋了，因为老板跑路，只好趁经济危机毕业了。我没见过Doug，见过Mike几次，因为在同一个圈子里混的缘故。我其实对09年毕业的Mike印象不深，印象更深刻的是他的同门师兄弟Chris Re。那年经济危机我被迫毕业，到处投各种职位，包括申请faculty的职位，结果Mike没有太多出面申请很多学校，Chris则几乎把每个学校都投了一个遍。凡是我投的他也投的，面试都属于他的。我只在200多名的一个小学校拿了个onsite最后还挂掉了。充分证明了谁是真正的大牛，谁是在风口也没飞起来的那头猪。 两年后Yahoo spinoff了它的Hadoop团队，VP of Hadoop等一干人成立了Hortonworks。这就是为什么今天的开源Hadoop里要么是这个批发商的，要么是那个批发商的，却没有MapR什么事情。当然，MapR也弄出了一个开源项目Drill，这是应对后来Google的BigQuery的策略了，和Cloudera的Impala有异曲同工之妙。我们还是留待以后再慢慢的讲吧。Yahoo的spinoff也就意味着它作为活雷锋时代的结束。让我们为这个即将死去的活雷锋这多年来对Hadoop无私奉献支持来说声感谢。 由衷的感谢Yahoo这头风飞了很多年的猪对开源Hadoop ecosystem的巨大而无私的贡献。 沉没的微软以及Dryad 到目前为止，我大致上是按照年代的顺序来讲述故事，除了刻意的延迟了对Google第三架马车的叙述。但是接下来的文章，出于逻辑的考虑，可能会更加的前后错开一些。大数据技术的发展，很快从史前时代进入了蓬勃发展的时期，我关注得到的东西也就越来越少了。 在这场大数据的革命里，有的公司耀眼了，赚到了名。有的公司做了雷锋，赚到了关注度。有的公司起了个早，在内斗中赶了个晚集。还有的公司，微软这个上个时代的领军人物，扑通了几声，迅速被淹没在了大浪里面，沉没了。 然而我们必须说，作为老司机，微软还是非常有鉴别能力的，什么东西是好东西，什么是烂东西。换句话说什么该抄什么应该抛弃，在我有限的接触的几个公司譬如IBM，Yahoo来说，至少那个MapReduce耀眼横行的年代里，微软的某些决定显得很另类，并不引人注目，然而未必就错了。 微软大概是在2007年前后决定大规模的投资search，这可能一半是因为微软在自己的大本营上被Google撩拨的不行了。Google在Kirkland开了个office明目张胆的开始在微软挖人。网上有个视频是说当又一个微软的Fellow离开的时候，前CEO巴尔默问对方去哪，还说，千万不要又是Google。结果对方说很不幸的就是Google。于是巴尔默砸椅子了。当然这个坊间传闻不知道真假。那个先开始叫Windows Live Search，后来改名叫Bing的产品，在外名声不显。 然而我必须说，从微软内部来看，这个投资的意义极其的巨大。因为投资Bing，微软掌握了大规模data center的建设和管理能力，开发出了几个对微软这个只会做单机版软件的公司有着飞跃性意义的平台，掌握了A/B testing的实验平台，学会了大规模数据分析的能力。其中有一些东西则成为了Windows Azure的基础。可以说，没有Bing的钱砸进去，微软并没有办法顺利的从一个软件公司过度到一个云计算的公司。如此算一笔账，亏了还是赚了确实是不好说。同时代的IBM和Oracle显然就没有这样的幸运。至今依然在苦苦的挣扎中不知道能云成什么鬼样。 这里我们要介绍一个人Michael Isard。这个作为在这个特定时期对微软非常有意义的人，值得去大书特书一下。Michael Isard，微软硅谷研究院的高级研究员，早年做计算机视觉出身。按照以前我看他在微软的主页上的说法，他在2007年前后几年的时候和微软的Search有着非常的紧密的合作，参与了微软Search的两个特别重要的infrastructure项目的开发：Autopilot和Cosmos。因为这两个项目其实现在都不是秘密的项目了，所以我就可以自由自在的拎出来讲。 其中Autopilot的早期情况可以参考他的论文：Autopilot: Automatic Data Center Management。从标题上看大家就知道Autopilot是干什么的了。Autopilot后来有了非常长足的发展，并成为了windows azure下面管理data center的基础。因为鹅厂不让我贴外面的链接，所以就只能辛苦大家自己动手丰衣足食了。而Cosmos是微软的大数据计算的平台。我一度在此team共事非常长的时间。 关于Cosmos的详细情况也可以参考VLDB Journal的论文 SCOPE: Parallel Databases Meet MapReduce。关于后者，在以后讲到相关话题的时候我们会展开叙述。 顺便说两个八卦，都是和微软的现任CEO Satya有关的。 第一个八卦是澄清一下大家长久以来的误会。Satya一直以来都是受到微软上层非常信任的人。在执掌search也就是后来的Bing的时候，作为Senior Vice President，Search和Ads的大头，两个VP都是直接report给他的。而陆奇在2008年登陆微软的时候，虽然名义上是Online Service Division，实际上来说，只有msn是直接汇报给陆奇，其他都是汇报给Satya，然后Satya再汇报给陆大大。所以虽然说有所谓的上下级关系，到底谁更获得高层的信任其实可见一斑。后来Satya去了Server and Tools成了President，陆大大直接接手了Search和Ads的汇报，中间那一层并没有其他人来接替。因此坊间传闻陆大大是上级然后变成了下级不爽，多半不靠谱。在微软内部，Satya获得高层的信任一直以来都高于陆大大。当初把陆大大搞过来也是想促成Yahoo的deal，确保Bing有三分之一的traffic。至于谁是名义上的头，谁是实际上的老大，其实很容易看明白的。 第二个八卦是Satya上台以后的一次layoff，做出来的决定是把Microsoft Silicon Valley Research Lab给关了，这次关掉整个研究院的事情发生在2014年，造成了非常恶劣的影响。我们的主角Michael Isard也被裁员了。这些被裁员的人据说当天Jeff Dean带着Google的HR就守在门口给签了Google研究院的合同。而最新的公开资料显示Michael Isard去做TensorFlow了。果然牛人是在什么地方都能发光发热的。 提这个人是因为他发表了Dryad这篇论文。Dryad这个东西最终被微软用到了一些产品里，具体的细节我们也等到了后面相关的故事慢慢展开。但是作为一个比MapReduce更通用，也同样更底层的系统，在这个时代里其实是被大大的忽略了。另外说一句，Hortonworks主导的开源项目Tez的原型就是Dryad系统。大概是2013年左右，在Cosmos里面负责开发Dryad相关的东西的一个印度人跳槽去了Hortonworks，我想这可能和之后Hortonworks决定做Tez有一定的关系。 Dryad的基本思想并不难理解，说白了就是一个有向无环图的执行引擎，其中图里面的每个点表示了一个计算，而边则表示了数据流，边的方向决定了数据的流向。系统可以通过这个图来按照一定的调度尽可能的让更多的东西并行执行起来。Dryad的另外一个特点是，图上指定的边可以在运行时候进行展开，举个例子来说，套用MapReduce吧。程序运行前的图可以是一个Mapper和一个Reducer，但是当runtime发现数据量比较大的时候，它可以动态的切成若干份，从而改变图的结构和连接，获得更多的并发度。最初实验室里面的Dryad其实缺了很多东西，所以只能稳定的运行在几百台机器上。而经过Cosmos组不断增强的Dryad层，可以扩展到几万台机器上。MapReduce里有的监控和自动重试功能在这个系统里面也同样的实现了。 我想系统的细节我就不展开了，大家可以看论文去。但是作为和MapReduce比较一下还是有必要的。其实Dryad就是一个DAG的执行引擎，学到了Google作为MapReduce infrastructure那个部分的核心。在一个海量文件系统的支持下，做到了对系统的自动监控，运行和重试。另外一个方面，这个系统并没有局限成Map Shuffle Reduce这三个阶段，故而提供了很多的灵活性。 但是我们需要注意到的是，这个系统对用户的要求太高了，需要给每个节点定义计算，给每条边定义数据流向，和MapReduce比起来，就像是SQL和汇编的区别。所以这个系统其实是没有那么强的可用性的。不仅仅如此，因为用户要负责的东西很多，所以用户错误也可能导致很多的job 失败的问题。因此大家可以想象，下面的路就是在这个汇编语言上发展出更高层次的编程接口。DryadLinQ和SCOPE就是在这样的背景下诞生的两个项目。关于它们，我们留到以后相关的主题的时候再展开。 额外说一句MapReduce这个框架里面的Shuffle其实是不公开给用户的，当然，你非要override partitioner也是可以的。然而不知道大家是不是注意到Google论文里面的一个细节。Google的Shuffle阶段是Sort based。作为一个长在关系代数下的生是关系数据库的人，死是关系数据库的死人的我，第一次读这个论文的时候在心里大大的嘲笑了一把Google这个傻13.这种情况下不就是一个GroupBy么。关系数据库的世界里玩了几十年了，Hashing明显是比Sorting更好的一个选择么。 只不过Google没有告诉大家，在数据规模足够大的时候，Hashing会产生很多很多的小文件，因此，它的效率其实不如Sorting。如果我们追溯一下现在特别流行的Spark的版本变迁，在早年的版本里，Spark做了并且只做了Hash-based partition，充分说明了Spark是一群根红苗正的关系代数和关系数据库的人搞出来的。但是后来Spark实现了Sort-based partition，并且把这个做成了默认值。 我想Spark肯定也是吃了大量小文件的亏，所以只能吃土了，老老实实的做Sorting-based。我其实不知道Google是一开始就直接上了Sorting呢，还是Hashing失败了再搞的Sorting。但是这种细节上的东西，没有做过是断然无法真的知道的。顺便说一句，Cosmos里面最后还是Sorting和Hashing都有，并且默认是Hashing，因为解决了产生大量小文件的问题。 Dryad和MapReduce比起来显然是没有太多的声音，而微软作为这波大数据里面非常另类的一个公司，在整个浪潮里也并没有扑通出什么来。但是一则我是微软出来的，二则我觉得让大家看一看相对更小众一些的实现，现在回头看也有其参考价值。 以上内容由飞总授权转载，版权所有，侵权必究，转载请授权。 |
|
|
