大数据那些事:从Spark到Spark

  1. 云栖社区>
  2. 博客>
  3. 正文

大数据那些事:从Spark到Spark

泡泡浅眠 2017-07-05 09:08:00 浏览1486
展开阅读全文

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无疑是大数据开源项目里面最具影响力的项目之一,而且其影响力应该会是越来越大。

【本文为51CTO专栏作者“徐飞”的原创稿件,转载请通过作者微信公众号“飞总的IT世界面面观”获取联系和授权】

本文转自d1net(转载)

网友评论

登录后评论
0/500
评论
泡泡浅眠
+ 关注