[[196100]]

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è)大的話題，本次不展開詳述。

(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_cores*num_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_cores*num_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é)，所以我寫了個(gè)小腳本分析了下前后具體的計(jì)算耗時(shí)信息，可以一目了然的看到是哪個(gè) stage 的問(wèn)題，有針對(duì)性的優(yōu)化。

可以看到優(yōu)化后的瓶頸主要在***寫 redis 的階段，要把 60G 的數(shù)據(jù)，25億條結(jié)果寫入 redis，這對(duì) redis 來(lái)說(shuō)是個(gè)挑戰(zhàn)，這個(gè)就只能從寫入數(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)分析，此處也不展開。

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 落磁盤，CPU 能并行就別串行，數(shù)據(jù)能 local 就別 shuffle。