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

【一、背景】

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

本次采用的搬迁的方案是通过万国机房的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文件的指针，实际并不拷贝数据，snapshot只是对元数据信息进行克隆。

【四、操作步骤】

1、hdfs迁移

在新集群的的namenode中进入hdfs用户 su - hdfs

在老集群的namenode中使用命令 hadoop distcp -overwrite -i webhdfs://源集群cm节点ip：NameNode Web UI 端口/solr webhdfs://目标集群cm节点ip：NameNode Web UI 端口

2、hbase迁移

基本迁移思路是先使用snapshot在目标集群恢复出一个全量数据，再使用replication技术增量复制源集群的更新数据，等待两个集群数据一致后将客户端请求重定向到目标集群。

a、存量数据同步步骤

1）在源集群为表建立快照

hbase shell中执行snapshot，spanhost 'sourceTable','snapshotName'

hbase(main):018:0* snapshot 'tbl_common_his_trans','tbl_common_his_trans20190320'

0 row(s) in 16.7940 seconds

然后在/hbase根目录下会产生一个目录：/hbase/.hbase-snapshot/，子目录为各个表的快照。

查看快照

hbase(main):025:0* list_snapshots

hbase(main):001:0> list_snapshots

SNAPSHOT                                   TABLE + CREATION TIME                 

 AgentEvent0321                            AgentEvent (Thu Mar 21 14:37:29 +0800 2019)             

 AgentInfo0321                             AgentInfo (Thu Mar 21 14:37:29 +0800 2019)     

 AgentLifeCycle0321                        AgentLifeCycle (Thu Mar 21 14:37:29 +0800 2019)

 …………………………

snapshotStringMetaData", "snapshotTestTable", "snapshotTraceV2", "snapshotTraces", "test0321_back0321", "tsdb-meta-wallet0321", "tsdb-meta0321", "tsdb-tree-wallet0321", "tsdb-tree0321", "tsdb-uid-wallet0321", "tsdb-uid0321", "tsdb-wallet0321", "tsdb0321", "tsdb0322"]

2）使用ExportSnapshot工具可用将源集群的快照数据迁移到目标集群

ExportSnapshot是HDFS层面的操作，会调用MR进行数据的并行迁移，因此需要在开启MR的机器上进行迁移。HMater和HRegionServer并不参与这个过程。

因此不会带来额外的内存开销及GC开销。唯一可能会在数据拷贝阶段对带宽和I/O产生影响，这可以通过指定-bandwidth进行限制。

sudo -u hbase hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot tbl_common_his_trans20190320 -copy-to hdfs://目标namenode地址:8020/hbase -mappers 12 -bandwidth 10

…………

…………

这里提一句，直接在原表snapshot上执行export会影响集群性能，在业务场景对性能要求很高的情况下，可用先把老表clone成一个新表，再对新表进行迁移，以避免对原表的直接操作。

3）到目标集群恢复快照

restore_snapshot 'tbl_common_his_trans20190320'

当然，也可以在页面上执行操作：CM界面——>hbase>表浏览器——>选中目标表——>右侧选择——>从快照还原表

数据比对：

hbase(main):005:0> count 'StringMetaData'

Current count: 1000, row: \x00ysf-19.239.6.83\x00\x00\x00\x00\x00\x00\x00\x00\x00\x7F\xFF\xFE\x97\xEC\x0B=R\xFF\xFF\xFF\xFF                                          

……………………                                       

29413 row(s) in 1.2730 seconds

=> 29413

b、增量数据同步

add_peer：在源集群上设置向目标集群上replication数据。所有对于replication的shell操作，只对列族为REPLICATION_SCOPE=>"1"才有效。

hbase(main):007:0> add_peer 'bak','zk1,zk2,zk3:2181:/hbase'

hbase(main):008:0> list_peers

 PEER_ID CLUSTER_KEY ENDPOINT_CLASSNAME STATE TABLE_CFS

 bak zk1,zk2,zk3:2181:/hbase nil ENABLED nil

1 row(s) in 0.1260 seconds

hbase(main):009:0> disable 'test'

hbase(main):010:0> alter 'test',{NAME => 'cf',REPLICATION_SCOPE => '1'}

hbase(main):011:0> enable 'test'

【检查步骤】

1、HDFS一致性检查

HDFS的一致性检查，可以通过HDFS文件数目，以及大小两个维度确认数据的一致性。

文件数目比对

比对新老集群，拷贝的HDFS目录以及文件的数目是否一致。理论上，应该完全一致，否则应该排查是什么原因，进行解决。

文件数据量比对

逐一比对新老集群，拷贝的HDFS目录，文件的数据量大小。理论上应该完全一致。如果不一致，应该进行数据更新。

2、 Hive一致性检查

在完成数据拷贝之后，理论上新老集群两边的数据是一致的，这个时候，我们需要进行数据一致性的对比，来确认是否数据是一致的。挑选部分关键的表格进行抽查一致性比对，主要包含如下内容：

（1）数据量比对

挑选部分关键表格，比对新老集群数据量的大小，注意这里的数据量大小并不会完全一致，原因是因为两边hadoop，hive等组件的版本都不相同，在数据存储上面会有细微的变化，因此最终的数据量是不同的。这里主要比对的是数据量的量级是否一致。

（2）Hive表格条数比对

挑选部分关键表格 ，比对新老集群Hive表格记录数。记录数应该完全一致。如果不一致，则需要重新同步。

（3）关键SQL结果比对

挑选部分的关键SQL，或者编写部分SQL，分别在新老集群运行，运行结果应该完全一致。如果不一致，则需要分析原因，重新同步

（4）Hive表格数对比

对比拷贝列表中的hive表格数与实际新集群的hive表格数是否一致。

注意，由于本次大数据平台只迁移部分数据，因此两边的表格数可能不同，但是关键数据库的表格应该相同。

1、HDFS一致性检查

HDFS的一致性检查，可以通过HDFS文件数目，以及大小两个维度确认数据的一致性。

分别在新老集群下面执行如下命令

hadoop fs -du -h / # 统计文件大小

hadoop fs -count / # 统计文件数量，返回的数据是目录个数，文件个数，文件总计大小

hadoop fs -count /user 

hadoop fs -count /hdfs

hadoop fs -count /hbase

逐一比对新老集群，拷贝的HDFS目录，文件的数据量大小。

2、 Hive一致性检查

在完成数据拷贝之后，主要包含如下内容：

（1）数据量比对

主要比对的是数据量的量级是否一致。

登录CM界面，进入hive界面，选择数据库>库名>表格名，查看当前表格的rows数字是否一致。

或登录元数据库

mysql> use hive

select * from TBLS where TBL_NAME='各个应用的表格名';

（2）表格数对比

hive 分别进入新老集群的hive shell界面

show tables; 查看当前hive中有哪些表格，比对新老集群中的表格数目是否一致。

（3）Hive表格条数比对

挑选部分关键表格 ，比对新老集群Hive表格记录数。记录数应该完全一致。如果不一致，则需要重新同步。

挑选应用表格，例tbl_test

select count(*) from tbl_test;逐一对比新老集群的应用表格数据量是否一致。

（4）关键SQL结果比对

挑选部分的关键SQL，或者编写部分SQL，分别在新老集群运行，运行结果应该完全一致。如果不一致，则需要分析原因，重新同步

在新老集群中逐个表进行sql查询，检验数据是否一致。例如表名为tbl_test

select * from tbl_test limit 1; 检查两个集群反馈结果是否一致

也可联系应用发起一笔查询，检查返回结果是否正确。