一個企業的大數據系統通常由三層構成：底層基礎設施、大數據平臺、數據智能化應用。隨着雲計算的發展，大多數中小型企業越來越依賴雲廠商提供的服務來構建自己的大數據平臺，而不再自己維護底層基礎設施。比如，我們公司目前主要使用AWS EMR服務來構建Spark系統。EMR可以幫助我們根據需要快速建立一個Spark集羣，讓我們從底層機器的維護、集羣的部署等繁雜的工作中解放出來，更多的關注在應用層。
基於EMR構建Spark系統時，有兩個選擇：第一個，構建一個大的EMR集羣，在裏面跑多個Spark應用；第二個，一個EMR集羣只跑一個Spark應用。我們推薦儘量採用後者，這種方式可以充分利用雲的優勢，達到資源即用即啓，應用間相互隔離。在這樣的建設模式下，我們的性能調優工作主要包括以下幾點：
- 將一個集羣的資源充分分配給Spark
- 將Spark拿到的資源充分利用起來
- 優化Spark的使用方法，避免不必要的計算
本文主要探討第一點，即如何在EMR下爲Spark有效分配資源，從而榨乾一個集羣的所有可用資源。文中所述均基於AWS EMR 5.20、Spark 2.4版本。
1. 整體分析
我們先來談談在EMR中通過YARN Cluster模式來部署一個Spark集羣時，會涉及到哪些角色與概念，從而搞清楚這中間有哪些與資源相關的事情。
一個EMR集羣包含了一組AWS EC2機器，按照功能劃分爲三種角色：Master、Core、Task。Master機器負責整體的協調與管理；Core和Task機器負責具體任務的執行，區別在於Core機器上會運行HDFS程序用來存儲數據。
YARN是Hadoop的一個獨立組件，用於集羣資源管理，被廣泛應用在各種大數據計算引擎的部署中。YARN系統有兩種角色：Resource Manager（RM）、Node Manager（NM）。NM運行在每臺EMR Core/Task機器上面，負責本機的資源管理；RM運行在EMR Master機器上，負責整個集羣的資源管理。YARN在資源管理上主要考慮兩點要素：CPU和內存，表現形式是根據申請的CPU和內存數創建一個Container，然後將對應的程序跑在Container進程中。
Spark系統由兩個角色組成：Driver、Executor，Driver負責任務的調度，Executor負責具體任務的執行。在YARN Cluster模式下，Driver通常跑在第一個Container中，即Application Master中，之後會根據配置的Executor的資源大小和數量向RM申請創建相應的Container，並將Executor跑在裏面。
綜合來看，與資源分配相關的事情主要有：
- 集羣機器有多少資源
- YARN可以支配的資源有多少
- 一個YARN Container佔用多少資源
集羣機器有多少資源取決於我們選擇什麼樣的AWS EC2機器，AWS提供了不同類型、不同規格的機器。比如我們常用的M4系列機器，屬於通用型的範疇，即CPU、內存等能力均還不錯，而這個系列裏面又分xlarge、2xlarge、4xlarge等不同規格，每種規格對應了不同的CPU、內存等。
一臺機器的資源顯然不能完全被用於Spark計算，還需要預留一部分給系統、監控程序、調度程序等等。Spark是向YARN申請資源的，那麼YARN怎麼知道自己可以支配多少資源呢？主要由yarn-site.xml中的兩個參數來配置，分別指定可以被分配的CPU和內存大小：
- yarn.nodemanager.resource.cpu-vcores
- yarn.nodemanager.resource.memory-mb
一個YARN Container所佔用的資源大小主要由Spark Driver和Executor的大小來決定，這些配置在啓動Spark應用時指定，主要有下面5個。其中，前兩個用於配置Driver的大小，第三、四個配置Executor的大小，第五個配置需要多少個Executor。
- spark.driver.cores
- spark.driver.memory
- spark.executor.cores
- spark.executor.memory
- spark.executor.instances
2. EMR默認分配情況
假設我們創建了一個1+3（1個Master，3個Core機器）的Spark集羣，不做任何額外的配置，默認情況下其資源使用情況如何呢？我們結合下圖來總結一下：
- 1臺M4.xlarge機器有4個vCPU、16GB內存，3臺Core機器總共有12個vCPU、48GB內存，但是在YARN上看到的可以支配的資源是24個vCore、36GB內存，YARN的可以支配資源是如何換算與配置的？
- 根據默認的Spark配置，Spark需要的資源是9個vCore、11GB內存，但是YARN上看到的已分配掉的資源是9個vCore、12.38GB內存，多出來的1.38GB內存是做什麼用的？
- Spark使用的資源只佔用了YARN可以支配的資源的一小部分，也就說該集羣大部分資源處於閒置狀態。
這三個問題將分別在下文進行分析與闡述，進而得出最佳的資源分配方式。
3. 常見的EMR機器資源情況
作爲雲服務，AWS EMR根據每種機器的特性等因素幫助我們預設好YARN可以支配的資源，即上文提到的yarn-site.xml中的兩個參數。當然，我們也可以根據業務需要進行調整，大多數情況下我們會基於這些配置來進行資源估算，那麼搞清楚AWS EMR設置這些參數的方法與規律就很重要。我們將其歸納如下：
- 對於M4系列機器，YARN vCores = 2 * EC2 vCPUs
- 對於C4/R4系列機器，YARN vCores = EC2 vCPUs
- EMR會預留1/4的內存，最大預留8GB，最小2GB
基於此，對於3臺M4.xlarge機器，YARN總共可以支配的資源爲vCore = 3 * (2 * 4) = 24，內存 = 3 * (3/4 * 16) = 36GB，這就解釋了第2節中的第1個問題。
4. YARN Container Overhead
Spark內存模型還蠻複雜的，本文不會就此展開，主要關注的是Container Overhead。Spark的Driver和Executor是跑在YARN Container裏面的，其本身是一個JVM程序。我們在Spark中對Driver和Executor進行的配置僅僅考慮的是Spark層面的資源需求，在這之上還有YARN Container JVM本身需要一些內存。默認情況下，其大小是分配給Driver或Executor的內存的10%，最小爲384MB，可以通過下面兩個參數進行調整：
- spark.yarn.driver.memoryOverhead
- spark.yarn.executor.memoryOverhead
基於此，如果Spark需要的資源是9個vCore、11GB內存，那麼實際YARN上看到的資源使用情況應該是9個vCore、12.38GB內存，這也解釋了第2節中的第2個問題。
5. 合理分配資源的方法
有了上文的基礎，我們就可以來探討合理分配資源的方法了，其本質是如何計算第1節提到的Spark的5個參數，確保一個集羣的可用資源都被利用起來。
基本思路是先從Executor入手，然後拿掉一個Executor換成Driver即可。
對Executor進行資源分配時，首先考慮vCore因素，重點考慮兩點：
- Executor數量需要適中。過多會帶來很重的額外開銷；過小會導致容錯性差，比如一個Executor掛了會導致很多Task一起失敗。
- 所選的不同規格的機器中最小規格的vCore個數，即最小粒度問題。
通常，對於M4系列機器，我們推薦單個Executor的vCore = 4。有了這個值，就可以計算整個集羣可以承載多少個Executor了，即M = 總共的YARN vCores / 單個Executor vCores。進一步可以計算出單個Executor的內存大小，即總共的YARN vCores / 1.1 / M，這裏採用了默認的10%比例作爲Container Overhead。
完成上述計算後，我們拿出一個Executor的資源，作爲Driver的資源大小，將Executor的個數設置爲M-1即可。Driver也許用不掉那麼多資源，但是即使不用這部分資源也沒法再分配一個新的Executor了，所以這部分資源可以全部給Driver，也可以歸還部分給系統。通常情況下，Driver擁有此資源就足夠了，如果有下面的情況，可以酌情考慮增加內存。
- 有很大的數據需要回收到Driver
- 需要加載的文件的Partition很多，導致需要構建一個很大的InMemoryFileIndex
繼續以第2節中的例子爲例，參照上述計算方法，相關參數應該如下圖表所示，共使用了24個vCores，33GB內存的資源，達到了最大利用率。
本文闡述的思路與方法雖然是應用在AWS EMR下，但是可以酌情參考應用在其他場景，期望對同道中人有所幫助。
（全文完，本文地址：https://bruce.blog.csdn.net/article/details/105037575 ）
版權聲明：本人拒絕不規範轉載，所有轉載需徵得本人同意，並且不得更改文字與圖片內容。大家相互尊重，謝謝！
Bruce
2020/03/28 晚