<轉載>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）