深入理解Hadoop集群和网络

本文侧重于Hadoop集群的体系结构和方法，以及它与网络和服务器基础设施这件的关系。文章的素材主要来自于研究工作以及同现实生活中运行Hadoop集群客户的讨论。如果你也在你的数据中心运行产品级的Hadoop集群，那么我希望你能写下有价值的评论。

Hadoop集群部署时有三个角色：Client machines, Master nodes和Slave nodes。

Master nodes负责Hadoop的两个关键功能：数据存储（HDFS）；以及运行在这个数据之上的并行计算，又称为Map-Reduce。Name node负责调度数据存储，而Job Tracker则负责并行数据处理的调度（使用Map-Reduce技术）。Slave nodes由大量的机器组成，完成数据存储以及运行计算这样的脏活。每个slave node都运行Data node和Task Tracker daemon，这些slave daemon和master nodes的相应daemon进行通信。Task tracker daemon由Job Tracker管理，Data node Daemon由Name node管理。

Client机器包含了Hadoop集群的所有设置，但是它既不是Master也不是Slave。Client的角色是向集群保存数据，提交 Map-Reduce jobs（描述如何处理数据），获取查看MR jobs的计算结果。在小型集群中（40节点）你可能会发现一个物理机器扮演多个角色，比如既是Job Tracker又是Name node，在中等或者大规模集群中，一般都是用独立的服务器负责单独的角色。

在真正的产品集群中，不存在虚拟服务器和虚拟机平台，因为他们仅会导致不必要的性能损耗。Hadoop最好运行在 linux 机器上，直接工作于底层硬件之上。换句话说，Hadoop可以工作在虚拟机之上，对于学习Hadoop是一个不错的廉价方法，我本身就有一个6-node的Hadoop cluster运行Windows 7 laptop的VMware Workstation之上

上图是Hadoop集群的典型架构。机架服务器（不是刀锋服务器）分布在多个机架中，连接到一个1GB(2GB)带宽的机架交换机，机架交换机连接到上一层的交换机，这样所有的节点通过最上层的交换机连接到一起。大部分的服务器都是Slave nodes配置有大的磁盘存储 中等的CPU和DRAM，少部分是Master nodes配置较少的存储空间 但是有强大的CPU和大DRAM

本文中，我们不讨论网络设计的各种细节，而是把精力放在其他方面。首先我们看下应用的工作流程。

为什么会出现Hadoop？ 它又解决了什么问题？ 简单的说，是由于商业和政府有大量的数据需要快速分析和处理，如果我们把这些巨大的数据切分为小的数据块分散到多台计算机中，并且用这些计算机并行处理分配给他们的小块数据，可以快速的得到结果，这就是Hadoop能做的事情。

在我们的简单例子中，我们有一个大文件保存着所有发给客户服务部分的邮件，想要快速统计单词"Refund"被输入了多少次，这个结果有助于评估对退换货部门的需求，以指定相应对策。这是一个简单的单词计数练习。Client上传数据到集群(File.txt)，提交一个job来描述如何分析数据，集群存储结果到一个新文件(Result.txt)，然后Client读取结果文件。

没有加载数据，Hadoop集群就没有任何用途。所以我们首先从加载大文件File.txt到集群中以便处理。目标是能够快速并行处理许多数据，为了达到这个目的需要尽可能多的机器能够同时操纵文件数据。Client把数据文件切分成许多小blocks，然后把他们分散到集群的不同机器上。块数越多，用来处理这些数据的机器就越多。同时这些机器一定会失效，所以要确保每个数据块保存到多个机器上以防止数据丢失。所以每个数据块在存入集群时会进行复制。Hadoop的标准设定是集群中的每个block有三份copy，这个配置可以由hdfs-site.xml的dfs.replication 参数设置

Client把文件File.txt分成3块，对于每一块，Client和Name node协商获取可以保存它以及备份块的Data nodes列表。Client然后直接写block数据到Data node，Data node负责写入数据并且复制copy到其他的Data nodes。重复操作，直到所有的块写完。Name node本身不参与数据保存，Name node仅仅提供文件数据位置以及数据可用位置（文件系统元数据）

Hadoop引入了Rack Awareness的概念。作为Hadoop系统管理员，你能够手动定义集群中每一个slave Data node的rack号。为什么要把自己置于这种麻烦呢？有两个关键的原因：数据丢失和网络性能。记住每一个数据块都会被复制到多台Data node上，以防止某台机器失效导致数据丢失。有没有可能一份数据的所有备份恰好都在同一个机架上，而这个机架又出现了故障，比如交换机失效或者电源失效。为了防止这种情况，Name node需要知道Data nodes在网络拓扑中的位置，并且使用这个信息决定数据应该复制到集群的什么位置。

我们还假定同一机架的两台机器间相比不同机架的两台机器间 有更高的带宽和更低的网络延迟，在大部分情况下是正确的。机架交换机的上行带宽通常小于下行带宽。此外，机架内延迟通常低于机架间延迟。如果上面的假定成立，那么采用Rack Awareness既可以通过优化位置保护数据，同时提升网络性能，岂不是太cool了。是的，的确是这样，非常cool，对不对。

别急，Not cool的是Rack Awareness是需要手工定义的，并且要持续的更新它，并且保证这个信息精确。如果机架交换机可以自动提供它下面的Data node列表给Name node，那就更cool了。或者如果Data nodes可以自动告知Name node他们属于哪个交换机，一样很cool.

此外，让人感兴趣的是OpenFlow 网络，Name node可以请求OpenFlow控制器关于节点位置的拓扑情况。

Client准备写文件File.txt到集群时，把文件划分为块，块A为第一个块。Client向Name node申请写文件File.txt，从Name node获得许可，并且接收到一个Data nodes列表（3个表项），每一个Data nodes用来写入块A的一个copy。Name node使用Rack Awareness来决定这个Data nodes列表。规则是：对于每一个数据块，两个 copy存放在一个机架上，另外一个copy存放在另外一个机架上。