集群规范
Hadoop运行在商业硬件上。用户可以选择普通豳件厂商生产的标准化的、广泛有 效的硬件来构建集群，无需使用特定厂商生产的昂贵、专有的硬件设备。
首先澄清两点。第一，商业硬件并不等同于低端硬件。低端机器常常使用便宜的零 部件，其故障率远高于更昂贵(但仍是商业级别)的机器。当用户管理几十台、上百 台，甚至几千台机器时，便宜的零部件故障率更髙，导致维护成本更髙。第二，也 不推荐使用大型数据库级别的机器，因为性价比太低了。用户可能会考虑使用少数 几台数据库级别的计算机来构建一个集群，使其性能与一个中等规模的商业机器集 群差不多。然而，某一台机器发生故障时，会对集群产生更大的负面影响，因为相 对而言，故障硬件所占的比重更大了。
硬件规格很快就会过时。但为了举例说明，下面列举一下硬件规格。在2010年 中，搭载Hadoop的datanode和tasktracker的典型机器具有以下规格：
处理器
2个四核 2~2.5 GHz CPU
内存
16~24 GB ECC RAM
存储器
4x lTB SATA 硬盘
网络
千兆以太网
尽管集群采用的机器硬件肯定有所不同，但是Hadoop一般使用多核CPU和多磁 盘，以充分利用现代化硬件的强大功能。
为何不使用RAID? 尽管建议采用 RAID(Redundant Array of Independent Disk)fS namenode 的外部 存储器以避免元数据冲突，但在datanode中使用RAID作为外部存储器并不会 给HDFS带来好处。因为HDFS所提供的节点间复制技术已满足了数据备份需 求，无需使用RAID的冗余机制。 此外，尽管RAID条带化(RAID 0)技术被广泛用于提升性能，但是其速度仍然比 HDFS 的 JBOD(Just a Bunch OfDisks)慢。JBOD 在所有磁盘之间循环调度 HDFS 块。RAID 0的读写操作受限于磁盘阵列中最慢盘片的速度，而JBOD的磁盘操 作均独立，因而平均读写速度髙于最慢盘片的读写速度。需要强调的是，各个 磁盘的性能多少总存在一些差异，即使同一品牌也不例外。针对某一Yahoo！集 群的评测报告表明，在一个测试 (Gridmix)中, JBOD比 RAID 0快 10%,在另一测试（HDFS写吞吐量)中，JBOD 比 RAID 0 快 30%。 最后，如果JBOD配置的某一磁盘出现故障，HDFS还可以忽略该磁盘，继续工 作。相比之下，RAID的某一盘片故障会导致整个磁盘阵列不可用。 |
Hadoop的主体用Java语言写成，能够在任意一个安装了 JVM的平台上运行。但 由于仍有部分代码(例如控制脚本)需在Unix环境下执行，因而Hadoop并不适宜在 非Unix平台上运行供生产用。
事实上，Windows操作系统主要作为一个开发平台(安装了 Cygwin之后），而非生 产平台。
一个Hadoop集群到底应该有多大？这个问题并无确切答案。但是，Hadoop的魅 力在于用户可以在初始阶段构建一个小集群(大约10个节点），并随存储与计算需 求增长持续扩充。从某种意义上讲，更恰当的问题是：你到底需要多快的集群？以 下举一个关于存储的例子，用户可以有更深的体会。
假如数据每周增长1TB。如果采用三路HDFS复制技术，则每周需要增加3TB存 储能力。再加上一些中间文件和日志文件(约占30%),基本上相当于每周增加一台 机器(2010年的髙端机型）。实际上，用户无需每周购买一台新机器并将其加入集 群。上述粗略计算的意义在于让用户了解集群的规模：在本例中，保存两年数据大 致需要100台机器。
对于一个小集群（几十个节点）而言，在一台master机器上运行namenode和 jobtracker通常没问题（前提是至少一份namenode的元数据另存在远程文件系统 中）。随着HDFS中的集群和文件数不断增长，namenode需要使用更多内存，因此 namenode和jobtracker最好分别放在不同机器中。
辅助namenode可以和namenode运行在同一机器之中，但是同样由于内存使用的 原因(辅助namenode和主namenode具有相同的内存需求），二者最好运行在独立的 硬件之上，特别是对于大规模的集群。
网络拓扑
通常，Hadoop集群架构包含两级网络拓扑，如图9-1所示。一般来说，各机架装 配30~40个服务器，共享一个1 GB的交换机(该图中各机架只画了 3个服务器)各 机架的交换机又通过上行链路与一个核心交换机或路由器互联。这个架构的一突出 特点是：同一机架内部节点间的总带宽要远髙于不同机架间节点的带宽。
图9-1.Hadoop集群的典型二级网络架构
机架的注意事项
为了达到Hadoop的最佳性能，配置Hadoop系统以让其了解网络拓扑状况就极为 关键。如果集群只包含一个机架，就不需要进行配置，因为这种情况就是默认情 况。但是对于多机架的集群来说，描述清楚节点-机架间的映射关系就很有必要。 这样的话，当hadoop将 MapReduce任务分配到各个节点时，会倾向于执行机架内 的数据传输(拥有更多带宽），而非跨机架数据传输。HDFS将能够更加智能地放置 复本(replica),以取得性能和灵活性的平衡。
节点和机架这样的“网络位置”(location)以树的形式来表示，这种树形结构能够体 现出各个位置之间的网络“距离”,namenode使用网络位置来确定在哪里放置块 的复本;Jobtracker根据网络 位置来查找最近的复本，将它作为map任务的输入，并调度到tasktracker上 运行。
在图9-1所示的网络中，机架拓扑由两个网络位置来描述，即/交换机1/机架1和/ 交换机1/机架2。由于该集群只有一个顶级路由器，这两个位置可以简写为/机架1 和/机架2。
Hadoop配罝需要通过一个Java接口 DNSToSwitchMapping来记录节点地址和网络位置之间的映射关系。该接口定义如下：
public interface DNSToSwitchMapping { public List<String> resolve(List<String> names);}
参数names是一个lP地址列表，resolve()函数的返回值是对应网络位置字符串 列表。topology.node.switch.mapping.impl 配置属性实现了 DNSToSwitchMapping 接口，namenode和jobtracker均采用它来解析工作节点的网络位置。
在上例的网络拓扑中，可将节点1、节点2和节点3映射到/机架1,将节点4、节点5和节点6映射到/机架2中。
但是，对于大多数安装来说，用户不需要再额外实现接口，只需使用默认的 ScriptBasedMapping实现即可，它运行用户定义的脚本来描述映射关系。脚本 的存放路径由属性topology.script.file.name控制。脚本接受一系列输入参 数，描述带映射的主机名称或lP地址，再将相应的网络位置以空格分开，输出到 标准输出_。用户可以参考Hadoop wiki的一个例子，网址为http:"wiki.apache.org/ hadoop/ topology_rack_awareness_scripts。
如果没有指定脚本位置，默认情况下，会将所有节点映射到单个网络位置，即 /default-rack。
