Hadoop 2.6.0 HDFS Rack Awareness（机架感知）原理与配置步骤详解

Hadoop 2.6.0 HDFS Rack Awareness（机架感知）原理与配置步骤详解

前言：
  多副本前提下，在访问Hadoop HDFS集群时，访问速度直接受到Datanode选取策略的影响。Hadoop HDFS提供了一种Rack Awareness机制，以便于粗略计算Client到Datanode的访问开销。本文在Ambari环境下详细分析、介绍两种配置实现机架感知的途径。
（本文基于Hadoop 2.6.0举例）

一、Rack Awareness（机架感知）原理

---

  关于Rack Awareness的原理，官方文档有比较初步的介绍，简单来说就是在Namenode上维护一个树状数据结构的NetworkTopology对象，用来映射Rack、Datanode之间的关系，当Client通过Namenode访问Datanode时，通过一定的策略计算得到访问各个Replication所在Datanode的“距离”。因为我们总是会“认为”跨网段、跨Rack访问是会消耗更多的带宽资源、导致更大的访问延时的。

一个HDFS Network Topology的例子

图中有两种节点，Innernode和Datanode,其中Innernode可以是root节点，可以是Datacenter、也可以是Rack，代表着所有非数据实体（switch/router）的节点，Innernode的特点是它所有的叶子节点都是Datanode；Datenode的特点是它没有子树或者自己的叶子节点，它本身只能是叶子节点。
在典型的部署工具中，如Ambari、ClouderaManager，都集成了Rack（机架）信息的管理。实际上，更常见的一种NetworkTopology是这样的三层结构：

一种常见的结构

那么，每一个节点都可以用类似文件路径的方式来表示它的定位，比如 /Rack1/Dn1、/Dc2/Rack2/Dn4

• HDFS的写访问机制：

在访问者client对HDFS进行写访问时，执行如下原则：
副本数 = 1时：

1. 首先挑选与client相同Host的Datanode进行写操作；
2. 如果没有，则挑选相同Rack的Datanode；
3. 如果再没有，则随机挑选一个Datanode；

副本数 = 2时：

1. 第一个副本按照以上原则选取Datanode进行写操作；
2. 第二个副本选取一个与第一副本不同Rack的Datanode进行写操作；

副本数 = 3时：

1. 第一、第二副本按照以上原则选取Datanode；
2. 第三个副本选取与第一个副本同Rack的不同Datanode进行写操作；

副本数 >= 4时：

1. 前三个副本按照以上原则选取Datanode；
2. 从第四个副本开始，随机选取Datanode进行写操作；

每个节点只保留一份副本，每个Rack不超过两个副本。

• HDFS的读访问机制：

HDFS在读取文件的时候会首先获取client的IP，保存在一个clientMachine的字符串对象中，如果是REST调用，则clientMachine就是REST请求发起者，如果是JAVA API访问，clientMachine就是RPC Client。
然后DatanodeManager类会以clientMachine为参数，到NetworkTopology对象里去检索计算它到各个保存有replication的Datanode的距离weight，然后根据weight再进行排序，最后返回给DFSClient进行读取，从而实现“就近”访问。
维护网络拓扑结构的NetworkTopology类是可以自定义的，类名在core-site.xml的net.topology.impl字段里定义，如果该字段未定义，则默认是类org.apache.hadoop.net.NetworkTopology。默认类的计算weight的算法是：

1. 与clientMachine同Host的Datanode，weight = 0；
2. 与clientMachine不同Host，但是同Rack的Datanode，weight = 2；
3. 与clientMachine不同Rack的Datanode，weight = 4；

——实际上就是client到目标Datanode路径长度，如果NetworkTopology类实现了Datacenter，那么对不同Datacenter的Datanode，weight = 6；

---

二、HDFS实现Rack Awareness的技术途径

1. Java类直接静态解析

由core-site.xml中的 net.topology.node.switch.mapping.impl字段指定一个自定义实现DNSToSwitchMapping接口类的类：
以下是javashooter给出的一个简单例子：

public class JavaTestBasedMapping implements DNSToSwitchMapping {  
  
    //key:ip value:rack  
    private static ConcurrentHashMap cache = new ConcurrentHashMap();  
      
    static {  
        //rack0 16  
        cache.put("192.168.5.116", "/ht_dc/rack0");  
        cache.put("192.168.5.117", "/ht_dc/rack0");  
        cache.put("192.168.5.118", "/ht_dc/rack0");  
        cache.put("192.168.5.120", "/ht_dc/rack0");  
        cache.put("192.168.5.121", "/ht_dc/rack0");  
        cache.put("host116", "/ht_dc/rack0");  
        cache.put("host117", "/ht_dc/rack0");  
        cache.put("host118", "/ht_dc/rack0");  
        cache.put("host120", "/ht_dc/rack0");  
        cache.put("host121", "/ht_dc/rack0");  
    }  
      
    @Override  
    public List resolve(List names) {  
        List m = new ArrayList();  
          
        if (names == null || names.size() == 0) {  
            m.add("/default-rack");  
            return m;  
        }  
          
        for (String name : names) {  
            String rack = cache.get(name);  
            if (rack != null) {  
                m.add(rack);  
            }  
        }  
          
        return m;  
    }  
}  

core-site.xml文件相应的字段修改如下：

    topology.node.switch.mapping.impl
    com.dmp.hadoop.cluster.topology.JavaTestBasedMapping

2. Java调用外部脚本解析mappingFile

HDFS默认使用的是内置的 org.apache.hadoop.net.ScriptBasedMapping 类，用来调用外部脚本来解析net.topology.script.file.name字段指定的数据文件。

以下是官方文档给出的bash脚本和数据文件示例（为了强调是bash脚本，我特意增加了脚本的#-bang）：

#!/bin/bash
#mapping.sh
HADOOP_CONF=/etc/hadoop/conf 

while [ $# -gt 0 ] ; do
  nodeArg=$1
  exec< ${HADOOP_CONF}/topology.data 
  result="" 
  while read line ; do
    ar=( $line ) 
    if [ "${ar[0]}" = "$nodeArg" ] ; then
      result="${ar[1]}"
    fi
  done 
  shift 
  if [ -z "$result" ] ; then
    echo -n "/default/rack "
  else
    echo -n "$result "
  fi
done 

dataFile: mapping.data

hadoopdata1.ec.com     /dc1/rack1
hadoopdata1            /dc1/rack1
10.1.1.1               /dc1/rack2

core-site.xml文件相应的字段修改如下：

    topology.node.switch.mapping.impl
    org.apache.hadoop.net.ScriptBasedMapping


    net.topology.script.file.name
    mapping.sh

3. 基于配置文件的静态解析

HDFS内置的类org.apache.hadoop.net.StaticMapping实现了对core-site.xml
hadoop.configured.node.mapping配置项定义的主机/rack映射关系的解析，相关配置项的格式为：

    topology.node.switch.mapping.impl
    org.apache.hadoop.net.StaticMapping


    hadoop.configured.node.mapping
    192.168.6.10=/rack1,192.168.6.11=/rack2

4. TableMapping解析

HDFS内置的 org.apache.hadoop.net.TableMapping 类，实现的是对mappingFile的直接解析，mappingFile的格式如下：

192.168.6.10  /rack1
192.168.6.11  /rack2

mappingFile由net.topology.table.file.name配置项定义

几种方法各有优缺点，实际运用中可以灵活组合使用。Ambari和ClouderaManager默认使用的都是ScriptBasedMapping类调用脚本解析。

三、利用Rack Awareness机制对HDFS读取访问进行优化

  有了对以上的机制了解，就可以做一些工作来优化HDFS的读取流程，因为在很多情况下，HDFS的用户在物理上是跟Datanode节点同一网段的，这样可以视作是同一个Rack，而因为代表用户的ClientMachine没有Rack信息，在NetworkTopology中会被视作与所有Datanode不同Rack，这显然是不合理的，通过阅读源码，发现DatanodeManager类中有对非Datanode的节点Rack信息的处理，所以，可以考虑把clientMachine引入NetworkTopology，但不归入Datanode，同样作为叶子节点参与路径长度weight的计算，这样就能够更加科学的对包含数据副本的Datanode进行排序，实现读速度优化的目标。这里就不贴源码献丑了。
  另外，还可以对通过修改net.topology.impl改变Hadoop使用的NetworkTopology工具类，自己设计构造网络拓扑结构的算法，实现对具体场景下HDFS文件读访问的优化。

以上内容引用部分均以文字说明或链接方式给出。
欢迎转载，转载请联系我并注明来源。