HDFS数据迁移解决方案之DistCp工具的巧妙使用

前言

---

在当今每日信息量巨大的社会中,源源不断的数据需要被安全的存储.等到数据的规模越来越大的时候,也许瓶颈就来了,没有存储空间了.这时候怎么办,你也许会说,加机器解决,显然这是一个很简单直接但是又显得有些欠缺思考的办法.无谓的加机器只会带来无限上升的成本消耗,更好的办法应该是做到更加精细化的数据存储与管理,比如说非常典型的冷热数据的存储.对于巨大的长期无用的冷数据而言,应该用性能偏弱,但是磁盘空间富余的机器存,热数据则反之.数据的分类存储一定会带来数据的同步问题,假若我有2套集群,1个是线上的正在使用的集群,另外1个则是冷数据集群,我如何做定期的数据同步并且同时对业务方的使用影响完全透明呢?本文就给大家阐述一下本人的一个解决方案,供大家参考.

数据迁移使用场景

---

上小节中说到的冷热数据的同步只是数据迁移的一个表现场景,那么数据迁移还有其他哪些使用场景呢,如下:

• 冷热集群数据分类存储,详见上述描述.
• 集群数据整体搬迁.当公司的业务迅速的发展,导致当前的服务器数量资源出现临时紧张的时候,为了更高效的利用资源,会将原A机房数据整体迁移到B机房的,原因可能是B机房机器多,而且B机房本身开销较A机房成本低些等.
• 数据的准实时同步.数据的准实时同步与上一点的不同在于第二点可以一次性操作解决,而准实时同步需要定期同步,而且要做到周期内数据基本完全一致.数据准实时同步的目的在于数据的双备份可用,比如某天A集群突然宣告不允许再使用了,此时可以将线上使用集群直接切向B的同步集群,因为B集群实时同步A集群数据,拥有完全一致的真实数据和元数据信息,所以对于业务方使用而言是不会受到任何影响的.

上述3个使用场景中,其中第一点相比较于第二,三点来说可能稍微容易一些,但是想要完全做好也不简单.第三点数据的实时同步想比较第二点来说更加实际一些.因为如果公司要准备集群数据迁移了,一般都会提前通知,然后做逐步迁移,而且也肯定不会让原集群停止服务,所以采用数据慢慢同步的方式,等到数据彻底同步完了,才最终实现切换,达到最终的迁移目标.

数据迁移要素考量

---

当要做大规模的数据迁移的时候,需要做很多的前期准备工作,而且需要对很多因素,指标进行考量.以下是几个主要指标:

1.Bandwidth-带宽

---

在做大规模数据量的同步过程中,如何控制同步数据过程中所占用的网络带宽就显得非常的重要.带宽用的多了,会影响到线上业务的任务运行,带宽用的少了又会导致数据同步过慢的问题.所以这里会引发出另外一个问题,对于带宽的限流.也就是说,我要保证我的数据同步程序能保证限定在指定的网络传输速率下,如果你不做任何处理的话,那结果基本上就是网络有多少带宽我就用多少带宽的局面.

2.Performance-性能

---

性能问题同样也是一个很关键的问题,是采用简单的单机程序?还是多线程的性能更佳的分布式程序?显然后者是我们更想要的.

3.Data-Increment-增量同步

---

当TB,PB级别的数据需要同步的时候,如果每次以全量的方式去同步数据,结果一定是非常糟糕.增量方式的同步会是不错的选择,那么哪些情况下会导致数据发生增量变动呢

• 原始数据文件进行了Append追加写
• 原始数据文件被delete删除或rename重命名

可能会有人好奇这里为什么没有对原始数据进行改动的情况,这种case也会造成数据的变动啊,因为一般在海量数据存储系统中,例如HDFS,一般不会在原文件内容上做修改,要么继续追加写,要么删除文件,不会有类似RandomAccessFile的随机写的功能,所以做增量数据同步,只要考虑上述2个条件即可.上述条件中的第二点是非常容易判断出的,通过定期的快照文件或元信息文件一比就出来了,但是对于文件是否被进行了追加写或是其他的外界主动的修改操作的时候,我们如何进行判断呢,下面给出2个步骤:

• 第一步: 先比较文件大小,如果2个阶段文件大小发生改变,截取对应原始长度部分进行checksum比较,如果此checksum不变,则此文件必定发生过改变.
• 第二步: 如果文件大小一致,则计算相应的checksum,然后比较2者的checksum.

这种方式算得上是最保险的.

4.Syncable-数据迁移的同步性

---

数据迁移的过程中需要保证周期内数据是一定能够同步完的,不能差距太大.比如A集群7天内的增量数据,我只要花半天就可以完全同步到B集群,然后我又可以等到下周再次进行同步.最可怕的事情在于A集群的7天内的数据,我的程序花了7天还同步不完,然后下一个周期又来了,这样就无法做到准实时的一致性.其实7天还是一个比较大的时间,最好是能达到按天同步.

HDFS数据迁移解决方案: DistCp的使用

---

上面分析了很多数据迁移中的很多使用场景和可能出现的问题.但是从这里开始,是一个分水岭了,下部分的文章主要阐述HDFS中的数据迁移解决方案,面对上文中提到的诸多问题,HDFS中到底应该如何解决.如果你不是HDFS,Hadoop的专家,可能问题看起来有点棘手,但是没有关系,Hadoop内部专门开发了相应的工具,DistCp.在DistCp工具在HDFS中的定位就是来干这件事情的,从source filesystem到target filesystem的数据拷贝.DistCp在hadoop-tools工程下,作为独立子工程存在.在官方注释中,对于DistCp的解释如下:

 DistCp is the main driver-class for DistCpV2.
 For command-line use, DistCp::main() orchestrates the parsing of command-line
 parameters and the launch of the DistCp job.
 For programmatic use, a DistCp object can be constructed by specifying
 options (in a DistCpOptions object), and DistCp::execute() may be used to
 launch the copy-job. DistCp may alternatively be sub-classed to fine-tune
 behaviour. 

大意是通过命令行附带参数的形式,构造出DistCp的job,然后执行此Job.所以从这里可以知道,拷贝任务本身是一个MR的Job,已经把Hadoop本身的分布式执行的特性用上了.

DistCp优势特性

---

鉴于DistCp的特殊使用场景,程序设计者在此工具代码中添加了很多的独到的设计.下面针对上文提到的一些要素进行相应的阐述:

1.带宽限流

---

DistCp是支持带宽限流的,使用者可以通过命令参数bandwidth来为程序进行限流,原理类似于HDFS中数据Balance程序的限流.但是个人感觉做的比Balance稍微简化了一些.DistCp中相关类是ThrottledInputStream,在每次读操作的时候,做一些限流判断:

  /** {@inheritDoc} */
  @Override