連城：大資料場景下的“搔到癢處”和“戳到痛處”（圖靈訪談）

連城，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等一些動態語言中也同樣存在，但是我只知其然，而不知其所以然。我覺得好奇的是，第一、函式式語言跟普通的命令式語言的本質相比有什麼優勢；第二、這些特性背後的執行時機制到底是什麼。那個時候我在百度已經開始做管理，基本脫離了一線開發，說實話少了挺多樂趣。我就決定用業餘時間把函數語言程式設計搞清楚。

我自己的習慣是每年都會做一個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的介紹，其中提到大資料時代的計算平臺必須要開源，你能稍微解釋一下嗎？

我自己的理解是這樣的，大資料分析複雜性相對來說是很高的，從使用者的角度來看，複雜性突出體現在兩個方面：

第一、很多情況下，採用大資料系統的組織內部原本就存在一些重要的遺留系統，難免面臨對內外系統進行擴充套件和/或改造，這時也會產生很多複雜的技術性和非技術性問題。採用開源系統時，我們可以有效地對系統進行定製。

第二、大資料系統一般來說程式碼量比較大，動輒十數萬、數十萬行程式碼，難免會存在各式各樣的缺陷；分析、除錯、修復這些系統中的缺陷同樣是一個複雜的工作。大資料場景下，很多問題必須在足夠的體量下才能夠重現，難以構造最小的問題重現場景，這使得現場除錯定位顯得尤為重要。而開源軟體大大降低了現場除錯定位的難度。

問：有人說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了。”

這裡邊有好幾個原因。

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

第二、Spark SQL不僅僅提供了關係查詢，而且還可以藉助SchemaRDD（1.3以後升級為DataFrame）這一統一抽象實現與其他Spark元件的無縫整合，並可以融合多種資料來源完成更為豐富的計算。

第三、拋開上述的各種相對於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的作者辛湜博士本人就是中國人，這點不知道是不是也有關係 :-)

---

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