大数据这个概念红红火火的也有两三个年头了，我在这个坑里的时间可能要更长一些，勉强可以从2008年开始算。所谓年头待得久了，看得也多一些。对应中国传统文化的说法，什么东西老了都能成精。这个坑的主要目的还是以八卦为主，顺便把我知道的道听途说的有的没的的大数据相关的东西给大家讲一讲，顺便也把大数据来龙去脉理一理，权当诸位茶余饭后的谈资。倘若写到精彩之处，还请多多打赏。钱多钱少其实不是问题，收起打赏就颇有成就感。感觉人生又完整了一些。
Google的后悔药
大概说起大数据，我们就不可避免的要谈起这个曾经在国内风光无限，然后又从国内退出去的公司，号称Do not Evil而实际上相当Evil的公司——Google。当然，因为我本人的经历的关系，我在自己公众号前面的文章里也提到过，我是Gou黑软粉，不是和主流大众的审美观一致。
不可否认，大数据伊始，主要是因为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这个词出来以后，不知道有多少篇论文发表出来，又不知道有多少口诛笔伐的文章。我曾经在HANA篇里写过围绕MapReduce，Google和Michael StoneBraker等等database的元老之间的论战。欢迎大家先读读这篇八卦文。为了避免重复，这篇文章里，我就不再展开这部分的话题了。
作为论文来说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给学术界掀起了一片灌水高潮，学术界自娱自乐的精神实在很值得敬佩。然而这个东西火得快，死的也快。所谓人怕出名猪怕撞。但愿我的公众号不会是MapReduce的下场。
以上内容由飞总授权转载，版权所有，侵权必究，转载请授权。
联系客服
