Spark不同Cluster Manager下的資料本地性表現

一. 概述

Spark中的資料本地性分為兩種

• executor 層面的資料本地性

• task 層面的資料本地性

在兩種本地性中，task層面的資料本地性是由Spark本身決定的，而executor的分發則是Cluter Manager控制的，因此下文主要描述在不同Cluster Manager中的executor分發機制。

1. Spark Standalone
   Standalone提供了兩種executor的分發模式。
   由引數spark.deploy.spreadOut控制，預設為true，將會把executor分配到儘可能多的worker上，因此通常都能提供非常良好的資料本地性。

   如果設定為false(不建議)，會將executor優先分配到一臺機器中，能提供更高的機器使用率。

2. Spark on Yarn
   在Spark on Yarn方式下，如果啟用了Dynamic Allocation並設定spark.dynamicAllocation.initialExecutors為一個較低的值（例如0）。則在pending task申請executor時，就會判斷任務的資料本地性，並且在有資料的節點上啟動executor。

3. Spark on Mesos
   mesos會先offer給spark一個空閒的slave，spark會在上面啟動executor，直到slave佔滿，mesos會再發一個新的offer過來。這種做法類似於standalone關閉spreadOut的效果，因此會導致某些節點load非常高，而一些節點異常空閒情況。
   解決方式有2個：

   1. 修改spark原始碼解決這個問題（接收到一個offer的時候只啟動一個executor），在spark2.0的基礎上只需要改動MesosCoarseGrainedSchedulerBackend中buildMesosTasks那段程式碼即可。

   2. 配合docker,marathon解決。

修改mesos排程前:

修改mesos排程前

修改mesos排程後:

修改mesos排程後

觀察到本地性有較大的提升，執行時間縮短了25%左右。

同時離線任務執行時間波動減少，趨於穩定

這裡寫圖片描述

二. 結語

透過上述來看，目前Spark on Yarn + Dynamic Allocation的方式在executor的資料本地性上有著一定的優勢。

分散式計算的瓶頸往往出現在IO上，因此良好的資料本地效能提高程式的整體執行速度。在機器較多的叢集中，為了擁有更好的資料本地性，最簡單的一種方式就是透過啟動更多的executor來實現。

例如需要一個<4 cores, 20G RAM>的Spark Application。如果只啟動一個executor，那麼只會執行在一臺節點上，其他機器的資料則需要透過網路IO來獲取。如果啟動4個executor,每個executor使用<1 cores,5G RAM>，那麼executor將能分佈到更多的節點上，獲取更好的資料本地性。

作者：breeze_lsw
連結：