估計所有的spark開發者都很關心spark的硬件要求。恰當的硬件配置需要具體情況具體分析，在這裏給出以下建議。主要譯自官網
壹，存儲系統
因為大多數Spark工作可能需要從外部存儲系統（例如Hadoop文件系統或HBase）中讀取輸入數據，所以將spark盡可能部署到靠近存儲系統很重要。所以，有如下建議：
1，如果可能，在與HDFS相同的節點上運行Spark。最簡單的方式是將spark的Standalone集群和hadoop集群安裝在相同的節點，同時配置好Spark和hadoop的內存使用，避免相互幹擾(對於hadoop，每個task的內存配置參數是mapred.child.java.opts；mapreduce.tasktracker.map.tasks.maximum 和mapreduce.tasktracker.reduce.tasks.maximum決定了task的數目)。也可以將hadoop和spark運行在***同的集群管理器上，如mesos和 yarn。
2，如果不可能，請在與HDFS相同的局域網中的不同節點上運行Spark。
3，對於低延遲數據存儲（如HBase），可能優先在與存儲系統不同的節點上運行計算任務以避免幹擾。
二，本地磁盤
雖然Spark可以在內存中執行大量的計算，但它仍然使用本地磁盤來存儲不適合RAM的數據，以及在stage之間，也即shuffle的中間結果。建議每個節點至少有4-8塊磁盤，並且不需要RAID，僅僅是獨立的磁盤掛在節點。在Linux中，使用noatime選項安裝磁盤，以減少不必要的寫入。在spark任務中，spark.local.dir配置可以十多個磁盤目錄，以逗號分開。如果運行在hdfs上，與hdfs保持壹致就很好。
使用noatime選項安裝磁盤，要求當掛載文件系統時，可以指定標準Linux安裝選項（noatime），這將禁用該文件系統上的atime更新。磁盤掛在命令：
mount -t gfs BlockDevice MountPoint -onoatime
BlockDevice 指定GFS文件系統駐留的塊設備。
MountPoint 指定GFS文件系統應安裝的目錄。
例子：
mount -t gfs /dev/vg01/lvol0 /gfs1 -onoatime
三，內存
單臺機器內存從8GB到數百GB，spark都能運行良好。在所有情況下，建議僅為Spark分配最多75％的內存;留下其余的操作系統和緩沖區緩存。
需要多少內存取決於妳的應用程序。要確定妳的應用的特定數據集需要多大內存，請加載部分數據集到內存，然後在Spark UI的Storage界面去看它的內存占用量。
請註意，內存使用受到存儲級別和序列化格式的極大影響 - 有關如何減少內存使用的技巧，請參閱另壹篇調優的文章。
最後，請註意，對於超過200GB的內存的機器JAVA VM運行狀態並不壹直表現良好。如果買的機器內存超過了200GB，那麽可以在壹個節點上運行多個worker。Spark Standalone模式下，可以在配置文件 conf/spark-env.sh中設置SPARK_WORKER_INSTANCES的值來設置單節點worker的數目。也可以設置SPARK_WORKER_CORES參數來設置每個Worker的cpu數目。
四，網絡
根據以往的經驗，假如數據是在內存中，那麽spark的應用的瓶頸往往就在網絡。用10 Gigabit或者更高的網絡，是使spark應用跑的最更快的最佳方式。特別是針對“distributed reduce”應用，如group-bys,reduce-bys和sql joins，就表現的更加明顯。在任何給定的應用程序中，可以通過spark ui查看spark shuffle過程誇網絡傳輸了多少數據。
五， cpu
對於每臺機器幾十個cpu的機器，spark也可以很好的擴展，因為他在線程之間執行最小的***享cpu。應該每臺機器至少配置8-16個內核。根據cpu負載，可能需要更多的cpu：壹旦數據在內存中，大多數應用程序的瓶頸就在CPU和網絡。
推薦閱讀：
面試必備|spark 高層通用調優
Spark Adaptive Execution調研
Spark 的硬件配置
從MapReduce的興起，就帶來壹種思路，就是希望通過大量廉價的機器來處理以前需要耗費昂貴資源的海量數據。這種方式事實上是壹種架構的水平伸縮模式——真正的以量取勝。畢竟，以現在的硬件發展來看，CPU的核數、內存的容量以及海量存儲硬盤，都慢慢變得低廉而高效。然而，對於商業應用的海量數據挖掘或分析來看，硬件成本依舊是開發商非常關註的。當然最好的結果是：既要馬兒跑得快，還要馬兒少吃草。
\\
Spark相對於Hadoop的MapReduce而言，確乎要跑得迅捷許多。然而，Spark這種In-Memory的計算模式，是否在硬件資源尤其是內存資源的消耗上，要求更高呢？我既找不到這麽多機器，也無法租用多臺虛擬instance，再沒法測評的情況下，只要尋求Spark的官方網站，又或者通過Google搜索。從Spark官方網站，Databricks公司Patrick Wendell的演講以及Matei Zaharia的Spark論文，找到了壹些關於Spark硬件配置的支撐數據。
\\
Spark 與存儲系統
\\
如果Spark使用HDFS作為存儲系統，則可以有效地運用Spark的standalone mode cluster，讓Spark與HDFS部署在同壹臺機器上。這種模式的部署非常簡單，且讀取文件的性能更高。當然，Spark對內存的使用是有要求的，需要合理分配它與HDFS的資源。因此，需要配置Spark和HDFS的環境變量，為各自的任務分配內存和CPU資源，避免相互之間的資源爭用。
\\
若HDFS的機器足夠好，這種部署可以優先考慮。若數據處理的執行效率要求非常高，那麽還是需要采用分離的部署模式，例如部署在Hadoop YARN集群上。
\\
Spark 對磁盤的要求
\\
Spark是in memory的叠代式運算平臺，因此它對磁盤的要求不高。Spark官方推薦為每個節點配置4-8塊磁盤，且並不需要配置為RAID（即將磁盤作為單獨的mount point）。然後，通過配置spark.local.dir來指定磁盤列表。
\\
Spark 對內存的要求
\\
Spark雖然是in memory的運算平臺，但從官方資料看，似乎本身對內存的要求並不是特別苛刻。官方網站只是要求內存在8GB之上即可（Impala要求機器配置在128GB）。當然，真正要高效處理，仍然是內存越大越好。若內存超過200GB，則需要當心，因為JVM對超過200GB的內存管理存在問題，需要特別的配置。
\\
內存容量足夠大，還得真正分給了Spark才行。Spark建議需要提供至少75%的內存空間分配給Spark，至於其余的內存空間，則分配給操作系統與buffer cache。這就需要部署Spark的機器足夠幹凈。
\\
考慮內存消耗問題，倘若我們要處理的數據僅僅是進行壹次處理，用完即丟棄，就應該避免使用cache或persist，從而降低對內存的損耗。若確實需要將數據加載到內存中，而內存又不足以加載，則可以設置Storage Level。0.9版本的Spark提供了三種Storage Level：MEMORY_ONLY（這是默認值），MEMORY_AND_DISK，以及DISK_ONLY。
\\
關於數據的持久化，Spark默認是持久化到內存中。但它也提供了三種持久化RDD的存儲方式：
\\
\\t
in-memory storage as deserialized Javaobjects
\\t\\t
\\t
in-memory storage as serialised data
\\t\\t
\\t
on-disk storage
\\t\
第壹種存儲方式性能最優，第二種方式則對RDD的展現方式（Representing）提供了擴展，第三種方式則用於內存不足時。
\\
然而，在最新版（V1.0.2）的Spark中，提供了更多的Storage Level選擇。壹個值得註意的選項是OFF_HEAP，它能夠將RDD以序列化格式存儲到Tachyon中。相比MEMORY_ONLY_SER，這壹選項能夠減少執行垃圾回收，使Spark的執行器（executor）更小，並能***享內存池。Tachyon是壹個基於內存的分布式文件系統，性能遠超HDFS。Tachyon與Spark同源同宗，都烙有伯克利AMPLab的印記。目前，Tachyon的版本為0.5.0，還處於實驗階段。
\\
註意，RDDs是Lazy的，在執行Transformation操作如map、filter時，並不會提交Job，只有在執行Action操作如count、first時，才會執行Job，此時才會進行數據的加載。當然，對於壹些shuffle操作，例如reduceByKey，雖然僅是Transformation操作，但它在執行時會將壹些中間數據進行持久化，而無需顯式調用persist()函數。這是為了應對當節點出現故障時，能夠避免針對大量數據進行重計算。要計算Spark加載的Dataset大小，可以通過Spark提供的Web UI Monitoring工具來幫助分析與判斷。
\\
Spark的RDD是具有分區（partition）的，Spark並非是將整個RDD壹次性加載到內存中。Spark針對partition提供了eviction
policy，這壹Policy采用了LRU（Least Recently Used）機制。當壹個新的RDD分區需要計算時，如果沒有合適的空間存儲，就會根據LRU策略，將最少訪問的RDD分區彈出，除非這個新分區與最少訪問的分區屬於同壹個RDD。這也在壹定程度上緩和了對內存的消耗。
\\
Spark對內存的消耗主要分為三部分：
\\
1. \\t
數據集中對象的大小；
\\t\\t
2. \\t
訪問這些對象的內存消耗；
\\t\\t
3. \\t
垃圾回收GC的消耗。
\\t\
壹個通常的內存消耗計算方法是：內存消耗大小= 對象字段中原生數據 * (2~5)。這是因為Spark運行在JVM之上，操作的Java對象都有定義的“object header”，而數據結構（如Map，LinkedList）對象自身也需要占用內存空間。此外，對於存儲在數據結構中的基本類型，還需要裝箱（Boxing）。Spark也提供了壹些內存調優機制，例如執行對象的序列化，可以釋放壹部分內存空間。還可以通過為JVM設置flag來標記存放的字節數（選擇4個字節而非8個字節）。在JDK 7下，還可以做更多優化，例如對字符編碼的設置。這些配置都可以在spark-env.sh中設置。
\\
Spark 對網絡的要求
\\
Spark屬於網絡綁定型系統，因而建議使用10G及以上的網絡帶寬。
\\
Spark 對 CPU 的要求
\\
Spark可以支持壹臺機器擴展至數十個CPU
core，它實現的是線程之間最小***享。若內存足夠大，則制約運算性能的就是網絡帶寬與CPU數。
\\
Spark官方利用Amazon EC2的環境對Spark進行了基準測評。例如，在交互方式下進行數據挖掘（Interative Data Mining），租用Amazon EC2的100個實例，配置為8核、68GB的內存。對1TB的維基百科頁面查閱日誌（維基百科兩年的數據）進行數據挖掘。在查詢時，針對整個輸入數據進行全掃描，只需要耗費5-7秒的時間。如下圖所示：
在Matei Zaharia的Spark論文中還給出了壹些使用Spark的真實案例。視頻處理公司Conviva，使用Spark將數據子集加載到RDD中。報道說明，對於200GB壓縮過的數據進行查詢和聚合操作，並運行在兩臺Spark機器上，占用內存為96GB，執行完全部操作需要耗費30分鐘左右的時間。同比情況下，Hadoop需要耗費20小時。註意：之所以200GB的壓縮數據只占用96GB內存，是因為RDD的處理方式，使得我們可以只加載匹配客戶過濾的行和列，而非所有壓縮數據。`
Spark集群硬件配置推薦
計算與存儲：
大多數Spark作業可能需要從外部存儲系統（例如 ：Cassandra、Hadoop文件系統或HBase）讀取輸入數據，所以要讓Spark計算引擎盡可能靠近數據持久層。如果使用HDFS作為數據存儲集群，可以在相同的集群上部署Spark集群，並配置Spark和Hadoop的內存和CPU使用率以避免幹擾。我們的生產存儲使用的是Cassandra集群，spark
master 服務單獨部署，其它節點同時部署：Cassandra
+ spark worker，保證spark
worker 節點可以快速從本地讀取數據進行計算匯總。
磁盤：
雖然Spark可以在內存中執行大量的計算，但它仍然可能會使用本地磁盤來存儲不適用於RAM的數據，建議每個節點配置4-8個磁盤，不需要配置RAID（磁盤陣列），磁盤成本越來越低，可以考慮配置ssd硬盤，可以大幅提升性能。另外；在Linux中，使用noatime選項掛載磁盤，以減少不必要的寫入操作。 在Spark中，可以將spark.local.dir變量配置為多個本地磁盤的地址，多個地址之間以逗號分隔。
內存
建議為Spark分配的內存容量不大於機器總內存容量的75％；確保為操作系統和緩沖區留下足夠的內存。根據業務特點評估需要多少內存。請註意，當內存容量超過200GB時Java 虛擬機的性能表現會不穩定。如果您購買的RAM大於200G，則可以為每個節點運行多個worker
JVM。在Spark的standalone模式下，您可以通過conf/spark-env.sh中的SPARK_WORKER_INSTANCES變量設置每個節點運行的worker進程數，以及通過SPARK_WORKER_CORES變量設置每個worker可用的cpu核心數。
網絡
當數據已經存儲在內存中時，很多Spark應用程序的性能瓶頸在於網絡的傳輸速率。推薦最低使用10G的網絡。
CPU
Spark運行匯總計算任務比較多，推薦配置更多的cpu核數，性能提升還是比較明顯，推薦：每臺機器至少配置8-16個核。可以根據Spark作業的CPU負載情況，進行配置調整。壹旦數據已經在內存中，大多數應用程序的性能瓶頸在於CPU和網絡。
參考文檔
http://spark.apache.org/docs/latest/hardware-provisioning.html