<转载>HBase跨版本数据迁移总结

*本文结合客户案例，分享了5.5T数据迁移至腾讯云HBase使用以及数据迁移遇到的各类问题以及解决方法。
做者：王亮
出处：腾云阁文章

---

某客户大数据测试场景为：Solr相似画像的数据查出用户标签——经过这些标签在HBase查询详细信息。以上测试功能以及性能。

其中HBase的数据量为500G，Solr约5T。数据均须要从对方的集群人工迁移到咱们本身搭建的集群。因为Solr没有在咱们集群中集成，优先开始作HBase的数据迁移，如下总结了HBase使用以及数据迁移遇到的各类问题以及解决方法。

一.迁移过程遇到问题以及解决

客户HBase版本：Version 0.94.15
腾讯大数据套件HBase版本：Version 1.2.1
客户私有云系统版本（测试）：tlinux1.2
遇到的问题以及解决过程以下：

1.HBase运行异常现象一（date和hwclock）

HBase运行偶发不正常，出现组件中止运行的状况，看日志有说时间的差别等信息，但date查看彻底一致，想到多是硬件时间的差别问题，经过hwclock看，确实差别很大，经过hwclock -w调整后基本恢复。后确认初始化脚本中只对腾讯云环境的机器作了硬件时间同步，目前已优化。

2.HBase运行异常现象二（hostname 和/etc/resolv.conf）

HBase再次运行不正常，出现组件中止运行的状况。经过日志看以下错误
ERROR [regionserver//10.0.0.106:16020] regionserver.HRegionServer: Master passed us a different hostname to use; was=10.0.0.106, but now=host-10-0-0-106.openstacklocal
经过hostname看全部机器hostname均为内网IP，猜测多是网络交互的时候查询什么表致使出现的不一致，查看dns解析信息以下

有search openstacklocal的状况，猜想是虚拟机的异常行为，注释掉resolv.conf里相关search信息，停掉nscd服务后，重启HBase，再未出现这个错误，HBase运行彻底正常。

3.须要支持snappy的发现与修复过程：

迁移表的过程当中计划使用官方的import/export工具进行，第一步须要在目标集群建表，经过desc信息在目标集群建表完成后，list可看到表，经过scan查询后，没法查询内容，查日志有以下错误：
org.apache.hadoop.HBase.DoNotRetryIOException: Compression algorithm 'snappy' previously failed test.
经过google查询须要HBase支持snappy压缩算法，经过hadoop checknative发现集群默认确实不支持snappy算法（虽然安装snappyrpm）

经过手动建表的方法用如下desc信息建表后能够list查看到表信息。scan没法查看表内容，日志发现以下错误
desc信息：

COLUMN FAMILIES DESCRIPTION
{NAME => 'A', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE',
REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY',
MIN_VERSIONS => '0', TTL => 'FOR EVER', KEEP_DELETED_CELLS => 'false',
BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true',
METADATA => {'ENCODE_ON_DISK' => 'true'}} {NAME
=> 'D', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '2147483647', COMPRESSION =>
'SNAPPY', MIN_VERSIONS => '0', TT L => 'FOREVER', KEEP_DELETED_CELLS
=> 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', ENCODE_ON_DISK => 'true'}

错误信息：

org.apache.hadoop.HBase.DoNotRetryIOException: java.lang.RuntimeException: native snappy library not available: this version of libhadoop was built without snappy support
在HBase-site.xml增长属性HBase.regionserver.codecs value为snappy便可，在测试集群经过该方法，HBase启动失败

后确认tlinux1.2的hadoop集群上支持snappy的方法：即须要在特定系统编译hadoop相关本地库（native库）替换hadoop当前的native库，而后HBase的启动环境脚本增长hadoop主目录便可

目前tlinux1.2下的hadoop的nativesnappy库有现网使用，同时须要保证这个hadoop的库能够引用到libjvm.so（jre的一个so文件）直接替换hadoop/lib下的native目录，保证已经安装snappy的rpm包，在HBase-env.sh里添加HADOOP_HOME={Hadoop安装主目录}。再hadoop checknative后发现已支持snappy。逐步全量重启HBase。

4.HBase0.9.4集群数据表到HBase1.2.1集群数据表的迁移方法

暴力迁移参考http://my.oschina.net/CainGao...
1)找到源集群源表在hdfs上的目录位置，直接将该目录移动到目标集群HBase的表在目标集群hdfs上的表根目录下

2)暴力迁移时tableinfo信息是一个文件即.tableinfo.00000001。0.9.4的版本这个文件位于HBase表在hdfs上表目录的根目录下，而1.2.1的这个文件位于HBase表在hdfs上表目录的根目录下的./tabledesc目录下，须要手动建立这个目录并调整这个文件的位置

3) 修改复制过来的表目录文件的属主信息

4) 重启HBase的全部组件

5) 此时登陆HBaseshell已经能够经过list查看到迁移过来的表，但scan等操做会失败

6) 经过HBase hbck -fixMeta修复meta信息；HBase hbck -fixAssignments 修复分区。这两个步骤的操做过程当中注意观察日志是否有异常，实践中首次尝试此方法有大量错误，发现错误内容为snappy相关，支持snappy后，查看表信息，表内容正常，随机选取表内容对比也正常，可认为此种方法迁移成功。

7) 经过import/export的方法迁移时须要在目标集群手动建立目标表，查看源集群的表结构以下：
import/export参考地址

COLUMN FAMILIES DESCRIPTION
{NAME => 'A', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE',
REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY',
MIN_VERSIONS => '0', TTL => 'FOR EVER', KEEP_DELETED_CELLS => 'false',
BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true',
METADATA => {'ENCODE_ON_DISK' => 'true'}} {NAME
=> 'D', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '2147483647', COMPRESSION =>
'SNAPPY', MIN_VERSIONS => '0', TT L => 'FOREVER', KEEP_DELETED_CELLS
=> 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', ENCODE_ON_DISK => 'true'}

经过该desc信息建立新表时出现以下错误：
Unknown argument ignored for column family A: ENCODE_ON_DISK
手动测试只要加这个参数ENCODE_ON_DISK去建表必定会出现这个错误，建表会成功，但表信息里没有这个字段了。通过look查代码发现这个字段在新版本已经废弃，但客户的老集群是版本须要这个字段，经过import的方法没法正常写入、经过步骤6）的暴力迁移成功后（暴力迁移成功兼容了这个字段），查看表的desc信息以下：

COLUMN FAMILIES DESCRIPTION
{NAME => 'A', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE',
REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY',
MIN_VERSIONS => '0', TTL => 'FOR EVER', KEEP_DELETED_CELLS => 'false',
BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true',
METADATA => {'ENCODE_ON_DISK' => 'true'}} {NAME
=> 'D', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '2147483647', COMPRESSION =>
'SNAPPY', MIN_VERSIONS => '0', TT L => 'FOREVER', KEEP_DELETED_CELLS
=> 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', METADATA => {'ENCODE_ON_DISK' => 'true'}}

老集群表结构

COLUMN FAMILIES DESCRIPTION
{NAME => 'A', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE',
REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY',
MIN_VERSIONS => '0', TTL => 'FOR EVER', KEEP_DELETED_CELLS => 'false',
BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true',
METADATA => {'ENCODE_ON_DISK' => 'true'}} {NAME
=> 'D', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '2147483647', COMPRESSION =>
'SNAPPY', MIN_VERSIONS => '0', TT L => 'FOREVER', KEEP_DELETED_CELLS
=> 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', ENCODE_ON_DISK => 'true'}

能够看到关于ENCODE_ON_DISK字段在新老版本的定义方法有差别，故咱们测试在新集群使用上面的desc信息建表后，再经过import方法导入到HBase。结果依然没有数据写入，能够判定这个参数ENCODE_ON_DISK在HBase1.2.1中彻底废弃，新版本采用了一个整字段来包裹这个信息。当老集群有参数时，官方import/export方法在HBase0.9.8到HBase1.2.1直接迁移暂时不可用。

二.后续

在HBase0.9.8集群上建表设置ENCODE_ON_DISK=false（默认为true），在HBase1.2.1上不带ENCODE_ON_DISK建表，使用export/import方法迁移测试研究其余HBase数据跨集群（版本差别，网络不通）迁移方法。

.
.
.

---

获取更多云计算技术干货，可请前往

腾讯云技术社区

微信公众号：腾讯云技术社区（ QcloudCommunity）