071 谷歌的大数据路：一场影响深远的论战 在大数据发展史上有过一场非常著名的论战，这场争议影响深远，值得大书特书：其中一方是数据库领域的元老级人物迈克尔 · 斯通布雷克（Michael Stonebraker）和大卫 · 德威特（David Dewitt）。另外一方是主导了谷歌技术发展的杰夫 · 迪恩（Jeff Dean）。这两群人就谷歌“三架马车”之一的MapReduce和数据库到底谁好谁坏，争得不可开交。

在讲述这段故事之前，我先来介绍一下两方的人物。迈克尔是数据库领域的元老级人物，也是这场争议发起者。我们通常把数据库领域的人分为搞理论研究的和做数据库系统研究的两类，而迈克尔当之无愧是数据库系统研究领域最具影响力的人，没有之一。

迈克尔做过很多具有开拓性的事情，这里我就不再一一列举了，拣最最重要地来说。

迈克尔是第一个关系数据库系统Ingres的研发者，还是开源数据库系统Postgres最早的开发者。Postgres是目前开源数据库里面最具影响力的项目之一，只有MySQL勉强可以匹敌。

同时，迈克尔还是列存数据库C-Store，以及此后的商用版Vertica的开发者。他开发的系统，很多都被公司商业化了。

他还于2015年获得了图灵奖，迄今为止数据库领域只有4个人获得了这个奖项。他的学生更是遍布整个数据库领域的大学、政府、公司等等。

和迈克尔一同发起这场论战的大卫，曾经是美国威斯康辛大学的教授，退休之后被微软聘用，成为微软的技术院士。他同样也是数据库领域的元老级人物，最初的并行数据库系统和很多算法都是他提出来的。虽然和迈克尔比起来，大卫更加学术一些，但这丝毫没有影响到他在工业界的地位。

这场争论的另外一方人物是谷歌最牛、名气最大的工程师杰夫，他还是美国工程院院士，在谷歌内外都拥有庞大的粉丝群。他参与了谷歌多个重要项目的研发，为谷歌的基础架构研发做出了开创性和奠基性的工作。谷歌“三驾马车”中的MapReduce和BigTable，他都是主要的研发者和设计者，这场论战针对的MapReduce就是他最引以为傲的项目。

可以这样说，因为杰夫，谷歌才有了今天的高度。无论是早期基础架构研发的开创性工作，还是后期在人工智能方面的突破，没有杰夫，谷歌不一定能走这么远。但是，我们同样可以说，是谷歌成就了杰夫。因为，只有谷歌才有如此多的数据、计算机资源，和杰出的人才储备，可以让杰夫有足够的发挥空间和平台。

介绍完了相持不下的两方人物，我具体说说这场论战。这场针对MapReduce和数据库的争论在2008年1月17日爆发，这一天迈克尔、大卫以及朋友们联合发表了一篇长文“MapReduce:一个巨大的倒退”（MapReduce：A major step backwards），开始了对MapReduce的围剿。

这篇文章引起了广泛关注和讨论。首先，作者都是计算机行业赫赫有名的人物；其次，文章公然对谷歌宣传的新技术、伟大发明提出质疑。我们知道，这种质疑如果出自你我这样的“吃瓜群众”，谷歌当然不在乎。但如果是泰斗级的人物提出质疑，那就有如“平地一声雷”，每个人都要好好想一想了。

这篇博文的主要观点如下：

  • MapReduce让人感觉像是生活在原始社会。使用MapReduce查询数据时还需要写很多的C++或者Java程序，而数据库系统在很多年前就发明了SQL语言，通过SQL语言本可以很方便地进行数据查询。
  • MapReduce毫无效率可言。它并不是一个最优实现，现代数据库系统实现多年的性能优化（例如索引），在MapReduce里面都没有得到体现。
  • MapReduce不具创新性。函数式编程语言很早就具备MapReduce的语言特性了。
  • MapReduce不能兼容数据库系统用户已经依赖的所有工具，并且缺乏当前数据库系统拥有的大多数特性。

客观地说，在我这个“吃瓜群众”看来，第一点“感觉像是生活在原始社会”的比喻其实不是问题。因为Hadoop生态圈里很快就出现了类似SQL的查询语言。如果有需要，谷歌也可以分分钟钟在MapReduce里面实现用SQL检索数据的功能。

第二点所说的“毫无效率”确实是问题，也是最为大家诟病的问题。后来，整个学术界和工业界围绕MapReduce的优化展开的各种工作，无非就是把分布式数据库领域里面实现了很多年的功能重新做了一遍。

至于第三点“MapReduce不具创新性”，有点儿道理，但也不是什么大问题。函数式编程里面的Map、Reduce和谷歌实现的MapReduce显然不是同一个概念，它们只是形似而已。而且，创新与否并不是衡量一个系统好坏的标准。

而第四点所说的“和现有数据库工具不兼容”，在我看来就多少有点牵强附会了。因为谷歌内部的系统完全可以形成闭环，不需要兼容外面的数据库工具。而且，和外部数据库的兼容也并不是什么大问题，开源的Hadoop社区很快就解决了这个问题。

其实，这篇博文最大的问题是，文中只提到了数据库比MapReduce好的方面，却没有说MapReduce的优势，因此表述太过偏颇。

相对于数据库系统来说，MapReduce最主要的优点是提出了在海量的普通廉价个人计算机上，进行稳定的大规模并行计算需要的技术，因为传统意义上的数据库系统都需要很高端的机器来完成同样的任务。

对于数据库系统来说，机器可以随时坏掉，但是系统却必须不间断地运行。因此，数据库系统必须要在稳定可靠的高端机器上运行，并进行冗余备份，来规避机器坏掉的风险。这就在无形中增加了数据库系统运行的成本，而MapReduce很好地解决了这个问题。

这场争论影响广泛，以至于数据库圈子里的很多人都开始站队。有支持甲方迈克尔和大卫的，也有支持乙方杰夫和谷歌的，还有“和稀泥”觉得双方都有道理的。这场争论更是持续了两年之久，“MapReduce到底是好是坏”也慢慢演变成为了学术圈的一个政治问题。

2009年，大卫在SIGMOD大会上发表了一篇论文：《大规模数据分析方法对比》（/A comparison of approaches to large-scale data analysis/）。论文比较了MapReduce在Hadoop开源社区中的实现和数据库系统的性能，并得出了数据库系统性能要好很多的结论。当时，我就在SIGMOD的现场，论文宣讲结束后，无数人质疑这篇论文的评价方式是否公平。

我印象最为深刻的是，数据库领域的知名学者拉 · 罗摩克里希纳恩（Raghu Ramakrishnan）当场就提出了质疑。他曾经和大卫同为威斯康辛大学的教授，不久前加入了雅虎研究院，并负责数据库研究工作。而雅虎是Hadoop的主导者，所以通常和大卫意见一致的他，这次却对这篇论文的内容表示了强烈反对。在我看来，这更多的就是政治立场的不同了。

更加不可思议的是，美国计算机协会ACM的重要刊物Communications of the ACM 也介入进了这场论战。这个杂志是美国计算机协会的会刊，通常刊登一些在计算机领域比较有影响力的文章。

2010年的第1期刊登了涉及这场争论的两篇论文：《MapReduce和并行数据库：是朋友还是敌人？》（MapReduce and Parallel DBMSs：Friends or Foes？）和《MapReduce：一个灵活的数据库处理工具》（MapReduce：A Flexible Data Processing Tool）。

虽然两篇文章都互相引用了对方的观点，但很大程度上还是自说自话。据我所知，这是Communications of the ACM 第一次刊登这种类型的文章，这也说明论战已经影响到整个计算机领域，不再仅仅局限于数据库的圈子了，可谓“一石激起千层浪”。

这场论战的深远影响还体现在，很多人都对这场论战的两方观点进行了认真思考，并希望可以扬长避短开发出更好的系统。但是，真正把从这场论战中得到的反思成功付诸实际行动的，就只有加州伯克利大学AMP实验室里的那群人了，他们发明了一个叫作Spark的计算引擎。

Spark项目的重要负责人之一迈克尔 · 富兰克林（Michael Franklin）在2017年的国际数据库顶级会议VLDB (International Conference of Very Large Data Base）上做了一个主题演讲：《大数据软件路在何方》（Big Data Software: What’s Next? ），主要内容就是“Spark是如何诞生的”。

在主题报告上，他提到了这场论战，当时整个AMP实验室的教授们都在思考这两方到底谁更有道理。经过非常深入地思考和论证，AMP实验室的教授们决定吸取MapReduce和数据库系统两方的精华，同时抛弃这两方不合理的地方，从头开始构建一个大数据计算引擎。于是，Spark在这样的背景下诞生了。

目前来看，Spark非常得成功。它既不是数据库，也不像MapReduce。在某种程度上来说，Spark是两者的结合，又有自己的创新。现在，Spark归属于这群人的创业公司Databricks，有关Spark和Databricks的故事我会在这个系列后续的文章里详细讲解。

这次针对MapReduce和数据库的大论战，最后伴随着Spark的诞生也就有了结果。

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e6%8a%80%e6%9c%af%e4%b8%8e%e5%95%86%e4%b8%9a%e6%a1%88%e4%be%8b%e8%a7%a3%e8%af%bb/071%20%e8%b0%b7%e6%ad%8c%e7%9a%84%e5%a4%a7%e6%95%b0%e6%8d%ae%e8%b7%af%ef%bc%9a%e4%b8%80%e5%9c%ba%e5%bd%b1%e5%93%8d%e6%b7%b1%e8%bf%9c%e7%9a%84%e8%ae%ba%e6%88%98.md