大数据的那些八卦事儿（一）：从史前时代到三驾马车

Google的后悔药

　　 大数据 这个概念红红火火的也有两三个年头了，我在这个坑里的时间可能要更长一些，勉强可以从08年开始算。所谓年头待得久了，看得也多一些。对应中国传统文化的说法，什么东西老了都能成精。这个坑的主要目的还是以八卦为主，顺便把我知道的道听途说的有的没的的大数据相关的东西给大家讲一讲，顺便也把大数据来龙去脉理一理，权当诸位茶余饭后的谈资。

Google的后悔药

大概说起大数据，我们就不可避免的要谈起这个曾经在国内风光无限，然后又从国内退出去的公司，号称Do not Evil而实际上相当Evil的公司——Google。当然，因为我本人的经历的关系，我在自己公众号前面的文章里也提到过，我是??黑软粉，不是和主流大众的审美观一致。

不可否认，大数据伊始，主要是因为Google这个公司。更加确切的说，不仅仅是因为Google的一系列的论文，更是因为Google以自己的一年又一年的财报告诉大家，免费的消费者们，结合大数据的技术，做成广告平台，就像开了印钞机一样。钱之所在，趋之若鹜，人性本来就是如此。

我们把时光倒流到2009年，经济危机的时候。那一年全世界发生了很多事。除了大家开始狂印钞票以外，大数据作为一个概念也开始悄然登场了。这个时候我曾经听到一个特别著名的笑话。笑话大致上是说，有人采访了Larry Page，问他有没有什么后悔的事情，Larry Page说，他很后悔让MapReduce和Google File System这样的paper给发了出来。

　　这个采访估计是子虚乌有的东西，然而其反应的本质问题，Google后悔了，却是非常真实而有据可循的。在我看来，Google不仅仅是后悔了，而且是在不停的后悔又后悔之中。所以当一个新的名词 人工智能 ，以及伴随着的AR/VR出现的时候，Google采取了一种截然不同的做法。今天我们从Google的后悔药说起。

Google的后悔药的第一层意思其实非常的名曲，倘若Google早年没有发表了Google File System， MapReduce，以及BigTable这三篇文章，那么Google依然拥有着这世界上最为先进而独特的大规模数据存储和计算的能力。而业界的其他公司如果要想平地起高楼的起起来，那可能会需要更多的时间。

这其实从Google发表的一系列文章里也能看出来。Google File System是论文里面的经典，必须说每个做数据处理的人都值得一读。MapReduce则写得没那么实诚了。等BigTable出来的时候，那就更需要读者更多的想象空间了。至于此后若干年才诞生的Spanner，这个系统也许可以称为是一个伟大的系统，这篇论文，写得遮遮掩掩的那种样子，能被OSDI接收也是奇迹，更何况是Best Paper Award呢。就事论事，Google从一个非常开放的方式到越来越保守，和它后悔自己泄露了自己的商业机密，而以后又不得不继续以泄露商业机密的方式来半遮半掩的显示它在大数据领域的存在，无疑说明Google其实很后悔一开始发了那几篇论文，可惜这世界上并没有后悔药。

然而我觉得Google其实是一个商业上极其失败的公司。倘若我做CEO的话，估计高marketing的应该从上到下都清几遍。为什么这么说呢。Google这个公司有着天生的优越感：老子就是有Google File System，老子还有MapReduce，你们这些老朽的，还有新生的公司们，没有我这样牛逼的体系结构，你们搞什么飞机都没办法赶得上我。所以呢，Google这个作为奠定了整个BigData最开始的框架和基础的公司，从来都没有想过开源自己的系统，以便可以占领市场。于是活雷锋Yahoo上场，硅谷大大小小的公司都凑上去，乱拳打死老师傅。Hadoop这样的一个看起来很烂的系统就这样在大家七拼八凑的节奏下搭出来了。然后就茁壮成长起来了。这是一件非常有意思的事情。作为大数据技术的奠基人，在大数据领域的影响力，基本上是等于零。那么大一块饼，你Google只要自己open一点，本来很大的市场，现在是做了雷锋却没捞到任何的好处，我想Larry Page回头想起来，估计后悔药吃的不止是一瓶。

除去商业上极其的傲慢以外，Google还是一个以自我为中心的公司。Jobs的伟大在于他说过用户是愚蠢的我们要告诉用户怎么用才是正确的，这话的前提是Jobs的确是非常的比用户更知道他们需要的是什么。尽管苹果有诸多弊端，对用户的真实需要的理解是很深刻的。

Google不同，每次都是不切实际的指望用户去按照他们的方式去用他们的产品。早年的Google玩的那个只需要浏览器就可以让消费者访问全世界以及完成日常所有应用的Chrome应该是一个很好的例子。然而在大数据这个背景下，和云计算相关的地方，Google做了一件事：Google App Engine。非要定义的话，这是个PAAS的东西。Google2008年正式开始做这个App Engine，进入云计算市场，并且提供了包括BigTable在内的API的支持。问题吧，Google大概忘记了它自己和它的用户的不同。它的系统的Scalability对大部分用户来说，都没意义，没有什么用户要用几万台电脑去解决问题的。而它的API的局限，对很多用户来说其实无法接受。最简单的，Google当时并不支持join。并且Google告诉大家我自己这么大的公司就没有用Join，你们也不需要用。

Google App Engine折腾几年，并不成功。相反的微软亚马逊都开始做卖虚拟机的生意，而且越来越红火，所以到了12年终于忍不住开始做Google Compute Engine，也就是终于承认自己以前的战略错误，开始卖机器了。我相信4年时间可以做很多事情，我也相信4年时间足够让一个本来可以抢占一部分蛋糕的市场，变得无足轻重起来。所以说西雅图才是云的中心，而弯曲，包括Google在内，终究是慢了。我想Larry Page肯定是非常的感叹他接二连三的做出的错误决定。这些错误决定的唯一结果就是BigData这块大蛋糕，基于Google的论文，但是却没让Google吃到一口。

所以当人工智能这个新泡泡起来的时候，Google迅速采用了一个完全不同的策略，不仅仅用AlphaGo这个程序告诉大家，所谓围棋，不管东亚人怎么吹是信仰是人生是哲理，其实无非就是个计算的问题。Google接下来很快的开放了Google内部的人工智能平台TensorFlow。我想这个战略上的转变，反映了Google不想在人工智能这个新的热点上再一次吃上BigData上面颗粒无收的后悔药。

　 三驾马车之永垂不朽的GFS

但凡是要开始讲大数据的，都绕不开最初的Google三驾马车：Google File System(GFS)， MapReduce，BigTable。如果我们拉长时间轴到20年为一个周期来看呢，这三驾马车到今天的影响力其实已然不同。MapReduce作为一个有很多优点又有很多缺点的东西来说，很大程度上影响力已经释微了。BigTable以及以此为代表的各种KeyValue Store还有着它的市场，但是在Google内部Spanner作为下一代的产品，也在很大程度上开始取代各种各样的的BigTable的应用。而作为这一切的基础的Google File System，不但没有任何倒台的迹象，还在不断的演化，事实上支撑着Google这个庞大的互联网公司的一切计算。

作为开源最为成功的Hadoop Ecosystem来说，这么多年来风起云涌，很多东西都在变。但是HDFS的地位却始终很牢固。尽管各大云计算厂商都基于了自己的存储系统实现了HDFS的接口，但是这个文件系统的基本理念至今并无太多改变。

那么GFS到底是什么呢?简单一点来说它是一个文件系统，类似我们的NTFS或者EXT3，只是这个文件系统是建立在一堆的计算机的集群之上，用来存储海量数据的。一般来说，对文件系统的操作无非是读或者写，而写通常又被细分成update和append。Update是对已有数据的更新，而append则是在文件的末尾增加新的数据。Google File System的论文发表于2003年，那个时候Google已经可以让这个文件系统稳定的运行在几千台机器上，那么今天在我看来稳定的运行在几万台机器上并非是什么问题。这是非常了不起的成就，也是Hadoop的文件系统至今无非达到的高度。

GFS的设计理念上做了两个非常重要的假设，其一是这个文件系统只处理大文件，一般来说要以TB或者PB作为级别去处理。其二是这个文件系统不支持update只支持append。在这两个假设的基础上，文件系统进一步假设可以把大文件切成若干个chunk，本文上面的图大致上给了GFS的一个基本体系框架的解释。

Chunk server是GFS的主体，它们存在的目的是为了保存各种各样的chunk。这些chunk代表了不同文件的不同部分。为了保证文件的完整性不受到机器下岗的影响，通常来说这些chunk都有冗余，这个冗余标准的来说是3份。有过各种分析证明这个三份是多门的安全。在我曾经工作的微软的文件系统实现里面也用过三份这样的冗余。结果有一次data center的电源出问题，导致一个集装箱的机器整个的失联(微软的数据中心采用了非常独特的集装箱设计)。有一些文件的两个或者三个拷贝都在那个集装箱对应的机器上，可以想象，这也同样导致了整个系统的不可用。所以对于这三个拷贝要放哪里怎么去放其实是GFS里比较有意思的一个问题。我相信Google一定是经过了很多的研究。

除了保存实际数据的chunk server以外，我们还需要metadata manager，在GFS里面这个东西就是master了。按照最初的论文来说，master是一个GFS里面唯一的。当然后续有些资料里有提到GFS V2的相关信息表明这个single point bottleneck 在Google的系统演进中得到了解决。Master说白了就是记录了各个文件的不同chunk以及它们的各自拷贝在不同chunk server上的区别。

Master的重要性不言而喻。没有了metadata的文件系统就是一团乱麻。Google的实现实际上用了一个Paxos协议，倘若我的理解是正确的话。Paxos是Lamport提出来的用来解决在不稳定网络里面的consensus的一个协议。协议本身并不难懂，但是论文的证明需要有些耐心。当然最重要的，我自己从来没有实现过这个协议。但是就我能看到的周围实现过的人来说，这个东西很坑爹。Paxos干的事情是在2N+1台机器里保持N的冗余。简单一点说，挂掉N台机器这个metadata service依然可以使用。协议会选出一个master服务，而其他的则作为shadow server存在。一旦master挂了大家会重新投票。这个协议很好的解决了High Availability的问题。很不幸的是，抄袭的Hadoop 文件系统使用的是一个完全不同的方案。这个我们在讲到Hadoop的时候再说。

对GFS的访问通过client，读的操作里，client会从master那边拿回相应的chunk server，数据的传输则通过chunk server和client之间进行。不会因此影响了master的性能。而写的操作则需要确保所有的primary以及secondary都写完以后才返回client。如果写失败，则会有一系列的retry，实在不行则这些chunk会被标注成garbage，然后被garbage collection。

Master和chunk server之间会保持通信，master保持着每个chunk的三个copy的实际位置。当有的机器掉线之后，master如果有必要也会在其他的机器上触发额外的copy活动以确保冗余，保证文件系统的安全。

GFS的设计非常的值得学习。系统支持的目标文件以及文件的操作非常的明确而简单。对待大规模不稳定的PC机构成的data center上怎么样建立一个稳定的系统，对data使用了复制，而对metadata则用了Paxos这样的算法的实现。这个文件系统体现了相当高水准的系统设计里对方方面面trade off的选择。有些东西只有自己做过或者就近看人做过才能真正感受到这系统设计的博大精深。故而对我个人而言，我对GFS的论文一直是非常的推崇，我觉得这篇论文值得每个做系统的人反复的读。

　 三驾马车之坑人的MapReduce

在Google的三驾马车里面，Google File System是永垂不朽的，也是基本上没有人去做什么进一步的研究的。BigTable是看不懂的，读起来需要很多时间精力。唯独MapReduce，是霓虹灯前面闪烁的星星，撕逼战斗的主角，众人追捧和喊打的对象。自从MapReduce这个词出来以后，不知道有多少篇论文发表出来，又不知道有多少口诛笔伐的文章。

作为论文来说MapReduce严格的来讲不能算作一篇论文，因为它讲述了两件不同的事情。其一是一个叫做MapReduce的编程模型。其二是大规模数据处理的体系架构的实现。这篇论文将两者以某种方式混杂在一起来达到不可告人的目的，并且把这个体系吹得非常的牛，但是却并没有讨论一些Google内部造就知道的局限性，以我对某狗的某些表现来看，恐怕我的小人之心觉得有意为之的可能性比较大。

因此当智商比较低的Yahoo活雷锋抄袭MapReduce的时候弄出的Hadoop是不伦不类，这才有了后来Hadoop V2以及Yarn的引进。当然这是后话。作为同样抄袭对象的微软就显得老道很多。微软内部支撑大数据分析的平台Cosmos是狠狠的抄袭了Google的File system却很大程度上摒弃了MapReduce这个框架。当然这些都是后话，只能留待以后的篇幅慢慢展开。

我们先看看作为编程模型的MapReduce。所谓MapReduce的意思是任何的事情只要都严格遵循Map Shuffle Reduce三个阶段就好。其中Shuffle是系统自己提供的而Map和Reduce则用户需要写代码。Map是一个per record的操作。任何两个record之间都相互独立。Reduce是个per key的操作，相同key的所有record都在一起被同时操作，不同的key在不同的group下面，可以独立运行。这就像是说我们有一把大砍刀，一个锤子。世界上的万事万物都可以先砍几刀再锤几下，就能搞定。至于刀怎么砍，锤子怎么锤，那就算个人的手艺了。

从计算模型的角度来看，这个模型极其的粗糙。所以现在连Google自己都不好意思继续鼓吹MapReduce了。从做数据库的人的角度来看这无非是一个select一个groupby，这些花样197x的时候在SystemR里都被玩过了。数据库领域玩这些花样无数遍。真看不出有任何值得鼓吹的道理。因此，在计算模型的角度上来说，我觉得Google在很大程度上误导和夸大了MapReduce的实际适用范围，也可能是自己把自己也给忽悠了。

在Google内部MapReduce最大的应用是作为inverted index的build的平台。所谓inverted index是information retrieval里面一个重要的概念，简单的讲是从单词到包含单词的文本的一个索引。我们搜索internet，google需要爬虫把网页爬下来，然后建立出网页里面的单词到这个网页的索引。这样我们输入关键字搜索的时候，对应的页面才能出来。也正因为是这样，所以Google的论文里面用了word count这个例子。下图是word count的MapReduce的一个示意图。

然而我们需要知道的是，Google后来公布的信息显示它的广告系统是一直运行在MySQL的cluster的，该做join的时候也是做join的。MapReduce作为一个编程模型来说，显然不是万能的药。可是因为编程模型涉及的是世界观方法论的问题。于是催生了无数篇论文，大致的套路都是我们怎么样用MapReduce去解决这个那个问题。这些论文催生了无数PhD，帮助很多老师申请到了很多的钱。我觉得很大程度上都掉进了google的神话和这个编程模型的坑。

MapReduce这篇论文的另外一个方面是系统实现。我们可以把题目写成：如何用一堆廉价PC去稳定的实现超大规模的并行数据处理。我想这无疑可以体现出这篇论文真正有意义的地方。的确，数据库的工业界和学术界都玩了几十年了，有哪个不是用高端的机器。在MapReduce论文出来的那个时候，谁能处理1个PB的数据我给谁跪了。但是Google就能啊。我得意的笑我得意的笑。所以Google以它十分牛逼的数据处理平台，去吹嘘那个没有什么价值的编程模型。而数据库的人以攻击Google十分不行的编程模型，却故意不去看Google那个十分强悍的数据处理平台。这场冯京对马凉的比赛，我觉得毫无意义。

那么我们来看看为什么Google可以做到那么大规模的数据处理。首先这个系统的第一条，很简单，所有的中间结果可以写入到一个稳定的，不因为单机的失败而不能工作的分布式海量文件系统。GFS的伟大可见一斑。没有GFS，玩你妹的MapReduce。没有一个database厂商做出过伟大的GFS，当然也就没办法做出这么牛叉的MapReduce了。

这个系统的第二条也很简单，能够对单个worker进行自动监视和retry。这一点就使得单个节点的失败不是问题，系统可以自动的进行管理。加上Google一直保持着绝不泄密的资源管理系统Borg。使得Google对于worker能够进行有效的管理。

Borg这个系统存在有10多年了，但是Google故意什么都不告诉大家，论文里也假装没有。我第一次听说是几个从Google出来的人在Twitter想重新搞这样一个东西。然而一直到以docker为代表的容器技术的出现，才使得大家知道google的Borg作为一个资源管理和虚拟化系统到底是怎么样做的。而以docker为代表的容器技术的出现也使得Borg的优势不存在了。所以Google姗姗来迟的2015年终于发了篇论文。我想这也是Yahoo这个活雷锋没有抄好，而HadoopV2必须引入Yarn的很重要的原因。

解释这么多，其实是想说明几点，MapReduce作为编程模型，是一个很傻的模型。完全基于MapReduce的很多project都不太成功。而这个计算模型最重要的是做inverted index build，这就使得Google长久以来宣扬的Join没意义的论调显得很作。另外随着F1的披露，大家知道Google的Ads系统实际上长期运行在MySQL上，这也从侧面反应了Google内部的一些情况和当初论文的高调宣扬之间的矛盾。

Google真正值得大家学习的是它怎么样实现了大规模数据并发的处理。这个东西说穿了，一是依赖于一个很牛的文件系统，二是有着很好的自动监控和重试机制。而MapReduce这个编程模型又使得这两者的实现都简化了。然而其中很重要的资源管理系统Borg又在当初的论文里被彻底隐藏起来了。我想，随着各种信息的披露，我只能说一句，你妹的。

MapReduce给学术界掀起了一片灌水高潮，学术界自娱自乐的精神实在很值得敬佩。然而这个东西火得快，死的也快。所谓人怕出名猪怕撞。

活雷锋与风口的猪

按照惯例今天应该是继续讲三驾马车的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比起来显然是没有太多的声音，而微软作为这波大数据里面非常另类的一个公司，在整个浪潮里也并没有扑通出什么来。但是一则我是微软出来的，二则我觉得让大家看一看相对更小众一些的实现，现在回头看也有其参考价值。

　　 Windows 95 = Macintosh 89

前几天微软财报公布后，股票大涨，定在了60块以上。这是对微软有着历史意义的一刻。微软这个上世界最为蓬勃发展的公司在2000年的时候股票达到60块一股，这之后就一路走下坡路，16年之后，才重新爬回了当年的股价，有了历史新高。当然，这个历史新高其实不能算新高，货币都不知道贬值了多少轮了。

然而微软的出身类似一个屌丝，所有windows95上市，万人空巷抢购，类似今天排队买Iphone，却有了当年苹果公司的一句评价，Windows 95 = Macintosh 89。只是不可否认的是，在相当长一段时间里，这个屌丝翻身革命的占据了整个个人计算机的绝大部分市场，而苹果公司到1998年股票跌到了个位数。

大家可能奇怪了，为什么今天的大数据那些事，尽扯一些毫无关系的话题。其实当然是有关系的。我在讲大数据的这些事情的时候，比较刻意的让时间先停在了2008年前后，因为这一年前后对于现在的Hadoop Ecosystem有着很重要的意义。而我觉得再我们进入到近代Hadoop的历史之前，做个小结，问几个问题，试着寻找一下答案，也是颇有意义的一件事情。

大数据的发展，在2008年以前，属于古代。古代的时候，只有Google耀眼的三驾马车以及年年赚钱的财报。Hadoop的屌丝轮子正在努力的造着。不知道接下来的情况怎么样。至于其他的建筑于大数据基础构架之上的轮子，半个影子也没有见到。而2008年的时候，开始出现了现在还知道名字的Pig，现在不但知道名字，还以老一辈先辈在努力和后辈继续战斗的HIVE，以及曾经闪过几下但是现在恐怕没有几个人知道的JAQL。

　　虽然说作为一个Database的PhD，07年的时候就已经读过了Google的马车们，包括BigTable这样的著作。然而只是在2008年我来到IBM Almaden Research Center，第一次用上破败不堪的 Hadoop 的时候才真正的感受到大数据的力量。当然，那个时候的Hadoop圈子们自己也不知道自己要走向哪里去。在Yahoo的Hadoop Summit我参加了几次。经常就是迷茫加互相打鸡血的状态，就着pizza。那个时候我也遇到了IBM研究院里的一个牛人Eugene Shekita。我这几十年的人生里见过的聪明人也很多了，然而不得不说，能够让我比这位印象还深刻的人，实在是几乎没有。这位当然后来种种原因离开了钟爱的IBM去了Google。他在那个时候就极具远见的坚定不移的表示Hadoop这个东西虽然现在破烂，以后必然会大放异彩。

那个时候我就在想了，Google有着极为先进的理念，和非常优秀的infrastructure。放着大数据这样的一个蛋糕，为什么就没开源出来，来主导这个领域的发展。而Hadoop这个如果Google的系统是火箭的话，这个撑死一拖拉机的系统，居然越来越壮大和进化了。如果我们需要深究下去的话，其实Hadoop的实现也有很多的不同地方。最简单的就是各种概念都大量的简化了。这个问题等我再过两三年以后才明白。

Windows95的成功不是说windows有多好，是Mac实在是太贵。一个贵得离谱的东西即使再牛，也不会有市场。Google这个公司有一个非常奇特的偏见，这个偏见在很多的行为上都表现出来。这个偏见就是Google自己觉得自己是怎么样的，这个世界就应该是怎么样的。倒不一定是傲慢，而是确实睁眼瞎。

比如说，Google的MapReduce是为了解决海量数据上做inverted index的问题而设计的。Google的整个系统和平台都是为了整个互联网服务的。这意味着什么呢?简单一点就是大，数据规模大，需要的机器多，要的计算量大，各种各样的随机失败也很多。所以Google做出来的系统都是首先要有足够的体量，跨几个data center无所谓，其次要有很高的并发度，再次还需要足够多的冗余以及自动恢复的能力。但是请注意，这些东西都是需要代价的。这种代价，有的时候在不同的场景看，还非常的大。

而Hadoop的起家则很不一样，就是两个程序猿要为开源做贡献，当然其中一猿最后成了Cloudera的首席，一猿成了大学的叫兽。两个人，撑死了以10为量级的机器，搭出来的一个不稳定的各方面简化的系统。这样的系统有一个天然的优点：屌丝，够cheap。

我来解释一下吧。大概是2011年的时候，学术圈有人做了一个调查，看看大家用的Hadoop Cluster到底有多大，结果出来很有意思，20台机器左右的Hadoop Cluster占据了不止半壁江山。往上走，最多几百，上千的Hadoop cluster只存在于已经功成名就的互联网公司。拿微软的Cosmos举个例子就明白了。Cosmos是一个很多方面设计理念比Hadoop要先进的系统，但是它本来就是为了大的数据中心设计的。一个数据中心要部署Cosmos，先要来几十台机器，不做实际的事情，这些机器有的管deploy，有的管监控，有的管调度，这些都是不可用的worker。一个数据中心上去几万台机器，为了能更好更自动化的运行，弄出几十台机器去干其他活，其实性价比很高。但是Cosmos就是这样的贱，如果你来40台机器，它还是要这个那个的占去很多，deploy完了，我的妈，有一半的机器能干实际的MapReduce就不错了。对于小一些的cluster，这资源的利用率和各种各样需要加上的没什么意义的service，让这种系统成为一个没什么性价比的系统。

Google既然有GFS， 有Borg，有很多其他的东西，那么部署起来，必然是需要很多机器做不是实际的事情的。这无法避免的根本在于那个系统本来一开始就是为了一个大数据中心而设计的。所以屌丝的确也有屌丝的好处。一个系统如果设计起来弄进了条条框框，就容易把自己框的死死的，谁也不能免俗。我想即使Google一开始不愿意开源，后来恐怕不是不愿意，而是开不出来吧。就算开出来了，占据Hadoop市场大部分的中小型cluster也无法高效率的部署这样的系统。

所以很多年以后再来看，Hadoop能够起来，也有着它是从几十台机器起家，开始就设计的特别的屌丝的血脉在。毕竟在这个世界上，需要处理整个互联网规模的数据的公司，终究是两个手指头竖的过来的。而那些需要几十台机器部署BigData的解决方案的公司，则是无穷无尽的。

我知道，我想大家也知道，Hadoop取得的成功有着很多的原因，但是有的时候从根源上看一看，然后看看到底有多少的客户对应了这种根源上的需求，其实也能从另外一面给我们一些启示。所以从做人的角度来说，我们每个人也是被我们自己的日积月累的bias所围困着，能跳开自身局限之外看世界的人，都是伟人。时势造英雄还是英雄成就时势，真是永恒的话题。

未完待续，敬请期待。

大数据杂谈

ID：BigdataTina2016

责任编辑：陈近梅