講義參考調(diào)優(yōu)v120

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)勢(shì)，發(fā)展迅速，將成為替代 Hadoop 的下一代云計(jì)算、大數(shù)據(jù)技術(shù)。Spark 是大數(shù)據(jù)領(lǐng)域最活躍最熱門的高效大數(shù)據(jù)通用計(jì)算平臺(tái)，基于 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ù)平臺(tái)都無可匹敵的優(yōu)勢(shì)。任何大數(shù)在實(shí)際的生產(chǎn)環(huán)境中，世界上已經(jīng)出現(xiàn)很多一千個(gè)以上節(jié)點(diǎn)的 Spark 集群，以 eBay為例，eBay 的 Spark 集群節(jié)點(diǎn)已經(jīng)超過 2000 個(gè)，Yahoo！等公司也在大規(guī)模的使用Spark，國內(nèi)的淘寶、騰訊、網(wǎng)易、京

3、東、大眾點(diǎn)評(píng)、優(yōu)酷土豆等也在生產(chǎn)環(huán)境下深度使用 Spark。2014 Spark Summit 上的信息，Spark 已經(jīng)獲得世界 20 家頂級(jí)公司的支持，這些公司中包括 Intel、IBM 等，同時(shí)更重要的是包括了最大的四個(gè)Hadoop商，都提供了對(duì) Spark 非常強(qiáng)的支持。與 Spark 火爆程度形成鮮明對(duì)比的是 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ù)時(shí)代 100 期公益大講堂”，來推動(dòng) Spark 技術(shù)在國內(nèi)的普及及落地。具體信息請(qǐng)參考與此同時(shí)，為了向 Spark 學(xué)習(xí)者提供更為豐富的學(xué)習(xí)資料，Spark 亞太去年8 月發(fā)起并號(hào)召，結(jié)合網(wǎng)絡(luò)社區(qū)的力量構(gòu)建了 Spark 中文文檔翻譯團(tuán)隊(duì)，翻譯了Spark 中文文檔 V1.1.0 版本。2014 年 12 月，Spark 本，為了讓學(xué)習(xí)者了解到最新的內(nèi)容，Spark 中文文檔版本進(jìn)行了部分更新，在此，我謹(jǐn)代表 Spark 亞太團(tuán)隊(duì)發(fā)布了 Spark 1.2.0 版翻譯團(tuán)隊(duì)又對(duì) Spark 1.2.0及廣大 Spark 學(xué)習(xí)者向翻譯團(tuán)隊(duì)所有成員熱情而專業(yè)的工作致以深刻的敬意！當(dāng)然，作為相

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

6、版本翻譯的團(tuán)隊(duì)成員，他們分別是（排名不分先后）：, 快速開始(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í)時(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 亞太院長(zhǎng)2015 年 2 月3 / 13翻譯者：Spark文檔翻譯團(tuán)成員Spark 亞太Spark文檔翻譯Bagel 編程指南(v1.2.0)Life is short, you need spark!Spark 亞太決勝大數(shù)據(jù)100 期公益大講堂簡(jiǎn)介作為下一代云計(jì)算的技術(shù)，Spark 性能超 Hadoop 百倍，算法實(shí)現(xiàn)僅有其 1/10或 1/100,是可以Hadoop 的目前唯一替代者，能夠做 Hadoop 做的一切事情，同時(shí)速度比Hadoop 快了 1

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

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

10、，每周四晚 20:00-21:30，與大家不見不散！將就Spark 內(nèi)核剖析、源碼解讀、性能優(yōu)化及商業(yè)實(shí)戰(zhàn)案例等貨不容錯(cuò)過！內(nèi)容與大家，干時(shí)間：從 7 月份起，每周一期，每周四晚 20:00-21:30形式：騰訊課堂學(xué)習(xí)條件：對(duì)云計(jì)算大數(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 的計(jì)算大多數(shù)是在內(nèi)存中進(jìn)行的，所以集群中的 CPU、網(wǎng)絡(luò)帶寬、內(nèi)存等任何都可能成為Sp

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

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

14、務(wù)初始化的時(shí)候，可以通過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。這個(gè)設(shè)置會(huì)影響工作節(jié)點(diǎn)之間混洗（shuffling）的數(shù)據(jù)和將 RDDs 序列化到磁盤。需要用戶是不把Kryo 作為默認(rèn)的序列化方法的唯一，但是我們還是推薦你在任何網(wǎng)絡(luò)要求較高的應(yīng)用中試用一下。Spark 會(huì)在很多常用的中自動(dòng)包含

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

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

17、占用 60 個(gè)字節(jié)。 還有一些像 HashMap 和LinkedList 這樣常見的集合類。使用列表型的數(shù)據(jù)結(jié)構(gòu)，還有一些對(duì)象的封裝來每一個(gè)元素。（例如Map.Entry）。這個(gè)對(duì)象不僅僅是一個(gè)對(duì)象頭，還包含指向下一個(gè)元素的指針（通常每個(gè)元素需要 8 個(gè)字節(jié)）。 對(duì)基本類型的集合通常需要“裝箱”，例如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é)將會(huì)討論如何確定你的對(duì)象所需的內(nèi)存，以及如何優(yōu)化他?？梢酝ㄟ^改變數(shù)據(jù)結(jié)構(gòu)的方法，或者將數(shù)據(jù)以有序的方式排列。我們還會(huì)涉及 Spark 的緩存大小的調(diào)優(yōu)和Java的回收。確定內(nèi)存的消耗衡量數(shù)據(jù)所需內(nèi)存大小最好的方法是生成一個(gè)RDD 并緩存，然后通過SparkContext 的日志可以看到每一個(gè)分區(qū)的內(nèi)存消耗。這樣可以合計(jì)得到RDD 的總大小。將會(huì)看到如下信息：這表示RDD 0 的分區(qū)

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

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

21、如用Int的數(shù)組代替LinkedList）會(huì)很大程度減小這個(gè)開銷。一個(gè)更好的方法是將對(duì)象用序列化的形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 的每個(gè)分區(qū)中就只有一個(gè)對(duì)象（一個(gè)字節(jié)數(shù)組）。如果回收是一個(gè)問題的話可以先考慮使用緩存序列

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

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

24、為了更深入的優(yōu)化回收，我們首先要對(duì) JVM 的內(nèi)存管理有一些概念： Java 堆空間被分為和老年代兩個(gè)區(qū)域。表示保存存活期比較短的對(duì)象，而老年代用于存活期比較長(zhǎng)的對(duì)象。又進(jìn)一步分為三個(gè)區(qū)域 Eden, Survivor1, Survivor2。 簡(jiǎn)單描述一下回收的過程：當(dāng) Eden 區(qū)，會(huì)在 Eden 區(qū)發(fā)生一次 minor GC,到Survivor2 區(qū)。Survivor 區(qū)域被交同時(shí)Eden 區(qū)域Survivor1 區(qū)仍然存活的對(duì)象會(huì)被換。如果對(duì)象生命力足夠長(zhǎng)或者 Survivor2 區(qū)域滿了，就會(huì)被轉(zhuǎn)移到老年代。如果老年代區(qū)域滿了，會(huì)一次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)就是確保只有長(zhǎng)生命力的RDD 保存在老生代，同時(shí)有足夠空間來短生命力的對(duì)象。這樣可以避免任務(wù)執(zhí)行過程中回收臨時(shí)對(duì)象引起的 fullGC。下面這些步驟會(huì)有所幫助： 通過GC 的統(tǒng)計(jì)確定是否有過多的說明執(zhí)行任務(wù)的內(nèi)存不足。回收。如果任務(wù)完成之前有多次 full GC ， 如果GC 的統(tǒng)計(jì)表示老年代接近滿的話，減少緩存的內(nèi)存占用?？梢酝ㄟ^設(shè)置spark.storage.memoryFraction。少緩存一些對(duì)象總比減慢任務(wù)的執(zhí)行

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

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

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

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

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

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