Hadoop机架感知

不正狼

背景
　　最近在整理以前学过的大数据相关知识，今天从Hadoop的机架感知开始，Hadoop机架感知的实现有2种方式：
　　1）、通过实现一个Java接口DNSToSwitchMapping，然后在core-site.xml配置文件中配置net.topology.node.switch.mapping.impl，其值是实现DNSToSwitchMapping的类的全路径，例如：
　　

　　net.topology.node.switch.mapping.impl
　　com.inspur.rackawar.test.MyDNSToSwitchMapping
　　
　　

　　2）、大多数安装并不需要额外实现新的接口，只需要使用默认的ScriptBasedMapping实现即可，它运行用户定义的脚本来描述映射关系。脚本的存放路径通过core-site.xml文件中的配置项topology.script.file.name控制。只要不是非常复杂的业务，我个人推荐使用第二种方式，灵活简单。
　　Hadoop的分布式集群通常包含非常多的服务器，由于受到机架槽位和交换机网口的限制，通常大型的分布式集群都会跨好几个机架，由多个机架上的服务器共同组成一个分布式集群。机架内的服务器之间的网络速度通常都会高于跨机架服务器之间的网络速度，并且机架之间服务器的网络通信通常受到上层交换机间网络带宽的限制。
　　具体到Hadoop集群，由于hadoop的HDFS对数据文件的分布式存放是按照分块block存储，每个block会有多个副本(默认为3)，并且为了数据的安全和高效，所以hadoop默认对3个副本的存放策略为：
　　第一个block副本放在和client所在的node里（如果client不在集群范围内，则这第一个node是随机选取的）。
　　第二个副本放置在与第一个节点不同的机架中的node中（随机选择）。
　　第三个副本放置在与第一个副本所在节点同一机架的另一个节点上。
　　如果还有更多的副本就随机放在集群的node里。
　　这样的策略可以保证对该block所属文件的访问能够优先在本rack下找到，如果整个rack发生了异常，也可以在另外的rack上找到该block的副本。这样足够的高效，并且同时做到了数据的容错。
　　但是，hadoop对机架的感知并非是自适应的，亦即，hadoop集群分辨某台slave机器是属于哪个rack并非是智能感知的，而是需要hadoop的管理者人为的告知hadoop哪台机器属于哪个rack，这样在hadoop的namenode启动初始化时，会将这些机器与rack的对应信息保存在内存中，用来作为对接下来所有的HDFS的写块操作分配datanode列表时（比如3个block对应三台datanode）的选择datanode策略，做到hadoop allocate block的策略：尽量将三个副本分布到不同的rack。
　　接下来的问题就是：通过什么方式能够告知hadoop namenode哪些slaves机器属于哪个rack？以下是配置步骤。

配置
　　默认情况下，hadoop的机架感知是没有被启用的。所以，在通常情况下，hadoop集群的HDFS在选机器的时候，是随机选择的，也就是说，很有可能在写数据时，hadoop将第一块数据block1写到了rack1上，然后随机的选择下将block2写入到了rack2下，此时两个rack之间产生了数据传输的流量，再接下来，在随机的情况下，又将block3重新又写回了rack1，此时，两个rack之间又产生了一次数据流量。在job处理的数据量非常的大，或者往hadoop推送的数据量非常大的时候，这种情况会造成rack之间的网络流量成倍的上升，成为性能的瓶颈，进而影响作业的性能以至于整个集群的服务。
　　要将hadoop机架感知的功能启用，配置非常简单，在namenode所在机器的core-site.xml配置文件中配置一个选项：
　　

　　topology.script.file.name
　　/software/hadoop/etc/hadoop/topology.py