對於Spark開發人員來說，一個比較普遍的問題就是如何合理的配置Spark的硬體？當然如何合理的對Spark叢集進行硬體配置要視情況而定，在這裡給出以下建議：
儲存系統
在大資料領域，有一句"名言"：移動資料不如移動計算。主要因為資料量是龐大的，如果將資料從一個節點移動到另外一個節點甚至從一個區域網移動到另外一個區域網，就必然會牽涉到大量的磁碟IO和網路IO，這是非常影響效能的。而這裡的計算可以理解為封裝了你的業務處理程式碼的jar包，這個是很輕量的，相對於移動資料可有效緩解IO帶來的弊端。
因此，將Spark叢集節點儘可能部署到靠近儲存系統的節點是非常重要的，因為大多資料Spark jobs通常從外部儲存系統，如Hadoop檔案系統、HBase獲取資料。
具體可參考以下建議：
1. 以HDFS作為儲存系統為例，建議在與HDFS相同的節點上執行Spark。最簡單的方式就是將Spark的standalone叢集和Hadoop進群部署在相同節點，同時配置好Spark和Hadoop的記憶體、CPU使用以避免相互干擾。
| 在Hadoop中，一些引數（注意Hadoop新版本中下列引數可能有所變化，具體根據自己使用的版本檢視Hadoop官網）每個task的記憶體配置引數：mapred.child.java.opts，如設定為-Xmx1024m
單個節點map task數目配置引數：mapreduce.tasktracker.map.tasks.maximum 單個節點reduce task數目配置引數：mapreduce.tasktracker.reduce.tasks.maximum |
此外，你也可以將Spark和Hadoop執行在共同的叢集資源管理器上，如Yarn和Meso。
2. 如果不能滿足1中的條件，請將Spark和HDFS部署在同一區域網下的不同節點上。
3.對於低延遲資料儲存如HBase，可能優先在與儲存系統不同的節點上執行計算任務以避免干擾【計算引擎在處理任務時，比較消耗伺服器資源，可能影響低延遲儲存系統的即時響應】
本地磁碟
儘管Spark可以在記憶體中處理大量的計算，但它仍然需要使用本地磁碟來儲存不適合RAM的資料、以及在stage之間即shuffle的中間結果。建議每個節點配備4-8塊磁碟，並且這些磁碟是作為獨立的磁碟掛在節點即可，不需要做磁碟陣列。
在Linux中，使用noatime選項安裝磁碟，以減少不必要的寫操作。在Spark中，通過引數spark.local.dir可以配置多個本地磁碟目錄，多個目錄之間以逗號分開。如果Spark任務執行在hdfs上，與hdfs保持一致就好。
使用noatime選項安裝磁碟，要求當掛載檔案系統時，可以指定標準Linux安裝選項，這將停止該檔案系統上的atime更新。
磁碟掛載命令：mount -t gfs BlockDevice MountPoint -o noatime（BlockDevice：指定GFS檔案系統駐留的塊裝置；MountPoint：指定GFS檔案系統應安裝的目錄）。
示例：mount -t gfs /dev/vg00/lvol00 /gfs_dir -o noatime
記憶體
通常情況下，每臺機器的記憶體配置從8G到數百G，Spark都能良好的執行。但建議最多分配給Spark75%的記憶體，剩餘的留給作業系統和buffer cache。
當然，具體需要多少記憶體取決於你的應用。要確定你的應用使用的特定資料集需要多大記憶體，請載入部分資料集到記憶體快取起來，然後在Spark UI（http://<driver-node>:4040）的Storage介面去看它的記憶體佔用量。
注意：記憶體使用多少受到儲存級別和序列化格式的影響，可以參考http://spark.apache.org/docs/latest/tuning.html的建議。
最後，請注意，對於超過200GB的記憶體的RAM，JAVA VM執行狀態並不一直表現良好。如果你的機器記憶體超過了200GB，那麼可以在一個節點上執行多個worker。在Spark standalone模式下，可以在配置檔案conf/spark-env.sh中設定SPARK_WORKER_INSTANCES的值來設定每個節點worker的數目，通過SPARK_WORKER_CORES引數來設定每個Worker的核數。
網路
根據以往的經驗，如果資料是在記憶體中，那麼Spark應用的瓶頸往往就在網路。用10 Gigabit或者更高的網路，是使Spark應用跑的更快的最佳方式。特別是針對"distributed reduce"操作，如group-bys,reduce-bys和SQL joins，就表現的更加明顯。在任何給定的應用程式中，都可以通過Spark UI檢視Spark shuffle過程中跨網路傳輸了多少資料。
CPU cores
因為Spark線上程之間執行最小的共享CPU，因此它可以很好的擴充套件到每臺機器幾十個CPU核。建議每臺機器至少配置8-16個核心。當然，具體根據你任務的CPU負載，可能需要更多的CPU：一旦資料在記憶體中，大多數應用程式的瓶頸就在CPU和網路。
本文主要參譯於官網，筆者在此基礎上做了一些解釋說明，利於大家理解。
關注微信公眾號：大資料學習與分享，獲取更對技術乾貨