Spark任務的core，executor，memory資源配置方法是什么

這期內容當中小編將會給大家帶來有關Spark任務的core，executor，memory資源配置方法是什么，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

執行Spark任務，資源分配是很重要的一方面。如果配置不準確，Spark任務將耗費整個集群的機緣導致其他應用程序得不到資源。

怎么去配置Spark任務的executors，cores，memory，有如下幾個因素需要考慮：

• 數據量

• 任務完成時間點

• 靜態或者動態的資源分配

• 上下游應用

Spark應用當中術語的基本定義：

• Partitions : 分區是大型分布式數據集的一小部分。 Spark使用分區來管理數據，這些分區有助于并行化數據處理，并且使executor之間的數據交換最小化

• Task：任務是一個工作單元，可以在分布式數據集的分區上運行，并在單個Excutor上執行。并行執行的單位是任務級別。單個Stage中的Tasks可以并行執行

• Executor：在一個worker節點上為應用程序創建的JVM，Executor將巡行task的數據保存在內存或者磁盤中。每個應用都有自己的一些executors，單個節點可以運行多個Executor，并且一個應用可以跨多節點。Executor始終伴隨Spark應用執行過程，并且以多線程方式運行任務。spark應用的executor個數可以通過SparkConf或者命令行 –num-executor進行配置

• Cores：CPU最基本的計算單元，一個CPU可以有一個或者多個core執行task任務，更多的core帶來更高的計算效率，Spark中，cores決定了一個executor中并行task的個數

• Cluster Manager：cluster manager負責從集群中請求資源

cluster模式執行的Spark任務包含了如下步驟：

1. driver端，SparkContext連接cluster manager（Standalone/Mesos/Yarn）

2. Cluster Manager在其他應用之間定位資源，只要executor執行并且能夠相互通信，可以使用任何Cluster Manager

3. Spark獲取集群中節點的Executor，每個應用都能夠有自己的executor處理進程

4. 發送應用程序代碼到executor中

5. SparkContext將Tasks發送到executors

以上步驟可以清晰看到executors個數和內存設置在spark中的重要作用。

以下將嘗試理解優化spark任務的最佳方式：

1. 靜態分配：配置值從spark-submit中體現

2. 動態分配：從數據量和計算需求上衡量資源需求，并在使用后釋放掉，這樣可以讓其他應用重復利用資源

靜態分配

以下按不同例子討論驗證不同參數和配置組合

例子1
硬件資源：  6 節點，每個節點16 cores, 64 GB 內存
每個節點在計算資源時候，給操作系統和Hadoop的進程預留1core，1GB，所以每個節點剩下15個core和63GB
內存。
core的個數，決定一個executor能夠并發任務的個數。所以通常認為，一個executor越多的并發任務能夠得到更好的性能，但有研究顯示一個應用并發任務超過5，導致更差的性能。所以core的個數暫設置為5個。
5個core是表明executor并發任務的能力，并不是說一個系統有多少個core，即使我們一個CPU有32個core，也設置5個core不變。
executor個數，接下來，一個executor分配 5 core,一個node有15 core，從而我們計算一個node上會有3 executor（15 / 5），然后通過每個node的executor個數得到整個任務可以分配的executors個數。
我們有6個節點，每個節點3個executor，6 ×  3 = 18個executors，額外預留1個executor給AM，最終要配置17個executors。
最后spark-submit啟動腳本中配置 –num-executors = 17
memory，配置每個executor的內存，一個node，3 executor， 63G內存可用，所以每個executor可配置內存為63 / 3 = 21G
從Spark的內存模型角度，Executor占用的內存分為兩部分：ExecutorMemory和MemoryOverhead，預留出MemoryOverhead的內存量之后，才是ExecutorMemory的內存。
MemoryOverhead的計算公式： max(384M, 0.07 × spark.executor.memory)

因此 MemoryOverhead值為0.07 × 21G  = 1.47G > 384M

最終executor的內存配置值為 21G – 1.47 ≈ 19 GB

至此， Cores = 5, Executors= 17,  Executor Memory = 19 GB

例子2
硬件資源：6 node，32 core / node ，64G RAM / node
core個數：5，與例子1中描述具體原因相同
每個node的executor個數是 32 / 5 = 6
executor總個數： 6 node × 6 executor  - 1 （AM） = 35
executor memory：
每個node的內存 = 63G（1G留給系統應用） / 6 ≈ 10
MemoryOverhead = 0.07 × 10G = 700M 約等于 1G
ExecutorMemory = 10 G - 1 G = 9 GB

最終 Cores = 5, Executors = 5, Executor Memory = 9 GB

例子3
硬件資源：  6 節點，每個節點16 cores, 64 GB 內存
例子1和2的場景，都是從固定的core數量，計算executor和memory的數量。
基于例子1，假設memory不需要19G，而僅需要10G內存就足夠數據計算，此時core, executor,memory按如下計算方式：
core個數據：5
每個node的executor個數：15 / 3 = 5
按照例子1計算方式，這個階段的內存使用21G，除去MemoryOverhead的內存占用，剩下19G。當我們10G內存就足夠的場景下，不能使用 63G / 10G = 6個executor。因為 6 exector × 5 core = 30 core，每個node要有30core，而例子1硬件配置是16core。這樣我們就需要修改每個executor的core配置。

接下來，將core的個數從5改為3，每個node有5個executor，一共應該有 5 executor * 6 node - 1（AM占用的core） = 29 ，memory則 63G / 5  ≈ 12
MemoryOverhead = 0.07 × 12G = 840M 約等于 1G
ExecutorMemory = 12 G - 1 G = 11 GB

最終 Core = 3，Executor = 29，Executor Memory = 11G

動態分配

如果采用動態分配策略，executer的個數上限是無窮大。這就意味著Spark任務在需要資源的情況下，會占用到集群左右資源，集群中會有其他應用也需要資源運行，所以我們需要在集群層面上對core進行分配控制。

這就意味著我們在基于用戶訪問基礎上，在基于YARN的任務中進行分配core，我們創建一個spark_user，分配min max的core個數，這些core從YARN中剝離，區別于其他基于YARN調度應用（例如Hadoop等）

為了理解動態資源分配，首先需要了解一些屬性配置項：

spark.dynamicAllocation.enabled ： 設置為true，意味著我們不關心executor的個數，考慮用到動態資源分配策略，在stage階段會有一下區別：

以多少個executor啟動Spark任務？

spark.dynamicAllocation.initialExecutors：初始化executor個數

怎樣動態控制executor的個數？
我們通過spark-submit的方式初始化executor個數，根據負載情況，任務在min(
spark.dynamicAllocation.minExecutors)和max(
spark.dynamicAllocation.maxExecutors)之間決定executor個數。

什么時候獲取一個新的executor和放棄一個executor
spark.dynamicAllocation.schedulerBacklogTimeout ：依靠這個參數，決定我們什么時候獲取一個新的executor，每輪任務executor個數較前一輪將逞指數增長，比如第一輪1個executor，后續添加2，4，8個executor的方式，在某些特定場景下，將使用max（spark.dynamicAllocation.maxExecutors）個executor。
spark.dynamicAllocation.executorIdleTimeout ：executor空閑的時間，超時之后，將executor移除

上述就是小編為大家分享的Spark任務的core，executor，memory資源配置方法是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。