HBASE表迁移之snapshot、hashtable和synctable、replication

对于生产环境中的HBASE表做数据迁移的话不建议使用CopyTable，CopyTable实质上是scan hbase表，对regionserver造成的压力太大，会影响线上的查询写入。而snapshot则是快照，只会映射出来一份元数据信息，exportSnapshot的时候会根据元数据信息去寻找对应的HFile，然后通过MapReduce导入到另一个集群的hbase中生成对应的快照。

snapshot用于历史数据迁移，命令如下：

对于开启了kerberos的集群来说，建议kinit成hbase服务的principal之后再进行操作。
在源集群操作：
1、进入hbase shell
2、create_snapshot 'tableA','snapshotA'
3、退出hbase shell
在目标集群操作：
1、进入hbase shell
2、create 'tableA','cf1'建上与源集群相同的表

在源集群操作：
4、hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -Dmapreduce.job.queuename=root.tmdsj -snapshot snapshotA -copy-to hdfs://ip:8020/hbase -mappers 10
还有一些其他的配置，比如可以改权限、所属用户、重命名等，大家可以hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -help查看
在目标集群操作：
1、进入hbase shell
2、restore_snapshot 'snapshotA'
3、scan 'tableA',LIMIT => 10检查数据是否过来了

snapshot初始化好历史数据之后便需要对增量数据做处理，有两种情景：

1、hbase表为批量增量更新的，并且进入Hbase的方式为Bulkload这种不写WAL日志的方式的话，建议使用hashtable和synctable，这个可以直接指定开始时间戳和结束时间戳，当然，若是你的数据根据rowkey是有序的，那也可以指定startrow和endrow。

源集群使用hashtable生成增量数据文件：
hbase org.apache.hadoop.hbase.mapreduce.HashTable --batchsize=32000 --starttime=1561910400000 --endtime=1562601600000 --families=f1 dl_zz:tg_all_wms_in /tmp/dl_zz_tg_all_wms_in

目标集群使用syncTable将源集群的增量文件拉过来并写入hbase：
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --dryrun=true --sourcezkcluster=xx,xx,xx:2181:/hbase  --targetzkcluster=xx,xx,xx:2181:/hbase hdfs://xxx:8020/tmp/dl_zz_tg_all_wms_in dl_zz:tg_all_wms_in(源表名) dl_zz:tg_all_wms_in(目标表名)

2、hbase表为实时进数的，(1)使用replication的方式向备份集群做同步。用这种方式需要做好replication status的监控，避免replication处理WAL日志堆积导致数据过不来。另外需要检查空的WAL日志文件，replication遇见空的WAL日志会卡住，可以在hbase中配置上replication.source.eof.autorecovery=true，这个参数可以自动跳过为空的WAL日志。(2)也可直接再起一个kafka consumer往备集群hbase也写数。

两集群都打开replication功能
在源集群操作：
add_peer 'test_rep',"xx,xx,xx:2181:/hbase","test_table:f1"
注意：
添加peer的时候就要指定table和family，否则会将Lily中的数据也同步到目标集群中