Spark，當前大數(shù)據(jù)領(lǐng)域最活躍的開源項目。好幾個人想讓我寫寫Spark了，說實話我覺得對Spark來說有點難寫。Spark的論文我倒多半讀過，但是Spark的系統(tǒng)就沒怎么用過了。所以以一個沒有實際使用經(jīng)驗的人去寫這樣一個當紅的系統(tǒng)， 我也不知道樓會歪到哪里去。

大家可能覺得這個標題很奇怪，確實，當我們開始談?wù)揝park的時候，我們需要區(qū)分一下最初Matei Zaharia論文里寫的Spark，還是今天開源社區(qū)廣泛使用的Spark。Spark和其他的開源項目有一個最大的不同，一開始是作為研究項目從學(xué)校里面出來的，現(xiàn)在則更多的是一個工業(yè)界使用的項目。研究和工業(yè)界的產(chǎn)品之間的差距，對于我這種讀過PhD做過那樣的系統(tǒng)和今天在寫商用系統(tǒng)的人來說，之間的區(qū)別還是大概可以說的。

舉個例子來說，關(guān)系數(shù)據(jù)庫里面最成功的研究系統(tǒng)，同樣是伯克利出品的Ingres顯然少不了。Ingres后來也商用了，被Oracle打敗了?，F(xiàn)在最成功的商用系統(tǒng)則應(yīng)該是Oracle。所以此Spark非彼Spark。

2016年在印度開VLDB，晚上吃飯的時候旁邊坐著的是從OS領(lǐng)域來客串DB會議的一個知名教授。喝了酒之后是相當?shù)某鲅圆贿d。大致的意思說，database這幾年是越混越不行了，你看所謂的BigData主要都是我們OS的人在做，從早年的MapReduce，BigTable，到現(xiàn)在當紅的Spark，哪個不是我們OS的人做出來的。這些人把論文投到了DB的會議，一個一個被拒了。周圍一群正統(tǒng)做DB的人都不知道怎么接這個話。

當時就讓我想起了可能是2011年的事情了，時間不太記得。但是我一個開始做DB轉(zhuǎn)做OS的PhD朋友，后來成了著名教授，給我轉(zhuǎn)了Spark的論文，問我有什么感受。我算得上初生牛犢吧，和對方的回復(fù)很簡單啊，這篇論文投到database的會議來，肯定被拒啊。這是大名鼎鼎的Spark，如今業(yè)界無數(shù)公司在用的Spark。那么現(xiàn)在是2017年了，我回頭問我自己，倘若那篇文章今天投稿到一個DB的會議，有假設(shè)才剛做出來，沒多大名氣，而我是審稿人之一，結(jié)果會是什么樣。這個問題我問自己好幾回，最后的答案是，倘若投了industry track，多半是發(fā)了，要是投到research track，基本上還是據(jù)。

各位看官看不明白了。數(shù)據(jù)庫領(lǐng)域的會議，對于創(chuàng)新性的要求很高，對系統(tǒng)的可用性要求沒那么高。說白了如果說思想是先進的，那么這個系統(tǒng)只是能跑幾個查詢，也就發(fā)了，至于有多少個bug，是不是能在實際中很好的用，就不好說了。而Spark如果作為一個研究項目，從創(chuàng)新性的角度去看，至少最初的那個版本，不管是RDD也好，還是作為一個通用的DAG execution engine也好，不是新鮮東西。舉幾個例子，Dryad， DryadLinq，F(xiàn)lumeJava這些發(fā)表更早或者同期的論文里面，都有著相似的思想，而我每次聽Spark早年的體系架構(gòu)講座，感覺就是我在微軟開組會看內(nèi)部文檔經(jīng)?？吹降臇|西。只是在那個時候open-source圈子里并無這樣的東西存在。

有個大八卦是我有次和UT Austin一教授聊天的時候聽說的，Spark的作者Matei當年畢業(yè)去面試UT Austin，作為有圖靈獎的計算機系，Austin的老教授們聽完他做的這個東西，頗不以為然，覺得這東西沒啥新意，然后就把大神給據(jù)了。我講這個八卦絕非鄙視大神，一個能進MIT去stanford的人，能把Spark從無到有帶那么大的人，毫無疑問是大神。但是數(shù)據(jù)庫這個圈子里的人非常的強調(diào)創(chuàng)新性，而并不是那樣的強調(diào)可用性。這到底是好事還是壞事，我時常在想這個問題，也想不清楚。相反而言O(shè)S的圈子對于系統(tǒng)實用性的在意程度，明顯比DB這個圈子更接地氣，而不是過度去追求那些虛無縹緲的創(chuàng)新性。我想過度的追求原創(chuàng)性，而不重視可用性，也是一種病。

但是毫無疑問，Spark是迄今為止由學(xué)校主導(dǎo)的最為成功的開源大數(shù)據(jù)項目，幾乎很難再有之二了。那么撇開這一個所謂的創(chuàng)新性我們來看看Spark為什么會那么成功。天時地利人和，其實我覺得Spark都做得很好。

Hadoop流行起來的時候，MapReduce很大程度上是被綁在了Hadoop上。MapReduce的弊病當然也很快被大家發(fā)現(xiàn)，尤其做機器學(xué)習(xí)的開源軟件Mahout早年在MapReduce上寫，那叫一個坑爹。業(yè)界有需求，那是非常明確的。

UCBerkeley作為一個傳統(tǒng)上非常有名的系統(tǒng)學(xué)校，它曾經(jīng)出過的系統(tǒng)都有一個非常明確的特點，可用性非常高。大凡高校做研究，學(xué)生做的東西，bug那基本上是滿天飛，很難真正在產(chǎn)品里面能用。行百里者半九十。這最后的十里，毫無疑問，絕大部分學(xué)校放棄了。譬如說華盛頓大學(xué)的某知名系統(tǒng)，很多查詢號稱都比Spark快很多，但是架不住bug多沒有人敢用啊。UCBerkeley這方面和別的學(xué)校很不一樣，大概是早年Michael Stonebraker留下來的傳統(tǒng)吧。系統(tǒng)做得都是非常的可用，最初的版本的系統(tǒng)的穩(wěn)定性，雖然也會遇到很多頭疼的問題，但是一般來說作為一個通用系統(tǒng)，可用性是非常的高。這在Spark上也是毫無疑問的體現(xiàn)出來了。

加上灣區(qū)是一個很特殊的地方，新東西出來，summit開起來，就會有很多公司去嘗試，嘗試著，好東西大浪淘沙，就很快被淘出來了。所以Spark能夠流行起來也是不奇怪的。

而且Spark的團隊顯然非常的知道在什么時候應(yīng)該做什么。Spark最初建立的生態(tài)圈的重點主要放在了圖算法和機器學(xué)習(xí)上。雖然說也做一點累世SQL on Hadoop的東西。但是當時HIVE作為敵人太強大，而Mahout什么的還有各類圖算法的庫，相對來說就弱多了，也有需求，所以最初的生態(tài)圈建立的非常的成功。

成功的站穩(wěn)了根據(jù)地以后又很早的和工業(yè)界進行了各種合作，Spark在非常早的時候就和Intel的人合作了，那個時候有工業(yè)界的人進來我想肯定是很大的助力。現(xiàn)在自然更不用說，自從大數(shù)據(jù)以來就做百變金剛天天換技術(shù)的IBM最后終于把自己的未來綁在了Spark的戰(zhàn)車上，算得上是一個很好的例子。

Spark團隊在商業(yè)上布局很少犯錯誤。我過去幾年里注意到比較明顯的錯誤是Shark這個東西。在Spark上面再搭一個東西做SQL on Hadoop還是說要把SQL做進Spark里面去，這個選擇，我一直以來都認為SQL應(yīng)該做進其他東西里面去做為一個component，這才是BigData Analytics未來的正確道路。那種SQL on Hadoop的產(chǎn)品有其生存空間，但也就這樣了。Shark明顯是一個沒有發(fā)揮Spark威力而把Spark引向錯誤道路的項目。但是很快的這個項目就停了，Spark SQL出來了，DataFrame也出來了。不得不說，這是Spark團隊在關(guān)鍵時候做了一次非常重要而正確的歷史選擇。如果當初繼續(xù)做Shark，我想可能是另外一個局面了。 另外一個需要提一句的是BlinkDB這個項目，也是這個團隊里面少數(shù)在我看來犯了錯誤的項目，但是這個項目應(yīng)該也停止多年了。

我在2014年決定離開微軟的時候，投過很多企業(yè)，也包括databricks。簡歷在對方系統(tǒng)里面出了點問題，過了若干個月以后，我在Tableau工作大概已經(jīng)一個月了，接到對方的回復(fù)說我簡歷給遺漏了，問我是不是愿意再去面試。大家都知道，找工作是個辛苦事，一鼓作氣，再而衰，三而竭。在新公司一個月就去面試然后離職，確實說不過去，而且當時我的狀態(tài)已經(jīng)是面試完徹底出了一口氣的懶散狀態(tài)，真去面試估計應(yīng)該也會面掛掉，所以我也就這樣和Databricks錯失了一次面試的機會。

我想Spark這個作為從UCBerkeley出來的項目，從最初的高可用性，到開始建立的生態(tài)圈，到后來的發(fā)展，乃至自身的糾錯，方方面面毫無疑問都證明了現(xiàn)在Spark無疑是大數(shù)據(jù)開源項目里面最具影響力的項目之一，而且其影響力應(yīng)該會是越來越大。

【本文為51CTO專欄作者“徐飛”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號“飛總的IT世界面面觀”獲取聯(lián)系和授權(quán)】