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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18、作業(yè)需求。 致謝感謝我的導師Scott Shenker和Ion Stoica教授，在我博士期間對我孜孜不倦的指導。他們都是非常卓越的研究者，總是能夠將想法往前推進一步，為我們提供完成任務所需的條件，以及分享他們做研究的經(jīng)驗。特別榮幸能和他們兩人一起工作，他們的觀點讓我受益。本論文的工作是與其他很多人合作的結果。第2章是和MosharafChowdhury,TathagataDas,Ankur Dave, Justin Ma, Murphy McCauley, Mike Franklin, Scott Shenker及 Ion Stoica一起合作的 118。第 3章中介紹的 Shark項目部分

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

20、面都提出了一些特別好的建議和想法。和BenHindman,AndyKonwinski，KurtisHeimerl在一起非常有趣，他們在一些好的想法上都是非常棒的合作者。Taylor Sittler讓我和 AMPLab的很多人對生物學產(chǎn)生了非常大的興趣，這促成了我和 Bill Bolosky, Ravi Pandya, Kristal Curtis, DavePatterson及其他很多人在AMP-X加入的最有趣的小組之一。在其它項目中，我也有幸與VernPaxson, Dawn Song, Anthony Joseph, Randy Katz和 Armando Fox一起合作，并從他們的見解中

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

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

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

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

25、修剪 463.4.4局部DAG執(zhí)行（PDE） 46性能 48方法和集群設置 483.53.5.13.5.2 Pavlo等人的基準測試 49 3.5.33.5.4微基準測試 51容錯 533.5.5真實的 Hive數(shù)據(jù)倉庫查詢 54與SQL相結合的復雜分析 553.63.73.6.1 語言集成 563.6.2 執(zhí)行引擎集成 573.6.3 性能 57總結 58第四章離散流 594.14.2簡介 59目標與背景 61目標 61以往的處理模型 62離散流（D-Streams） 63計算模型 64時序方面的考慮 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總結 71系統(tǒng)架構 72應用程序執(zhí)行 73流處理優(yōu)化 74內存管理 74故障和慢節(jié)點恢復 75并行恢復 75減緩慢結點的影響 764.4.14.4.24.4.34.54.5.14.5.2 4.5.3 Master恢復 764.6評估 774.6.14.6.24.6.3性能 77故障和慢節(jié)點恢復 79實際應用 814.7討論 83相關工作 85總結 864.84.9第五章 RDD的通用性 885.1簡介 88觀點描述 885.25.2.1 MapReduce所能涵蓋的計算范圍 885.2.2 lineage和故障

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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