大數據那些事(29):從Spark到Spark

微信公眾號：飛總的IT世界面面觀

頭條號：飛總的IT世界面面觀

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無疑是大數據開源項目裡面最具影響力的項目之一，而且其影響力應該會是越來越大。