連城：大數據場景下的「搔到癢處」和「戳到痛處」

非商業轉載請註明做譯者、出處，並保留本文的原始連接：http://www.ituring.com.cn/article/179495

連城，Databricks工程師，Apache Spark committer。《Erlang/OTP併發編程實戰》與《Erlang併發編程（第一篇）》譯者。目前從事Apache Spark中結構化數據分析組件Spark SQL的開發。

在作Spark以前，連城歷來沒有作過大數據分析方向的工做。爲了理解函數式編程，他作了兩年和Scheme相關的side project；爲了學習分佈式存儲，他把1974年之後的分佈式文獻都過了一遍；爲了參與Spark相關的項目，他在Coursera上自學了Scala。現在做爲Spark committer的他，對大數據分析逐漸造成了本身的理解，他認爲「對工具的選擇，既能夠解放咱們的思想，也能夠禁錮咱們的思想」。而他本身曾經並不感冒的函數式編程，纔是更加契合大數據場景的編程方式。

愛上函數式編程

「由於從小到大走的都是C/C++/Java這類命令式語言的路線，函數式語言對於當時的我來講實在是很不合胃口。」

問：你是從何時開始編程的？

初一的時候由於我爸爸工做須要，家裏買了臺電腦，我就拿着電腦畫畫、玩掃雷。我爸大概是以爲我掃雷太上癮了，就不知從哪兒揀了一本少年兒童BASIC編程之類的書。如今惟一有印象的是那本書插圖特別地粗糙，講的基本概念也很是模糊。就i=i+1這麼一個概念，花了我好幾個禮拜才搞明白。由於那本書根本沒有講到賦值跟相等判斷的區別，而BASIC裏面賦值跟相等判斷都是一個等號。無論怎麼樣，正是這本書讓我知道了計算機編程這個事物的存在。

問：大學學的是什麼？

大學學的計算機。這是從初中開始就打定了主意的。初二時班級重組，剛好發現坐我前面的男生下課時間在草稿紙上塗寫BASIC程序，一問才知道他從小學就開始寫程序，因而拜師學藝。後來成了莫逆之交。如今他也在灣區工做。那時候其實也寫不出什麼有技術含量的東西。可是無知無畏啊，以爲寫程序的時候有造物主的感受，因而就下定決心走這條路了。

問：爲何對函數式編程和分佈式系統感興趣？

兩者都是從工做須要出發，逐漸探索出來的興趣。雖然從初中就開始寫程序，可是其實在本科以前歷來沒有接受過正規的計算機教育。畢業的時候各類基礎都通常，也沒有肯定到底要作哪一個細分方向。本科畢業後第一份工做是在網易杭州研究院作即時通信，也就是老一輩網民熟悉的網易泡泡。當時我也不知道本身對什麼感興趣，因而採起了一個簡單粗暴的策略：來者不拒，能幹的我都幹，再把不愛乾的篩掉。

在網易泡泡，我前後作過新舊版本的Windows客戶端、FreeBSD/Linux服務端以及舊版線上集羣運維等等。後來這個項目中須要用到一些分佈式存儲的東西，我以爲頗有意思。坦白說在此以前除了本科畢業的時候寫畢設翻過一些文獻材料，我尚未看過什麼論文。因而我從Google Bigtable開始，順着參考文獻列表一路往下遍歷，而後就一發不可收拾，包括後來去了百度也還在接着看。就這樣看了兩三年，大概1974年之後的分佈式文獻都過了一遍。

函數式編程其實也是在網易作即時通信的時候接觸到的。即時通信有一個開放的協議叫XMPP，當時我想找一個開源的分佈式XMPP服務器實現。找來找去，惟一一個比較靠譜的就是ejabberd。ejabberd是用Erlang寫的，而Erlang是一個函數式特性很強的語言。可是當時並無啃下去，由於從小到大走的都是C/C++/Java這類命令式語言的路線，函數式語言對於當時的我來講實在是很不合胃口。

後來到了百度，2009年我發現Facebook Chat的服務端就是一套定製版的ejabberd。大概也就是從那時候開始，Erlang開始進入互聯網行業，我想Facebook的這一動做應該算是個標誌。Erlang誕生於80年代，早就已經成熟應用在電信行業裏，最擅長處理的就是高併發、高可靠、分佈式的場景。而早年互聯網行業內這樣的場景還並不普遍，因而直到如今大衆纔開始關注Erlang。那時候我正好也還在研究分佈式系統，而且須要一套可以快速完成原型驗證的工具。用C/C++的話，光是底層網絡通信等基礎設施就已經夠複雜了。因而我又把Erlang撿起來了。此後，從Erlang出發，業餘又開始對函數式語言作了些研究。因此說，函數式編程和分佈式的學習背景其實都是由於工做須要。

問：你是如何學習函數式編程的？

玩Erlang的時候，我開始對Erlang的不少特性感到好奇，包括匿名函數、GC、尾遞歸調用等等，這些特性在Python、Ruby等一些動態語言中也一樣存在，可是我只知其然，而不知其因此然。我以爲好奇的是，第1、函數式語言跟普通的命令式語言的本質相比有什麼優點；第2、這些特性背後的運行時機制究竟是什麼。那個時候我在百度已經開始作管理，基本脫離了一線開發，說實話少了挺多樂趣。我就決定用業餘時間把函數式編程搞清楚。

我本身的習慣是每一年都會作一個side project，我以爲要把函數式搞明白，最簡單的辦法就是本身作一個實驗性的函數式語言實現，好比一個最簡單的解釋器什麼的，也不求它可以多麼高效、實用，只求把個中原理搞明白。既然是實驗，目標語言固然越簡單越好，因而選中了Scheme。Scheme的整個R5RS標準連目錄帶附錄總共才50頁，特別精簡。

由於都是業餘時間作，這個小項目斷斷續續地作了兩年，期間用不一樣方法重寫了若干遍。項目整個作完了以後，確實把動態類型函數式語言最基本的東西，從運行時模型到理論上的一些概念和原理都弄明白了。實際上就跟我以前研究的分佈式系統同樣，也是把主要文獻都粗略掃了一遍。

問：據說你在百度有一段時間在作管理工做，爲何？

這個說來有趣，最先入行的時候，對管理有誤解，原本是下定決心堅定不走管理路線的，由於當時以爲作經理這個事情特別無趣。百度內部各個部門有各自的TC（技術委員會），由部門內高級工程師組成，負責本部門的技術方向把控、技術評審、職稱評定等工做。我當時在客戶端軟件部，起初部門很小，高級工程師也很少。因爲當時處在擴張期，招了不少新人，TC的工做重點之一即是培訓和技術氛圍建設。我當時對這些事情比較活躍一些，發現新的、好玩的東西我比較喜歡拿出來跟你們講，由於我以爲若是好東西光我本身會用是用不起來的，必須你們一塊兒用，這個東西才能推得動。大概由於這個緣由，我入職不到一年的時候，TC主席破格把我調到TC。因爲TC站在一個相對全局的視角，而且常常須要跟其餘經理打交道，相對於其餘工程師，我得以更早地接觸到一些管理相關的工做，逐漸體會到了這些工做的重要性和難度。

後來，客戶端軟件部內部整合，須要創建一個後端團隊統一負責各產品的後端服務。因爲一時沒有合適的經理人選，TC主席對我說：「要不你先把這個隊伍建起來，過個半年咱們招到經理了就換你下來。」我心說，試試管理崗位也不錯，就答應了。結果這一干就幹了兩年沒換下來。這支隊伍我從零建起來，到離職時已經有25人，而且保持了部門內最低的離職率。這兩年裏，我從個人團隊和合做夥伴們那裏學到了大量的非技術知識和技能，並徹底改變了我之前對管理的幼稚見解。但儘管如此，我我的仍然對管理工做提不起興趣。所以直到離職爲止，也一直沒有正式轉到管理線上去。

問：後來找工做好像有些趣事？

是的，2012年下半年從百度離職，打算出國。準備了半年後來去Google、Amazon和Facebook面試，沒有成功，因此寫了那篇《加州求職記》。那篇文章兩三天被刷上萬，大概是由於不多有人寫面試失敗的面經，因此你們以爲特別親切吧……由於面試過程不順，刷題又很無聊，因而跟着Coursera上Martin Odersky開設的Functional Programming Principles in Scala課程學了Scala。巧的是，13年六月份意外得知Intel中國研究院在招會Scala的實習生作Spark。那時候Scala還在國內尚未多少動靜，不要說會，據說過Scala的學生都很少。當時我對Spark還一無所知，簡單看了一下，發現這個項目很好地結合了分佈式系統和函數式語言這兩個我最爲感興趣的技術方向。耐不住在家賦閒刷題的無聊，我最終以contractor身份加入了Intel，並和Intel中國研究院吳甘沙和楊棟帶領的團隊一塊兒作了大半年Hadoop和Spark相關的研究。

在作Spark以前，我歷來沒有作過大數據分析相關的方向。之前研究分佈式系統，主要集中在分佈式存儲方面，和大數據分析差異仍是蠻大的。在Intel期間，能在大數據分析方面快速入門，要特別感謝甘沙。他技術嗅覺極其敏銳，精力極其充沛，並且善於表達。在短期內就將這一領域的歷史、現狀、機遇高屋建瓴地描繪給了整個團隊。更妙的是，咱們團隊成員的能力很是互補，既有作操做系統的，又有作機器學習的，也有我這樣工做多年有實際系統經驗的。這半年多，算是我近幾年學習速度最快，長進最大的一段時間。

問：你是如何加入Databricks的？

剛開始作Spark相關的工做時，Databricks尚未成立。當時一方面是對Spark感興趣，一方面也是爲14年初在灣區找工做再打些基礎。（我在加入Intel之初就明確說過打算出國，也正所以一直是contractor。）

在Intel期間，我前後向Spark貢獻了一些補丁，對總體系統比較熟悉以後，就挑了一件相對完整的工做。我基於兩年多前Ankur Dave（後來GraphX的做者）的Arthur項目開發了用於分析和調試分佈式Spark做業的Spark Replay Debugger（惋惜後來並無被合併到主線）。這個時候，Databricks成立的消息公佈，對我產生了巨大的吸引力。正好公司創始人之一辛湜博士回國參加China Hadoop Summit。以Spark Replay Debugger爲契機，在甘沙的引薦下，辛湜爲我安排了面試。面試過程種種略去不表，最終總算幸運經過。

問：如今你在Databricks工做，可是尚未去美國那邊，你如今是怎麼和團隊合做的？

由於Apache Spark自己是個開源項目，你們直接經過GitHub和郵件列表就能夠比較好地交互。同時咱們每週有一到兩次遠程會議。還好時差不算太嚴重，北京早上8點的時候是加州那邊下午4點。通常事務主要經過郵件，急事則經過Google Hangout或Skype聯繫。因爲開源項目的公開透明性質，溝通問題並不太嚴重。

大數據處理的因此然

「JVM的設計使得在JVM之上實現函數式變成一種戴着枷鎖跳舞的藝術，Clojure、Scala都由於JVM的限制而不得不在語言層面做出了一些醜陋的妥協。」

問：Databricks上面有一個對Spark的介紹，其中提到大數據時代的計算平臺必需要開源，你能稍微解釋一下嗎？

我本身的理解是這樣的，大數據分析複雜性相對來講是很高的，從用戶的角度來看，複雜性突出體如今兩個方面：

第1、不少狀況下，採用大數據系統的組織內部本來就存在一些重要的遺留系統，不免面臨對內外系統進行擴展和/或改造，這時也會產生不少複雜的技術性和非技術性問題。採用開源系統時，咱們能夠有效地對系統進行定製。

第2、大數據系統通常來講代碼量比較大，動輒十數萬、數十萬行代碼，不免會存在各式各樣的缺陷；分析、調試、修復這些系統中的缺陷一樣是一個複雜的工做。大數據場景下，不少問題必須在足夠的體量下才可以重現，難以構造最小的問題重現場景，這使得現場調試定位顯得尤其重要。而開源軟件大大下降了現場調試定位的難度。

問：有人說MapReduce是一個巨大的倒退，說它倒退回了現代數據管理系統發明之前的時代，你怎麼看？

這個說法是數據庫大師David DeWitt和Michael Stonebraker在2008年在發表的MapReduce: A major step backwards一文中提出的。這裏的「現代數據管理系統」指的主要是關係數據庫。文章將MapReduce與關係數據庫作了一個詳細的比較，得出了MapReduce在功能、性能、易用性等方面相對於關係數據庫都是巨大倒退的結論，而且抨擊MapReduce背後的想法「毫無創新可言」，甚至還質疑了MapReduce的可伸縮性（scalability）。這篇文章自己發表以後飽受爭議。評論中有大量針鋒相對的辯論。我最爲贊同的兩點相反意見包括：

1. MapReduce和數據庫面臨的場景是很不同的。傳統數據庫處理的是規整的結構化數據集，全部數據都符合預先設定的規則（schema）；而Google最初MapReduce處理的是不規則的半結構化數據——整個互聯網。
2. MapReduce的可伸縮性是鐵板釘釘的不爭事實。MapReduce論文中提到，Google利用MapReduce天天處理20PB的數據，在當時這是任何傳統關係型數據庫也作不到的記錄。

MapReduce提供的抽象當然十分簡單，缺乏高層抽象和更加易用的接口，但在當時它確實有效地解決了最迫切的問題——可伸縮性。這就比如乘坐火車、汽車、輪船時咱們能夠用手機，但坐飛機的時候就不行，咱們能說飛機相對於火車等傳統交通工具是倒退嗎？當技術發展還不足夠成熟時，爲了達到某一重要目標，每每不得不捨棄另一些東西。

但從如今來看，MapReduce確實已經落伍了。DeWitt和Stonebraker提出的MapReduce的諸多缺點也逐漸被後來人所彌補。自Hadoop提供了開源的MapReduce以後，整個大數據產業蓬勃發展。缺乏schema、邏輯層和執行層耦合緊密的問題，已經由各類SQL on Hadoop系統解決；作複雜計算時MapReduce涉及的shuffle過多，磁盤IO密集的問題由Tez等DAG計算引擎緩解；MapReduce所不擅長的流式數據處理，也由MillWheel、Storm等系統挑起了大梁。而Spark做爲MapReduce的超集，更是能夠在單一軟件棧上搭建一體化的大數據流水線，同時完成批處理、流處理、關係查詢、迭代計算、圖計算等多種計算範式而無須維護多套系統。

因此我認爲，說MapReduce相對於現代數據管理系統是歷史倒退是不公平的，由於它在當時提供了關係數據庫沒法提供的價值——足以處理整個互聯網的超高可伸縮性。但在MapReduce論文發表十多年後的今天，它也確實該退休了。

問：JVM能在大數據領域裏面流行，其背後的緣由是什麼？

JVM在大數據領域的流行，與Hadoop脫不開干係。Hadoop自己的成功，與Java的低入門門檻、高開發效率（相對於C++而已）應該有至關大的關係。在HDFS、Hadoop MapReduce流行以後，爲了能與Hadoop無縫互操做，後續的一些大數據系統天然而然地也選擇了Java。近年來，雖然Java在語言層面發展緩慢，愈來愈被詬病，但Clojure、Scala等JVM上的新語言卻層出不窮，這又進一步激發了人們繼續以JVM爲平臺搭建新興大數據系統的熱情。Hadoop生態圈越作越大，而試圖加入這個生態圈的新系統若想無縫利用現有的遺產，就只能選擇JVM。因而雪球越滾越大，進而令JVM幾乎壟斷了整個大數據行業。

然而我想說的是，除了Hadoop的緣由以外，還有更多人的因素摻合在內。JVM之因此可以流行，另外一個緣由是JVM之上最初的語言Java，對於幾十年來被命令式語言和OOP所統治的工業界來講很是直觀和簡單。這種直觀和簡單最直接的體現就是初學者的心智負擔很低，讓人以爲「理所固然」，這使得人們天然而然地更傾向於使用這些這類語言，促使其流行。然而，直觀的事物卻未必是正確，反之正確的事物也未必就直觀——現實世界中客觀存在的波粒二象性、量子糾纏、黑洞等事物都是典型的反直覺的存在。

在這個問題上，我禁不住想多說兩句題外話。愈來愈多的實踐代表，函數式編程更加契合大數據場景。對不變性的強調使得分佈式一致性、容錯、並行/併發都變得更爲簡單和高效。函數式語言的各類基本算子天生適合數據並行處理。GFS/HDFS對數據不變性的強調以及MapReduce的成功，自己就是函數式編程範式適合大數據處理的絕佳證據。實際上不只僅是大數據領域，在不少方面函數式語言都有着優異的表現。雖然JVM上Clojure和Scala逐漸壯大，渣打銀行也打出了Haskell程序員的招聘帖，但爲何函數式語言卻仍然如此小衆呢？更進一步，我發現歷史上以及當前不少流行的工具，其實未必是該領域內最優的選項。這是爲何呢？

這兩年時不時會思考這個問題，得出了一些結論：

1. 對於大部分人來講，甚至包括不少很是聰明的人，他們並不樂於去改變本身的思惟方式——對本身的大腦從新「編程」實在太難了。
2. 流行的工具大體能夠分爲兩類。第一類能夠幫助人們以熟悉、直觀、符合大衆思惟的方式便捷地解決眼前的問題，搔到癢處。第二類要麼可以將不可能變爲可能，要麼在應用效果上遠遠超越同類競爭者，戳到痛處。

然而長遠來看，第一類解決方案卻未必正確，甚至每每犧牲了其餘更爲重要的系統屬性——例如一些動態語言中的monkey patching，看似方便，卻打破了對象運行時佈局不變的假設，結果既犧牲了運行時性能，又破壞了系統的靜態分析潛力，使得大型項目重構困難重重。第二類技術和工具，因爲效果絕佳、暫時無可替代，即使會帶來必定的心智負擔，要求大衆轉變思惟方式，你們也心甘情願。例如當年橫空出世時的MapReduce，以及如今的Spark。這類技術和工具，更有益於健康的思惟方式和方法論的推廣。正如Dijkstra在1975年時所說：

The tools we use have a profound (and devious!) influence on our
thinking habits, and, therefore, on our thinking abilities.

對工具的選擇，既能夠解放咱們的思想，也能夠禁錮咱們的思想。

從這個意義上將，做爲一個爲命令式OOP語言設計的JVM，在大數據領域已經開始顯得格格不入了。JVM的設計使得在JVM之上實現函數式變成一種戴着枷鎖跳舞的藝術，Clojure、Scala都由於JVM的限制而不得不在語言層面做出了一些醜陋的妥協。Erlang、Haskell等強調不變性的單次賦值語言所特有的高效GC和並行優點在JVM上也不可能實現。Full GC帶來的停頓恐怕是每一個與JVM打交道的工程師都飽嘗過的噩夢。

也正是由於這些限制，JVM上目前尚未一個特別令我滿意的語言實現，Scala算是JVM上最爲接近的一個。脫離JVM，Rust也是我特別感興趣的一門語言。我的特別期待能出現一門既帶有靜態強類型純函數式語言特質，又帶有與Erlang相似的運行時級別的軟實時、高併發支持，同時還能儘可能接近native執行性能的語言。

問：若是你的想法這麼具體的話，是否是能夠本身去寫了？

確實時不時會有這種想法。可是實際上去作一個語言的話，要作的並不只僅是一個編譯器，還有不少和整個生態發展相關的因素須要考慮，其工做量是巨大的，而且我自認如今也遠沒有相應的能力，耽於空想罷了。固然，我很是指望從此有精力的時候，可以去作這樣的研究。哪怕不是作一個實用的語言，僅僅試作一個原型，去作一些探索。

進擊的Spark

「他們試用過Spark SQL以後廣泛反饋：‘不再想回到Shark了。’」

問：Spark及其相似產品取代MapReduce是否是一個必然？

我以爲如今已經有比較明顯的趨勢了。固然，Spark跟Hadoop生態之間仍是一個補充關係，可是Spark做爲一個計算引擎，確實已是在革MapReduce的命了，實際上它也在革不少基於MapReduce搭建的其餘計算引擎的命。這也是爲何如今Mahout、Hive、Pig等一些原先基於Hadoop MapReduce的系統都正在逐漸遷移到Spark上來。

問：和Spark相似的好像還有一些模型，好比你剛纔提到的Tez，還有一個就是在2014 Daytona GraySort大賽中和Spark並列第一的Themis，能不能比較一下？

Themis系統其實是一個特化系統，而不是一個通用的計算引擎。這也是Spark在排序比賽當中獲獎特別使人振奮的一點，由於Spark並無專門爲這樣的一個排序競賽去作特殊的優化。Spark作的全部的優化實際上都是對總體執行效率以及穩定性的提高，搭建在Spark core之上的Spark Streaming、Spark SQL、MLlib、GraphX等全部組件均可以直接獲益。Tez雖然也是DAG計算引擎，從目前來看總體的執行效率還在Spark之下。Hive 0.14集成Tez引擎後，相對於Spark SQL，單從執行效率上講並未看到明顯優點。

問：Databricks提供技術支持的服務嗎？

雖然去年公司人數翻了一倍多，但Databricks目前總共也只有不到50人。直接面向終端用戶提供Spark技術支持很是消耗人力，這對於Databricks目前的規模來講是不現實的，咱們目前更但願將人力投入到研發和Spark的推廣上。目前Databricks和包括Coursera、Hortonworks、Pivotal、MapR在內的全部Hadoop發行商都創建和合做關係，終端用戶能夠從這些廠商處得到專業的技術支持服務。

問：Spark如今在國內和國外的應用狀況如何？國內如今有騰訊、百度這樣的企業用起來了，TDW應該算是國內Spark比較典型的成功案例，會不會影響大環境？

確定會帶來積極的影響。大公司的規模效應能夠起到一個定心丸的做用，增強了不少觀望中的中小公司的信心。據我所知，國內的不少小公司尤爲不少創業公司也都在用Spark。實際上，相對於大公司來說，Spark對於這些創業公司來講更加有吸引力。緣由很簡單，對於大公司來說，它們在引入Spark以前就已經有了本身的專有系統或者其餘開源系統。引入Spark以後，還有對接、替換、改造、擴展的成本。

此外，Spark相對於其餘大數據系統的一個巨大優點在於可讓開發者在一個系統內實現多種計算範式，從而無縫地在一套系統上搭建一個完整的一體化流水線。對於創業公司來講，無需部署多套系統，只須要一個stack，就能夠完成各類類型的大數據分析需求，這樣就節省了大量的學習成本、開發成本、部署成本和運維成本。對於大公司來說，因爲現有遺留系統的存在，Spark一體化流水線的優點反而不太容易發揮出來，他們只會用Spark來作現有系統作不到或作很差的事情。好比騰訊和阿里更多地是用Spark去作機器學習，而不太可能將從數據清洗開始的一整條數據流水線都遷移到Spark上來。百度之因此前兩年在Spark社區裏聲音很少，也是由於他們在作內部系統的整合和消化。如今百度本身的BMR服務已經出來了，說明內部的整合和消化已經基本完畢了。

問：你如今的工做重點仍是在Spark SQL上？你說過但願外部數據源API設計能有更多進展，如今怎麼樣了？

個人工做重點目前的確還在Spark SQL上。在Spark1.2中，外部數據源API最重要的一部分已經發布出來了。目前開發者已經能夠基於這個API去開發各類各樣的connector，而後把外部的數據源對接到Spark上。可是當前的API中咱們只提供了查詢入口，尚未辦法把咱們處理完畢的數據寫回到外部系統當中去。在1.3和1.4中會提供相應的支持。

另外在外部數據源的集成上，咱們目前的重點主要集中在高度可擴展的API上，同時也會實現一些最爲經常使用的數據源，例如JSON、Parquet、JDBC。此外社區中也已經出現了一些第三方數據源的實現。

問：Shark如今已經沒有在開發了，把Shark用戶遷移到Spark SQL上，這個過程有沒有困難？

我曾和國內的一些用戶聊過這個問題，包括一些曾經在Shark上用了蠻久的用戶。他們試用過Spark SQL以後廣泛反饋：「不再想回到Shark了。」

這裏邊有好幾個緣由。

第1、Shark是直接從Hive改造過來的，因此很大程度上受到了Hive的鉗制。Shark中從查詢語句解析成抽象語法樹，到抽象語法樹翻譯成邏輯執行計劃，再到邏輯執行計劃優化，都是利用Hive完成的，而Hive的查詢優化器是針對MapReduce設計的，這使咱們受到很大的限制。而在Spark SQL中，咱們拿到抽象語法樹以後，除了經過Hive的Metastore獲取表的元信息之外，後續的執行路徑跟Hive就沒有什麼關係了，查詢計劃的生成和優化所有都由咱們本身接管，這樣就能夠更加充分地發揮Spark的優點，進一步提高執行效率。

第2、Spark SQL不只僅提供了關係查詢，並且還能夠藉助SchemaRDD（1.3之後升級爲DataFrame）這一統一抽象實現與其餘Spark組件的無縫集成，並能夠融合多種數據源完成更爲豐富的計算。

第3、拋開上述的各類相對於Shark的優點，Spark SQL自己就是一個十分使人興奮的項目。Spark SQL的核心，其實是一個用一種函數式語言（Scala）實現的另外一種函數式語言（SQL）的編譯器。Spark SQL中原創的Catalyst框架大量應用了Scala的函數式特性，令開發者得以以極爲簡潔明瞭的聲明式代碼實現各類查詢優化策略，從而大大下降了查詢優化器這一數據庫中的硬骨頭的開發難度和維護成本。

全部這些因素加在一塊兒，使得Spark SQL成爲一個顯著優於Shark的方案，所以你們仍是相對愉快地和Shark告別了。

如今整個Spark SQL社區裏面有很是多中國的用戶，也有很是多中國開發者。我曾經作過一個統計，發現Spark SQL的貢獻者中有一半左右是華人。

問：你以爲有這麼多中國開發者的緣由是什麼？

據我瞭解到的狀況，國內的不少企業，尤爲是電信行業的企業，過往大量依賴Oracle和DB2，業務緊密依賴SQL。而在近幾年的去IOE潮流中，又恰恰缺少高效的可以處理大數據的SQL執行引擎。這個時候，Shark和Spark SQL的出現給你們帶來了較好的選擇。以此爲契機，大量的開發者被吸引到了Spark SQL社區。此外，Shark的做者辛湜博士本人就是中國人，這點不知道是否是也有關係 :-)

---

更多精彩，加入圖靈訪談微信！