大数据那些事(29):从Spark到Spark

Spark，当前大数据领域最活跃的开源项目。好几个人想让我写写Spark了，说实话我觉得对Spark来说有点难写。Spark的论文我倒多半读过，但是Spark的系统就没怎么用过了。所以以一个没有实际使用经验的人去写这样一个当红的系统， 我也不知道楼会歪到哪里去。

大家可能觉得这个标题很奇怪，确实，当我们开始谈论Spark的时候，我们需要区分一下最初Matei Zaharia论文里写的Spark，还是今天开源社区广泛使用的Spark。Spark和其他的开源项目有一个最大的不同，一开始是作为研究项目从学校里面出来的，现在则更多的是一个工业界使用的项目。研究和工业界的产品之间的差距，对于我这种读过PhD做过那样的系统和今天在写商用系统的人来说，之间的区别还是大概可以说的。

举个例子来说，关系数据库里面最成功的研究系统，同样是伯克利出品的Ingres显然少不了。Ingres后来也商用了，被Oracle打败了。现在最成功的商用系统则应该是Oracle。所以此Spark非彼Spark。

2016年在印度开VLDB，晚上吃饭的时候旁边坐着的是从OS领域来客串DB会议的一个知名教授。喝了酒之后是相当的出言不逊。大致的意思说，database这几年是越混越不行了，你看所谓的BigData主要都是我们OS的人在做，从早年的MapReduce，BigTable，到现在当红的Spark，哪个不是我们OS的人做出来的。这些人把论文投到了DB的会议，一个一个被拒了。周围一群正统做DB的人都不知道怎么接这个话。

当时就让我想起了可能是2011年的事情了，时间不太记得。但是我一个开始做DB转做OS的PhD朋友，后来成了著名教授，给我转了Spark的论文，问我有什么感受。我算得上初生牛犊吧，和对方的回复很简单啊，这篇论文投到database的会议来，肯定被拒啊。这是大名鼎鼎的Spark，如今业界无数公司在用的Spark。那么现在是2017年了，我回头问我自己，倘若那篇文章今天投稿到一个DB的会议，有假设才刚做出来，没多大名气，而我是审稿人之一，结果会是什么样。这个问题我问自己好几回，最后的答案是，倘若投了industry track，多半是发了，要是投到research track，基本上还是据。

各位看官看不明白了。数据库领域的会议，对于创新性的要求很高，对系统的可用性要求没那么高。说白了如果说思想是先进的，那么这个系统只是能跑几个查询，也就发了，至于有多少个bug，是不是能在实际中很好的用，就不好说了。而Spark如果作为一个研究项目，从创新性的角度去看，至少最初的那个版本，不管是RDD也好，还是作为一个通用的DAG execution engine也好，不是新鲜东西。举几个例子，Dryad， DryadLinq，FlumeJava这些发表更早或者同期的论文里面，都有着相似的思想，而我每次听Spark早年的体系架构讲座，感觉就是我在微软开组会看内部文档经常看到的东西。只是在那个时候open-source圈子里并无这样的东西存在。

有个大八卦是我有次和UT Austin一教授聊天的时候听说的，Spark的作者Matei当年毕业去面试UT Austin，作为有图灵奖的计算机系，Austin的老教授们听完他做的这个东西，颇不以为然，觉得这东西没啥新意，然后就把大神给据了。我讲这个八卦绝非鄙视大神，一个能进MIT去stanford的人，能把Spark从无到有带那么大的人，毫无疑问是大神。但是数据库这个圈子里的人非常的强调创新性，而并不是那样的强调可用性。这到底是好事还是坏事，我时常在想这个问题，也想不清楚。相反而言OS的圈子对于系统实用性的在意程度，明显比DB这个圈子更接地气，而不是过度去追求那些虚无缥缈的创新性。我想过度的追求原创性，而不重视可用性，也是一种病。

但是毫无疑问，Spark是迄今为止由学校主导的最为成功的开源大数据项目，几乎很难再有之二了。那么撇开这一个所谓的创新性我们来看看Spark为什么会那么成功。天时地利人和，其实我觉得Spark都做得很好。

Hadoop流行起来的时候，MapReduce很大程度上是被绑在了Hadoop上。MapReduce的弊病当然也很快被大家发现，尤其做机器学习的开源软件Mahout早年在MapReduce上写，那叫一个坑爹。业界有需求，那是非常明确的。

UCBerkeley作为一个传统上非常有名的系统学校，它曾经出过的系统都有一个非常明确的特点，可用性非常高。大凡高校做研究，学生做的东西，bug那基本上是满天飞，很难真正在产品里面能用。行百里者半九十。这最后的十里，毫无疑问，绝大部分学校放弃了。譬如说华盛顿大学的某知名系统，很多查询号称都比Spark快很多，但是架不住bug多没有人敢用啊。UCBerkeley这方面和别的学校很不一样，大概是早年Michael Stonebraker留下来的传统吧。系统做得都是非常的可用，最初的版本的系统的稳定性，虽然也会遇到很多头疼的问题，但是一般来说作为一个通用系统，可用性是非常的高。这在Spark上也是毫无疑问的体现出来了。

加上湾区是一个很特殊的地方，新东西出来，summit开起来，就会有很多公司去尝试，尝试着，好东西大浪淘沙，就很快被淘出来了。所以Spark能够流行起来也是不奇怪的。

而且Spark的团队显然非常的知道在什么时候应该做什么。Spark最初建立的生态圈的重点主要放在了图算法和机器学习上。虽然说也做一点累世SQL on Hadoop的东西。但是当时HIVE作为敌人太强大，而Mahout什么的还有各类图算法的库，相对来说就弱多了，也有需求，所以最初的生态圈建立的非常的成功。

成功的站稳了根据地以后又很早的和工业界进行了各种合作，Spark在非常早的时候就和Intel的人合作了，那个时候有工业界的人进来我想肯定是很大的助力。现在自然更不用说，自从大数据以来就做百变金刚天天换技术的IBM最后终于把自己的未来绑在了Spark的战车上，算得上是一个很好的例子。

Spark团队在商业上布局很少犯错误。我过去几年里注意到比较明显的错误是Shark这个东西。在Spark上面再搭一个东西做SQL on Hadoop还是说要把SQL做进Spark里面去，这个选择，我一直以来都认为SQL应该做进其他东西里面去做为一个component，这才是BigData Analytics未来的正确道路。那种SQL on Hadoop的产品有其生存空间，但也就这样了。Shark明显是一个没有发挥Spark威力而把Spark引向错误道路的项目。但是很快的这个项目就停了，Spark SQL出来了，DataFrame也出来了。不得不说，这是Spark团队在关键时候做了一次非常重要而正确的历史选择。如果当初继续做Shark，我想可能是另外一个局面了。 另外一个需要提一句的是BlinkDB这个项目，也是这个团队里面少数在我看来犯了错误的项目，但是这个项目应该也停止多年了。

我在2014年决定离开微软的时候，投过很多企业，也包括databricks。简历在对方系统里面出了点问题，过了若干个月以后，我在Tableau工作大概已经一个月了，接到对方的回复说我简历给遗漏了，问我是不是愿意再去面试。大家都知道，找工作是个辛苦事，一鼓作气，再而衰，三而竭。在新公司一个月就去面试然后离职，确实说不过去，而且当时我的状态已经是面试完彻底出了一口气的懒散状态，真去面试估计应该也会面挂掉，所以我也就这样和Databricks错失了一次面试的机会。

我想Spark这个作为从UCBerkeley出来的项目，从最初的高可用性，到开始建立的生态圈，到后来的发展，乃至自身的纠错，方方面面毫无疑问都证明了现在Spark无疑是大数据开源项目里面最具影响力的项目之一，而且其影响力应该会是越来越大。