HBase跨版本資料遷移總結

HBase 資料遷移 · 發表 2018-11-30 17:14:00

摘要：本文由王亮發表某客戶大資料測試場景為：Solr類似畫像的資料查出使用者標籤——通過這些標籤在HBase查詢詳細資訊。以上測試功能以及效能。其中HBase的資料量為500G，Solr約5T。資料均需要從對方的叢集人工遷移到我們自己搭建的叢集。由於Solr沒有在我們叢集中整合，優先開始...

本文由王亮發表

某客戶大資料測試場景為：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解析資訊如下

[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

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叢集資料表的遷移方法

暴力遷移參考ofollow,noindex" target="_blank">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資料跨叢集（版本差異，網路不通）遷移方法。