版权声明：本文为博主原创文章，未经博主允许不得转载。https://www.jianshu.com/p/6be827b25cb1
【一、背景】
按照中心总体计划，目前部署在生产区的运营大数据集群需要搬迁至万国机房。
本次采用的搬迁的方案是通过万国机房的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; 检查两个集群反馈结果是否一致
也可联系应用发起一笔查询，检查返回结果是否正确。