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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17、占用 60 個字節。 還有一些像 HashMap 和LinkedList 這樣常見的集合類。使用列表型的數據結構，還有一些對象的封裝來每一個元素。（例如Map.Entry）。這個對象不僅僅是一個對象頭，還包含指向下一個元素的指針（通常每個元素需要 8 個字節）。 對基本類型的集合通常需要“裝箱”，例如java.lang.Integer.7 / 13翻譯者：Spark文檔翻譯團成員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!這一章節將會討論如何確定你的對象所需的內存，以及如何優化他。可以通過改變數據結構的方法，或者將數據以有序的方式排列。我們還會涉及 Spark 的緩存大小的調優和Java的回收。確定內存的消耗衡量數據所需內存大小最好的方法是生成一個RDD 并緩存，然后通過SparkContext 的日志可以看到每一個分區的內存消耗。這樣可以合計得到RDD 的總大小。將會看到如下信息：這表示RDD 0 的分區

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

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

21、如用Int的數組代替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 的每個分區中就只有一個對象（一個字節數組）。如果回收是一個問題的話可以先考慮使用緩存序列

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

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

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

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

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

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

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

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

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

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