作者:安徒生笔下苍老了谁1_120 | 来源:互联网 | 2023-09-18 12:17
Hadoop2.6.0HDFSRackAwareness(机架感知)原理与配置步骤详解前言: 多副本前提下,在访问HadoopHDFS集群时,访问速度直接受到Datanode选取
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
在访问者client对HDFS进行写访问时,执行如下原则:
副本数 = 1时:
- 首先挑选与client相同Host的Datanode进行写操作;
- 如果没有,则挑选相同Rack的Datanode;
- 如果再没有,则随机挑选一个Datanode;
副本数 = 2时:
- 第一个副本按照以上原则选取Datanode进行写操作;
- 第二个副本选取一个与第一副本不同Rack的Datanode进行写操作;
副本数 = 3时:
- 第一、第二副本按照以上原则选取Datanode;
- 第三个副本选取与第一个副本同Rack的不同Datanode进行写操作;
副本数 >= 4时:
- 前三个副本按照以上原则选取Datanode;
- 从第四个副本开始,随机选取Datanode进行写操作;
每个节点只保留一份副本,每个Rack不超过两个副本。
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的算法是:
- 与clientMachine同Host的Datanode,weight = 0;
- 与clientMachine不同Host,但是同Rack的Datanode,weight = 2;
- 与clientMachine不同Rack的Datanode,weight = 4;
——实际上就是client到目标Datanode路径长度,如果NetworkTopology类实现了Datacenter,那么对不同Datacenter的Datanode,weight = 6;
二、HDFS实现Rack Awareness的技术途径
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
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
基于配置文件的静态解析
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
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文件读访问的优化。
以上内容引用部分均以文字说明或链接方式给出。
欢迎转载,转载请联系我并注明来源。