<转载>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解析信息如下

[root@10~]# hostname10.0.0.106; generatedby/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)

Nativelibrary 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:truerevision:99

bzip2:false

openssl:falsebuild does not support openssl.

通过手动建表的方法用以下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 =>'FOREVER', 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', TTL =>'FOREVER', KEEP_DELETED_CELLS =>'false', BLOCKSIZE =>'65536', IN_MEMORY =>'false', BLOCKCACHE =>'true', ENCODE_ON_DISK =>'true'}

错误信息:

org.apache.hadoop.HBase.DoNotRetryIOException:java.lang.RuntimeException:nativesnappylibrarynotavailable:thisversionoflibhadoopwasbuiltwithoutsnappysupport

在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。

Nativelibrary checking:hadoop:true/data/tbds-base/usr/hdp/2.2.0.0-2041/hadoop/lib/native/libhadoop.sozlib:true/lib64/libz.so.1snappy:true/usr/lib64/libsnappy.so.1lz4:truerevision:99bzip2:falseopenssl:falsebuild 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参考地址

COLUMN FAMILIES DESCRIPTION                                                                 

 {NAME =>'A', DATA_BLOCK_ENCODING =>'NONE', BLOOMFILTER =>'NONE', REPLICATION_SCOPE =>'0', VERSIONS =>'1', COMPRESSION =>'SNAPPY', MIN_VERSIONS =>'0', TTL =>'FOREVER', 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', TTL =>'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 =>'FOREVER', 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', TTL =>'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 =>'FOREVER', 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', TTL =>'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)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,242评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,769评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,484评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,133评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,007评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,080评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,496评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,190评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,464评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,549评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,330评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,205评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,567评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,889评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,160评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,475评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,650评论 2 335

推荐阅读更多精彩内容