1、Spark文檔翻譯Spark調(diào)優(yōu)(v1.2.0)翻譯者文檔翻譯團(tuán)成員SparkSpark文檔翻譯Bagel 編程指南(v1.2.0)Life is short, you need spark!前言伴隨著大數(shù)據(jù)相關(guān)技術(shù)和產(chǎn)業(yè)的逐步成熟，繼 Hadoop 之后，Spark 技術(shù)以集大成的無可比擬的優(yōu)勢，發(fā)展迅速，將成為替代 Hadoop 的下一代云計算、大數(shù)據(jù)技術(shù)。Spark 是大數(shù)據(jù)領(lǐng)域最活躍最熱門的高效大數(shù)據(jù)通用計算平臺，基于 RDD，Spark的構(gòu)建起了、多元化的大數(shù)據(jù)處理體系，在“One Stack to rule them的使用 Spark SQL、Spark Streaming、MLL

2、ib、GraphXall”思想的引領(lǐng)下，Spark近乎完美的解決了大數(shù)據(jù)中 Batch Processing、Streaming Processing、Ad-hocQuery 等三大問題，更為美妙的是在 Spark 中 Spark SQL、Spark Streaming、MLLib、GraphX 四大子框架和庫之間可以無縫的共享數(shù)據(jù)和操作，這是據(jù)平臺都無可匹敵的優(yōu)勢。任何大數(shù)在實(shí)際的生產(chǎn)環(huán)境中，世界上已經(jīng)出現(xiàn)很多一千個以上節(jié)點(diǎn)的 Spark 集群，以 eBay為例，eBay 的 Spark 集群節(jié)點(diǎn)已經(jīng)超過 2000 個，Yahoo！等公司也在大規(guī)模的使用Spark，國內(nèi)的淘寶、騰訊、網(wǎng)易、京

3、東、大眾點(diǎn)評、優(yōu)酷土豆等也在生產(chǎn)環(huán)境下深度使用 Spark。2014 Spark Summit 上的信息，Spark 已經(jīng)獲得世界 20 家頂級公司的支持，這些公司中包括 Intel、IBM 等，同時更重要的是包括了最大的四個Hadoop商，都提供了對 Spark 非常強(qiáng)的支持。與 Spark 火爆程度形成鮮明對比的是 Spark的嚴(yán)重稀缺，這一情況在中國尤其嚴(yán)重，這種的稀缺，一方面是由于 Spark 技術(shù)在 2013、2014 年才在國內(nèi)的一些大型企業(yè)里面被逐步應(yīng)用，另一方面是由于匱乏 Spark 相關(guān)的中文資料和系統(tǒng)化的培訓(xùn)。為此，Spark 亞太和 51CTO推出了“Spark 亞太決勝

4、大數(shù)據(jù)時代 100 期公益大講堂”，來推動 Spark 技術(shù)在國內(nèi)的普及及落地。具體信息請參考與此同時，為了向 Spark 學(xué)習(xí)者提供更為豐富的學(xué)習(xí)資料，Spark 亞太去年8 月發(fā)起并號召，結(jié)合網(wǎng)絡(luò)社區(qū)的力量構(gòu)建了 Spark 中文文檔翻譯團(tuán)隊，翻譯了Spark 中文文檔 V1.1.0 版本。2014 年 12 月，Spark 本，為了讓學(xué)習(xí)者了解到最新的內(nèi)容，Spark 中文文檔版本進(jìn)行了部分更新，在此，我謹(jǐn)代表 Spark 亞太團(tuán)隊發(fā)布了 Spark 1.2.0 版翻譯團(tuán)隊又對 Spark 1.2.0及廣大 Spark 學(xué)習(xí)者向翻譯團(tuán)隊所有成員熱情而專業(yè)的工作致以深刻的敬意！當(dāng)然，作為相

5、對系統(tǒng)的 Spark 中文文檔，不足之處在所難免，大家有任何建議或者意見都可以發(fā)郵件到 ；同時如果您想加入 Spark 中文2 / 13TEL: 4006-998-758Spark文檔翻譯Bagel 編程指南(v1.2.0)Life is short, you need spark!文檔翻譯團(tuán)隊，也請發(fā)郵件到 進(jìn)行申請；Spark 中文文檔的翻譯是一個持續(xù)更新的、不斷版本迭代的過程，我們會盡全力給大家提供更高質(zhì)量的 Spark 中文文檔翻譯。最后，也是最重要的，請我榮幸的介紹一下我們的 Spark 中文文檔 1.2.0

6、版本翻譯的團(tuán)隊成員，他們分別是（排名不分先后）：, 快速開始(v1.2.0)舟,Spark學(xué)習(xí)庫 (v1.2.0)，在 Yarn 上運(yùn)行 Spark (v1.2.0)Spark 調(diào)優(yōu)(v1.2.0)，Spark 配置(v1.2.0)Spark 作業(yè)調(diào)度(v1.2.0)，Bagel 編程指南(v1.2.0)harli，Spark 編程指南 (v1.2.0)，Spark SQL 編程指南(v1.2.0)，文檔首頁(v1.2.0)，Spark 實(shí)時流處理編程指南(v1.2.0)，使用 Maven 編譯 Spark(v1.2.0)，給 Spark 提交代碼(v1.2.0)Ernest，集群模式概覽(v

7、1.2.0)與相關(guān)工具(v1.2.0)提交應(yīng)用程序(v1.2.0)Life is short, You need Spark!Spark 亞太院長2015 年 2 月3 / 13翻譯者：Spark文檔翻譯團(tuán)成員Spark 亞太Spark文檔翻譯Bagel 編程指南(v1.2.0)Life is short, you need spark!Spark 亞太決勝大數(shù)據(jù)100 期公益大講堂簡介作為下一代云計算的技術(shù)，Spark 性能超 Hadoop 百倍，算法實(shí)現(xiàn)僅有其 1/10或 1/100,是可以Hadoop 的目前唯一替代者，能夠做 Hadoop 做的一切事情，同時速度比Hadoop 快了 1

8、00 倍以上。目前 Spark 已經(jīng)構(gòu)建了的整個大數(shù)據(jù)處理生態(tài)系統(tǒng)，國外一些大型互聯(lián)網(wǎng)公司已經(jīng)部署了 Spark。甚至連 Hadoop 的早期主要貢獻(xiàn)者Yahoo 現(xiàn)在也在多個項目中部署使用 Spark；國內(nèi)的淘寶、優(yōu)酷土豆、網(wǎng)易、Baidu、騰訊、皮皮網(wǎng)等已經(jīng)使用 Spark 技術(shù)用于的商業(yè)生產(chǎn)系統(tǒng)中，國內(nèi)外的應(yīng)用開始越來越廣泛。Spark 正在逐漸成熟，并在這個領(lǐng)域扮演更加重要的, 剛剛結(jié)束的2014 Spark Summit 上的信息，Spark 已經(jīng)獲得世界 20 家頂級公司的支持，這些公司中包括 Intel、IBM 等，同時更重要的是包括了最大的四個 Hadoop商都提供了對非常強(qiáng)的

9、支持 Spark 的支持.鑒于 Spark 的巨大價值和潛力，同時由于國內(nèi)極度缺乏Spark，Spark 亞太在完成了對 Spark 源碼的徹底研究的同時，不斷在實(shí)際環(huán)境中使用 Spark 的各種特性的基礎(chǔ)之上，推出了 Spark 亞太決勝大數(shù)據(jù)100 期公益大講堂，希需求的企業(yè)和望能夠幫助大家了解Spark 的技術(shù)。同時，對Spark培養(yǎng)個人，以公開課和企業(yè)內(nèi)訓(xùn)的方式，來幫助大家進(jìn)行 Spark 技能的提升。同樣，我們也為企業(yè)提供Spark 亞太的顧問式服務(wù)及Spark 一站式項目解決方案和實(shí)施方案。決勝大數(shù)據(jù)100 期公益大講堂是國內(nèi)第一個 Spark 課程免講座，每周一期，從 7 月份起

10、，每周四晚 20:00-21:30，與大家不見不散！將就Spark 內(nèi)核剖析、源碼解讀、性能優(yōu)化及商業(yè)實(shí)戰(zhàn)案例等貨不容錯過！內(nèi)容與大家，干時間：從 7 月份起，每周一期，每周四晚 20:00-21:30形式：騰訊課堂學(xué)習(xí)條件：對云計算大數(shù)據(jù)感課程學(xué)習(xí)地址：的技術(shù)4 / 13TEL: 4006-998-758Spark文檔翻譯Bagel 編程指南(v1.2.0)Life is short, you need spark!Spark 調(diào)優(yōu)(v1.2.0)（翻譯者：）Tuning Spark，原文檔目錄Spark 調(diào)優(yōu)6數(shù)據(jù)序列化6內(nèi)存調(diào)優(yōu)7確定內(nèi)存的消耗8數(shù)據(jù)結(jié)構(gòu)調(diào)優(yōu)8序列化RDD. 8回收調(diào)優(yōu)8

11、其他需要考慮的地方10Reduce 任務(wù)的內(nèi)存使用10廣播（Broadcasting）較大的變量11數(shù)據(jù)分布11總結(jié)125 / 13翻譯者：Spark文檔翻譯團(tuán)成員Spark 亞太Spark文檔翻譯Bagel 編程指南(v1.2.0)Life is short, you need spark!Spark 調(diào)優(yōu) 數(shù)據(jù)序列化 內(nèi)存調(diào)優(yōu)o 確定內(nèi)存消耗o 數(shù)據(jù)結(jié)構(gòu)調(diào)優(yōu)序列化回收調(diào)優(yōu)oo 其他需要考慮的地方o 并行度o 任務(wù)的內(nèi)存使用o 廣播（Broadcasting）較大的變量o 數(shù)據(jù)分布 總結(jié)由于基于Spark 的計算大多數(shù)是在內(nèi)存中進(jìn)行的，所以集群中的 CPU、網(wǎng)絡(luò)帶寬、內(nèi)存等任何都可能成為Sp

12、ark 程序的瓶頸。通常如果數(shù)據(jù)正好存在內(nèi)存中，那網(wǎng)絡(luò)帶寬就會成為瓶頸，但有時你還是需要做一些調(diào)優(yōu)，就像 用序列化的方法RDDs 中所說的方法來減少內(nèi)存使用。這篇指南將主要涉及兩個話題：數(shù)據(jù)序列化，這個對于網(wǎng)絡(luò)性能來說是關(guān)鍵，同時也能減少內(nèi)存使用。另外一個是內(nèi)存調(diào)優(yōu)。同時我們還會涉及一些小的話題。數(shù)據(jù)序列化在所有的分布式應(yīng)用中，序列化對性能。那些序列化速度慢或者占用大量內(nèi)存的格式會明顯拖慢計算速度。這通常是你對Spark 應(yīng)用優(yōu)化的第一步。Spark 致力于在便捷性（你操作任意的Java 類型）與性能之間取得平衡。所以提供兩個序列化的類庫： Java 序列化: Spark 默認(rèn)的對象序列化方法

13、是Java 原生的ObjectOutputStream 框架，你定義的任何類只要實(shí)現(xiàn)了 java.io.Serializable 的接口都可以正常的使用。 你也可以通過繼承 java.io.Externalizable 類來獲得更好的序列化性能。Java 原生序列化方法雖然很方便，但是通常很慢。這導(dǎo)致許多類的序列化格式很大。 Kryo 序列化: Spark 也可以使用Kryo 的序列化庫(版本號 2)以進(jìn)行更快的序列化。Kryo 比Java 原生序列化方法更為高效（可達(dá) 10 倍），但是并不支持所有實(shí)現(xiàn)了 Serializable接口的類型，為了獲得最好的效果，需要將要使用那些類后再使用。在任

14、務(wù)初始化的時候，可以通過SparkConf 調(diào)用conf.set(spark.serializer,6 / 13TEL: 4006-998-758Spark文檔翻譯Bagel 編程指南(v1.2.0)Life is short, you need spark!org.apache.spark.serializer.KryoSerializer)來設(shè)置使用 Kryo。這個設(shè)置會影響工作節(jié)點(diǎn)之間混洗（shuffling）的數(shù)據(jù)和將 RDDs 序列化到磁盤。需要用戶是不把Kryo 作為默認(rèn)的序列化方法的唯一，但是我們還是推薦你在任何網(wǎng)絡(luò)要求較高的應(yīng)用中試用一下。Spark 會在很多常用的中自動包含

15、Kryo 序列化方法。Scala 類（均在chill 庫中的AllScalaRegistrar 中）使用registerKryoClasses 方法在 Kryo你的類Kryo 文檔中講述了的高級選項，例如增加自定義序列化代碼。如果你的對象很大，你可以增加spark.kryoserializer.buffer.mb 配置選項。默認(rèn)值為2，但是這個值要足夠大來保存你要序列化的最大的那個對象。當(dāng)然，如果你不你自定義的類，Kryo 仍然正常工作，但是他會在每一個對象中保存類的全名，相當(dāng)浪費(fèi)空間。內(nèi)存調(diào)優(yōu)內(nèi)存使用的調(diào)優(yōu)有如下三個注意事項： 對象占用內(nèi)存的大小(你可能會使整個數(shù)據(jù)匹配對象的效率，以及回收的

16、額外空間 （如果頻繁生成對象）。內(nèi)存空間),默認(rèn)情況下，Java 對象的速度很快，但是比數(shù)據(jù)本身會多消耗超過 2-5 倍的空間。這是由于如下幾個造成的： 每一個不同的 Java 對象一個“對象頭（object header）”，大概占用 16 個字節(jié)，包含一些如這個類的指針等信息。對于那些幾乎不占空間的數(shù)據(jù)（比如Int）來說，這比數(shù)據(jù)本身還要大。 Java String 類型除了原始字符串?dāng)?shù)據(jù)大概還需要 40 個字節(jié)的額外空間（數(shù)據(jù)保存在 Char 數(shù)組中，同時要保存數(shù)組的長度信息等），同時每一個字符需要兩字節(jié)的空間，因?yàn)镾tring 類在UTF-16 編碼。因此，一個 10 字符的字符串至少

17、占用 60 個字節(jié)。 還有一些像 HashMap 和LinkedList 這樣常見的集合類。使用列表型的數(shù)據(jù)結(jié)構(gòu)，還有一些對象的封裝來每一個元素。（例如Map.Entry）。這個對象不僅僅是一個對象頭，還包含指向下一個元素的指針（通常每個元素需要 8 個字節(jié)）。 對基本類型的集合通常需要“裝箱”，例如java.lang.Integer.7 / 13翻譯者：Spark文檔翻譯團(tuán)成員Spark 亞太val conf = new SparkConf().setMaster(.).setAppName(.) conf.registerKryoClasses(Seq(classOfMyClass1, c

18、lassOfMyClass2)val sc = new SparkContext(conf)Spark文檔翻譯Bagel 編程指南(v1.2.0)Life is short, you need spark!這一章節(jié)將會討論如何確定你的對象所需的內(nèi)存，以及如何優(yōu)化他。可以通過改變數(shù)據(jù)結(jié)構(gòu)的方法，或者將數(shù)據(jù)以有序的方式排列。我們還會涉及 Spark 的緩存大小的調(diào)優(yōu)和Java的回收。確定內(nèi)存的消耗衡量數(shù)據(jù)所需內(nèi)存大小最好的方法是生成一個RDD 并緩存，然后通過SparkContext 的日志可以看到每一個分區(qū)的內(nèi)存消耗。這樣可以合計得到RDD 的總大小。將會看到如下信息：這表示RDD 0 的分區(qū)

19、1 占消耗了 717.5 KB 內(nèi)存。數(shù)據(jù)結(jié)構(gòu)調(diào)優(yōu)第一個減少內(nèi)存消耗的方法是避免使用一些 Java 會增加額外開銷的特性，比如基于指針的數(shù)據(jù)結(jié)構(gòu)和對象的封裝。有下面幾種方法可以使用：1. 設(shè)計數(shù)據(jù)結(jié)構(gòu)的時候盡量使用數(shù)組和基本元素，避免使用 Java 或者Scala 的集合類（例如HashMap）。 fastutil 庫為基本類型提供一些高效的集合類于 Java 標(biāo)準(zhǔn)類庫兼容。2.3.4.盡可能避免使用包含大量小對象和指針的嵌套數(shù)據(jù)結(jié)構(gòu)。考慮使用數(shù)字型的ID 或者枚舉類型代替字符串類型作為鍵。如果你的內(nèi)存不到 32GB，可以設(shè)置 JVM 的參數(shù)-XX:+UseCompressedOops 將指針

20、大小從 8 字節(jié)改為 4 字節(jié)。你可以將這個選項寫入 spark-env.sh.序列化RDD如果經(jīng)過優(yōu)化后對象仍然過大不能有效的話，一個更簡單的減少內(nèi)存占用的方法是將他們保存為序列化的形式，可以使用序列化的詳細(xì)參見RDD 持久化 API。級別，例如MEMORY_ONLY_SER，回收調(diào)優(yōu)如果你的程序頻繁“折騰”RDD 們的話，JVM 的回收會成為一個問題（通常如果對RDD 只一次再做多次操作的話這并不是個問題）。當(dāng) Java 需要為新對象來清不需要的那些。這里主要的問題是回除舊對象的時候，會跟蹤所有的Java 對象來收的代價與 Java 對象的數(shù)量是成正比的，所以使用含有較少對象的數(shù)據(jù)結(jié)構(gòu)（例

21、如用Int的數(shù)組代替LinkedList）會很大程度減小這個開銷。一個更好的方法是將對象用序列化的形8 / 13TEL: 4006-998-758INFO BlockManagerMasterActor: Added rdd_0_1 in memory on mbk.local:50311 (size: 717.5 KB, free: 332.3 MB)Spark文檔翻譯Bagel 編程指南(v1.2.0)Life is short, you need spark!式持久化，像前面提到的那樣，這樣在RDD 的每個分區(qū)中就只有一個對象（一個字節(jié)數(shù)組）。如果回收是一個問題的話可以先考慮使用緩存序列

22、化中提到的方法。回收的問題還可能存在于任務(wù)工作用的內(nèi)存（執(zhí)行任務(wù)所需要的空間）與節(jié)點(diǎn)上緩存的RDD 之間的。我們會討論如何RDD 緩存大小來緩解這個問題。估計回收的影響對于回收的調(diào)優(yōu)，第一步要對回收發(fā)生的頻率以及消耗的時間進(jìn)行統(tǒng)計。可以etails -XX:+PrintGCTimeStamps 到 Java 環(huán)境變通過增加-verbose:gc -XX:+Print量來實(shí)現(xiàn)。在后面的 Spark 任務(wù)運(yùn)行時，就可以在 worker 的日志中看到每次回收發(fā)生的相關(guān)信息。注意這些日志會在集群中的工作節(jié)點(diǎn)上看到（在目錄中的 stdout 文件中），而不是你的driver 程序。緩存大小調(diào)優(yōu)對于回收一

23、個重要的參數(shù)是用于緩存RDD 的內(nèi)存大小。Spark 默認(rèn)使用executor60%的內(nèi)存(spark.executor.memory)來緩存 RDD。也就是說 40%的內(nèi)存可以用于任務(wù)執(zhí)行中的對象創(chuàng)建。當(dāng)你任務(wù)變慢的時候，如果發(fā)現(xiàn) JVM 頻繁進(jìn)行回收或者把內(nèi)存被用盡，那么可以調(diào)低這個值以減少內(nèi)存消耗。如果要調(diào)整為 50%，你可以在 SparkConf 中設(shè)置 conf.set(spark.storage.memoryFraction, 0.5) 。通過與緩存的序列化結(jié)合，使用較小的緩存可以有效緩解大部分回收相關(guān)的問題。如果你對Java回收的調(diào)優(yōu)還有的話，可以繼續(xù)看看下面的內(nèi)容。回收調(diào)優(yōu)進(jìn)階

24、為了更深入的優(yōu)化回收，我們首先要對 JVM 的內(nèi)存管理有一些概念： Java 堆空間被分為和老年代兩個區(qū)域。表示保存存活期比較短的對象，而老年代用于存活期比較長的對象。又進(jìn)一步分為三個區(qū)域 Eden, Survivor1, Survivor2。 簡單描述一下回收的過程：當(dāng) Eden 區(qū)，會在 Eden 區(qū)發(fā)生一次 minor GC,到Survivor2 區(qū)。Survivor 區(qū)域被交同時Eden 區(qū)域Survivor1 區(qū)仍然存活的對象會被換。如果對象生命力足夠長或者 Survivor2 區(qū)域滿了，就會被轉(zhuǎn)移到老年代。如果老年代區(qū)域滿了，會一次full GC。9 / 13翻譯者：Spark文檔

25、翻譯團(tuán)成員Spark 亞太Spark文檔翻譯Bagel 編程指南(v1.2.0)Life is short, you need spark!那Spark 在GC 調(diào)優(yōu)的目標(biāo)就是確保只有長生命力的RDD 保存在老生代，同時有足夠空間來短生命力的對象。這樣可以避免任務(wù)執(zhí)行過程中回收臨時對象引起的 fullGC。下面這些步驟會有所幫助： 通過GC 的統(tǒng)計確定是否有過多的說明執(zhí)行任務(wù)的內(nèi)存不足。回收。如果任務(wù)完成之前有多次 full GC ， 如果GC 的統(tǒng)計表示老年代接近滿的話，減少緩存的內(nèi)存占用。可以通過設(shè)置spark.storage.memoryFraction。少緩存一些對象總比減慢任務(wù)的執(zhí)行

26、要好! 如果 minor GC 發(fā)生的次數(shù)過多但是 major GC 并不多的話，那最好給Eden 區(qū)分配內(nèi)存。你可以估計每一個任務(wù)需要多少內(nèi)存來設(shè)置 Eden 區(qū)的大小。如果 Eden 區(qū)大小為E，那么可以通過選項 -Xmn=4/3*E 來設(shè)置Survivor 區(qū)也要占用空間。) 舉個例子，如果你的任務(wù)需要從 HDFS 上的大小。（擴(kuò)到 4/3 倍是考慮到數(shù)據(jù)，那么可以通過從HDFS 上數(shù)據(jù)塊的大小來估計任務(wù)需要使用的內(nèi)存。需要注意解壓后的塊大小可能是原始塊大小的 2、3 倍。如果你希望有 3、4 個任務(wù)進(jìn)行工作，并且HDFS 數(shù)據(jù)塊大小為 64MB，那么我們可以估計Eden 區(qū)的大小為 4

27、*3*64MB。 使用新設(shè)置后注意觀察回收的頻率和次數(shù)的變化。我們的實(shí)驗(yàn)表明GC 調(diào)優(yōu)的效果約定于應(yīng)用本身和可用的內(nèi)存大小。可以參見的調(diào)優(yōu)選項所描述的。 從更面來說，管理 full GC 的發(fā)生頻率可以減少額外開銷。其他需要考慮的地方并行度將每一個操作并行度設(shè)置的足夠高才能充分利用集群的。Spark 根據(jù)每個文件的大小自動設(shè)置“map”任務(wù)的個數(shù)。（你也可以通過參數(shù) SparkContext.textFile 等方法來控制），對于分布式的“reduce”操作，例如 groupByKey 和reduceByKey 會使用那些父RDD 的最大分區(qū)數(shù)。你可以將并行度通過第二個參數(shù)傳入（參見the s

28、park.PairRDDFunctions 的文檔），或者通過設(shè)置 spark.default.parallelism 改變默認(rèn)值。通常情況下，我們推薦你的集群中每個 CPU 核執(zhí)行 2-3 個任務(wù)。Reduce 任務(wù)的內(nèi)存使用有時候出現(xiàn)OutOfMemory 錯誤的時候并不是因?yàn)镽DD 的內(nèi)存不足，而是任務(wù)中的一個引起內(nèi)存不足。比如groupByKey 中的一個reduce 任務(wù)過大。Spark 的 shuflle 操作（sortByKey，groupByKey，reduceByKey，join，等）會在每一個聚合任務(wù)中建立一個hash 表，通常會很大。最簡單解決這個問題的方法是 增加并行度

29、這樣可以使每一個任務(wù)的10 / 13TEL: 4006-998-758Spark文檔翻譯Bagel 編程指南(v1.2.0)Life is short, you need spark!輸入的集合變小。Spark 在200ms 高效的支持任務(wù)，因?yàn)樵S多任務(wù)都可以重用一個executorJVM，啟動一個任務(wù)的開銷很小。所以你可以安全的提高并行度到比集群 cpu的數(shù)量。數(shù)廣播（Broadcasting）較大的變量使用SparkContext 中的廣播 可以極大減小每個序列化任務(wù)的大小以及在集群中啟動一個job 的代價。如果你的任務(wù)中使用了來自driver program 的大型對象，（比如一個靜態(tài)的

30、查找表），那就可以考慮將這個變量進(jìn)行廣播。Spark 打印了 master 上每一個任務(wù)的序列化大小，你可以通過這個來確定你的任務(wù)是不是過大了。通常任務(wù)比 20KB 大的話就值得進(jìn)行優(yōu)化了。數(shù)據(jù)分布數(shù)據(jù)分布對 Spark 任務(wù)的性能有顯著影響。如果數(shù)據(jù)和操作的代碼在一起的話那計算將會很快，但是如果數(shù)據(jù)和代碼是分離的，那其中一個必須移動到另外一方。通常來說傳輸 序列化過的代碼肯定比傳輸數(shù)據(jù)要快得多，畢竟代碼比數(shù)據(jù)小太多了。Spark 就是基于此原則建立數(shù)據(jù)分布的調(diào)度策略。數(shù)據(jù)分布是指數(shù)據(jù)與處理它的代碼有多遠(yuǎn)。根據(jù)數(shù)據(jù)當(dāng)前的位置用幾個級別來確定，從最近到最遠(yuǎn)的距離為： PROCESS_LOCAL

31、數(shù)據(jù)和運(yùn)行代碼在同一個 JVM 中，這是最好的分布情況 than PROCESS_LOCAL because the data has to travel between processes NODE_LOCAL 數(shù)據(jù)在同一個節(jié)點(diǎn)。例如可能在HDFS 的同一個節(jié)點(diǎn)或者一個節(jié)點(diǎn)中的其他executor。這會比PROCESS_LOCAL 慢一點(diǎn)，因?yàn)閿?shù)據(jù)要在進(jìn)程間交換。 NO_PREF 數(shù)據(jù)從各處都差不多快，沒有位置偏好 RACK_LOCAL 數(shù)據(jù)在同樣一個機(jī)架的服務(wù)器上。數(shù)據(jù)在不同的服務(wù)器上但是在同一個機(jī)架，所以需要通過網(wǎng)絡(luò)傳輸，通常經(jīng)過一個交換機(jī)。 ANY 數(shù)據(jù)可能在網(wǎng)絡(luò)的任何地方并且不再一個機(jī)架上Spark 傾向于將所有的任務(wù)都安排在最佳的位置，但不可能總是這樣。當(dāng)任意空閑節(jié)點(diǎn)上有未處理的數(shù)據(jù)的時候，Spark 會轉(zhuǎn)換較低的位置級別。這里有兩個選擇：1）等待繁忙的 CPU 空閑后啟動一個數(shù)據(jù)相同服務(wù)器上的任務(wù)，或者 2）立刻啟動一個任務(wù)但是需要從獲取數(shù)據(jù)。Spark 通常會稍等一下來期望繁忙的 CPU 可以。一旦超時，他把數(shù)據(jù)移動到的空閑 CPU。各個級別間等待超時的回退時間可以分別配置或者統(tǒng)一配置。詳情參見11 / 13翻譯者：Spar