0型酥、背景
上周四接到反饋，集群部分 spark 任務(wù)執(zhí)行很慢查乒，且經(jīng)常出錯(cuò)弥喉，參數(shù)改來(lái)改去怎么都無(wú)法優(yōu)化其性能和解決頻繁隨機(jī)報(bào)錯(cuò)的問(wèn)題。
看了下任務(wù)的歷史運(yùn)行情況玛迄，平均時(shí)間 3h 左右由境，而且極其不穩(wěn)定，偶爾還會(huì)報(bào)錯(cuò)：
1憔晒、優(yōu)化思路
任務(wù)的運(yùn)行時(shí)間跟什么有關(guān)藻肄？
（1）數(shù)據(jù)源大小差異
在有限的計(jì)算下，job的運(yùn)行時(shí)長(zhǎng)和數(shù)據(jù)量大小正相關(guān)拒担，在本例中嘹屯，數(shù)據(jù)量大小基本穩(wěn)定，可以排除是日志量級(jí)波動(dòng)導(dǎo)致的問(wèn)題：
（2）代碼本身邏輯缺陷
比如代碼里重復(fù)創(chuàng)建从撼、初始化變量州弟、環(huán)境、RDD資源等低零，隨意持久化數(shù)據(jù)等婆翔，大量使用 shuffle 算子等，比如reduceByKey掏婶、join等算子啃奴。
在這份100行的代碼里，一共有 3 次 shuffle 操作雄妥，任務(wù)被 spark driver 切分成了 4 個(gè) stage 串行執(zhí)行最蕾，代碼位置如下：
咱們需要做的就是從算法和業(yè)務(wù)角度盡可能減少 shuffle 和 stage，提升并行計(jì)算性能老厌，這塊是個(gè)大的話題瘟则，本次不展開(kāi)詳述。
（3）參數(shù)設(shè)置不合理
這塊技巧相對(duì)通用枝秤，咱們來(lái)看看之前的核心參數(shù)設(shè)置：
num-executors=10 || 20 醋拧，executor-cores=1 || 2， executor-memory= 10 || 20，driver-memory=20丹壕，spark.default.parallelism=64
假設(shè)咱們的 spark 隊(duì)列資源情況如下：
memory=1T庆械，cores=400
參數(shù)怎么設(shè)置在這里就有些技巧了，首先得明白 spark 資源的分配和使用原理：
在默認(rèn)的非動(dòng)態(tài)資源分配場(chǎng)景下雀费， spark 是預(yù)申請(qǐng)資源干奢，任務(wù)還沒(méi)起跑就獨(dú)占資源，一直到整個(gè) job 所有 task 結(jié)束盏袄，比如你跳板機(jī)起了一個(gè) spark-shell 一直沒(méi)退出辕羽，也沒(méi)執(zhí)行任務(wù)，那也會(huì)一直占有所有申請(qǐng)的資源。（如果設(shè)置了 num-executors件缸，動(dòng)態(tài)資源分配會(huì)失效）
注意上面這句話已艰，spark 的資源使用分配方式和 mapreduce/hive 是有很大差別的哩掺，如果不理解這個(gè)問(wèn)題就會(huì)在參數(shù)設(shè)置上引發(fā)其它問(wèn)題。
比如 executor-cores 設(shè)多少合適？少了任務(wù)并行度不行，多了會(huì)把整個(gè)隊(duì)列資源獨(dú)占耗光绽昏，其他同學(xué)的任務(wù)都無(wú)法執(zhí)行爷贫，比如上面那個(gè)任務(wù)，在 num-executors=20 executor-cores=1 executor-memory= 10 的情況下，會(huì)獨(dú)占20個(gè)cores未巫，200G內(nèi)存箫津，一直持續(xù)3個(gè)小時(shí)。
那針對(duì)本case中的任務(wù)师抄，結(jié)合咱們現(xiàn)有的資源，如何設(shè)置這 5 個(gè)核心參數(shù)呢教硫？
1） executor_coresnum_executors 不宜太小或太大叨吮！一般不超過(guò)總隊(duì)列 cores 的 25%，比如隊(duì)列總 cores 400瞬矩，最大不要超過(guò)100茶鉴，最小不建議低于 40，除非日志量很小景用。
2） executor_cores 不宜為1涵叮！否則 work 進(jìn)程中線程數(shù)過(guò)少，一般 2~4 為宜。
3） executor_memory 一般 6~10g 為宜割粮，最大不超過(guò) 20G盾碗，否則會(huì)導(dǎo)致 GC 代價(jià)過(guò)高，或資源浪費(fèi)嚴(yán)重舀瓢。
4） spark_parallelism 一般為 executor_coresnum_executors 的 1~4 倍廷雅，系統(tǒng)默認(rèn)值 64，不設(shè)置的話會(huì)導(dǎo)致 task 很多的時(shí)候被分批串行執(zhí)行京髓，或大量 cores 空閑航缀，資源浪費(fèi)嚴(yán)重。
5） driver-memory 早前有同學(xué)設(shè)置 20G朵锣，其實(shí) driver 不做任何計(jì)算和存儲(chǔ)谬盐，只是下發(fā)任務(wù)與yarn資源管理器和task交互，除非你是 spark-shell诚些，否則一般 1-2g 就夠了飞傀。
Spark Memory Manager：
6）spark.shuffle.memoryFraction(默認(rèn) 0.2) ，也叫 ExecutionMemory诬烹。這片內(nèi)存區(qū)域是為了解決 shuffles,joins, sorts and aggregations 過(guò)程中為了避免頻繁IO需要的buffer砸烦。如果你的程序有大量這類操作可以適當(dāng)調(diào)高。
7）spark.storage.memoryFraction(默認(rèn)0.6)绞吁，也叫 StorageMemory幢痘。這片內(nèi)存區(qū)域是為了解決 block cache(就是你顯示調(diào)用dd.cache, rdd.persist等方法), 還有就是broadcasts,以及task results的存儲(chǔ)〖移疲可以通過(guò)參數(shù)颜说，如果你大量調(diào)用了持久化操作或廣播變量，那可以適當(dāng)調(diào)高它汰聋。
8）OtherMemory门粪，給系統(tǒng)預(yù)留的，因?yàn)槌绦虮旧磉\(yùn)行也是需要內(nèi)存的烹困， (默認(rèn)為0.2)玄妈。Other memory在1.6也做了調(diào)整，保證至少有300m可用髓梅。你也可以手動(dòng)設(shè)置 spark.testing.reservedMemory . 然后把實(shí)際可用內(nèi)存減去這個(gè)reservedMemory得到 usableMemory拟蜻。 ExecutionMemory 和 StorageMemory 會(huì)共享usableMemory * 0.75的內(nèi)存。0.75可以通過(guò) 新參數(shù) spark.memory.fraction 設(shè)置枯饿。目前spark.memory.storageFraction 默認(rèn)值是0.5,所以ExecutionMemory酝锅，StorageMemory默認(rèn)情況是均分上面提到的可用內(nèi)存的。
例如奢方，如果需要加載大的字典文件搔扁，可以增大executor中 StorageMemory 的大小擒权，這樣就可以避免全局字典換入換出，減少GC阁谆，在這種情況下，我們相當(dāng)于用內(nèi)存資源來(lái)?yè)Q取了執(zhí)行效率愉老。
最終優(yōu)化后的參數(shù)如下：
效果如下：
（4）通過(guò)執(zhí)行日志分析性能瓶頸
最后的任務(wù)還需要一個(gè)小時(shí)场绿，那這一個(gè)小時(shí)究竟耗在哪了？按我的經(jīng)驗(yàn)和理解嫉入，一般單天的數(shù)據(jù)如果不是太大焰盗，不涉及復(fù)雜迭代計(jì)算，不應(yīng)該超過(guò)半小時(shí)才對(duì)咒林。
由于集群的 Spark History Server 還沒(méi)安裝調(diào)試好熬拒，沒(méi)法通過(guò) spark web UI 查看歷史任務(wù)的可視化執(zhí)行細(xì)節(jié)，所以我寫(xiě)了個(gè)小腳本分析了下前后具體的計(jì)算耗時(shí)信息垫竞，可以一目了然的看到是哪個(gè) stage 的問(wèn)題澎粟，有針對(duì)性的優(yōu)化。
可以看到優(yōu)化后的瓶頸主要在最后寫(xiě) redis 的階段欢瞪，要把 60G 的數(shù)據(jù)活烙，25億條結(jié)果寫(xiě)入 redis，這對(duì) redis 來(lái)說(shuō)是個(gè)挑戰(zhàn)遣鼓，這個(gè)就只能從寫(xiě)入數(shù)據(jù)量和 kv 數(shù)據(jù)庫(kù)選型兩個(gè)角度來(lái)優(yōu)化了啸盏。
（5）其它優(yōu)化角度
當(dāng)然，優(yōu)化和高性能是個(gè)很泛骑祟、很有挑戰(zhàn)的話題回懦，除了前面提到的代碼、參數(shù)層面次企，還有怎樣防止或減少數(shù)據(jù)傾斜等怯晕，這都需要針對(duì)具體的場(chǎng)景和日志來(lái)分析，此處也不展開(kāi)抒巢。
2贫贝、spark 初學(xué)者的一些誤區(qū)
對(duì)于初學(xué)者來(lái)說(shuō) spark 貌似無(wú)所不能而且高性能，甚至在某些博客蛉谜、技術(shù)人眼里 spark 取代 mapreduce稚晚、hive、storm 分分鐘的事情型诚，是大數(shù)據(jù)批處理客燕、機(jī)器學(xué)習(xí)、實(shí)時(shí)處理等領(lǐng)域的銀彈狰贯。但事實(shí)確實(shí)如此嗎也搓？
從上面這個(gè) case 可以看到赏廓，會(huì)用 spark、會(huì)調(diào) API 和能用好 spark傍妒，用的恰到好處是兩碼事幔摸，這要求咱們不僅了解其原理，還要了解業(yè)務(wù)場(chǎng)景颤练，將合適的技術(shù)方案既忆、工具和合適的業(yè)務(wù)場(chǎng)景結(jié)合——這世上本就不存在什么銀彈。嗦玖。患雇。
說(shuō)道 spark 的性能，想要它快宇挫，就得充分利用好系統(tǒng)資源苛吱，尤其是內(nèi)存和CPU：核心思想就是能用內(nèi)存 cache 就別 spill 落磁盤(pán)，CPU 能并行就別串行器瘪，數(shù)據(jù)能 local 就別 shuffle翠储。
Refer：
[1] spark 內(nèi)存管理
https://zhangyi.gitbooks.io/spark-in-action/content/chapter2/memory_management.html
[2] Spark Memory解析
https://github.com/ColZer/DigAndBuried/blob/master/spark/spark-memory-manager.md
[3] Spark1.6內(nèi)存管理模型設(shè)計(jì)稿-翻譯
http://ju.outofmemory.cn/entry/240714
[4] Spark內(nèi)存管理
http://blog.csdn.net/vegetable_bird_001/article/details/51862422
[5] Apache Spark 內(nèi)存管理詳解
https://www.ibm.com/developerworks/cn/analytics/library/ba-cn-apache-spark-memory-management/index.html
