专访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ù)，在“前文”中我們曾詳細(xì)介紹過。
為了更好的了解這次比賽始末，以及當(dāng)下Spark社區(qū)中存在的一些熱門問題，筆者特采訪了Databricks的辛湜（Reynold Xin，@hashjoin）。（PS：感謝@徽滬一郎的技術(shù)支持）
以下為采訪原文
CSDN：本次比賽的規(guī)則？考量的是哪些方面？
辛湜：這個(gè)比賽最早是由Jim Gray（對數(shù)據(jù)庫領(lǐng)域做出了不可磨滅貢獻(xiàn)的圖靈獎(jiǎng)得主）在八十年代提出的，測量計(jì)算機(jī)軟件和硬件性能優(yōu)化上的提升。這個(gè)比賽有多個(gè)不同的類別，其中最有挑戰(zhàn)性的類別就是測量參賽系統(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ī)則，比如說所有的排序輸出必須在不同的節(jié)點(diǎn)上復(fù)制，使得儲存數(shù)據(jù)能夠容忍節(jié)點(diǎn)宕機(jī)，排序系統(tǒng)必須能夠支持任意長度，且排序分布極端不均的數(shù)據(jù)。
大賽委員會(huì)非常認(rèn)真，會(huì)對參賽系統(tǒng)和技術(shù)報(bào)告進(jìn)行長達(dá)一個(gè)月的審核。詳細(xì)規(guī)則可以參見大賽官方網(wǎng)頁：?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以什么樣的成績獲得了比賽的第一名？與其他參賽者對比如何？
辛湜：我們基于Spark搭建的系統(tǒng)用了207臺Amazon EC2上的虛擬機(jī)，在23分鐘內(nèi)排序了100TB的數(shù)據(jù)。去年的冠軍Hadoop用了2100臺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)需要的功能，比如說容錯(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)異的成績，是否可以從技術(shù)角度詳細(xì)分析一下？
辛湜：這個(gè)成績主要?dú)w于三點(diǎn)：我們前期對Spark工程上的投入，Spark的靈活性，以及我們團(tuán)隊(duì)自身對大規(guī)模系統(tǒng)優(yōu)化的經(jīng)驗(yàn)。
Databricks成立之后我們加大了對Spark工程系統(tǒng)上的投入，有不少的資源都用來提高shuffle的性能。談到排序，其實(shí)最重要的一步就是shuffle，在提升shuffle方面最近有三個(gè)工作對這個(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)還可以通過這個(gè)service來抓取shuffle數(shù)據(jù)，所以網(wǎng)絡(luò)傳輸本身不受到GC的影響。
過去一些的參賽系統(tǒng)軟件方面的處理都沒有能力達(dá)到硬件的瓶頸，甚至對硬件的利用率還不到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è)老生長談的問題，前一階段終止Shark，并開啟Spark SQL項(xiàng)目，可否具體談?wù)勗?#xff1f;另外，Spark SQL的規(guī)劃是什么？當(dāng)下對SQL的支持如何？大家期待的SQL92或者以上的標(biāo)準(zhǔn)什么時(shí)候能得到滿足？
辛湜：Shark對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），我們和他交流之后感覺這個(gè)新的架構(gòu)借鑒了過去三十年學(xué)術(shù)和工業(yè)界研究的成果，再加上了他自己新穎的詮釋，和傳統(tǒng)的架構(gòu)相比更靈活，有很大架構(gòu)上的優(yōu)勢。花了幾個(gè)月時(shí)間我們終于說服了Michael加入Databricks，開始Spark SQL的開發(fā)。
Spark SQL現(xiàn)在可能是最大的Big Data SQL開源項(xiàng)目，雖然從開源到現(xiàn)在不到半年時(shí)間，已經(jīng)有接近一百位代碼貢獻(xiàn)者。和Spark的靈活性一樣，Spark SQL的架構(gòu)讓開源社區(qū)可以很快的迭代，貢獻(xiàn)新的功能，很多類似SQL92的功能都有不少開源社區(qū)的貢獻(xiàn)者感興趣，應(yīng)該都會(huì)很快得到實(shí)現(xiàn)。
CSDN：關(guān)于計(jì)算方面。運(yùn)行Spark時(shí)，應(yīng)用的中間結(jié)果會(huì)通過磁盤傳遞，勢必會(huì)影響到性能，而業(yè)內(nèi)李浩源的Tachyon可以剝離spark，并且對HDFS文件系統(tǒng)有很好的支持，在不更改用戶使用情況下大幅度提高性能，當(dāng)下也受到Intel、EMC等公司的支持，在Spark生態(tài)圈發(fā)展良好。那么Databricks對這方面的打算是什么？提供更原生的支持，或者是提升自己的？
辛湜：Spark的中間結(jié)果絕大多數(shù)時(shí)候都是從上游的operator直接傳遞給下游的operator，并不需要通過磁盤。Shuffle的中間結(jié)果會(huì)保存在磁盤上，但是隨著我們對shuffle的優(yōu)化，其實(shí)磁盤本身并不是瓶頸。這次參賽也驗(yàn)證了shuffle真正的瓶頸在于網(wǎng)絡(luò)，而不是磁盤。
Tachyon印證了儲存系統(tǒng)應(yīng)該更好利用內(nèi)存的大趨勢。我預(yù)測未來越來越多的存儲系統(tǒng)會(huì)有這方面的考慮和設(shè)計(jì)，Spark項(xiàng)目的原則就是能夠更好的利用下層的儲存系統(tǒng)，所以我們也會(huì)對這方面做出支持。
值得注意的是，把shuffle數(shù)據(jù)放入Tachyon或者HDFS cache（HDFS的新功能）其實(shí)不是一個(gè)好的優(yōu)化模式。原因是shuffle每個(gè)數(shù)據(jù)塊本身非常的小，而元數(shù)據(jù)量非常的多。直接把shuffle數(shù)據(jù)寫入Tachyon或者HDFS這種分布式儲存系統(tǒng)多半會(huì)直接擊垮這些系統(tǒng)的元數(shù)據(jù)存儲，反而導(dǎo)致性能下降。
CSDN：算法方面考慮。大數(shù)據(jù)的核心在數(shù)據(jù)建模和數(shù)據(jù)挖掘，那么對于算法玩家來說，對R等語言的支持無疑很有必要。而據(jù)我所知，當(dāng)下Spark 1.1發(fā)行版還未包括SparkR，那么這方面的roadmap會(huì)是什么？
辛湜：SparkR是Spark生態(tài)系統(tǒng)走入傳統(tǒng)data scientist圈很重要的一步。Databricks和Alteryx幾個(gè)月前宣布合作開發(fā)SparkR。這個(gè)項(xiàng)目不在Spark自身主要是因?yàn)轫?xiàng)目許可證(license)的問題。R的許可證和Apache 2.0沖突，所以SparkR短期內(nèi)應(yīng)該會(huì)以一個(gè)獨(dú)立項(xiàng)目的形式存在。
CSDN：數(shù)據(jù)倉庫互通。上面說到了數(shù)據(jù)的計(jì)算，那么數(shù)據(jù)的計(jì)算將存向何處？你們在工作中看到用戶使用的常用數(shù)據(jù)倉庫是什么？Cassandra還是其他？Spark更看好哪些數(shù)據(jù)倉庫？更看好哪些NoSQL？是否已經(jīng)有打通數(shù)據(jù)倉庫的計(jì)劃，提供一個(gè)更原生的支持，這里的趨勢是什么？
辛湜：和對儲存系統(tǒng)的態(tài)度一樣，Spark本身不應(yīng)該限制用戶對數(shù)據(jù)庫的使用。Spark的設(shè)計(jì)使得他可以很容易的支持不同的儲存格式以及存儲系統(tǒng)。我們希望對最熱門的幾個(gè)數(shù)據(jù)庫，比如說Cassandra能夠有原生的支持。
在Spark 1.2里面我們會(huì)開放一個(gè)新的儲存接口（API），這個(gè)接口使得外界儲存系統(tǒng)和數(shù)據(jù)庫可以非常容易的連接到Spark SQL的SchemaRDD，并且在查詢時(shí)候optimizer甚至可以直接把一些過濾的filter直接發(fā)送到實(shí)現(xiàn)這個(gè)接口的數(shù)據(jù)庫里面，最大限度的利用這些數(shù)據(jù)庫自身的過濾功能減少網(wǎng)絡(luò)傳輸。
目前我們內(nèi)部一些存儲格式和系統(tǒng)的實(shí)現(xiàn)（比如說JSON、Avro）都已經(jīng)轉(zhuǎn)移到了這個(gè)新的接口。1.2雖然還沒有發(fā)布，但是已經(jīng)有很多社區(qū)成員開始了對不同數(shù)據(jù)庫的實(shí)現(xiàn)。我預(yù)計(jì)未來絕大多數(shù)的數(shù)據(jù)庫都會(huì)通過這個(gè)接口和Spark SQL集成起來，使得Spark SQL可以成為一個(gè)統(tǒng)一的查詢層，甚至在一個(gè)查詢語句里面利用多個(gè)不同數(shù)據(jù)庫的數(shù)據(jù)。
總結(jié)
以上是生活随笔為你收集整理的专访Databricks辛湜，谈Spark排序比赛摘冠及生态圈热点-2014的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Spark核心开发者：性能超Hadoop
- 下一篇： 钱钱钱钱钱