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

[[email protected]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）

    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信息： 
    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。 
    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参考地址

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数据跨集群（版本差异，网络不通）迁移方法。

相关推荐

腾讯云数据库Hbase相关产品文档

Hbase写入hdfs源码分析


版权说明：本人作者张浩，转载请注明文章出处哦。

获取更多云计算技术干货，可请前往腾讯云技术社区，当然我们也会在博客园持续同步更新~

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

时间： 2024-10-12 14:12:03

HBase跨版本数据迁移总结的相关文章

Core Data 版本数据迁移

Core Data版本迁移基础 通常,在使用Core Data的iOS App上,不同版本上的数据模型变更引发的数据迁移都是由Core Data来负责完成的.这种数据迁移模式称为Lightweight Migration(可能对于开发人员来说是lightweight),开发人员只要在添加Persistent Store时设置好对应选项,其它的就交付给Core Data来做了:从命名上可以看出这两个选项分别代表:自动迁移Persistent Store,以及自动创建Mapping Model.自动

HBase集群数据迁移方案

一.静态迁移方案 1.在hbase停止的状态下进行数据的迁移. 2.采用Hadoop distcp方式,将以上目录的内容,迁移到另一个集群. 使用add_table.rb进行恢复. 缺点:不太灵活 二.动态迁移方案 -Replication备份方案 -CopyTable方案 -Export and Import方案 1.Replication备份方案 修改hbase-site.xml配置,增加hbase.replication属性, 增加表属性REPLICATION_SCOPE属性. add_p

SVN跨版本库迁移目录并保留提交日志

现在有一份代码code在版本库reposA/dirB/下,现在想把它移动到reposB/dirAA/下,本来打算交给SA做,没想到SA似乎 也不太懂的样子.于是,自己在VPS搭建了一个svnserver,然后在网上查了一下资料,确实没有明确的攻略,不过,综合一下,却也解决了问题. 需要达到的目的是: 1. 将代码移动到新的版本库 2. 将原始的提交记录保留 版本库的结构如下,有reposA和reposB这两个版本库,然后红色的reposA/dirB/code就是需要移动的代码目录.本来打算用 s

HBase存储剖析与数据迁移

1.概述 HBase的存储结构和关系型数据库不一样,HBase面向半结构化数据进行存储.所以,对于结构化的SQL语言查询,HBase自身并没有接口支持.在大数据应用中,虽然也有SQL查询引擎可以查询HBase,比如Phoenix.Drill这类.但是阅读这类SQL查询引擎的底层实现,依然是调用了HBase的Java API来实现查询,写入等操作.这类查询引擎在业务层创建Schema来映射HBase表结构,然后通过解析SQL语法数,最后底层在调用HBase的Java API实现. 本篇内容,笔者并

微软虚拟化跨版本迁移

之前老王曾经在WSFC2008R2跨群集迁移WSFC2012R2一文中提到过虚拟化迁移,但是由于不是专门写虚拟化迁移的文章,所以写的不是很详尽,本文我们将详细讨论微软虚拟化的跨版本迁移 微软Hyper-V于2008发布,经历过2008,2008R2,2012,2012R2,2016等五个版本,其中目前国内使用最多的是2008R2,2012R2两个版本,可能大多数用户使用2008R2 Hyper-V用作过尝试测试,或者觉得2008R2 Hyper-V的性能不能满足需求,2012R2 Hyper-V

HDFS数据迁移解决方案之DistCp工具的巧妙使用

前言 在当今每日信息量巨大的社会中,源源不断的数据需要被安全的存储.等到数据的规模越来越大的时候,也许瓶颈就来了,没有存储空间了.这时候怎么办,你也许会说,加机器解决,显然这是一个很简单直接但是又显得有些欠缺思考的办法.无谓的加机器只会带来无限上升的成本消耗,更好的办法应该是做到更加精细化的数据存储与管理,比如说非常典型的冷热数据的存储.对于巨大的长期无用的冷数据而言,应该用性能偏弱,但是磁盘空间富余的机器存,热数据则反之.数据的分类存储一定会带来数据的同步问题,假若我有2套集群,1个是线上的正

Amazon Redshift数据迁移到MaxCompute

Amazon Redshift 中的数据迁移到MaxCompute中经常需要先卸载到S3中,再到阿里云对象存储OSS中,大数据计算服务MaxCompute然后再通过外部表的方式直接读取OSS中的数据.如下示意图: 前提条件本文以SQL Workbench/J工具来连接Reshift进行案例演示,其中用了Reshift官方的Query editor发现经常报一些奇怪的错误.建议使用SQL Workbench/J. 下载Amazon Redshift JDBC驱动程序,推荐4.2 https://s

[JIRA] 最新Linux版本 jira6.3.6安装汉化破解以及数据迁移

序言: JIRA是澳大利亚 Atlassian 公司开发的一款优秀的问题跟踪管理软件工具,可以对各种类型的问题进行跟踪管理,包括缺陷.任务.需求.改进等.JIRA采用J2EE技术,能够跨平台部署.它正被广泛的开源软件组织,以及全球著名的公司使用. JIRA产品非常完善且功能强大,安装配置简单,多语言支持.界面十分友好,和其他系统如CVS.Subversion(SVN).VSS.LDAP.邮件服务整合得相当好,文档齐全,可用性以及可扩展性方面都十分出色,拥有完整的用户权限管理. 环境:jira软件

[Sqlite]-->数据迁移备份--从低版本3.6.2到高版本3.8.6

数据迁移 一, 使用.dump命令 命令帮助提示 .dump ?TABLE? ...      Dump the database in an SQL text format If TABLE specified, only dump tables matching LIKE pattern TABLE. 理解分析:       使用.dump命令可以将数据库对象导出成SQL格式.不带任何参数时,.dump将整个数据库导出为数据库定义语言(DDL)和数据库操作语言(DML)命令,适合重新创建数据