大数据集群机房搬迁数据迁移

【一、背景】

按照中心总体计划，目前部署在生产区的运营大数据集群需要搬迁至万国机房。

本次采用的搬迁的方案是通过万国机房的72台物理主机上新建运营大数据集群，老集群应用数据同步至新集群的方式，之后应用进行迁移。确保数据不丢失，应用无感知。

本次变更完成新集群的搭建以及存量数据的同步。本文只对数据同步方案进行展开。

【二、迁移思路】

1. 搭建新集群

2. 将老集群中的数据全量拷贝到新集群

3. 由于在进行全量拷贝过程中，老集群数据量较大，需要的时间比较长，老集群又会有新的数据被写入，因此需要进行增量拷贝

4. 增量拷贝的数据量相对比较少，需要的时间比较短。可以迭代多次增量拷贝，直到最终增量拷贝的时间到了一个可接受的时间范围。

5. 选择合适的时间点，老集群停止应用，确保没有新数据写入，进行增量拷贝。（这里如果存在应用数据补录机制，也可以通过数据补录功能，将数据进行完善）

6. 增量拷贝完成之后，理论上新老集群数据一致，进行数据一致性检查

7. 进行集群切换

8. 业务端可以重写最近几天的数据，以确保数据是正确的

【三、迁移方案】

运营大数据集群上的组件包括hdfs、hbase、hive、impala、spark，因此计划对HDFS和HBase数据进行分开迁移。

这里要提一下，似乎也可以使用hadoop distcp方式复制HDFS上整个/hbase目录以备份数据。但是不推荐这种方案，原因有三：

1、该操作在复制文件的过程中会忽略文件的状态；

2、用户可能在memstore的刷写操作过程中复制数据数据，这与会导致数据中混杂新旧多种文件；

3、该操作会导致用户忽略在内存中还没有被刷写的数据。

低层次复制操作只操作那些已经持久化的数据。一种解决办法是禁止对这张表的写操作，明确地刷写这张表的内存，然后再复制HDFS。然而禁止对表的操作无法保证对业务的无感透明，因此对hbase的迁移采用snapshot方案。

【snapshot介绍】

快照是对表当前元数据做一个克隆，因为不实际拷贝数据，所以整个过程是很快的。主要分三个步骤：

1、加锁：对象是regionserver的memstore，目的是禁用在创建快照过程中的DML操作；

2、刷盘：刷盘是将当前还在memstore中的数据刷写在HDFS上，以保证数据的完整性；

3、创建指针：创建对HDFS文件的指针