共计 8120 个字符，预计需要花费 21 分钟才能阅读完成。
随着 Apache Hadoop 的起步，云客户的增多面临的首要问题就是如何为他们新的的 Hadoop 集群选择合适的硬件。
尽管 Hadoop 被设计为运行在行业标准的硬件上，提出一个理想的集群配置不想提供硬件规格列表那么简单。选择硬件，为给定的负载在性能和经济性提供最佳平衡是需要测试和验证其有效性。（比如，IO 密集型工作负载的用户将会为每个核心主轴投资更多）。
在这个博客帖子中，你将会学到一些工作负载评估的原则和它在硬件选择中起着至关重要的作用。在这个过程中，你也将学到 Hadoop 管理员应该考虑到各种因素。
结合存储和计算
过去的十年，IT 组织已经标准化了刀片服务器和存储区域网 (SAN) 来满足联网和处理密集型的工作负载。尽管这个模型对于一些方面的标准程序是有相当意义 的，比如网站服务器，程序服务器，小型结构化数据库，数据移动等，但随着数据数量和用户数的增长，对于基础设施的要求也已经改变。网站服务器现在有了缓存 层；数据库需要本地硬盘支持大规模地并行；数据迁移量也超过了本地可处理的数量。
大部分的团队还没有弄清楚实际工作负载需求就开始搭建他们的 Hadoop 集群。
硬 件提供商已经生产了创新性的产品系统来应对这些需求，包括存储刀片服务器，串行 SCSI 交换机，外部 SATA 磁盘阵列和大容量的机架单元。然 而，Hadoop 是基于新的实现方法，来存储和处理复杂数据，并伴随着数据迁移的减少。相对于依赖 SAN 来满足大容量存储和可靠性，Hadoop 在软件层次处理大数据和可靠性。
Hadoop 在一簇平衡的节点间分派数据并使用同步复制来保证数据可用性和容错性。因为数据被分发到有计算能力的节点，数据的处理可以被直接发送到存储有数据的节点。由于 Hadoop 集群中的每一台节点都存储并处理数据，这些节点都需要配置来满足数据存储和运算的要求。
工作负载很重要吗？
在几乎所有情形下，MapReduce 要么会在从硬盘或者网络读取数据时遇到瓶颈（称为 IO 受限的应用），要么在处理数据时遇到瓶颈（CPU 受限）。排序是 一个IO 受限的例子，它需要很少的 CPU 处理（仅仅是简单的比较操作），但是需要大量的从硬盘读写数据。模式分类是一个 CPU 受限的例子，它对数据进行复杂的处理，用来判定本体。
下面是更多 IO 受限的工作负载的例子：
- 索引
- 分组
- 数据导入导出
- 数据移动和转换
下面是更多 CPU 受限的工作负载的例子：
- 聚类 / 分类
- 复杂文本挖掘
- 自然语言处理
- 特征提取
Cloudera 的客户需要完全理解他们的工作负载，这样才能选择最优的 Hadoop 硬件，而这好像是一个鸡生蛋蛋生鸡的问题。大多数工作组在没有彻底剖析他们的工作负载时，就已经搭建好了 Hadoop 集群，通常 Hadoop 运行的工作负载随着他们的精通程度的提高而完全不同。而且，某些工作负载可能会被一些未预料的原因受限。例如，某些理论上是 IO 受限的工作负载却最终成为了 CPU 受限，这是可能是因为用户选择了不同的压缩算法，或者算法的不同实现改变了 MapReduce 任务的约束方式。基于这些原因，当工作组还不熟悉要运行任务的类型时，深入剖析它才是构建平衡的 Hadoop 集群之前需要做的最合理的工作。
接下来需要在集群上运行 MapReduce 基准测试任务，分析它们是如何受限的。完成这个目标最直接的方法是在运行中的工作负载中的适当位置添加监视器来检测瓶颈。我们推荐在 Hadoop 集群上安装 Cloudera Manager，它可以提供 CPU，硬盘和网络负载的实时统计信息。（Cloudera Manager 是 Cloudera 标准版和企业版的一个组件，其中企业版还支持滚动升级）Cloudera Manager 安装之后，Hadoop 管理员就可以运行 MapReduce 任务并且查看Cloudera Manager 的仪表盘，用来监测每台机器的工作情况。
第一步是弄清楚你的作业组已经拥有了哪些硬件
在为你的工作负载构建合适的集群之外，我们建议客户和它们的硬件提供商合作确定电力和冷却方面的预算。由于 Hadoop 会运行在数十台，数百台到数千台节点上。通过使用高性能功耗比的硬件，作业组可以节省一大笔资金。硬件提供商通常都会提供监测功耗和冷却方面的工具和建议。
相关阅读：
Ubuntu 13.04 上搭建 Hadoop 环境 http://www.linuxidc.com/Linux/2013-06/86106.htm
Ubuntu 12.10 +Hadoop 1.2.1 版本集群配置 http://www.linuxidc.com/Linux/2013-09/90600.htm
Ubuntu 上搭建 Hadoop 环境（单机模式 + 伪分布模式）http://www.linuxidc.com/Linux/2013-01/77681.htm
Ubuntu 下 Hadoop 环境的配置 http://www.linuxidc.com/Linux/2012-11/74539.htm
单机版搭建 Hadoop 环境图文教程详解 http://www.linuxidc.com/Linux/2012-02/53927.htm
搭建 Hadoop 环境（在 Winodws 环境下用虚拟机虚拟两个 Ubuntu 系统进行搭建）http://www.linuxidc.com/Linux/2011-12/48894.htm
为你的 CDH(Cloudera distribution for Hadoop) Cluster 选择硬件
选择机器配置类型的第一步就是理解你的运维团队已经在管理的硬件类型。在购买新的硬件设备时，运维团队经常根据一定的观点或者强制需求来选择，并且他们倾向于工作在自己业已熟悉的平台类型上。Hadoop 不是唯一的从规模效率上获益的系统。再一次强调，作为更通用的建议，如果集群是新建立的或者你并不能准确的预估你的极限工作负载，我们建议你选择均衡的硬件类型。
Hadoop 集群有四种基本任务角色: 名称节点（包括备用名称节点），工作追踪节点，任务执行节点，和数据节点。节点是执行某一特定功能的工作站。大部分你的集群内的节点需要执行两个角色的任务，作为数据节点（数据存储）和任务执行节点（数据处理）。
这是在一个平衡 Hadoop 集群中，为数据节点 / 任务追踪器提供的推荐规格：
- 在一个磁盘阵列中要有 12 到 24 个 1~4TB 硬盘
- 2 个频率为 2~2.5GHz 的四核、六核或八核 CPU
- 64~512GB 的内存
- 有保障的千兆或万兆以太网（存储密度越大，需要的网络吞吐量越高）
名字节点角色负责协调集群上的数据存储，作业追踪器协调数据处理（备用的名字节点不应与集群中的名字节点共存，并且运行在与之相同的硬件环境上。）。Cloudera 推荐客户购买在 RAID1 或 10 配置上有足够功率和企业级磁盘数的商用机器来运行名字节点和作业追踪器。
NameNode 也会直接需要与群集中的数据块的数量成比列的 RAM。一个好的但不精确的规则是对于存储在分布式文件系统里面的每一个 1 百万的数据块，分配 1GB 的 NameNode 内存。于在一个群集里面的 100 个 DataNodes 而言，NameNode 上的 64GB 的 RAM 提供了足够的空间来保证群集的增长。我们也推荐把 HA 同时配置在 NameNode 和 JobTracker 上，
这里就是为 NameNode/JobTracker/Standby NameNode 节点群推荐的技术细节。驱动器的数量或多或少，将取决于冗余数量的需要。
- 4–6 1TB 硬盘驱动器 采用 一个 JBOD 配置 (1 个用于 OS, 2 个用于文件系统映像[RAID 1], 1 个用于 Apache ZooKeeper, 1 个用于 Journal 节点)
- 2 4-/16-/8- 核心 CPUs, 至少运行于 2-2.5GHz
- 64-128GB 随机存储器
- Bonded Gigabit 以太网卡 or 10Gigabit 以太网卡
记住, 在思想上，Hadoop 体系设计为用于一种并行环境。
如果你希望 Hadoop 集群扩展到 20 台机器以上，那么我们推荐最初配置的集群应分布在两个机架，而且每个机架都有一个位于机架顶部的 10G 的以太网交换。当这个集群跨越多个机架的时候，你将需要添加核心交换机使用 40G 的以太网来连接位于机架顶部的交换机。两个逻辑上分离的机架可以让维护团队更好地理解机架内部和机架间通信对网络需求。
Hadoop 集群安装好后，维护团队就可以开始确定工作负载，并准备对这些工作负载进行基准测试以确定硬件瓶颈。经过一段时间的基准测试和监视，维护团队将会明白如何配置添加的机器。异构的 Hadoop 集群是很常见的，尤其是在集群中用户机器的容量和数量不断增长的时候更常见 - 因此为你的工作负载所配置的“不理想”开始时的那组机器不是在浪费时间。Cloudera 管理器提供了允许分组管理不同硬件配置的模板，通过这些模板你就可以简单地管理异构集群了。
下面是针对不同的工作负载所采用对应的各种硬件配置的列表，包括我们最初推荐的“负载均衡”的配置：
- 轻量处理方式的配置(1U 的机器）: 两个 16 核的 CPU，24-64GB 的内存以及 8 张硬盘（每张 1TB 或者 2TB)。
- 负载均衡方式的配置(1U 的机器）: 两个 16 核的 CPU，48-128GB 的内存以及由主板控制器直接连接的 12-16 张硬盘（每张 1TB 或者 2TB)。通常在一个 2U 的柜子里使用 2 个主板和 24 张硬盘实现相互备份。
- 超大存储方式的配置(2U 的机器）: 两个 16 核的 CPU，48-96GB 的内存以及 16-26 张硬盘（每张 2TB-4TB)。这种配置在多个节点 / 机架失效时会产生大量的网络流量。
- 强力运算方式的配置(2U 的机器）: 两个 16 核的 CPU，64-512GB 的内存以及 4 - 8 张硬盘（每张 1TB 或者 2TB)。
（注意 Cloudera 期望你配置它可以使用的 2 ×8,2×10 和 2 ×12 核心 CPU 的配置。)
下图向你展示了如何根据工作负载来配置一台机器：
随着 Apache Hadoop 的起步，云客户的增多面临的首要问题就是如何为他们新的的 Hadoop 集群选择合适的硬件。
尽管 Hadoop 被设计为运行在行业标准的硬件上，提出一个理想的集群配置不想提供硬件规格列表那么简单。选择硬件，为给定的负载在性能和经济性提供最佳平衡是需要测试和验证其有效性。（比如，IO 密集型工作负载的用户将会为每个核心主轴投资更多）。
在这个博客帖子中，你将会学到一些工作负载评估的原则和它在硬件选择中起着至关重要的作用。在这个过程中，你也将学到 Hadoop 管理员应该考虑到各种因素。
结合存储和计算
过去的十年，IT 组织已经标准化了刀片服务器和存储区域网 (SAN) 来满足联网和处理密集型的工作负载。尽管这个模型对于一些方面的标准程序是有相当意义 的，比如网站服务器，程序服务器，小型结构化数据库，数据移动等，但随着数据数量和用户数的增长，对于基础设施的要求也已经改变。网站服务器现在有了缓存 层；数据库需要本地硬盘支持大规模地并行；数据迁移量也超过了本地可处理的数量。
大部分的团队还没有弄清楚实际工作负载需求就开始搭建他们的 Hadoop 集群。
硬 件提供商已经生产了创新性的产品系统来应对这些需求，包括存储刀片服务器，串行 SCSI 交换机，外部 SATA 磁盘阵列和大容量的机架单元。然 而，Hadoop 是基于新的实现方法，来存储和处理复杂数据，并伴随着数据迁移的减少。相对于依赖 SAN 来满足大容量存储和可靠性，Hadoop 在软件层次处理大数据和可靠性。
Hadoop 在一簇平衡的节点间分派数据并使用同步复制来保证数据可用性和容错性。因为数据被分发到有计算能力的节点，数据的处理可以被直接发送到存储有数据的节点。由于 Hadoop 集群中的每一台节点都存储并处理数据，这些节点都需要配置来满足数据存储和运算的要求。
工作负载很重要吗？
在几乎所有情形下，MapReduce 要么会在从硬盘或者网络读取数据时遇到瓶颈（称为 IO 受限的应用），要么在处理数据时遇到瓶颈（CPU 受限）。排序是 一个IO 受限的例子，它需要很少的 CPU 处理（仅仅是简单的比较操作），但是需要大量的从硬盘读写数据。模式分类是一个 CPU 受限的例子，它对数据进行复杂的处理，用来判定本体。
下面是更多 IO 受限的工作负载的例子：
- 索引
- 分组
- 数据导入导出
- 数据移动和转换
下面是更多 CPU 受限的工作负载的例子：
- 聚类 / 分类
- 复杂文本挖掘
- 自然语言处理
- 特征提取
Cloudera 的客户需要完全理解他们的工作负载，这样才能选择最优的 Hadoop 硬件，而这好像是一个鸡生蛋蛋生鸡的问题。大多数工作组在没有彻底剖析他们的工作负载时，就已经搭建好了 Hadoop 集群，通常 Hadoop 运行的工作负载随着他们的精通程度的提高而完全不同。而且，某些工作负载可能会被一些未预料的原因受限。例如，某些理论上是 IO 受限的工作负载却最终成为了 CPU 受限，这是可能是因为用户选择了不同的压缩算法，或者算法的不同实现改变了 MapReduce 任务的约束方式。基于这些原因，当工作组还不熟悉要运行任务的类型时，深入剖析它才是构建平衡的 Hadoop 集群之前需要做的最合理的工作。
接下来需要在集群上运行 MapReduce 基准测试任务，分析它们是如何受限的。完成这个目标最直接的方法是在运行中的工作负载中的适当位置添加监视器来检测瓶颈。我们推荐在 Hadoop 集群上安装 Cloudera Manager，它可以提供 CPU，硬盘和网络负载的实时统计信息。（Cloudera Manager 是 Cloudera 标准版和企业版的一个组件，其中企业版还支持滚动升级）Cloudera Manager 安装之后，Hadoop 管理员就可以运行 MapReduce 任务并且查看Cloudera Manager 的仪表盘，用来监测每台机器的工作情况。
第一步是弄清楚你的作业组已经拥有了哪些硬件
在为你的工作负载构建合适的集群之外，我们建议客户和它们的硬件提供商合作确定电力和冷却方面的预算。由于 Hadoop 会运行在数十台，数百台到数千台节点上。通过使用高性能功耗比的硬件，作业组可以节省一大笔资金。硬件提供商通常都会提供监测功耗和冷却方面的工具和建议。
相关阅读：
Ubuntu 13.04 上搭建 Hadoop 环境 http://www.linuxidc.com/Linux/2013-06/86106.htm
Ubuntu 12.10 +Hadoop 1.2.1 版本集群配置 http://www.linuxidc.com/Linux/2013-09/90600.htm
Ubuntu 上搭建 Hadoop 环境（单机模式 + 伪分布模式）http://www.linuxidc.com/Linux/2013-01/77681.htm
Ubuntu 下 Hadoop 环境的配置 http://www.linuxidc.com/Linux/2012-11/74539.htm
单机版搭建 Hadoop 环境图文教程详解 http://www.linuxidc.com/Linux/2012-02/53927.htm
搭建 Hadoop 环境（在 Winodws 环境下用虚拟机虚拟两个 Ubuntu 系统进行搭建）http://www.linuxidc.com/Linux/2011-12/48894.htm
其他要考虑的
记住 Hadoop 生态系统的设计是考虑了并行环境这点非常重要。当购买处理器时，我们不建议购买最高频率 (GHZ) 的芯片，这些芯片都有很高的功耗（130 瓦以上）。这么做会产生两个问题：电量消耗会更高和热量散发会更大。处在中间型号的 CPU 在频率、价格和核心数方面性价比是最好的。
当我们碰到生成大量中间数据的应用时 - 也就是说输出数据的量和读入数据的量相等的情况 - 我们推荐在单个以太网接口卡上启用两个端口，或者捆绑两个以太网卡，让每台机器提供 2Gbps 的传输速率。绑定 2Gbps 的节点最多可容纳的数据量是 12TB。一旦你传输的数据超过 12TB，你将需要使用传输速率为捆绑方式实现的 4Gbps(4x1Gbps)。另外，对哪些已经使用 10Gb 带宽的以太网或者无线网络用户来说，这样的方案可以用来按照网络带宽实现工作负载的分配。如果你正在考虑切换到 10GB 的以太网络上，那么请确认操作系统和 BIOS 是否兼容这样的功能。
当计算需要多少内存的时候，记住 Java 本身要使用高达 10% 的内存来管理虚拟机。我们建议把 Hadoop 配置为只使用堆，这样就可以避免内存与磁盘之间的切换。切换大大地降低 MapReduce 任务的性能，并且可以通过给机器配置更多的内存以及给大多数 Linux 发布版以适当的内核设置就可以避免这种切换。
优化内存的通道宽度也是非常重要的。例如，当我们使用双通道内存时，每台机器就应当配置成对内存模块（DIMM）。当我们使用三通道的内存时，每台机器都应当使用三的倍数个内存模块（DIMM）。类似地，四通道的内存模块（DIMM)就应当按四来分组使用内存。
超越 MapReduce
Hadoop 不仅仅是 HDFS 和 MapReduce；它是一个无所不包的数据平台。因此 CDH 包含许多不同的生态系统产品（实际上很少仅仅做为 MapReduce 使用）。当你在为集群选型的时候，需要考虑的附加软件组件包括 Apache HBase、Cloudera Impala 和 Cloudera Search。它们应该都运行在 DataNode 中来维护数据局部性。
关注资源管理是你成功的关键。 |
HBase 是一个可靠的列数据存储系统，它提供一致性、低延迟和随机读写。Cloudera Search 解决了 CDH 中存储内容的全文本搜索的需求，为新类型用户简化了访问，但是也为 Hadoop 中新类型数据存储提供了机会。Cloudera Search 基于 Apache Lucene/Solr Cloud 和 Apache Tika，并且为与 CDH 广泛集成的搜索扩展了有价值的功能和灵活性。基于 Apache 协议的 Impala 项目为 Hadoop 带来了可扩展的并行数据库技术，使得用户可以向 HDFS 和 HBase 中存储的数据发起低延迟的 SQL 查询，而且不需要数据移动或转换。
由于 垃圾回收器（GC）的超时，HBase 的用户应该留意堆的大小的限制。别的 JVM 列存储也面临这个问题。因此，我们推荐每一个区域服务器的堆最大不超过 16GB。HBase 不需要太多别的资源而运行于 Hadoop 之上，但是维护一个实时的 SLAs，你应该使用多个调度器，比如使用 fair and capacity 调度器，并协同 Linux Cgroups 使用。
Impala 使用内存以完成其大多数的功能，在默认的配置下，将最多使用 80%的可用 RAM 资源，所以我们推荐，最少每一个节点使用 96GB 的 RAM。与 MapReduce 一起使用 Impala 的用户，可以参考我们的建议 -“Configuring Impala and MapReduce for Multi-tenant Performance.”也可以为 Impala 指定特定进程所需的内存或者特定查询所需的内存。
搜索是最有趣的订制大小的组件。推荐的订制大小的实践操作是购买一个节点，安装 Solr 和 Lucene，然后载入你的文档群。一旦文档群被以期望的方式来索引和搜索，可伸缩性将开始作用。持续不断的载入文档群，直到索引和查询的延迟，对于项目而言超出了必要的数值 - 此时，这让你得到了 在可用的资源上 每一个节点所能处理的最大文档数目的基数，以及不包括欲期的集群复制此因素的节点的数量总计基数。
结论
购买合适的硬件，对于一个 Hapdoop 群集而言，需要性能测试和细心的计划，从而全面理解工作负荷。然而，Hadoop 群集通常是一个形态变化的系统，而 Cloudera 建议，在开始的时候，使用负载均衡的技术文档来部署启动的硬件。重要的是，记住，当使用多种体系组件的时候，资源的使用将会是多样的，而专注与资源管理将会是你成功的关键。
我们鼓励你在留言中，加入你关于配置 Hadoop 生产群集服务器的经验！
Kevin O‘Dell 是一个工作于 Cloudera 的系统工程师。
更多 Hadoop 相关信息见Hadoop 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=13
