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