【Hbase】Hbase数据迁移方案及引发的一系列问题

公司需要对Hbase中每个月的数据做离线备份，备份方案刚开始也调研了好几种，最终选择的基于Snapchat的方式。先简单说一下Hbase数据迁移。

数据迁移

平时难免会遇到数据迁移的需求。Hbase官方提供了一些数据迁移方案https://hbase.apache.org/2.1/book.html#tools，包括，Export，Import工具、CopyTable工具，datax，flinkx这些工具的原理基本都是Scan出数据然后写到目标表，这种方案的的坏处很明显，大数据的写入必定对集群正常业务造成影响。

所以官方给了另外一种方式，BulkLoadhttps://hbase.apache.org/2.1/book.html#arch.bulk.load，这种方式的原理就是提前将数据转换成为HFile，直接将数据上线到Hbase，这种方式的解决了大数据量写入的问题，几乎不影响集群。如果是同Hbase数据迁移，就没必要了，我们采用Snapchot 快照的方式，大致流程如下。

// 导出快照 指定-copy-to参数 导出到另一个集群的HDFS
hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -copy-to
//然后将导出的快照文件复制到相应的目录下，刷新Hbase webui会看见Hbase自动识别了Snapshot
//有两个目录 /hbase/.hbase-snapshot 元数据目录
//hbase/archive/data/ 数据目录
hadoop fs -mv /tmp/xxxx /hbase/.hbase-snapshot
hadoop fs -mv /tmp/xxxx/archive/data /hbase/archive/data/default
//恢复快照
restore_snapshot 'table'
//合并
major_compact 'youtube'
//删除快照
delete_snapshot 'snap'

迁移数据问题

Locality低

locality=该文件存储在本地机器的字节数之和 / 该文件总字节数，说白了就是这个regionserver机器上的数据有多上在本机器的datanode上，这个值在0，1之间，为1的话说明所有文件就在本地。这样可以使用HDFS的Short Circuit Read机制，不走TCP进行读取。

这时我们可以用过手动触发major compact，来让集群开始合并（这里应当注意compact吞吐量设置，避免大量抢占集群带宽，导致影响写入），此时会将数据从hdfs://hbase/archive/data/default下移动到hdfs://hbase/data/default下。Locality也会在compact完成之后变为1，也就是所有的数据都在regionserver本地。

 

原本20个region，Compact之后变成了100个

合并时发现有大量的region split，导致某个table的region数量增加，region数据增加会增大对内存的使用。

经过一番研究，这个行为跟hbase.hregion.max.filesize这个参数有关，意为单个Hfile最大文件大小。如果Compact时，hbase发现copy过来的table中region超过这个大小，就会自动拆分掉。之后修改了这个参数，Compact完成之后就没有出现拆分region的情况。