HBase跨版本数据迁移总结【文末有福利】

qcloudcommunity · · 631 次点击 · 开始浏览置顶

这是一个创建于的主题，其中的信息可能已经有所发展或是发生改变。

> 本文由王亮发表某客户大数据测试场景为：Solr类似画像的数据查出用户标签——通过这些标签在HBase查询详细信息。以上测试功能以及性能。其中HBase的数据量为500G，Solr约5T。数据均需要从对方的集群人工迁移到我们自己搭建的集群。由于Solr没有在我们集群中集成，优先开始做HBase的数据迁移，以下总结了HBase使用以及数据迁移遇到的各种问题以及解决方法。 ## 一.迁移过程遇到问题以及解决遇到的问题以及解决过程如下： #### 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解析信息如下 ```js [root@10 ~]# hostname 10.0.0.106 ; generated by /sbin/dhclient-script #search openstacklocal 0.0.106 #nameserver 10.0.0.2 #nameserver 10.0.0.3 ``` 有`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` ```js Native library checking: hadoop: true /data/tbds-base/usr/hdp/2.2.0.0-2041/hadoop/lib/native/libhadoop.so zlib: true /lib64/libz.so.1 snappy: false lz4: true revision:99 bzip2: false openssl: false build does not support openssl. ``` - 通过手动建表的方法用以下desc信息建表后可以list查看到表信息。scan无法查看表内容，日志发现如下错误 desc信息： ```js 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'} ``` 错误信息： ```js 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。 ```js Native library checking: hadoop: true /data/tbds-base/usr/hdp/2.2.0.0-2041/hadoop/lib/native/libhadoop.so zlib: true /lib64/libz.so.1 snappy: true /usr/lib64/libsnappy.so.1 lz4: true revision:99 bzip2: false openssl: false build does not support openssl. ``` #### 4.HBase0.9.4集群数据表到HBase1.2.1集群数据表的迁移方法暴力迁移参考<http://my.oschina.net/CainGao/blog/616502> 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[参考地址](http://www.tuicool.com/articles/VZFNR3) ```js 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信息如下： ```js 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'}} ``` 老集群表结构 ```js 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数据跨集群（版本差异，网络不通）迁移方法。【腾讯云100元无门槛代金券开抢】各位新老乡亲，腾讯云数据库年终福利来啦！为了更好地为广大开发者提供服务，数据君诚挚的邀请您参与本次有奖调研，说你最想说的话，用最好用的数据库！问卷会占用您两分钟左右的时间，回答完毕后将有机会获得腾讯云100元无门槛代金券，限云数据库和云服务器使用哦~如您抽中奖品，请在页面填写手机号，该手机号将用于接收兑换券码。数量有限先到先得，12月15日抽奖入口将关闭，快[点击参与吧!](https://wj.qq.com/s/2944045/b78b/) **此文已由作者授权腾讯云+社区发布** **搜索关注公众号「云加社区」，第一时间获取技术干货，关注后回复1024 送你一份技术课程大礼包！**

有疑问加站长微信联系（非本文作者）