专访Databricks辛湜，谈Spark排序比赛摘冠及生态圈热点-2014
據Sort Benchmark最新消息，Databricks的Spark與加州大學圣地亞哥分校的TritonSort兩個系統在2014 Daytona GraySort排序比賽上并列第一。其中，TritonSort是一個多年的學術項目，使用186個EC2 i2.8xlarge節點在1378秒內完成了100TB數據的排序；而Spark則是一個生產環境通用的大規模迭代式計算工具，它使用了207個EC2 i2.8xlarge節點在1406秒內排序了100TB的數據，在“前文”中我們曾詳細介紹過。
為了更好的了解這次比賽始末，以及當下Spark社區中存在的一些熱門問題，筆者特采訪了Databricks的辛湜（Reynold Xin，@hashjoin）。（PS：感謝@徽滬一郎的技術支持）
以下為采訪原文
CSDN：本次比賽的規則？考量的是哪些方面？
辛湜：這個比賽最早是由Jim Gray（對數據庫領域做出了不可磨滅貢獻的圖靈獎得主）在八十年代提出的，測量計算機軟件和硬件性能優化上的提升。這個比賽有多個不同的類別，其中最有挑戰性的類別就是測量參賽系統在多快的時間內能排序一定量的數據。
最早始的時候Jim Gray制定的比賽規則要求參賽者排序100MB的數據，到了2001年數據量上升到了1TB。2007年Jim Gray出海航行失蹤之后比賽由一個委員會負責舉辦。2009年為了紀念Jim Gray，將最有挑戰的類別改名為了Daytona GraySort，并把數據量提升到了100TB。除此之外，這個類別還有很多苛刻的規則，比如說所有的排序輸出必須在不同的節點上復制，使得儲存數據能夠容忍節點宕機，排序系統必須能夠支持任意長度，且排序分布極端不均的數據。
大賽委員會非常認真，會對參賽系統和技術報告進行長達一個月的審核。詳細規則可以參見大賽官方網頁：?http://sortbenchmark.org/FAQ-2014.html
這個比賽參賽系統一般都出自規模很大的公司（Microsoft、Yahoo和當年的Tandem、DEC）或者學術機構（UC Berkeley， UCSD加州大學圣地亞哥分校）。有不少的參賽者為了提高性能會專門為這個比賽特制一些硬件系統和軟件系統。
CSDN：Spark以什么樣的成績獲得了比賽的第一名？與其他參賽者對比如何？
辛湜：我們基于Spark搭建的系統用了207臺Amazon EC2上的虛擬機，在23分鐘內排序了100TB的數據。去年的冠軍Hadoop用了2100臺Yahoo內置的機器，花了72分鐘。相比之下，我們用了不到十分之一的機器，排序速度是Hadoop記錄的三倍。值得注意的是這是比賽歷史上第一次基于公有云的系統獲得了第一。
大賽委員會曾告知參賽系統每年都非常多，但是因為這個大賽最終只會通告冠軍，所以我們并不知道究竟有多少其他的參賽者。
今年有兩個系統并列第一：Databricks的Spark和UCSD的Themis都花了23分鐘左右的時間。Themis是一個多年的學術項目，專門研究如何高效的shuffle數據和排序，為此他們犧牲了很多通用系統需要的功能，比如說容錯性等等。Spark作為一個通用系統，能夠在一個排序比賽里面和UCSD的Themis并列第一是一件非常不容易的事情。一個有趣的事情：帶領Themis團隊的George Porter教授也是Berkeley畢業的博士，所以最后是兩個Berkeley校友并列第一，呵呵。
CSDN：什么樣的特性讓Spark獲得如此優異的成績，是否可以從技術角度詳細分析一下？
辛湜：這個成績主要歸于三點：我們前期對Spark工程上的投入，Spark的靈活性，以及我們團隊自身對大規模系統優化的經驗。
Databricks成立之后我們加大了對Spark工程系統上的投入，有不少的資源都用來提高shuffle的性能。談到排序，其實最重要的一步就是shuffle，在提升shuffle方面最近有三個工作對這個比賽影響很大：
第一個是sort-based shuffle。這個功能大大的減少了超大規模作業在shuffle方面的內存占用量，使得我們可以用更多的內存去排序。第二個是新的基于Netty的網絡模塊取代了原有的NIO網絡模塊。這個新的模塊提高了網絡傳輸的性能，并且脫離JVM的GC自己管理內存，降低了GC頻率。第三個是一個獨立于Spark executor的external shuffle service。這樣子executor在GC的時候其他節點還可以通過這個service來抓取shuffle數據，所以網絡傳輸本身不受到GC的影響。
過去一些的參賽系統軟件方面的處理都沒有能力達到硬件的瓶頸，甚至對硬件的利用率還不到10%。而這次我們的參賽系統在map期間用滿了3GB/s的硬盤帶寬，達到了這些虛擬機上八塊SSD的瓶頸，在reduce期間網絡利用率到了1.1GB/s，接近物理極限。
準備這次比賽我們從頭到尾用了不到三個禮拜的時間。這個和Spark本身架構設計的靈活使得我們可以很快的實現一些新的算法以及優化密切相關。
CSDN：關于SQL的支持。SQL on Spark是個老生長談的問題，前一階段終止Shark，并開啟Spark SQL項目，可否具體談談原因？另外，Spark SQL的規劃是什么？當下對SQL的支持如何？大家期待的SQL92或者以上的標準什么時候能得到滿足？
辛湜：Shark對Hive的依賴性太強，而Hive自身設計比較糟糕，有大量傳統遺留的代碼，使得Shark在新功能上的更新非常緩慢。去年年中的時候Michael Armbrust（Spark SQL主要設計者）在Google內部設計F1的新一代的query optimizer。當時他有一個新的設計想法（Catalyst），我們和他交流之后感覺這個新的架構借鑒了過去三十年學術和工業界研究的成果，再加上了他自己新穎的詮釋，和傳統的架構相比更靈活，有很大架構上的優勢。花了幾個月時間我們終于說服了Michael加入Databricks，開始Spark SQL的開發。
Spark SQL現在可能是最大的Big Data SQL開源項目，雖然從開源到現在不到半年時間，已經有接近一百位代碼貢獻者。和Spark的靈活性一樣，Spark SQL的架構讓開源社區可以很快的迭代，貢獻新的功能，很多類似SQL92的功能都有不少開源社區的貢獻者感興趣，應該都會很快得到實現。
CSDN：關于計算方面。運行Spark時，應用的中間結果會通過磁盤傳遞，勢必會影響到性能，而業內李浩源的Tachyon可以剝離spark，并且對HDFS文件系統有很好的支持，在不更改用戶使用情況下大幅度提高性能，當下也受到Intel、EMC等公司的支持，在Spark生態圈發展良好。那么Databricks對這方面的打算是什么？提供更原生的支持，或者是提升自己的？
辛湜：Spark的中間結果絕大多數時候都是從上游的operator直接傳遞給下游的operator，并不需要通過磁盤。Shuffle的中間結果會保存在磁盤上，但是隨著我們對shuffle的優化，其實磁盤本身并不是瓶頸。這次參賽也驗證了shuffle真正的瓶頸在于網絡，而不是磁盤。
Tachyon印證了儲存系統應該更好利用內存的大趨勢。我預測未來越來越多的存儲系統會有這方面的考慮和設計，Spark項目的原則就是能夠更好的利用下層的儲存系統，所以我們也會對這方面做出支持。
值得注意的是，把shuffle數據放入Tachyon或者HDFS cache（HDFS的新功能）其實不是一個好的優化模式。原因是shuffle每個數據塊本身非常的小，而元數據量非常的多。直接把shuffle數據寫入Tachyon或者HDFS這種分布式儲存系統多半會直接擊垮這些系統的元數據存儲，反而導致性能下降。
CSDN：算法方面考慮。大數據的核心在數據建模和數據挖掘，那么對于算法玩家來說，對R等語言的支持無疑很有必要。而據我所知，當下Spark 1.1發行版還未包括SparkR，那么這方面的roadmap會是什么？
辛湜：SparkR是Spark生態系統走入傳統data scientist圈很重要的一步。Databricks和Alteryx幾個月前宣布合作開發SparkR。這個項目不在Spark自身主要是因為項目許可證(license)的問題。R的許可證和Apache 2.0沖突，所以SparkR短期內應該會以一個獨立項目的形式存在。
CSDN：數據倉庫互通。上面說到了數據的計算，那么數據的計算將存向何處？你們在工作中看到用戶使用的常用數據倉庫是什么？Cassandra還是其他？Spark更看好哪些數據倉庫？更看好哪些NoSQL？是否已經有打通數據倉庫的計劃，提供一個更原生的支持，這里的趨勢是什么？
辛湜：和對儲存系統的態度一樣，Spark本身不應該限制用戶對數據庫的使用。Spark的設計使得他可以很容易的支持不同的儲存格式以及存儲系統。我們希望對最熱門的幾個數據庫，比如說Cassandra能夠有原生的支持。
在Spark 1.2里面我們會開放一個新的儲存接口（API），這個接口使得外界儲存系統和數據庫可以非常容易的連接到Spark SQL的SchemaRDD，并且在查詢時候optimizer甚至可以直接把一些過濾的filter直接發送到實現這個接口的數據庫里面，最大限度的利用這些數據庫自身的過濾功能減少網絡傳輸。
目前我們內部一些存儲格式和系統的實現（比如說JSON、Avro）都已經轉移到了這個新的接口。1.2雖然還沒有發布，但是已經有很多社區成員開始了對不同數據庫的實現。我預計未來絕大多數的數據庫都會通過這個接口和Spark SQL集成起來，使得Spark SQL可以成為一個統一的查詢層，甚至在一個查詢語句里面利用多個不同數據庫的數據。
總結
以上是生活随笔為你收集整理的专访Databricks辛湜，谈Spark排序比赛摘冠及生态圈热点-2014的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Spark核心开发者：性能超Hadoop
- 下一篇： 钱钱钱钱钱