大型集群上的快速和通用數(shù)據(jù)處理架構(gòu)

1、 大型集群上的快速和通用數(shù)據(jù)處理架構(gòu)An Architecture for Fast and General Data Processing on Large ClustersMatei Zaharia著CSDN CODE翻譯社區(qū)譯加州大學(xué)伯克利分校電氣工程和計(jì)算機(jī)科學(xué)系技術(shù)報(bào)告編號(hào)：UCB/EECS-2014-12/Pubs/TechRpts/2014/EECS-2014-12.htmlCSDN CODE翻譯社區(qū)項(xiàng)目地址：/translations/15 版權(quán)聲明本文由加州大學(xué)伯克利分校計(jì)算機(jī)科學(xué)研究生部 Matei Alexandru Zaharia博士著。委員會(huì)負(fù)責(zé)：Scott Shen

2、ker教授，Ion Stoica首席教授，Alexandre Bayen教授，JoshuaBloom教授。本論文原文版權(quán)歸 Matei Alexandru Zaharia博士所有，譯文版權(quán)歸所有譯者共同所有。允許個(gè)人或課堂使用全部或部分作品的電子版或硬拷貝，不收取費(fèi)用。副本不允許制作或以商業(yè)盈利為目進(jìn)行制作出售。以其他方式進(jìn)行復(fù)制、轉(zhuǎn)載、發(fā)布，或再版均需預(yù)先取得授權(quán)許可。 譯者名錄本論文翻譯由 CSDN CODE翻譯平臺(tái)（/translations）組織，網(wǎng)友自愿報(bào)名參與。共有 35名譯者，7名審校先后報(bào)名參與本論文的翻譯工作。最終有 29名譯者、6名審校完整跟進(jìn)并完成翻譯工作。在此，我們對(duì)這

3、些譯者、審校以及項(xiàng)目經(jīng)理吳小然表示誠(chéng)摯的謝意。感謝 CSDN CODE翻譯平臺(tái)及北京語智云帆科技有限公司提供翻譯平臺(tái)和技術(shù)支持。以下列出了完整跟進(jìn)此項(xiàng)目至完成的譯者、審校和項(xiàng)目經(jīng)理名單。項(xiàng)目經(jīng)理：CSDN ID: xiaoran27昵稱/姓名：吳小然個(gè)人簡(jiǎn)介：美一天進(jìn)步一點(diǎn)點(diǎn)，盡人事，聽天命。主審校：CSDN ID: aiuyjerry昵稱/姓名：邵賽賽個(gè)人簡(jiǎn)介：邵賽賽，開發(fā)工程師，專注于大數(shù)據(jù)領(lǐng)域，開源愛好者，現(xiàn)從事Spark相關(guān)工作，Spark代碼貢獻(xiàn)者。CSDN ID: liyezhang556520昵稱/姓名：張李曄個(gè)人簡(jiǎn)介：英特爾大數(shù)據(jù)研發(fā)工程師，apache spark contr

4、ibutor 審校：CSDN ID: u011278817昵稱/姓名：余根茂個(gè)人簡(jiǎn)介：心若沒有棲息的地方，到哪里都是在流浪。CSDN ID: u012969795昵稱/姓名：Ali個(gè)人簡(jiǎn)介：很高興能和大家一起走過來，謝謝。要有到深圳來玩的，吱個(gè)聲，聚聚CSDN ID: lance_123昵稱/姓名：王聯(lián)輝個(gè)人簡(jiǎn)介：Hadoop/Hive/Spark Contributor，2009年開始從事Hadoop相關(guān)的工作，經(jīng)歷了Hadoop千臺(tái)規(guī)模的擴(kuò)張及解決方案。對(duì)Hadoop,Hive,HBase,Yarn,Storm,Spark等項(xiàng)目有豐富的實(shí)踐經(jīng)驗(yàn)且熟悉其核心代碼，熱衷于大數(shù)據(jù)開源項(xiàng)目與技術(shù)。

5、CSDN ID: derek12344321昵稱/姓名：馬繼個(gè)人簡(jiǎn)介：大家好，我叫馬繼，目前在亞信從事spark相關(guān)研究工作，希望能在這個(gè)平臺(tái)認(rèn)識(shí)更多的spark愛好者，一起為社區(qū)貢獻(xiàn)力量。 初譯（按工作量排名）：CSDN ID：Aylee_Liu昵稱/姓名：Ayleeliu個(gè)人簡(jiǎn)介：我不認(rèn)同“不以物喜，不以己悲”，但并不代表我要大喜大悲，遇到開心的事要笑，對(duì)自己的缺點(diǎn)不避諱；我喜歡向日葵，不是因?yàn)樗甙?，而是她可以一直面?duì)陽光，作為一個(gè)小人物，我只信奉：做好眼前的事，未來一定有驚喜。CSDN ID： qfdai2昵稱/姓名：代其鋒個(gè)人簡(jiǎn)介：沉迷Spark已有半載，被Spark的設(shè)計(jì)原理和強(qiáng)大

6、功能所深深吸引，這次能有幸參與Spark主要作者M(jìn)atei Zaharia博士的畢業(yè)論文讓我不僅對(duì)作者開發(fā)Spark的思路脈絡(luò)有了清晰認(rèn)識(shí)，更讓自己能站在一個(gè)更高視角了解大數(shù)據(jù)的發(fā)展和趨勢(shì)。CSDN ID：shiyuzh2007昵稱/姓名：AlexZhou個(gè)人簡(jiǎn)介：平和追求希望珍惜CSDN ID：caidaoqq昵稱/姓名：潘義文個(gè)人簡(jiǎn)介：妹子，能交個(gè)朋友嗎？哈哈 CSDN ID：u011582658昵稱/姓名：雷力明個(gè)人簡(jiǎn)介：國(guó)內(nèi)某小二本（XJTU）一個(gè)，正在上研一。平時(shí)喜歡讀書，有時(shí)寫點(diǎn)代碼，有時(shí)看看論文，有時(shí)出去戶外運(yùn)動(dòng)，有時(shí)看看電影，還喜歡打游戲，Braid死忠粉。CSDN ID：su

7、n7545526昵稱/姓名：孫愛華個(gè)人簡(jiǎn)介：之前幾年一直接觸j2ee，最近從事云計(jì)算的研究，范圍包括openstack,ceph,hadoop等技術(shù)，初出茅廬的spark其魅力讓我無法抗拒，相信它一定會(huì)有更好的前景。CSDN ID：litao471625wo昵稱/姓名：栗濤個(gè)人簡(jiǎn)介：非常幸運(yùn)可以參與到Spark論文的翻譯工作，也收獲了很多理解和研究論文的經(jīng)驗(yàn)。不能像閱讀論文的時(shí)候，遇到不太理解的詞語、概念，可以跳過去，翻譯的過程更像一個(gè)研究的過程，要理解上下文，來表達(dá)某些語句的技術(shù)重點(diǎn)。希望以后還可以更多的參與到類似的翻譯工作，一起和大家交流學(xué)習(xí)。CSDN ID：zhangkan1983昵稱/

8、姓名：張侃個(gè)人簡(jiǎn)介：希望能多為開源社區(qū)做一些貢獻(xiàn)，正從事大數(shù)據(jù)/車聯(lián)網(wǎng)相關(guān)工作，歡迎交流。CSDN ID：laizx昵稱/姓名：賴正興個(gè)人簡(jiǎn)介：一名熱愛軟件開發(fā)技術(shù)的老程序員！ CSDN ID：luogankungmail昵稱/姓名：PK時(shí)發(fā)型不亂個(gè)人簡(jiǎn)介：PK時(shí)發(fā)型不亂CSDN ID：lvhaozhi昵稱/姓名：呂浩志個(gè)人簡(jiǎn)介：感謝CSDN給了我開闊眼界的機(jī)會(huì)。CSDN ID：jacty0219昵稱/姓名：陳駿個(gè)人簡(jiǎn)介：一個(gè)略微憂郁的英語愛好者兼碼農(nóng)，正在慢慢得朝著筆譯之路前行。CSDN ID：wuyang630昵稱/姓名：武揚(yáng)個(gè)人簡(jiǎn)介：從大公司起步，到小公司創(chuàng)業(yè)，無論是談技術(shù)還是談事業(yè)希望

9、能與更多志同道合的同學(xué)交流CSDN ID：yuangeqingtian昵稱/姓名：yuangeqingtian個(gè)人簡(jiǎn)介：下次有這種項(xiàng)目，記得叫上我 CSDN ID：lazyman500昵稱/姓名：Dongxu個(gè)人簡(jiǎn)介：這個(gè)人很懶，什么都沒有留下。CSDN ID：liuchao_9昵稱/姓名：劉超個(gè)人簡(jiǎn)介：感謝CSDN發(fā)起這次協(xié)作翻譯，以及參與協(xié)調(diào)的工作人員。很多優(yōu)秀的技術(shù)文檔都是英文的，平時(shí)也是直接看英文的，也覺得自己可以讀懂，沒有什么問題，但當(dāng)要翻譯成中文，貢獻(xiàn)給讀者時(shí)才發(fā)現(xiàn)很難。一句話可能要仔細(xì)琢磨好多次，在不改變?cè)髡咭馑糃SDN ID：ljkang1990昵稱/姓名：劉見康個(gè)人簡(jiǎn)介：大

10、家好，我叫劉見康，人稱康帥博，健康的康，帥氣的帥，博學(xué)的博。我的理想是成為一名德智體美勞全面發(fā)展的暴棧工程師，因?yàn)椴粫?huì)彈吉他的攝影師不是好程序員。平時(shí)喜歡看書、聽音樂、攝影，彈彈吉他唱唱歌，籃球羽毛球打的不錯(cuò)，代碼寫的也還可以，不約，謝謝！CSDN ID：qwewegfd昵稱/姓名：楊志斌個(gè)人簡(jiǎn)介：愛老婆，愛兒子，我愛我家。CSDN ID：usen521昵稱/姓名：張冰個(gè)人簡(jiǎn)介：在業(yè)余時(shí)間能有機(jī)會(huì)結(jié)合自己的興趣愛好做點(diǎn)積極的事情，是一件很有樂趣的事。參與翻譯活動(dòng)純屬偶然，但很高興得到這么一個(gè)機(jī)會(huì)，認(rèn)真的翻譯認(rèn)真的玩，不求多么完美，自己滿意就好。 CSDN ID：xhz1234昵稱/姓名：徐洪志

11、個(gè)人簡(jiǎn)介：沒傘的孩子，拼命跑CSDN ID：pastgift昵稱/姓名：周逸靈（本本亂）個(gè)人簡(jiǎn)介：周逸靈，男，漢，1987年生，2010年日語畢業(yè)；籍貫江蘇，現(xiàn)居上海；后端開發(fā)，熟悉C、Python、Docker；熱愛技術(shù)、涉獵廣泛。CSDN ID：Martin19870726昵稱/姓名：周項(xiàng)勇(Martin Zhou)個(gè)人簡(jiǎn)介：致力于實(shí)時(shí)/離線大數(shù)據(jù)分析！實(shí)時(shí)大數(shù)據(jù)分析系統(tǒng)Druid拓荒者。熱心開源事業(yè)，Zookeeper管理系統(tǒng)ZookeeperEdit、Zookeeper集群一鍵安裝腳本Zookeeper-Cluster Installer開發(fā)者?，F(xiàn)從事在線廣告業(yè)務(wù)數(shù)據(jù)分析，和DSP(D

12、emand-Side Platform)系統(tǒng)研發(fā)工作。CSDN ID：u011941712昵稱/姓名：籽皓個(gè)人簡(jiǎn)介：謝謝CSDN的這次活動(dòng)，讓我了解了自己曾經(jīng)不知道的技術(shù)，希望下次還可以參加類似的活動(dòng)。CSDN ID：fancylee0808昵稱/姓名：李奕飛個(gè)人簡(jiǎn)介： CSDN ID：LinuxCoder昵稱/姓名：LinuxCoder個(gè)人簡(jiǎn)介：美國(guó)拿到計(jì)算機(jī)碩士學(xué)位，在國(guó)外從事7年的技術(shù)工作。CSDN ID：S1012W2昵稱/姓名：葉秋個(gè)人簡(jiǎn)介：丘吉爾曾說過，We make a living by what we get,but we make a life by what we giv

13、e.我雖擁有的不多，但也希望能發(fā)揮自己所長(zhǎng)做些有意義的事情。不給自己設(shè)限，世界就沒有邊界。CSDN ID：wanghu稱/姓名：王華個(gè)人簡(jiǎn)介：CSDN ID：ytfuestc昵稱/姓名：袁騰飛個(gè)人簡(jiǎn)介：愛生活，愛程序，愛籃球，正在奮力研究sparkCSDN ID：zhang177昵稱/姓名：張剛個(gè)人簡(jiǎn)介：大家好，我叫張剛，2011年碩士畢業(yè)，現(xiàn)任職于某研究院從事項(xiàng)目管理及軟件設(shè)計(jì)工作，愛好笛子，游泳，心理咨詢等，業(yè)余時(shí)間熱衷于公益活動(dòng)。我相信一個(gè)人的視野決定他的深度，一個(gè)人的思維決定他的高度，所以不斷學(xué)習(xí)，不斷挑戰(zhàn)，將是我不變的追求。 以下譯者對(duì)本文亦有貢獻(xiàn)：CSDN

14、 ID: u012830490昵稱/姓名：私家宅院個(gè)人簡(jiǎn)介：為了讓生活更精彩！CSDN ID: u014388509昵稱/姓名：OopsOutOfMemoryCSDN ID:harryxujiao昵稱/姓名：馬小喬CSDN ID: pandonghua_de昵稱/姓名：pandonghua_deCSDN ID:lu8000昵稱/姓名：木風(fēng)卜雨CSDN ID:kevenking昵稱/姓名：kevenkingCSDN ID: mqshen昵稱/姓名：mqshen 摘要基于大型集群的快速通用數(shù)據(jù)處理架構(gòu)由計(jì)算機(jī)科學(xué)博士Matei Alexandru Zaharia加州大學(xué)伯克利分校教授、主席Scot

15、t Shenker撰寫過去的幾年中，計(jì)算系統(tǒng)經(jīng)歷著重大的變革，為了滿足不斷增長(zhǎng)的數(shù)據(jù)量和處理速度需求，越來越多的應(yīng)用向分布式系統(tǒng)擴(kuò)展。如今，從互聯(lián)網(wǎng)到企業(yè)運(yùn)作，再到科技設(shè)備，不盡其數(shù)的數(shù)據(jù)源都在產(chǎn)生大量的、有價(jià)值的數(shù)據(jù)流。然而，單一的機(jī)器處理能力并沒有跟上數(shù)據(jù)增長(zhǎng)的速度，使得這些有價(jià)值的數(shù)據(jù)越來越難以被使用。以至于越來越多的組織不僅僅是互聯(lián)網(wǎng)公司，還有一些傳統(tǒng)企業(yè)和研究室迫切需要將他們重要的計(jì)算能力擴(kuò)展到成百上千臺(tái)機(jī)器上去。在這同時(shí)，數(shù)據(jù)處理所需的速度和復(fù)雜性也在逐漸增加。在許多領(lǐng)域中，除了簡(jiǎn)單的查詢，像機(jī)器學(xué)習(xí)和圖分析這樣的復(fù)雜算法也得到日益廣泛的應(yīng)用。另外，除了批量處理，一些組織還需要在實(shí)

16、時(shí)數(shù)據(jù)源上進(jìn)行流分析，以保證能夠及時(shí)采取行動(dòng)。未來的計(jì)算平臺(tái)不僅需要能滿足常規(guī)作業(yè)的擴(kuò)展，同時(shí)也需要對(duì)新的應(yīng)用有更好的支持。針對(duì)上述的各種問題，本文提出了一種集群計(jì)算架構(gòu)，能夠解決這些新出現(xiàn)的數(shù)據(jù)處理作業(yè)的需求，同時(shí)還可以應(yīng)對(duì)越來越大規(guī)模的擴(kuò)展。雖然早期的集群計(jì)算系統(tǒng)，如MapReduce，已經(jīng)能夠進(jìn)行批量處理，但我們的架構(gòu)更支持流處理和交互查詢，并且擁有和之前系統(tǒng)相同的可擴(kuò)展性和容錯(cuò)性。然而當(dāng)前所部署的大部分的系統(tǒng)僅支持簡(jiǎn)單的單路運(yùn)算(例如,聚合或SQL查詢)，而我們的系統(tǒng)針更為復(fù)雜的分析（例如，機(jī)器學(xué)習(xí)的迭代算法）擴(kuò)展到了對(duì)多路算法的支持。最后，與處理特定工作的專有系統(tǒng)不同的是，我們的架構(gòu)

17、允許這些算法相互結(jié)合，從而實(shí)現(xiàn)更豐富的新應(yīng)用。例如，流處理和批量處理，或SQL和復(fù)雜分析之間的相互結(jié)合。為了實(shí)現(xiàn)上述的各種特性，我們通過簡(jiǎn)單的擴(kuò)展MapReduce，為其增加了數(shù)據(jù)共享原語，也就是所謂的彈性分布式數(shù)據(jù)集（RDDs）。我們發(fā)現(xiàn)，這樣的擴(kuò)展足以能夠有效地覆蓋大部分作業(yè)的需求。在開源的Spark系統(tǒng)中我們實(shí)現(xiàn)了RDDs，同時(shí)使用了模擬測(cè)試程序和真實(shí)的用戶應(yīng)用對(duì)其進(jìn)行評(píng)估。在許多應(yīng)用領(lǐng)域中，Spark已經(jīng)接近或是超過了專有系統(tǒng)的性能，同時(shí)提供更強(qiáng) 大的容錯(cuò)保證，并允許這些作業(yè)之間能夠進(jìn)行結(jié)合。我們從理論建模和實(shí)踐的角度去探索 RDDs的通用性，來解釋為什么這樣的擴(kuò)展可以覆蓋大范圍的不同

18、作業(yè)需求。 致謝感謝我的導(dǎo)師Scott Shenker和Ion Stoica教授，在我博士期間對(duì)我孜孜不倦的指導(dǎo)。他們都是非常卓越的研究者，總是能夠?qū)⑾敕ㄍ巴七M(jìn)一步，為我們提供完成任務(wù)所需的條件，以及分享他們做研究的經(jīng)驗(yàn)。特別榮幸能和他們兩人一起工作，他們的觀點(diǎn)讓我受益。本論文的工作是與其他很多人合作的結(jié)果。第2章是和MosharafChowdhury,TathagataDas,Ankur Dave, Justin Ma, Murphy McCauley, Mike Franklin, Scott Shenker及 Ion Stoica一起合作的 118。第 3章中介紹的 Shark項(xiàng)目部分

19、，是與 Reynold Xin, Josh Rosen, MikeFranklin,ScottShenker及IonStoica一起開發(fā)的113。第4章是與TathagataDas,HaoyuanLi, Timothy Hunter, Scott Shenker及 Ion Stoica一起合作的119.。更廣泛的說，很多在AMPLab以及參與Spark相關(guān)項(xiàng)目如GraphX 112和MLI 98的人，都對(duì)文中的思想形成和完善有所貢獻(xiàn)。除了這個(gè)項(xiàng)目中的直接合作者，很多人對(duì)我博士期間的工作都做出了貢獻(xiàn)，這些都促成Berkeley成為了難忘的經(jīng)歷。在多次的喝茶過程中，AliGhodsi在研究和開源方

20、面都提出了一些特別好的建議和想法。和BenHindman,AndyKonwinski，KurtisHeimerl在一起非常有趣，他們?cè)谝恍┖玫南敕ㄉ隙际欠浅０舻暮献髡摺aylor Sittler讓我和 AMPLab的很多人對(duì)生物學(xué)產(chǎn)生了非常大的興趣，這促成了我和 Bill Bolosky, Ravi Pandya, Kristal Curtis, DavePatterson及其他很多人在AMP-X加入的最有趣的小組之一。在其它項(xiàng)目中，我也有幸與VernPaxson, Dawn Song, Anthony Joseph, Randy Katz和 Armando Fox一起合作，并從他們的見解中

21、學(xué)到知識(shí)。最后，AMPLab和RADLab是一個(gè)奇妙的組織，無論是Berkeley的成員，還是工業(yè)界的一些接觸者，都在不斷地給我們建議。我也非常榮幸參與到早期的開源大數(shù)據(jù)社區(qū)工作。在 Facebook，Dhruba Borthakur以及Joydeep Sen Sarma引導(dǎo)我開始為 Hadoop做出貢獻(xiàn)，同時(shí)，與 Eric Baldeschwieler, OwenOMalley, Arun Murthy, Sanjay Radia和 Eli Collins參與的很多討論，讓我們的研究想法得到實(shí)現(xiàn)。在我們開始開發(fā) Spark項(xiàng)目后，我一直都被那些才華橫溢和熱情的貢獻(xiàn)者所折服。Spark和 Sh

22、ark的貢獻(xiàn)者目前已經(jīng)超過 130人了，非常感謝每個(gè)人，使得這些項(xiàng)目變成現(xiàn)實(shí)。當(dāng)然，這些項(xiàng)目的用戶也做出了巨大的貢獻(xiàn)，他們持續(xù)的提出了很多好的建議，并一直推動(dòng)系統(tǒng)朝新的方向上發(fā)展，這些都影響著核心設(shè)計(jì)。在其中，我特別感謝該項(xiàng)目的早期用戶，他們包括Lester Mackey, Tim Hunter, Dilip Joseph, Jibin Zhan, Erich Nachbar,以及KarthikThiyagarajan。最后，感謝我的家人及朋友在我讀博士期間對(duì)我堅(jiān)定的支持。 目錄第1章簡(jiǎn)介 11.1專業(yè)系統(tǒng)相關(guān)的問題 2彈性分布式數(shù)據(jù)集（RDDS） 3基于RDD機(jī)制實(shí)現(xiàn)的模型 4總結(jié) 6論文計(jì)

23、劃 71.21.31.41.5第二章彈性分布式數(shù)據(jù)集 82.1簡(jiǎn)介 8RDD概述 10概念 102.22.2.12.2.2 Spark編程接口 102.2.3 RDD模型的優(yōu)點(diǎn) 132.2.4不適合RDDs的應(yīng)用 142.3Spark編程接口 152.3.1 Spark中RDD的操作 17應(yīng)用示例 172.3.22.42.5抽象RDDs 20實(shí)現(xiàn) 22作業(yè)調(diào)度 222.5.12.5.22.5.3多用戶管理 24解析器集成 25內(nèi)存管理 26檢查點(diǎn)支持 272.5.42.5.52.6性能評(píng)估 27迭代式機(jī)器學(xué)習(xí)應(yīng)用 282.6.12.6.2 PageRank 30 2.6.32.6.42.6.5

24、2.6.6故障恢復(fù) 30內(nèi)存不足的情況 31交互式數(shù)據(jù)挖掘 32實(shí)際應(yīng)用 33討論 34對(duì)現(xiàn)有編程模型的表達(dá) 34解釋RDD表達(dá)能力 35利用RDD來調(diào)試 36相關(guān)工作 36總結(jié) 382.72.7.12.7.22.7.32.82.9第三章基于RDD的模型 383.13.2簡(jiǎn)介 38一些在RDDs上實(shí)現(xiàn)其他模型的技術(shù) 393.2.1 RDDs里的數(shù)據(jù)格式 393.2.2數(shù)據(jù)分區(qū) 403.2.3關(guān)于不可變性 41實(shí)現(xiàn)自定義轉(zhuǎn)換 42Shark:RDDs上的SQL 42動(dòng)機(jī) 42實(shí)現(xiàn) 44列式內(nèi)存存儲(chǔ) 45數(shù)據(jù)協(xié)同劃分 453.2.43.33.3.13.43.4.13.4.23.4.3分區(qū)統(tǒng)計(jì)和映射

25、修剪 463.4.4局部DAG執(zhí)行（PDE） 46性能 48方法和集群設(shè)置 483.53.5.13.5.2 Pavlo等人的基準(zhǔn)測(cè)試 49 3.5.33.5.4微基準(zhǔn)測(cè)試 51容錯(cuò) 533.5.5真實(shí)的 Hive數(shù)據(jù)倉(cāng)庫(kù)查詢 54與SQL相結(jié)合的復(fù)雜分析 553.63.73.6.1 語言集成 563.6.2 執(zhí)行引擎集成 573.6.3 性能 57總結(jié) 58第四章離散流 594.14.2簡(jiǎn)介 59目標(biāo)與背景 61目標(biāo) 61以往的處理模型 62離散流（D-Streams） 63計(jì)算模型 64時(shí)序方面的考慮 664.2.14.2.24.34.3.14.3.24.3.3 D-Stream API 6

26、74.3.44.3.54.3.64.4一致性語義 70批處理與交互式處理的統(tǒng)一 70總結(jié) 71系統(tǒng)架構(gòu) 72應(yīng)用程序執(zhí)行 73流處理優(yōu)化 74內(nèi)存管理 74故障和慢節(jié)點(diǎn)恢復(fù) 75并行恢復(fù) 75減緩慢結(jié)點(diǎn)的影響 764.4.14.4.24.4.34.54.5.14.5.2 4.5.3 Master恢復(fù) 764.6評(píng)估 774.6.14.6.24.6.3性能 77故障和慢節(jié)點(diǎn)恢復(fù) 79實(shí)際應(yīng)用 814.7討論 83相關(guān)工作 85總結(jié) 864.84.9第五章 RDD的通用性 885.1簡(jiǎn)介 88觀點(diǎn)描述 885.25.2.1 MapReduce所能涵蓋的計(jì)算范圍 885.2.2 lineage和故障

27、恢復(fù) 895.2.35.3與BSP的比較 91系統(tǒng)角度 91瓶頸資源 92容錯(cuò)的開銷 93限制與擴(kuò)展 94延遲 94通信模式 94異步 94細(xì)粒度更新 95不變性和版本追蹤 95相關(guān)工作 965.3.15.3.25.45.4.15.4.25.4.35.4.45.4.55.55.6小結(jié) 96第六章總結(jié) 976.1經(jīng)驗(yàn)總結(jié) 98 6.2更深遠(yuǎn)的影響 996.3未來的工作 100參考文獻(xiàn) 102 第1 章簡(jiǎn)介在過去的幾年里已經(jīng)看到了計(jì)算機(jī)系統(tǒng)的重大變革，隨著數(shù)據(jù)量的不斷增長(zhǎng)越來越多的應(yīng)用需要擴(kuò)展到大型集群。在商業(yè)和科學(xué)領(lǐng)域，新的數(shù)據(jù)源和工具(例如,基因測(cè)序儀，RFID和 Web)正在生產(chǎn)越來越多的信

28、息。不幸的是，單機(jī)的處理能力和I/O性能并沒有跟上這種增長(zhǎng)。這樣一來，越來越多的企業(yè)不得不向外擴(kuò)展他們的計(jì)算至集群模式。可編程的集群環(huán)境會(huì)帶來一些挑戰(zhàn)。第一個(gè)是并行化：這需要以并行的方式重寫應(yīng)用程序，同時(shí)這種編程模型能夠處理范圍廣泛的的計(jì)算。然而，與其他并行平臺(tái)相比，集群的第二個(gè)挑戰(zhàn)是容錯(cuò):在大規(guī)模的情況下節(jié)點(diǎn)故障和straggler（慢節(jié)點(diǎn)）將變得很常見，而且可以極大地影響應(yīng)用程序的性能。最后，集群通常在多個(gè)用戶之間共享，因此需要在運(yùn)行時(shí)可以動(dòng)態(tài)地?cái)U(kuò)展和縮減計(jì)算資源，而且加劇了應(yīng)用互相干擾的可能性。因此，各種各樣針對(duì)集群的新的編程模型已經(jīng)被設(shè)計(jì)出來。起初，谷歌的MapReduce36提出了一

29、種簡(jiǎn)單通用而且能夠自動(dòng)處理故障的批處理計(jì)算模型。然而，MapReduce并不適合其他類型的計(jì)算任務(wù)，以至于出現(xiàn)了大量的與 MapRedeuce有顯著不同的特制的編程模型。例如 ,在谷歌，Pregel72提供了一個(gè)bulk-sunchronousparallel（BSP）并行迭代圖計(jì)算模型；F195是一個(gè)快速但沒有容錯(cuò)的SQL查詢系統(tǒng)；MillWheel2支持連續(xù)地流式處理。谷歌之外，像Storm14,Impala 60, Piccolo 86 and GraphLab 71系統(tǒng)提供了相似的模型。隨著每年新模型持續(xù)地出現(xiàn)，集群計(jì)算勢(shì)必需要一系列的解決不同的計(jì)算工作的方案。本論文討論的剛好相反，我

30、們可以設(shè)計(jì)一個(gè)統(tǒng)一的編程抽象，不僅可以處理這些不同的計(jì)算任務(wù)，而且能使新的應(yīng)用更好的編程。特別的是，我們將展示 MapReduce的一個(gè)簡(jiǎn)單擴(kuò)展，稱為彈性分布式數(shù)據(jù)集（RDDS）,它增加了高效的數(shù)據(jù)共享元語，以及大大增加了它的通用性。由此產(chǎn)生的架構(gòu)比當(dāng)前系統(tǒng)有幾個(gè)關(guān)鍵優(yōu)勢(shì)：1.在相同的運(yùn)行環(huán)境下，它支持批處理、交互式、迭代和流計(jì)算，結(jié)合這些模式提供豐富的應(yīng)用編程，并且相對(duì)于單一模式的系統(tǒng)能更好的發(fā)揮其性能。2.它以很小的代價(jià)在這些計(jì)算模式上提供結(jié)點(diǎn)故障和straggler的容忍功能。事實(shí)上，在一些地方（如流和SQL），基于RDD產(chǎn)生的新系統(tǒng)比現(xiàn)有的系統(tǒng)有更強(qiáng)的容錯(cuò)性。3.它實(shí)現(xiàn)的性能往往比Ma

31、pReduce高100倍，并可媲美各個(gè)應(yīng)用領(lǐng)域的專業(yè)系統(tǒng)。4.這很適合多組織用戶管理，允許應(yīng)用程序彈性地?cái)U(kuò)縮容和響應(yīng)式地共享資源。1 我們實(shí)現(xiàn)了基于RDD的架構(gòu)，在這個(gè)開源系統(tǒng)棧里包括作為公共組件的ApacheSpark;處理SQL的 Shark;和處理分布式流的 Spark Streaming（圖 1.1）。我們使用了真實(shí)的用戶應(yīng)用案例和傳統(tǒng)的基準(zhǔn)測(cè)試來評(píng)估這些系統(tǒng)。我們的實(shí)現(xiàn)為傳統(tǒng)和新的數(shù)據(jù)分析工作提供了很好的性能，并成為第一個(gè)使得用戶可以組合這些計(jì)算任務(wù)的平臺(tái)。從更長(zhǎng)遠(yuǎn)的角度來看，我們也討論了在RDD上實(shí)現(xiàn)各種數(shù)據(jù)處理的通用技術(shù)，以及證實(shí)為什么RDD是如此通用。隨著集群的應(yīng)用程序變得越來

32、越復(fù)雜，我們相信通過RDD提供的這種統(tǒng)一處理架構(gòu)將在性能和易用性變得越來越重要。論文聲明：基于彈性分布式數(shù)據(jù)集的單個(gè)執(zhí)行模型可以有效地支持不同的分布式計(jì)算。在本章的其余部分，我們說明了RDD設(shè)計(jì)的一些動(dòng)機(jī)，然后突出展示我們的主要成果。1.1專業(yè)系統(tǒng)相關(guān)的問題今天的集群計(jì)算機(jī)系統(tǒng)越來越多地專門針對(duì)特定的應(yīng)用領(lǐng)域。雖然像 MapReduce和 Drayed36,61這樣的系統(tǒng)模型目標(biāo)是在于覆蓋相當(dāng)通用的計(jì)算，然而研究員和從業(yè)者已經(jīng)為新的應(yīng)用領(lǐng)域研發(fā)了越來越多的專業(yè)系統(tǒng)。Spark流離散流Shark(SQL)Bagel(Pregel)IterativeMapReduceSpark(RDDs)細(xì)粒度的

33、任務(wù)執(zhí)行模型多組織用戶管理,數(shù)據(jù)本地性,彈性圖 1.1本論文中計(jì)算棧的實(shí)現(xiàn)最近通過 Spark的 RDDs（彈性分布式數(shù)據(jù)集）的實(shí)現(xiàn)，我們建立起了其他的計(jì)算模型，如流式計(jì)算，SQL和圖計(jì)算，所有這些都可以混雜在 Spark程序中。RDDs本身利用一系列的細(xì)粒度的任務(wù)來執(zhí)行應(yīng)用程序，能有效的共享資源。2 其中包括交互式 SQL查詢系統(tǒng) Dremel和 Impala75,60,圖計(jì)算處理系統(tǒng) Pregel72,機(jī)器學(xué)習(xí)系統(tǒng)GraphLab，等等。雖然這些專業(yè)系統(tǒng)似乎天然地減少了那些在分布式環(huán)境中具有挑戰(zhàn)性的問題，但他們也有一些缺點(diǎn)：1.重復(fù)工作：許多專業(yè)系統(tǒng)仍然需要解決同樣的潛在問題，如分布式執(zhí)行

34、和容錯(cuò)性。舉個(gè)例子，分布式 SQL引擎或機(jī)器學(xué)習(xí)引擎都需要執(zhí)行并行聚合。對(duì)于獨(dú)立的系統(tǒng)，針對(duì)每個(gè)領(lǐng)域也是需要解決這些問題。2.組成：不同系統(tǒng)的組合計(jì)算既昂貴也笨重。尤其是對(duì)于“大數(shù)據(jù)”應(yīng)用，中間處理過程的數(shù)據(jù)集是龐大的且難以移動(dòng)的。為了使得在各個(gè)計(jì)算引擎之間共享數(shù)據(jù)，當(dāng)前的環(huán)境需要將數(shù)據(jù)導(dǎo)出到穩(wěn)定且多備份的存儲(chǔ)系統(tǒng)中，通常這比實(shí)際計(jì)算要多出更多的消耗。因此，相比于一棧式的系統(tǒng)，由多個(gè)系統(tǒng)組成的管道常常是低效的。3.范圍限制：如果應(yīng)用程序不符合專業(yè)系統(tǒng)的編程模型，用戶要不修改程序以適應(yīng)當(dāng)前的系統(tǒng)，要不就針對(duì)該程序?qū)懸粋€(gè)新的運(yùn)行系統(tǒng)。4.資源共享：在計(jì)算引擎之間動(dòng)態(tài)共享資源是很困難的，因?yàn)榇蠖鄶?shù)引

35、擎在應(yīng)用程序運(yùn)行期間都假定獨(dú)自擁有一組機(jī)器。5.管理和管理員：相對(duì)單一的系統(tǒng)，獨(dú)立的系統(tǒng)需要更多的工作用于管理和部署。對(duì)于用戶來說，它們需要學(xué)習(xí)多種 API和執(zhí)行模型。由于這些限制，集群計(jì)算的統(tǒng)一抽象在易用性和性能方面都有顯著的好處，特別是對(duì)于復(fù)雜的應(yīng)用程序和多用戶環(huán)境下。1.2彈性分布式數(shù)據(jù)集（RDDS）為了解決這個(gè)問題，我們引入一個(gè)新的概念，彈性分布式數(shù)據(jù)集 (RDDs)，它是 MapReduce模型一種簡(jiǎn)單的擴(kuò)展和延伸。進(jìn)一步說，雖然乍一看那些不適合 MapReduce的計(jì)算任務(wù)（例如，迭代，交互性和流查詢）之間存在著明顯的不同，但他們卻都有一個(gè)功能特性，也是 MapReduce模型的缺

36、陷：在并行計(jì)算階段之間能夠高效地?cái)?shù)據(jù)共享，這正是 RDD具有真知灼見的地方。運(yùn)用高效的數(shù)據(jù)共享概念和類似于 MapReduce的操作方式，使得所有這些計(jì)算工作都可以有效地執(zhí)行，并可以在當(dāng)前特定的系統(tǒng)中獲得關(guān)鍵性的優(yōu)化。RDDs以一種既高效有能容錯(cuò)的方式為廣泛的并行3 計(jì)算提出這樣一個(gè)抽象。特別提出的是，以前的這些集群容錯(cuò)處理模型，像MapReduce、Dryad，將計(jì)算轉(zhuǎn)換為一個(gè)有向非循環(huán)圖（DAG）的任務(wù)集合。這使得它們能夠高效地重復(fù)執(zhí)行DAG里的其中一部分任務(wù)來完成容錯(cuò)恢復(fù)。但對(duì)于一個(gè)獨(dú)立的計(jì)算，（例如在一個(gè)迭代過程中），這些模型除了可復(fù)制的文件系統(tǒng)外沒有提供其他存儲(chǔ)的概念，這就導(dǎo)致因?yàn)樵?/p>

37、網(wǎng)絡(luò)上進(jìn)行數(shù)據(jù)復(fù)制而增加了大量的消耗。RDDs是一個(gè)可以避免復(fù)制的容錯(cuò)分布式存儲(chǔ)概念。取而代之，每一個(gè) RDD都會(huì)記住由構(gòu)建它的那些操作所構(gòu)成的一個(gè)圖，類似于批處理計(jì)算模型，可以有效地重新計(jì)算因故障丟失的數(shù)據(jù)。由于創(chuàng)建 RDDS的操作是相對(duì)粗粒度的，即單一的操作應(yīng)用于許多數(shù)據(jù)元素，該技巧比通過網(wǎng)絡(luò)復(fù)制數(shù)據(jù)更高效。RDDs很好地運(yùn)用于當(dāng)前廣泛的數(shù)據(jù)并行算法和處理模型中，所有的這些對(duì)多個(gè)任務(wù)使用同一種操作?，F(xiàn)在它看起來很神奇，只是增加數(shù)據(jù)共享卻極大地提高了MapReduce的通用性，那就讓我們從幾個(gè)方面探討為什么會(huì)這樣。首先，從表現(xiàn)力的角度來說，我們了解到RDDs可以效仿任何一種分布式系統(tǒng)，并且會(huì)

38、在容許網(wǎng)絡(luò)延遲的條件下做的非常高效。這是因?yàn)椋坏┰黾恿丝焖贁?shù)據(jù)共享機(jī)制，MapReduce可以效仿并行計(jì)算中的Bulk Synchronous Parallel (BSP) 108模型，而主要的缺陷是每個(gè)MapReduce的階段會(huì)有延遲。根據(jù)經(jīng)驗(yàn)，在我們的Spark系統(tǒng)中，這可以低至50100毫秒。其次，從系統(tǒng)的角度來說，不像普通的MapReduce，RDDs在大多數(shù)集群計(jì)算中會(huì)給應(yīng)用足夠的控制以便優(yōu)化資源瓶頸（特別是網(wǎng)絡(luò)和存儲(chǔ) I/O）。因?yàn)檫@些資源經(jīng)常占據(jù)主要的執(zhí)行時(shí)間，通常僅控制它們( 例如，通過控制數(shù)據(jù)位置）就能達(dá)到使用相同資源的獨(dú)立系統(tǒng)的性能。除了這種探索，我們還實(shí)證研究表明，使用

39、 RDDs我們可以實(shí)現(xiàn)多種目前使用的專用模型，以及新的編程模型。我們的實(shí)現(xiàn)能達(dá)到專業(yè)系統(tǒng)的性能，同時(shí)提供豐富的容錯(cuò)特性和組合。1.3基于RDD機(jī)制實(shí)現(xiàn)的模型我們使用RDD機(jī)制實(shí)現(xiàn)了多類模型，包括多個(gè)現(xiàn)有的集群編程模型和之前模型所沒有支持的新應(yīng)用。在這些模型中，RDD機(jī)制不僅在性能方面能夠和之前系統(tǒng)相匹配，在其他方面，他們也能加入現(xiàn)有的系統(tǒng)所缺少的新特性，比如容錯(cuò)性，straggler容忍和彈性。我們討論以下四類模型。迭代式算法一種目前已經(jīng)開發(fā)的針對(duì)特定系統(tǒng)最常見的的工作模式是迭代算法，比如應(yīng)用于圖處理，數(shù)值優(yōu)化，以及機(jī)器學(xué)習(xí)中的算法。RDD可以支持廣泛類型的各種模型，包括Pregel72，像

40、HaLoop和 Twister這類的迭代式 MapReduce模型22， 37，以及確定版本的 GraphLab和PowerGraph模型71,48。4 關(guān)系查詢?cè)贛apReduce集群中的首要需求中的一類是執(zhí)行SQL查詢，長(zhǎng)期運(yùn)行或多個(gè)小時(shí)的批量計(jì)算任務(wù)和即時(shí)查詢。這促進(jìn)了很多在商業(yè)集群中應(yīng)用的并行數(shù)據(jù)庫(kù)系統(tǒng)的發(fā)展 95, 60, 75。MapReduce相比并行數(shù)據(jù)庫(kù)在交互式查詢84有非常大的缺陷，例如 MapReduce的容錯(cuò)機(jī)制模型，而我們發(fā)現(xiàn)通過在RDD操作中實(shí)現(xiàn)很多常用的數(shù)據(jù)庫(kù)引擎的特性（比如，列處理），這樣能夠達(dá)到相當(dāng)可觀的性能。由上述方式所構(gòu)建的系統(tǒng)，Shark113，提供完整

41、的容錯(cuò)機(jī)制，能夠在短查詢和長(zhǎng)查詢中很好的擴(kuò)展，同時(shí)也能在RDD之上提供復(fù)雜分析函數(shù)的調(diào)用(例如,機(jī)器學(xué)習(xí))。MapReduceRDD通過提供MapReduce的一個(gè)超集，能夠高效地執(zhí)行MapReduce程序，同樣也可以指向比如DryadLINQ這樣常見的機(jī)遇DAG數(shù)據(jù)流的應(yīng)用115。流式數(shù)據(jù)處理我們的系統(tǒng)與定制化系統(tǒng)最大的區(qū)別是我們也使用RDD實(shí)現(xiàn)了流式處理。流式數(shù)據(jù)處理已經(jīng)在數(shù)據(jù)庫(kù)和系統(tǒng)領(lǐng)域進(jìn)行了很長(zhǎng)時(shí)間研究，但是實(shí)現(xiàn)大規(guī)模流式數(shù)據(jù)處理仍然是一項(xiàng)挑戰(zhàn)。當(dāng)前的模型并沒有處理在大規(guī)模集群中頻繁出現(xiàn)的 straggler的問題，同時(shí)對(duì)故障恢復(fù)的方式也非常有限，需要大量的復(fù)制或浪費(fèi)很長(zhǎng)的恢復(fù)時(shí)間。特

42、別是，當(dāng)前的系統(tǒng)是基于一種持續(xù)操作的模型，這就需要長(zhǎng)時(shí)間的有狀態(tài)的操作處理每一個(gè)到達(dá)的記錄。為了恢復(fù)一個(gè)丟失的節(jié)點(diǎn)，當(dāng)前的系統(tǒng)需要保存每一個(gè)操作符的兩個(gè)副本，或通過一系列耗費(fèi)大量開銷的串行處理來對(duì)上游的數(shù)據(jù)進(jìn)行重放。我們提出了一個(gè)新的模型，離散數(shù)據(jù)流(D-Streams),來解決這樣的問題。對(duì)使用長(zhǎng)期狀態(tài)處理的過程進(jìn)行替換，D-Streams把流式計(jì)算的執(zhí)行當(dāng)做一系列短而確定性的批量計(jì)算的序列，將狀態(tài)保存在RDD里。D-Stream模型通過根據(jù)相關(guān)RDD的依賴關(guān)系圖進(jìn)行并行化恢復(fù)，就能達(dá)到快速的故障恢復(fù)，這樣不需要通過復(fù)制。另外，它通過推測(cè)(Speculative)來支持對(duì)straggler遷

43、移執(zhí)行36，例如，對(duì)那些慢任務(wù)運(yùn)行經(jīng)過推測(cè)的備份副本。盡管D-Stream將計(jì)算轉(zhuǎn)換為許多不相關(guān)聯(lián)的 jobs來運(yùn)行從而增加了部分延遲，然而我們證明了 D-Stream能夠被達(dá)到次秒級(jí)延時(shí)的實(shí)現(xiàn)，這樣能夠達(dá)到以前系統(tǒng)單個(gè)節(jié)點(diǎn)的性能，并能線性擴(kuò)展到 100個(gè)節(jié)點(diǎn)。D-Stream的強(qiáng)恢復(fù)特性讓他們成為了第一個(gè)處理大規(guī)模集群特性的流式處理模型，并且他們基于 RDD的實(shí)現(xiàn)使得應(yīng)用能夠有效的整合批處理和交互式查詢。通過將這些模型整合到一起，RDD還能支持一些現(xiàn)有系統(tǒng)不能表示的新的應(yīng)用。例如，許多數(shù)據(jù)流應(yīng)用程序還需要加入歷史數(shù)據(jù)的信息；通過使用 RDD可以在同一程序中同時(shí)使用批處理和流式處理，這樣來實(shí)現(xiàn)

44、在所有模型中數(shù)據(jù)共享和容錯(cuò)恢復(fù)。同樣的，流式應(yīng)用的操作者常常需要在數(shù)據(jù)流的狀態(tài)上執(zhí)行即時(shí)查詢；在D-Stream中的RDD能夠如靜態(tài)數(shù)據(jù)形式進(jìn)行查詢。我們使用一些在線機(jī)器學(xué)習(xí) (第 4.6.3節(jié))和視頻分析(第 4.6.3節(jié))的實(shí)際應(yīng)用來說明了這些用例。更一般5 的說，每一個(gè)批處理應(yīng)用常常需要整合多個(gè)處理類型：比如，一個(gè)應(yīng)用可能需要使用 SQL提取一個(gè)數(shù)據(jù)集，在數(shù)據(jù)集上訓(xùn)練一個(gè)機(jī)器學(xué)習(xí)模型，之后對(duì)這個(gè)模型進(jìn)行查詢。由于計(jì)算的大部分時(shí)間花在系統(tǒng)之間共享數(shù)據(jù)的分布式文件系統(tǒng)的 I/O開銷上，因此使用當(dāng)前多個(gè)系統(tǒng)組合而成的工作流的效率非常的低下。使用一個(gè)基于 RDD機(jī)制的系統(tǒng)，這些計(jì)算可以在同一個(gè)引

45、擎中緊接著執(zhí)行，而不需要額外的I/O。圖1.2.Spark棧和定制化系統(tǒng)在代碼量和性能上的比較Spark的代碼量和定制化系統(tǒng)是相近的，然而這些模型在Spark上的實(shí)現(xiàn)代碼量明顯要少。盡管如此，在選定的應(yīng)用中的Spark的性能可以和定制化系統(tǒng)相媲美。1.4總結(jié)我們?cè)谕泄苡贏pache孵化器而且已經(jīng)用于多個(gè)商業(yè)部署的開源系統(tǒng)Spark中實(shí)現(xiàn)了RDDs。盡管RDD很通用，但Spark相對(duì)較小:共34，000行Scala(公認(rèn)的高級(jí)語言)代碼，在同一范圍內(nèi)把它作為專業(yè)的集群計(jì)算系統(tǒng)。更重要的是，建立于 Spark上的專業(yè)模型比它們單獨(dú)運(yùn)行的時(shí)候小得多：我們用幾百行代碼實(shí)現(xiàn)Pregel和交互性的MapR

46、educe，8000行代碼實(shí)現(xiàn)了離散Stream,12000行代碼實(shí)現(xiàn)一個(gè)以ApacheHive作為Spark前段進(jìn)行查詢的SQL系統(tǒng)Shark。這些基于spark的系統(tǒng)比單獨(dú)的特定實(shí)現(xiàn)小幾個(gè)數(shù)量級(jí)且支持各種方法的混合模型，但是在性能上仍然比得上專業(yè)系統(tǒng)。簡(jiǎn)短總結(jié)一下，圖1.2從性能和代碼規(guī)模上對(duì)Spark及建立于Spark上的3個(gè)系統(tǒng)（Shark,SparkStreaming,GraphX）113,119,112，和廣受歡迎的專業(yè)系統(tǒng)（Impala，Amazon Redshift處理SQL的DBMS;Storm流處理;Giraph圖處理）60,5,14,10進(jìn)行了比較。除了這些實(shí)際的結(jié)果，我

47、們也包括通過RDD實(shí)現(xiàn)復(fù)雜處理函數(shù)的通用技術(shù)以及討論為什么RDD模型如此受歡迎。尤其是在1.2章節(jié)中表述的那樣，我們發(fā)現(xiàn)RDD模型可以與任何分布式系統(tǒng)競(jìng)爭(zhēng)，且6 有著比MapReduce更高效的表現(xiàn)。而實(shí)際上，RDD接口比起專業(yè)系統(tǒng)在集群瓶頸資源方面，給予了應(yīng)用足夠的自由控制，而且仍然可以實(shí)現(xiàn)自動(dòng)容錯(cuò)恢復(fù)和高效的組合。1.5論文計(jì)劃本文組織結(jié)構(gòu)如下。第 2章介紹了 RDD抽象并涵蓋了一些簡(jiǎn)單的編程模型的應(yīng)用。第 3章介紹了Shark SQL系統(tǒng)基于RDDs實(shí)現(xiàn)的更高級(jí)的存儲(chǔ)和處理模型的技術(shù)。第 4章介紹了如何使用RDDs開發(fā)離散的流，這是一種新的流式處理模型。第 5章則介紹了為什么RDD模型在

48、這些應(yīng)用中如此通用，同時(shí)介紹它的限制和擴(kuò)展性。最后，在第 6章，我們總結(jié)和討論一些未來工作的可能方向。7 第二章彈性分布式數(shù)據(jù)集2.1簡(jiǎn)介在本章中，我們提出了彈性分布式數(shù)據(jù)集（RDD）的抽象概念，論文其余部分基于此建立了一個(gè)通用的集群計(jì)算棧。RDD對(duì)MapReduce36和Dryad61提出的數(shù)據(jù)流編程模型進(jìn)行了擴(kuò)展，這些模型是目前大數(shù)據(jù)分析使用最為廣泛的編程模型。數(shù)據(jù)流系統(tǒng)取得了成功，很重要的因素是用戶通過使用比較高級(jí)的操作進(jìn)行計(jì)算而無需擔(dān)心任務(wù)分布和系統(tǒng)的容錯(cuò)問題。然而，隨著集群負(fù)載的增加，數(shù)據(jù)流系統(tǒng)在很多重要的應(yīng)用場(chǎng)景出現(xiàn)了低效率問題，比如迭代算法，交互式查詢和流式處理。這引發(fā)了大量針對(duì)

49、這些應(yīng)用而定制的計(jì)算框架的發(fā)展72, 22, 71,95, 60,14, 2。我們的工作源于觀察到很多數(shù)據(jù)流模型不適用的應(yīng)用場(chǎng)景所共有的一個(gè)特征：在計(jì)算過程中都需要高效率的數(shù)據(jù)共享。例如，迭代算法，如 PageRank, K-means聚類，或邏輯回歸，都需要進(jìn)行多次訪問相同的數(shù)據(jù)集；交互數(shù)據(jù)挖掘經(jīng)常需要對(duì)于同一數(shù)據(jù)子集進(jìn)行多個(gè)特定的查詢；而流式應(yīng)用下則需要隨時(shí)間對(duì)狀態(tài)信息進(jìn)行維護(hù)和共享。不幸的是，盡管數(shù)據(jù)流框架支持大量的計(jì)算操作運(yùn)算，但是它們?nèi)狈︶槍?duì)數(shù)據(jù)共享的高效原語。在這些框架中，實(shí)現(xiàn)計(jì)算之間(例如，兩個(gè)的MapReduce作業(yè)之間)數(shù)據(jù)共享只有一個(gè)辦法，就是將其寫到一個(gè)穩(wěn)定的外部存儲(chǔ)系統(tǒng)

50、，如分布式文件系統(tǒng)。這會(huì)引入數(shù)據(jù)備份、磁盤I/O以及序列化，這些都會(huì)引起大量的開銷，從而占據(jù)大部分的應(yīng)用執(zhí)行時(shí)間。事實(shí)上，在針對(duì)這些新應(yīng)用而定制的框架進(jìn)行研究的過程中，我們的確有發(fā)現(xiàn)它們會(huì)對(duì)數(shù)據(jù)共享進(jìn)行優(yōu)化。例如，Pregel72是一種針對(duì)圖迭代計(jì)算的系統(tǒng)，它會(huì)將中間狀態(tài)保存在內(nèi)存中。而 HaLoop22是一種迭代 MapReduce的系統(tǒng)，它會(huì)在各步驟中都以一種高效率的方式對(duì)數(shù)據(jù)進(jìn)行分區(qū)。不幸的是，這些框架只能支持特定的計(jì)算模式（例如，循環(huán)一系列的MapReduce的步驟），并對(duì)用戶屏蔽了數(shù)據(jù)共享的方式。它們不能提供一種更為通用的抽象模式，例如，允許一個(gè)用戶可以加載幾個(gè)數(shù)據(jù)集到內(nèi)存中并進(jìn)行一

51、些跨數(shù)據(jù)集的即時(shí)查詢。相反，我們所提出的彈性分布式數(shù)據(jù)集（RDDs），這種全新的抽象模式令用戶可以直接控制數(shù)據(jù)的共享。RDD具有可容錯(cuò)和并行數(shù)據(jù)結(jié)構(gòu)特征，這使得用戶可以指定數(shù)據(jù)存儲(chǔ)到硬盤還是內(nèi)存、控制數(shù)據(jù)的分區(qū)方法并在數(shù)據(jù)集上進(jìn)行種類豐富的操作。他們提供了一個(gè)簡(jiǎn)單8 高效的編程接口，可以同時(shí)滿足現(xiàn)有的特定模型和全新的應(yīng)用場(chǎng)景。RDD設(shè)計(jì)時(shí)的最大挑戰(zhàn)在于定義一個(gè)能提供高效容錯(cuò)能力的編程接口?，F(xiàn)有的基于集群的內(nèi)存存儲(chǔ)抽象，比如分布式共享內(nèi)存79,鍵-值存儲(chǔ)81,數(shù)據(jù)庫(kù),以及 Piccolo86,提供了一個(gè)對(duì)內(nèi)部狀態(tài)基于細(xì)粒度更新的接口(例如,表格里面的單元).在這樣的設(shè)計(jì)之下，提供容錯(cuò)性的方法就要

52、么是在主機(jī)之間復(fù)制數(shù)據(jù)，要么對(duì)各主機(jī)的更新情況做日志記錄。這兩種方法對(duì)于數(shù)據(jù)密集型的任務(wù)來說代價(jià)很高，因?yàn)樗鼈冃枰趲掃h(yuǎn)低于內(nèi)存的集群網(wǎng)絡(luò)間拷貝大量的數(shù)據(jù)，同時(shí)還將產(chǎn)生大量的存儲(chǔ)開銷。與上述系統(tǒng)不同的是，RDD提供一種基于粗粒度變換（如， map, filter, join）的接口，該接口會(huì)將相同的操作應(yīng)用到多個(gè)數(shù)據(jù)集上。這使得他們可以通過記錄用來創(chuàng)建數(shù)據(jù)集的變換（lineage），而不需存儲(chǔ)真正的數(shù)據(jù)，進(jìn)而達(dá)到高效的容錯(cuò)性。當(dāng)一個(gè)RDD的某個(gè)1分區(qū)丟失的時(shí)候，RDD記錄有足夠的信息記錄其如何通過其他的RDD進(jìn)行計(jì)算，且只需重新計(jì)算該分區(qū)。因此，丟失的數(shù)據(jù)可以被很快的恢復(fù)，而不需要昂貴的復(fù)制

53、代價(jià)。盡管基于粗粒度變換的接口顯得很局限，但RDD針對(duì)很多應(yīng)用都有很好的普適性，因?yàn)檫@些應(yīng)用可以自然地對(duì)多個(gè)數(shù)據(jù)項(xiàng)使用同樣的操作。事實(shí)上，RDD可充分表達(dá)多種現(xiàn)有的集群編程模型。這些模型之間相互獨(dú)立，它們包括 MapReduce、DryadLINQ、SQL、Pregel和HaLoop以及一些這些系統(tǒng)無法涵蓋的新需求，如交互式數(shù)據(jù)挖掘。RDD對(duì)新計(jì)算需求的適用能力是對(duì)RDD抽象優(yōu)勢(shì)的最佳見證。在這之前，這些新的需求在只能通過創(chuàng)建新的計(jì)算框架才能得到滿足。RDD已經(jīng)在一個(gè)名為Spark的系統(tǒng)中實(shí)現(xiàn)，該系統(tǒng)正廣泛應(yīng)用于UC Berkeley和其他公司的研究和生產(chǎn)環(huán)境下。與DryadLINQ115類似

54、，Spark提供了一種便捷的語言集成編程接口。該接口用Scala92語言實(shí)現(xiàn)。此外，借助Scala解釋器，Spark提供對(duì)大數(shù)據(jù)集進(jìn)行交互式查詢的功能。我們相信Spark是首個(gè)支持用通用編程語言來在集群上實(shí)現(xiàn)交互速度級(jí)的內(nèi)存數(shù)據(jù)挖掘的系統(tǒng)。我們基準(zhǔn)程序和用戶程序中的衡量指標(biāo)對(duì) RDD和 Spark進(jìn)行了評(píng)估。結(jié)果表明，Spark在迭代性的應(yīng)用上比 Hadoop最高可快80倍，真實(shí)的數(shù)據(jù)分析應(yīng)用上快40倍，而且在1TB的數(shù)據(jù)上實(shí)現(xiàn)5-7秒內(nèi)的交互式掃描。最后，為展現(xiàn)Spark的通用性，我們?cè)赟park實(shí)現(xiàn)了Pregel和 HaLoop編程模型。這些實(shí)現(xiàn)包括它們各自的分布優(yōu)化，并以相對(duì)較小的庫(kù)(每

55、個(gè)約200行代碼)來提供這些功能。本章首先會(huì)分別對(duì)RDD(章節(jié) 2.2)和Spark(章節(jié) 2.3)進(jìn)行概述。隨后會(huì)詳細(xì)討論RDD的內(nèi)部描述(章節(jié) 2.4)，具體實(shí)現(xiàn)過程(章節(jié) 2.5)以及實(shí)驗(yàn)結(jié)果(章節(jié) 2.6)。最后，我們會(huì)1當(dāng)lineage增加到做夠大時(shí)，對(duì)某些RDD中的數(shù)據(jù)進(jìn)行檢查或?qū)⒆兊糜幸饬x。相關(guān)細(xì)節(jié)我們將會(huì)在 2.5.5節(jié)進(jìn)行的討論。9 討論RDD如何適用于現(xiàn)有的編程模型 (章節(jié) 2.7)，闡述相關(guān)的工作 (章節(jié) 2.8)，并最終得出結(jié)論。2.2 RDD概述本節(jié)提供RDDs的概述。首先我們看下RDD(2.2.1)的概念以及它們?cè)赟park(2.2.2)中的編程接口。然后比較下RD

56、D與細(xì)粒度共享內(nèi)存（finer-grainedsharedmemory）。最后我們討論RDD模型的局限性。2.2.1概念從形式上看，RDD是一個(gè)分區(qū)的只讀記錄的集合。RDD只能通過在（1）穩(wěn)定的存儲(chǔ)器或（2）其他RDD的數(shù)據(jù)上的確定性操作來創(chuàng)建。我們把這些操作稱作變換以區(qū)別其他類型的操作。例如 map, filter,和 join。2RDD在任何時(shí)候都不需要被物化(進(jìn)行實(shí)際的變換并最終寫入穩(wěn)定的存儲(chǔ)器上)。實(shí)際上，一個(gè)RDD有足夠的信息描述著其如何從其他穩(wěn)定的存儲(chǔ)器上的數(shù)據(jù)生成。它有一個(gè)強(qiáng)大的特性：從本質(zhì)上說，若RDD失效且不能重建，程序?qū)⒉荒芤迷揜DD。最后，用戶可以控制RDD的其他兩個(gè)方

57、面：持久化和分區(qū)。用戶可以選擇重用哪個(gè)RDD，并為其制定存儲(chǔ)策略(比如，內(nèi)存存儲(chǔ))。也可以讓RDD中的數(shù)據(jù)根據(jù)記錄的key分布到集群的多個(gè)機(jī)器。這對(duì)位置優(yōu)化來說是有用的，比如可用來保證兩個(gè)要Jion的數(shù)據(jù)集都使用了相同的哈希分區(qū)方式。2.2.2 Spark編程接口Spark通過一種類似于 DryadLINQ 115和 FlumeJava 25集成語言 API來對(duì)外提供RDD的功能。具體來說，每一個(gè)數(shù)據(jù)集都會(huì)表示為一個(gè)對(duì)象，而各種變換則通過該對(duì)象相應(yīng)方法的調(diào)用而實(shí)現(xiàn)。2盡管單個(gè)的RDDS是不可變的，但可以通過多個(gè)RDDs來表示一個(gè)數(shù)據(jù)集的多個(gè)版本來實(shí)現(xiàn)可變。這種性質(zhì)（不可變）使得描述其linea

58、ge(獲取RDD所需要經(jīng)過的變換)變得容易?？梢赃@樣理解，RDD是版本化的數(shù)據(jù)集，并且可以通過變換記錄追蹤版本。10 在最開始，編程人員通過對(duì)穩(wěn)定存儲(chǔ)上的數(shù)據(jù)進(jìn)行變換操作(e.g., map 和 filter).而得到一個(gè)或多個(gè)RDD。之后，他們可以調(diào)用這些RDD的 actions(動(dòng)作)類的操作。這類操作的目的或是返回一個(gè)值，或是將數(shù)據(jù)導(dǎo)入到存儲(chǔ)系統(tǒng)中。動(dòng)作類的操作如 count(返回?cái)?shù)據(jù)集的元素?cái)?shù) ),collect(返回元素本身的集合 )和 save(輸出數(shù)據(jù)集到存儲(chǔ)系統(tǒng) )。與DryadLINQ一樣，Spark直到RDD第一次調(diào)用一個(gè)動(dòng)作時(shí)才真正計(jì)算RDD。這也就使得Spark可以按序

59、緩存多個(gè)變換。此外，編程人員還可以調(diào)用RDD的persist(持久化)方法來表明該RDD在后續(xù)操作中還會(huì)用到。默認(rèn)情況下，Spark會(huì)將調(diào)用過persist的RDD存在內(nèi)存中。但若內(nèi)存不足，也可以將其寫入到硬盤上。通過指定persist函數(shù)中的參數(shù)，用戶也可以請(qǐng)求其他持久化策略并通過標(biāo)記來進(jìn)行persist，比如僅存儲(chǔ)到硬盤上，又或是在各機(jī)器之間復(fù)制一份。最后，用戶可以在每個(gè) RDD 上設(shè)定一個(gè)持久化的優(yōu)先級(jí)來指定內(nèi)存中的哪些數(shù)據(jù)應(yīng)該被優(yōu)先寫入到磁盤。例如：控制臺(tái)日志挖掘假設(shè)一個(gè) Web 服務(wù)遇到錯(cuò)誤，操作員要在 Hadoop 文件系統(tǒng)（HDFS 11）里搜索 TB 級(jí)大小的日志，以查找原因。

60、通過Spark，操作員可以只把日志中的錯(cuò)誤信息加載到多個(gè)節(jié)點(diǎn)的內(nèi)存中，并進(jìn)行交互式查詢?？梢韵孺I入以下Scala代碼：lines = spark.textFile(hdfs:/. . .“)errors = lines.filter(_.startsWith(ERROR)Merrors.persist()第1行定義了以一個(gè)HDFS文件（由數(shù)行文本組成）為基礎(chǔ)的RDD。第2行則從它派生了一個(gè)過濾后的RDD。第3行要求 errors 在內(nèi)存中持久化，以便它可以通過查詢共享。需要注意的是filter的參數(shù)用的是Scala閉包的語法。到此，集群上還沒有工作被執(zhí)行。但是，用戶現(xiàn)在已經(jīng)可以在動(dòng)作(acti