由于Hadoop是运行在数十，数百甚至更多节点上，尽可能多的考虑方方面面都可以节省成本。所以基于性价比，怎么才能选择合适的硬件？比如，对于IO密集型的工作负载，需要为每个CPU core匹配更多的存储或更高的吞吐(more spindles per core)。
1，计算和存储
Hadoop将数据分布式存储在各台服务器上，使用文件副本来保证数据不丢以及容错。这样一个计算请求可以直接分发到存储数据的相应服务器并开始进行本地计算。由于Hadoop集群的每台节点都会存储和处理数据，所以就需要考虑怎样为集群里的这些服务器选择合适的配置。
2，为什么跟工作负载有关系
在很多情况下，MapReduce/Spark都会遭遇瓶颈，比如从磁盘或者网络读取数据(IO-bound的作业)，或者在CPU处理大量数据时(CPU-bound的作业)。IO-bound的作业的一个例子是排序，一般需要很少的处理（简单的比较）却需要大量的读写磁盘。CPU-bound的作业的一个例子是分类(classification)，一些数据往往需要很复杂的处理。
1) 典型的IO-bound的工作负载如下：
l 数据导入导出
l 数据传输和转换
l 索引(Indexing)
l 分组(Grouping)
2) 典型的CPU-bound工作负载如下：
l 聚类和分类(Clustering/Classification)
l 特征提取
l 复杂的文本挖掘
l 自然语言处理
完全了解工作负载，才能够正确的选择合适的Hadoop硬件。如果没有研究过工作负载，往往会导致Hadoop运行的作业是基于不合适的硬件。此外，一些工作负载往往会受到一些其他的限制。比如因为选择了压缩，本应该是IO-bound的工作负载实际却是CPU-bound的，或者因为算法选择不同而使MapReduce或者Spark作业受限。由于这些原因，当不熟悉未来将要运行的工作负载时，可以选择一些较为均衡的硬件配置来搭建Hadoop集群。
接下来就可以在集群中运行一些MapReduce/Spark作业进行基准测试，来分析它们的bound方式。可以通过一些监控工具来确定工作负载的瓶颈。当然Cloudera Manager提供了这个功能，包括CPU，磁盘和网络负载的实时统计信息。通过Cloudera Manager，当集群在运行作业时，系统管理员可以通过dashboard很直观的查看每台机器的性能表现。
3，不同的工作负载的常见机器配置
1) Light Processing Configuration
1U的机器，一般为测试，开发或者低要求的场景：2个8-core CPUs，24-64GB内存，8个磁盘（1TB或者2TB）
2) Balanced Compute Configuration均衡或主流的配置
1U/2U的机器：2个8-core CPUs，48-256GB的内存，12-16块磁盘（1TB-4TB），硬盘为直通挂载
3) Storage Heavy Configuration，重存储的配置
2U的机器：2个8-core CPUs，48-128GB的内存，16-24块磁盘（2TB-6TB）。这种配置一旦多个节点或者机架故障，将对网络流量造成很大的压力
4) Compute Intensive Configuration，计算密集型的配置
2U的机器：2个8-core CPUs，64-512GB memory,4-8块磁盘（1TB-4TB）
4，CDH集群挑选硬件
一个Hadoop集群通常有4个角色：NameNode（和Standby NameNode），ResourceManager，NodeManager和DataNode。集群中的绝大多数机器同时是NodeManager和DataNode，既用于数据存储，又用于数据处理。
1) 较为通用和主流的NodeManager/DataNode配置
12-24块1-6TB硬盘， JBOD (Just a Bunch Of Disks)
2路8核，2路10核，2路12核的CPU, 主频至少2-2.5GHz
64-512GB内存
绑定的万兆网 （存储越多，网络吞吐就要求越高）
NameNode负责协调集群上的数据存储，ResourceManager则是负责协调数据处理。Standby NameNode不应该与NameNode在同一台机器，但应该选择与NameNode配置相同的机器。
NameNode需要的内存与集群中存储的数据块成正比。常用的计算公式是集群中100万个块(HDFS blocks)对应NameNode的1GB内存。常见的10-50台机器规模的集群，NameNode服务器的内存配置一般选择128GB，NameNode的堆栈一般配置为32GB或更高。另外务必配置NameNode和ResourceManager的HA。
2) NameNode/ResourceManager及其Standby节点的推荐配置。磁盘的数量取决于冗余备份元数据的份数。
4–6个1TB的硬盘，JBOD(1个是OS, 2个是NameNode的FS image [RAID 1], 1个配置给Apache ZooKeeper,
还一个是配置给Journal node)
2路6核，2路8核的CPU, 主频至少2-2.5GHz
64-256GB的内存
绑定的万兆网
5，Hadoop其他组件的考虑
需要考虑HBase，Impala和Solr等。它们都会运行在DataNode上运行，从而保证数据的本地性。HBase是一个可靠的，列存储数据库，提供一致的，低延迟的随机读/写访问。Cloudera Search通过Solr实现全文检索，Solr是基于Lucene，CDH很好的集成了Solr Cloud和Apache Tika，从而提供更多的搜索功能。Apache Impala则可以直接运行在HDFS和HBase之上，提供交互式的低延迟SQL查询，避免了数据的移动和转换。
由于GC超时的问题，建议的HBase RegionServer的heap size大小一般为16GB，而不是简单的越大越好。为了保证HBase实时查询的SLA，可以通过Cgroups的的方式给HBase分配专门的静态资源。
Impala是内存计算引擎，有时可以用到集群80%以上的内存资源，因此如果要使用Impala，建议每个节点至少有128GB的内存。当然也可以通过Impala的动态资源池来对查询的内存或用户进行限制。
Cloudera Search在做节点规划时比较有趣，可以先在一个节点安装Solr，然后装载一些文档，建立索引，并以期望的方式进行查询。然后继续装载，直到索引建立以及查询响应超过了的预期，这时候就需要考虑扩展了。单个节点Solr的这些数据可以给提供一些规划时的参考，但不包括复制因子因素。
6，总结及参考文献
https://www.cloudera.com/documentation/enterprise/release-notes/topics/rg_release_notes.html