Spark官方推荐硬件配置
存储系统
让Spark尽可能的与HDFS运行在同一节点上，最简单的方式是使用Sparkstandalone mode部署Spark，然后分配Spark和Hadoop的内存和CPU使用，避免冲突。当然，你也可以在一些通用的集群管理器上同时运行Hadoop和Spark，如：Mesos或Hadoop YARN。
如果不能让Spark和HDFS运行在同一节点上的话，那么尽可能让它们在同一局域网内。
但是对于像HBase这样的低延迟数据存储，最好在与存储系统不同的节点上运行计算任务以避免干扰。
本地磁盘
虽然Spark能够在内存中完成大部分运算，但它依然需要本地磁盘（如：存储数据无法装载进内存、存储各个阶段输出的临时文件）。建议每个节点配4-8块磁盘，以非独立冗余磁盘阵列挂载（只需要单独挂载即可）。在Linux中，使用noatime选项挂载磁盘以减少不必要的写操作。在Spark中，可以配置spark.local.dir变量以逗号分离指定本地磁盘目录。如果该节点上也有HDFS，可以使用与HDFS相同的磁盘。
内存
通常，Spark在8GB到数百GB内存的机器上运行良好。在任何情况下，我们都建议给Spark分配至多75%的内存，剩下的部分留给操作系统和缓存。
你所需的内存大小取决于你的应用。如需确定你的应用在使用某些数据集时需要多少内存，可以先加载部分数据集然后通过Spark的监控UI（http://<driver-node>:4040）查看其占用内存大小。需要注意的是，内存占用很大程度上受存储级别和序列化格式影响——更多内存优化建议，参考调优指南。
最后，需要注意Java虚拟机在超过200GB内存的机器上并非总是表现良好。如果你购买的机器内存大于200GB，建议在单个节点上启动多个worker JVM。在Spark独立部署模式下（standalone mode），你可在conf/spark-env.sh中设置SPARK_WORKER_INSTANCES来配置单个节点上的worker个数，以及通过SPARK_WORKER_CORES来设置单个worker占用的CPU核心数。
网络
以我们的经验来说，当数据加载进内存，那么多数Spark应用的瓶颈都是网络带宽。使用万兆网（10 Gigabit）以上的网络可以优化应用速度。对于一些包含有分布式归约相关算子（distributed reduce相关算子，如：group-by系列，reduce-by系列以及SQL join系列）的应用尤是如此。对于任何给定应用，你可以在应用监控UI上（http://<driver-node>:4040）查看Spark混洗（Spark Shuffles）跨网络传输了多少数据。
CPU内核
Spark在拥有数十个CPU内核的单机上也能表现良好，因为它尽可能少的减少了线程间数据的共享。建议每台机器至少配置8-16个内核。当然，根据你的工作量你可能需要更多。记住，一旦数据加载进内存，绝大多数应用的瓶颈要么是CPU，要么是网络。
官方推荐配置总结
官方推荐配置从存储系统、本地磁盘、内存、网络以及CPU核心数五个方面来谈的，可以得出以下结论：
1、Spark需要从外部的存储系统读取数据，则应距离存储系统越近越好，可以与HDFS部署在同一节点，但对于HBase这样的低延迟数据存储，最好在与存储系统不同的节点上运行计算任务以避免干扰。
2、虽然Spark能够在内存中完成大部分运算，但它依然需要本地磁盘。建议每个节点配4-8块磁盘，以非独立冗余磁盘阵列挂载。
3、内存大小取决于具体应用，可以通过Spark的监控UI（http://<driver-node:4040>）查看部分数据集运行时占用内存大小，从而推断出实际所需内存。同时内存占用很大程度上受存储级别和序列化格式影响。当内存超过200GB时，需要特殊配置。
4、网络越快越好。
5、CPU建议每台机器至少配置8-16内核。
6、记住，数据一旦加载进内存，绝大多数应用的瓶颈要么是CPU，要么是网络。
Spark性能官方基准测试
测试背景
为了验证Spark的性能，Spark开发团队于2014年参加了Sort Benchmark比赛。为什么参加排序比赛呢？因为排序比赛的核心是洗牌操作(Shuffle Operation)，洗牌操作跨所有机器移动数据，几乎是所有分布式数据处理工作的基础。总之，排序比赛最能体现出系统的数据处理能力。Sort Benchmark比赛有多种类别，Spark团队参加了Daytona Gray类别的比赛——测试系统排序100TB（1万亿条记录）数据的速度。
测试结果
硬件环境：
206 Amazon EC2 i2.8xlarge nodes x(32 vCores - 2.5Ghz Intel Xeon E5-2670 v2, 244GBmemory, 8x800 GB SSD)
Spark团队使用了206台亚马逊ECS i2.8xlarge服务器，每台配置CPU为32核心-2.5Ghz Intel Xeon E5-2670 v2处理器，244GB内存，8*800GB SSD硬盘。
注意：关于到底是用了多少台机器，Sort Benchmark发布的测试结果中显示用了207台，而Spark创始人之一Reynold Xin在博客中说是用了206台，这一台的差异估计是没有算服务管理主机吧（我是这么理解的，这里就以Reynold Xin的为标准吧）。
测试结果：
| spark 100TB | |
|---|---|
| 数据量 | 100TB |
| 耗时 | 23分钟 |
| 节点数 | 206 |
| 内核总数 | 6592 |
| 集群磁盘吞吐量 | 618GB/s |
| 是否符合Sort Benchmark Daytona规则 | 是 |
| 网络 | 虚拟机 (EC2) 10Gbps网络 |
| 排序速率 | 4.27 TB/min |
| 排序速率/节点数 | 20.7 GB/min |
除了排序100TB大小的数据外，Spark团队还排序了1PB大小的数据量，测试结果如下：
| spark 1PB | |
|---|---|
| 数据量 | 1000TB |
| 耗时 | 234分钟 |
| 节点数 | 190 |
| 内核总数 | 6080 |
| 集群磁盘吞吐量 | 570 GB/s |
| 是否符合Sort Benchmark Daytona规则 | 否（因为目前还没有1PB数据的排序比赛） |
| 网络 | 虚拟机 (EC2) 10Gbps网络 |
| 排序速率 | 4.27 TB/min |
| 排序速率/节点数 | 22.5 GB/min |
其他测试
除了Spark官方测试外，还有其他一些测试数据仅供参考。
视频处理公司Conviva，使用Spark将数据子集加载到RDD中。对于200GB压缩过的数据进行查询和聚合操作，并运行在两台Spark机器上，占用内存为96GB，执行完全部操作需要耗费30分钟左右的时间。
参考资料
[1] Spark官方网站硬件配置资料. http://spark.apache.org/docs/latest/hardware-provisioning.html.
[2] Reynold Xin.Apache Spark officially sets a new record in large-scale sorting. https://databricks.com/blog/2014/11/05/spark-officially-sets-a-new-record-in-large-scale-sorting.html.
[3] SortBenchmark官方网站. http://sortbenchmark.org
[4]CenOS关于noatime的说明. https://www.centos.org/docs/5/html/Global_File_System/s2-manage-mountnoatime.html.
[5] 残霏.磁盘阵列百度百科. https://baike.baidu.com/item/%E7%A3%81%E7%9B%98%E9%98%B5%E5%88%97/1149823?fr=aladdin&fromid=33858&fromtitle=RAID.
写在最后
聊技术，不止于技术。
欢迎大家关注我的个人公众号：WU双，在这里我会与大家分享技术文章、管理知识以及个人的一些思想感悟。
