對於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和網絡。
本文主要參譯於官網，筆者在此基礎上做了一些解釋說明，利於大家理解。
關注微信公眾號：大數據學習與分享，獲取更對技術干貨