为Hadoop集选择合适的硬件配置
随着Apache 的起步，云客户的增多⾯临的⾸要问题就是如何为他们新的的Hadoop集选择合适的硬件。
尽管Hadoop被设计为运⾏在⾏业标准的硬件上，提出⼀个理想的集配置不想提供硬件规格列表那么简单。选择硬件，为给定的负载在性能和经济性提供最佳平衡是需要测试和验证其有效性。（⽐如，IO密集型⼯作负载的⽤户将会为每个核⼼主轴投资更多）。
在这个博客帖⼦中，你将会学到⼀些⼯作负载评估的原则和它在硬件选择中起着⾄关重要的作⽤。在这个过程中，你也将学到Hadoop管理员应该考虑到各种因素。
结合存储和计算
过去的⼗年，IT组织已经标准化了⼑⽚服务器和存储区域⽹(SAN)来满⾜联⽹和处理密集型的⼯作负载。尽管这个模型对于⼀些⽅⾯的标准程序是有相当意义的，⽐如⽹站服务器，程序服务器，⼩型结构化数据库，数据移动等，但随着数据数量和⽤户数的增长，对于基础设施的要求也已经改变。⽹站服务器现在有了缓存层；数据库需要本地硬盘⽀持⼤规模地并⾏；数据迁移量也超过了本地可处理的数量。
⼤部分的团队还没有弄清楚实际⼯作负载需求就开始搭建他们的Hadoop集。
硬件提供商已经⽣产了创新性的产品系统来应对这些需求，包括存储⼑⽚服务器，串⾏SCSI交换机，外部SATA磁盘阵列和⼤容量的机架单元。然⽽，Hadoop是基于新的实现⽅法，来存储和处理复杂数据，并伴随着数据迁移的减少。相对于依赖SAN来满⾜⼤容量存储和可靠性，Hadoop在软件层次处理⼤数据和可靠性。
Hadoop在⼀簇平衡的节点间分派数据并使⽤同步复制来保证数据可⽤性和容错性。因为数据被分发到有计算能⼒的节点，数据的处理可以被直接发送到存储有数据的节点。由于Hadoop集中的每⼀台节点都存储并处理数据，这些节点都需要配置来满⾜数据存储和运算的要求。
⼯作负载很重要吗？
在⼏乎所有情形下，MapReduce要么会在从硬盘或者⽹络读取数据时遇到瓶颈（称为IO受限的应⽤），要么在处理数据时遇到瓶颈（CPU 受限）。排序是⼀个IO受限的例⼦，它需要很少的CPU处理（仅仅是简单的⽐较操作），但是需要⼤量的从硬盘读写数据。模式分类是⼀个CPU受限的例⼦，它对数据进⾏复杂的处理，⽤来判定本体。
下⾯是更多IO受限的⼯作负载的例⼦：
索引
分组
hadoop分布式集搭建数据导⼊导出
数据移动和转换
下⾯是更多CPU受限的⼯作负载的例⼦：
聚类/分类
复杂⽂本挖掘
⾃然语⾔处理
特征提取
Cloudera的客户需要完全理解他们的⼯作负载，这样才能选择最优的Hadoop硬件，⽽这好像是⼀个鸡⽣蛋蛋⽣鸡的问题。⼤多数⼯作组在没有彻底剖析他们的⼯作负载时，就已经搭建好了Hadoop集，通常Hadoop运⾏的⼯作负载随着他们的精通程度的提⾼⽽完全不同。⽽且，某些⼯作负载可能会被⼀些未预料的原因受限。例如，某些理论上是IO受限的⼯作负载却最终成为了CPU受限，这是可能是因为
⽤户选择了不同的压缩算法，或者算法的不同实现改变了MapReduce任务的约束⽅式。基于这些原因，当⼯作组还不熟悉要运⾏任务的类型时，深⼊剖析它才是构建平衡的Hadoop集之前需要做的最合理的⼯作。
接下来需要在集上运⾏MapReduce基准测试任务，分析它们是如何受限的。完成这个⽬标最直接的⽅法是在运⾏中的⼯作负载中的适当位置添加监视器来检测瓶颈。我们推荐在Hadoop集上安装Cloudera Manager，它可以提供CPU，硬盘和⽹络负载的实时统计信息。（Cloudera Manager是Cloudera 标准版和企业版的⼀个组件，其中企业版还⽀持滚动升级）Cloudera Manager安装之后，Hadoop管理员就可以运⾏MapReduce任务并且查看Cloudera Manager的仪表盘，⽤来监测每台机器的⼯作情况。
第⼀步是弄清楚你的作业组已经拥有了哪些硬件
在为你的⼯作负载构建合适的集之外，我们建议客户和它们的硬件提供商合作确定电⼒和冷却⽅⾯的预算。由于Hadoop会运⾏在数⼗台，数百台到数千台节点上。通过使⽤⾼性能功耗⽐的硬件，作业组可以节省⼀⼤笔资⾦。硬件提供商通常都会提供监测功耗和冷却⽅⾯的⼯具和建议。
为你的CDH(Cloudera distribution for Hadoop) Cluster选择硬件
选择机器配置类型的第⼀步就是理解你的运维团队已经在管理的硬件类型。在购买新的硬件设备时，运维团队经常根据⼀定的观点或者强制
需求来选择，并且他们倾向于⼯作在⾃⼰业已熟悉的平台类型上。Hadoop不是唯⼀的从规模效率上获益的系统。再⼀次强调，作为更通⽤的建议，如果集是新建⽴的或者你并不能准确的预估你的极限⼯作负载，我们建议你选择均衡的硬件类型。
Hadoop集有四种基本任务⾓⾊：名称节点（包括备⽤名称节点），⼯作追踪节点，任务执⾏节点，和数据节点。节点是执⾏某⼀特定功能的⼯作站。⼤部分你的集内的节点需要执⾏两个⾓⾊的任务，作为数据节点（数据存储）和任务执⾏节点（数据处理）。
这是在⼀个平衡Hadoop集中，为数据节点/任务追踪器提供的推荐规格：
在⼀个磁盘阵列中要有12到24个1~4TB硬盘
2个频率为2~2.5GHz的四核、六核或⼋核CPU
64~512GB的内存
有保障的千兆或万兆以太⽹（存储密度越⼤，需要的⽹络吞吐量越⾼）
名字节点⾓⾊负责协调集上的数据存储，作业追踪器协调数据处理（备⽤的名字节点不应与集中的名字节点共存，并且运⾏在与之相同的硬件环境上。）。 Cloudera推荐客户购买在或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的配置。)
下图向你展⽰了如何根据⼯作负载来配置⼀台机器：
其他要考虑的
记住Hadoop⽣态系统的设计是考虑了并⾏环境这点⾮常重要。当购买处理器时，我们不建议购买最⾼频率(GHZ)的芯⽚，这些芯⽚都有很⾼的功耗（130⽡以上）。这么做会产⽣两个问题：电量消耗会更⾼和热量散发会更⼤。处在中间型号的CPU在频率、价格和核⼼数⽅⾯性
价⽐是最好的。
当我们碰到⽣成⼤量中间数据的应⽤时-也就是说输出数据的量和读⼊数据的量相等的情况-我们推荐在单个以太⽹接⼝卡上启⽤两个端⼝，或者捆绑两个以太⽹卡，让每台机器提供2Gbps的传输速率。绑定2Gbps的节点最多可容纳的数据量是12TB。⼀旦你传输的数据超过
12TB，你将需要使⽤传输速率为捆绑⽅式实现的4Gbps(4x1Gbps)。另外，对哪些已经使⽤10Gb带宽的以太⽹或者⽆线⽹络⽤户来说，这样的⽅案可以⽤来按照⽹络带宽实现⼯作负载的分配。如果你正在考虑切换到10GB的以太⽹络上，那么请确认操作系统和BIOS是否兼容这样的功能。
当计算需要多少内存的时候，记住Java本⾝要使⽤⾼达10%的内存来管理虚拟机。我们建议把Hadoop配置为只使⽤堆，这样就可以避免内存与磁盘之间的切换。切换⼤⼤地降低MapReduce任务的性能，并且可以通过给机器配置更多的内存以及给⼤多数发布版以适当的内核设置就可以避免这种切换。
优化内存的通道宽度也是⾮常重要的。例如，当我们使⽤双通道内存时，每台机器就应当配置成对内存模块（DIMM）。当我们使⽤三通道的内存时，每台机器都应当使⽤三的倍数个内存模块（DIMM）。类似地，四通道的内存模块（DIMM)就应当按四来分组使⽤内存。
超越MapReduce
Hadoop不仅仅是HDFS和MapReduce；它是⼀个⽆所不包的数据平台。因此CDH包含许多不同的⽣态系统产品（实际上很少仅仅做为MapReduce使⽤）。当你在为集选型的时候，需要考虑的附加软件组件包括Apache 、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 调度器，并协同 Cgroups使⽤。
Impala使⽤内存以完成其⼤多数的功能，在默认的配置下，将最多使⽤80％的可⽤RAM资源，所以我们推荐，最少每⼀个节点使⽤96GB的RAM。与MapReduce⼀起使⽤Impala的⽤户，可以参考我们的建议－也可以为Impala指定特定进程所需的内存或者特定查询所需的内存。
搜索是最有趣的订制⼤⼩的组件。推荐的订制⼤⼩的实践操作是购买⼀个节点，安装Solr和Lucene，然后载⼊你的⽂档。⼀旦⽂档被以期望的⽅式来索引和搜索，可伸缩性将开始作⽤。持续不断的载⼊⽂档，直到索引和查询的延迟，对于项⽬⽽⾔超出了必要的数值－此时，这让你得到了在可⽤的资源上每⼀个节点所能处理的最⼤⽂档数⽬的基数，以及不包括欲期的集复制此因素的节点的数量总计基数。
结论
购买合适的硬件，对于⼀个Hapdoop集⽽⾔，需要性能测试和细⼼的计划，从⽽全⾯理解⼯作负荷。然⽽，Hadoop集通常是⼀个形态变化的系统，⽽Cloudera建议，在开始的时候，使⽤负载均衡的技
术⽂
档来部署启动的硬件。重要的是，记住，当使⽤多种体系组件的时候，资源的使⽤将会是多样的，⽽专注与资源管理将会是你成功的关键。
我们⿎励你在留⾔中，加⼊你关于配置Hadoop⽣产集服务器的经验！
Kevin O‘Dell 是⼀个⼯作于Cloudera的系统⼯程师。
英⽂原⽂：
附：
淘宝Hadoop集机器硬件配置
国内外使⽤Hadoop的公司⽐较多，全球最⼤的Hadoop集在雅虎，有⼤约25000个节点，主要⽤于⽀持⼴告系统与⽹页搜索。国内⽤Hadoop的主要有百度、淘宝、腾讯、华为、中国移动等，其中淘宝的Hadoop集属于较⼤的（如果不是最⼤）。
淘宝Hadoop集现在超过1700个节点，服务于⽤于整个阿⾥巴巴集团各部门，数据来源于各部门产品
的线上数据库（, ）备份，系统⽇志以及爬⾍数据，截⽌2011年9⽉，数量总量已经超过17个PB，每天净增长20T左右。每天在Hadoop集运⾏的MapReduce任务有超过4万（有时会超过6万），其中⼤部分任务是每天定期执⾏的统计任务，例如数据魔⽅、量⼦统计、推荐系统、排⾏榜等等。这些任务⼀般在凌晨1点左右开始执⾏，3-4个⼩时内全部完成。每天读数据在2PB左右，写数据在1PB左右。
this picture is from Taobao
Hadoop包括两类节点Master和Slave节点，
Master节点包括Jobtracker，Namenode, SecondName, Standby，
硬件配置：16CPU*4核，96G内存。
Slave节点主要是TaskTracker和DataNode，
硬件配置存在⼀定的差别：8CPU*4核-16CPU*4核，16G-24G内存
（注：通常是⼀个slave节点同时是TaskTracker和DataNode，⽬的是提⾼数据本地性data locality）。
每个slave节点会划分成12~24个slots。整个集约34,916个slots，其中Map slots是19,643个，Reduce slots是15，273个
所有作业会进⾏分成多个，按照部门或⼩组划分，总共有38个Group。整个集的资源也是按各个Group进⾏划分，定义每个Group的最⼤并发任务数，Map slots与Reduce slots的使⽤上限。每个作业只能使⽤⾃⼰组的slots资源。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。