基于HDFS的分布式存储策略分析

王来　翟健宏

摘 要：本文重点对HDFS机架感知和副本存放策略方面对HDFS分布式存储进行剖析。副本存放策略和机架感知主要通过Datanode节点形成的树状网络拓扑图来让Namenode节点获取，从而确定副本存放的位置，这样方式保证了对于数据的极高的容错性的同时也兼顾了数据本地化，即提高了数据在集群网络中的传输效率。基于此，提出一个设想，希望通过对副本存放策略的深入挖掘，根据Datanode数据节点的实时状态信息，实现对于数据块副本的定向存储，再由数据驱动任务分配，来为每一个Datanode数据节点分配更适合的任务，从而达到负载均衡提高资源利用率的作用。

关键字：HDFS；分布式存储；副本存放策略；数据驱动

中图分类号：TP391.41 文献标识码：A 文章编号：2095-2163（2015）05-

Abstract： This article focuses on the strategy of ReplicationTargetChooser and Rack-Awareness to analyze HDFS distributed storage. To realize the strategy of ReplicationTargetChooser and Rack-Awareness， the HDFS forms a network topology tree of Datanode primarily to let Namenode nodes determine the location of replication， in such a way to ensure that for extremely high data fault tolerance while taking into account the data locally， and to improve the efficiency of data transmission in the cluster network. Based on this， the paper proposes an idea， hope to learn more of the strategy of ReplicationTargetChooser， based on real-time status information Datanode nodes to achieve the orientation for the data block， data-driven task redistribution to Datanode data for each node assign tasks better suited to achieve the effect of load balancing and improve resource utilization.

Keywords： HDFS； Distributed Storage； Replications Strategy； Data-driven

0 引 言

在二十一世纪的今天，社会已处于信息时代，其中的每一天都会产生海量的数据，如何对这些海量数据进行存储和利用，即已成为信息科技工作者们频繁遭遇并日渐关注的热点研究问题。然而无论在存储空间，存储速度方面，还是在数据的存储安全方面，传统的文件系统都已经达不到时下的处理要求[1]。直到近年来Hadoop的出现，这一问题才获得了突破性的解决办法。Hadoop提出了一种存储和处理大规模海量数据的现实有效方案，正因如此，Hadoop受到了Google，Yahoo，亚马逊等知名IT公司的热捧，而国内的一些公司如腾讯、阿里、百度、华为等都将Hadoop作为公司处理海量数据的一种解决方案[2]。其中的HDFS分布式文件系统是Hadoop的核心组件，也是解决大规模海量数据存储和利用的重要技术手段。

因此，深入了解HDFS分布式文件系统的存储策略，对于未来应用与改善HDFS分布式文件系统有着重要意义。

1 副本机制

HDFS将每一个文件的数据进行分块存储，同时每一个数据块保存有多个副本，具体副本的个数可在hdfs-site.xml中dfs.replication属性中配置[3]。相应数据块副本分布在不同的机器节点上，这种数据分块存储+副本的策略即是HDFS保证可靠性和性能的关键，主要是因为：

（1）文件分块存储之后按照数据块来读，提高了文件随机读的效率和并发读的效率；

（2）保存数据块若干副本到不同的机器节点，在实现可靠性的同时，也提高了同一数据块的并发读效率；

（3）数据分块是高度切合MapReduce中任务切分的思想。此处，副本的存放策略又是HDFS实现高可靠性和高性能的重点决定性主题。

2 机架感知

HDFS采用一种称为机架感知的策略来改进数据的可靠性、可用性和网络带宽的利用率。通过一个机架感知的过程，Namenode可以确定每一个Datanode所属的机架id。实际上，Namenode把注册的Datanode节点按照相关的ip地址存储到一个树状网络拓扑图中，然后Namenode调用ReplicationTargetChooser来为每一个数据块副本选择合适的存储节点。但是，Hadoop对机架的感知并非是自适应的，即Hadoop集群分辨某台slave机器是属于哪个rack并非是系统自我感知的，而是需要Hadoop的管理者人为告知Hadoop哪台机器属于哪个rack，这样在Hadoop的Namenode启动初始化时，就会将这些机器与rack的对应信息保存在内存中[4]。

默认情况下，Hadoop的机架感知是没有被启用的。所以，在通常情况下，Hadoop集群的HDFS都是随机选择机器的，也就是说，很有可能在写数据时，Hadoop将第一块数据block1写到了rack1上，然后在随机的选择下将block2写入到了rack2下，此时两个rack之间产生了数据传输的流量，再接下来，也在随机的情况下，又将block3重新又写回了rack1，此时，两个rack之间又产生了一次数据流量。这样job的数据处理量将非常巨大，或者向Hadoop推送的数据量也迹近庞大的时候，就会造成rack之间的网络流量成倍上升，由此成为性能的瓶颈，进而影响作业的性能以至于整个集群的服务。

要对Hadoop机架感知进行功能启用，配置非常简单，即在Namenode所在机器的core-site.xml配置文件中配置一个选项：topology.script.file.name，如图1所示，这个属性的value是一个路径，该路径指向一个可执行文件（或者脚本）， 该文件可以由Python或者C或C++实现编写。如果topology.script.file.name没有设定，则每个IP都会翻译成/default-rack[5]。

该可执行文件（或者脚本）需要提供IP->rackid的翻译。Namenode通过翻译结果得到集群中各个Datanode机器的rackid。该可执行文件（或者脚本）接受一个参数，输出一个值。接受的参数通常为某台Datanode机器的IP地址，而输出的值则多为该IP地址对应的Datanode所在的rack，例如”/rack-1”。Namenode启动时，会判断该配置选项是否为空，如果非空，则表示已经用机架感知的配置，此时Namenode会根据配置寻找该脚本，并在接收到每一个Datanode的heartbeat时，将该Datanode的IP地址作为参数传给该脚本运行，再将得到的输出作为该Datanode所属的机架，保存到内存的一个map中[6]。

编写脚本的时候，需要将真实的网络拓扑情况和机架信息了解清楚后，通过该脚本将机器的IP地址正确地映射到相应的机架上去。一个简单的实现如图2所示，研究中设置了三个Datanode节点，将其分别设置在rack-1和rack-2。

重启Namenode，如果配置成功，脚本可以返回如： rack-1 类似的字符串，同时在Namenode日志中会输出：INFO org.apache.hadoop.net.NetworkTopology： Adding a new node： /rack1/192.168.56.2：50010 。

实际上，对用户来说有两种方式可以实现用户自定义的机架感知IP解析，其一就是上面的用户自行编辑脚本实现，也就是一种插件方式，即插即用；其二则是直接实现DNSToSwitchMapping接口，并将这个实现类配置到配置文件的项。就可扩展行而言，第一种方式为佳，就性能而言，第二种方式为佳，现实最终还将取决于用户自身的应用场景。

设计实现了机架感知后，Namenode就可以画出如图3所示的Datanode网络拓扑图，实际上就是对应Networktopology类的一个实例。图3中，D1，R1都是交换机，最底层的叶子节点是Datanode。则H1的rackid=/D1/R1/H1，H1的parent是R1，R1的parent是D1。这些rackid信息可以通过topology.script.file.name提供相应配置。而获得了这些rackid信息后，就可以计算出任意两台Datanode之间的距离：

3 副本存放策略

在大多数情况下，副本系数是3，HDFS的存放策略是将一个副本存放在本地机架节点上，还有一个副本存放在同一个机架的另一个节点上，最后一个副本则存放在不同机架的节点上。这种策略减少了机架间的数据传输，提高了写操作的效率。机架的错误要远远小于节点的错误，所以这种策略不会影响到数据的可靠性和可用性。与此同时，因为数据块只存放在两个不同的机架上，最终也就减少了读取数据时需要的网络传输总带宽。同时，在该种策略下，副本并不是均匀分布在不同的机架上：三分之一的副本在一个节点上，三分之二的副本在一个机架上，其它副本均匀分布在剩余机架中，从而在不损害数据可靠性和读取性能的情况下改进了写的性能。

在Hadoop-1.X版本中，Namenode是通过ReplicationTargetChooser类来为每一分数据块选择副本存放位置的，该类的一般处理过程如图4所示。

下面将逐一介绍HDFS副本存放策略所涉及的四个主要函数：

3.1选择一个本地节点

这里所说的本地节点是相对于客户端来说的，也就是说某一个用户正在通过一个客户端而将数据写入HDFS中，如果该客户端上有数据节点，那么就应该最优先考虑把正在写入的数据的一个副本保存在这个客户端的数据节点上，如此即被看作是本地节点，但是如果这个客户端上的数据节点空间不足或者是当前负载过重，则应该从该数据节点所在的机架中选择一个合适的数据节点作为此时这个数据块的本地节点。

3.2选择一个本地机架节点

选择本地机架节点和远程机架节点都需要以一个节点为参考，如果参考点为空，则从整个集群中随机选择一个合适的数据节点作为此时的本地机架节点[7]；否则就从参考节点所在的机架中随机选择一个合适的数据节点作为此时的本地机架节点。

3.3选择一个远程机架节点

选择一个远程机架节点就是随机选择一个合适的不在参考点所在机架中的数据节点，如果没有找到这个合适的数据节点的话，就只能从参考点所在机架中选择一个合适的数据节点作为此时的远程机架节点。

3.4随机选择若干数据节点

这里，随机选择若干个数据节点实际上指的是从某一个范围内随机地选择若干个节点，其具体实现需要利用NetworkTopology类的数据结构。随机选择所使用的范围本质上指的是一个路径，这个路径展现的是NetworkTopology所表示的树状网络拓扑图中的一个非叶子节点，随机选择针对的就是这个节点的所有叶子节点，即Datanode数据节点。

副本位置确定之后，便涉及到了数据的传输问题。HDFS对于Block的副本copy采用的是流水线作业的方式：client把数据Block只传给一个Datanode，这个Datanode收到Block之后，传给下一个Datanode，依次类推，最后一个Datanode就不需要下传数据Block了。所以，在为一个数据块确定所有的副本存放的位置之后，就需要确定这种数据节点之间流水复制的顺序，确定后的顺序应该使得数据传输时花费的网络延时最小。这是由ReplicationTargetChooser类来负责执行的。副本传输路径如图5所示。

4 结束语

企业数据不断增加，数据存储至关重要。传统文件系统存储在数据安全和效率上达不到企业数据存储要求。另外近年Hadoop 受到国内外各大公司青睐，并将其作为数据存储和数据处理的一个解决方案。而HDFS 作为Hadoop 的核心，主要负责数据存储，本文即重点针对基于HDFS 的分布式数据存储的数据块副本存放机制问题做了相关研究，描述了HDFS文件系统的副本机制，实现机架感知的相关配置原理，以及数据副本的存放机制，这里的关键是让主机能够知道集群存储节点的网络位置，并以此为依据，在数据块存储的时候选择合适节点存储，这样不仅保证数据安全性和可靠性，还提高了数据访问效率。

通过对HDFS副本存放策略的深入了解，笔者提出一个设想，因为HDFS分布式文件系统采用随机的副本放置策略，使得系统在运行一段时间后会出现数据分布不均衡的情况，从而降低数据的可靠性和读取速率.为解决HDFS默认副本放置策略存在的问题，对HDFS 副本放置策略实施一定改进：在副本放置选择时，根据Datanode数据节点发给Namenode节点的心跳解析出每个Datanode数据节点的实时状态信息，为每个数据块结合本地化原则，优先考虑发送给存储使用率低的Datanode数据节点，再将这些Datanode节点作为数据块的优先目标发送节点。

在确定数据块的目标发送节点后，研究需要实现数据块向Datanode节点的定向发送，而不是Hadoop默认状态下的随机选择目标Datanode数据节点。为了实现这一操作，根据HDFS机架感知的设置，因为用户可以自行设置Datanode数据节点的IP解析脚本，也就是用户可以自行构造Datanode数据节点的树状网络拓扑图。因此通过动态改变集群数据节点的树状网络拓扑图，研究即能实现数据块向Datanode节点的定向发送。

上述想法是笔者的一个设想，现在已经实现了对Datanode数据节点的树状网络拓扑图的自行构造操作，但后续的具体操作却仍未付诸实现，最终希望通过实验来得到基于数据驱动的副本存储策略，如此则将起到负载均衡和提高资源利用率的作用。

参考文献：

[1] LIAN Qiao， CHEN Wei， ZHANG Zheng. On the impact of replica placement to the reliability of distributed brick storage systems[C]//Proceedings of 25th IEEE International Conference on Distributed Computing Systems，[S.l.]：IEEE， 2005： 187-196.

[2] DEAN J， GHEMAWAT S. MapReduce： Simplied data processing on large clusters[C]//Proceedings of the 6th Symposium on Operating System Design and Implementation， New York： ACM Press， 2004： 137-150.

[3] ZHU Yifeng， JIANG Hong， WANG Jun， et al. HBA： Distributrd metadata management For large cluster-based storage systems[J]. IEEE Transactions On Parallel And Distributed Systems， 2008， 19（6）： 750-762.

[4] KON F. Distributed file systems past present and future a distributed file system for 2006[J]. Computer and Information Science， 1996， 3（6）： 1-12.

[5] KO B J. Scalable service differentiation in a shared storage cache[C]/ /Proc of the 23rd International Conference on Distributed Computing Systems. Washington，DC，USA：IEEE，2003： 184-194.

[6] 王跃. 基于Hadoop 分布式文件系统的分析与研究.计算机光盘软件与应用，2011（9）： 161-162.

[7] 翟永东. Hadoop 分布式文件系统（HDFS）可靠性的研究与优化[D].武汉： 华中科技大学， 2011.