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跨版本資料遷移總結
某客戶大資料測試場景為:Solr類似畫像的資料查出使用者標籤——通過這些標籤在HBase查詢詳細資訊。以上測試功能以及效能。 其中HBase的資料量為500G,Solr約5T。資料均需要從對方的叢集人工遷移到我們自己搭建的叢集。由於Solr沒有在我們叢集中整合,優先
Hbase叢集間資料遷移方法總結
呵呵,今天花了一天的時間查資料做測試,略微的總結了一下hbase資料遷移的方法。 一、需要在hbase叢集停掉的情況下遷移 步驟:(1)執行hadoop distcp -f filelist "hdfs://new cluster ip:9000/hbasetest"
hbase0.94版本資料遷移到1.x版本
因公司的hbase0.9.4遷移到雲平臺,但阿里雲的emr的hbase是1.1版本,存在問題:hbase的版本間變化大,採用export/import方法時存在snappy支援問題,元資訊錯誤等問題。 想到hbase有bulkload方式入庫,查看了一下,hbase的hfi
使用dd實現跨主機資料遷移
dd遷移方案:(注意新建虛擬機器的時候要和物理機的磁碟、記憶體等大小一致) 一、物理機和虛擬機器分別用對應版的livecd啟動。 二、在物理機和虛擬機器上分別關閉防火牆和開啟sshd服務 1.關閉防火牆 systemctl stop firewalld.service#停止f
歷史資料遷移總結
這段時間一直忙於一個專案的歷史資料遷移,這期間遇到的問題千奇百怪,可以說杯具是接二連三。現將這些問題簡單總結一下: 第一個問題:不知道老系統的資料庫結構和程式碼的結構,客戶只給了我們一個執行包和dmp檔案,一下子不知道如何還原老系統的環境,在糾結中不停的百度, 後來通過R
VisualSVN跨版本庫遷移目錄(保留日誌)
參考文獻:SVN跨版本庫遷移目錄並保留提交日誌 真的非常感謝這位作者,寫得很好,簡單易懂,終於把版本庫轉移的問題解決了。 關鍵字:VisualSVN 跨版本庫遷移目錄保留日誌 整理需要遷移的目錄路徑對應表 目標:把“\PROG1”整個目錄及檔案遷移到“專案1\程式
跨庫資料遷移利器 —— Sqoop
一、Sqoop 基本命令 1. 檢視所有命令 # sqoop help 2. 檢視某條命令的具體使用方法 # sqoop help 命令名 二、Sqoop 與 MySQL 1. 查詢MySQL所有資料庫 通常用於 Sqoop 與 MySQL 連通測試: sqoop list-databases \
elasticsearch跨叢集資料遷移
寫這篇文章,主要是目前公司要把ES從2.4.1升級到最新版本7.8,不過現在是7.9了,官方的文件:https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html 由於從2.4.1跨很大基本的升級,所以不能平滑的升級了,只能
HBase 跨叢集遷移資料-Snapshot 實現
HBase資料遷移方案有很多種,但今天我們來通過Snapshot方式來實現HBase的資料遷移(即將A叢集HBase的資料遷移到B叢集),廢話不多說,直接進去主題吧: 參考文獻:https://www.cnbl
hdfs資料遷移至hbase(python2.7版本)
慣例直接上詳細註釋的程式碼。 任務是將HDFS上多個需要重新編碼的檔案合併後寫入HBASE。 python2.7完成,用3的話可能需要改hbase.py的一些原始碼。 # -*- coding: utf-8 -*- """ Created on Thu
技術實操丨HBase 2.X版本的元資料修復及一種資料遷移方式
摘要:分享一個HBase叢集恢復的方法。 背景 在HBase 1.x中,經常會遇到元資料不一致的情況,這個時候使用HBCK的命令,可以快速修復元資料,讓叢集恢復正常。 另外HBase資料遷移時,大家經常使用到一種遷移方式是:拷貝HBase的資料目錄/hbase/data/default到新的叢集,然後在新叢集
微軟虛擬化跨版本遷移
虛擬化跨版本遷移 虛擬化遷移 Hyper-V跨版本遷移 Hyper-V升級 之前老王曾經在WSFC2008R2跨群集遷移WSFC2012R2一文中提到過虛擬化遷移,但是由於不是專門寫虛擬化遷移的文章,所以寫的不是很詳盡,本文我們將詳細討論微軟虛擬化的跨版本遷移微軟Hyper-V於2008發布,
關於vue-cliaxsios的使用和跨域訪問資料的總結
一、安裝axsois 1.安裝:在vue-cli根目錄下安裝axsois 2.更改原型鏈方法:在main.js下更改: 3.在元件中使用: 二、跨域 1.在config/index.js 新增如下程式碼: proxyTable: { './api':{ targ
ef資料遷移命令總結之Add-Migration
ef資料遷移命令總結之Add-Migration 首先我們可以在vs的程式包管理控制檯輸入 get-help Add-Migration -detailed以檢視詳細資訊。 個人感覺有一篇好的文章,http://www.mortenanderson.net/code-firs
EF資料遷移命令總結
EF資料遷移命令總結 //段落 > >> >>> ,markdown用法 Get-Help add-migration/EntityFramework。 微軟官網關於ef的介紹 https://docs.microsoft.
HBase跨叢集複製資料的另一種方法
2012-08-14 http://abloz.com date:2012.8.14 上一篇文章《hbase 複製備份資料》 中提到用工具CopyTable來在叢集間複製資料。另外還有一種更暴力的方式,來共享HBase備份表。
【HBase】HBase各功能元件、整合MapReduce的方式及資料遷移
1、HBase體系架構 各個功能元件闡述如下: (1)Client 整個HBase叢集的訪問入口; 使用HBase RPC機制與HMaster和HRegionServer進行通訊; 與HMaster進行通訊進行管理類操作; 與HRegionServer進行資
專案總結——也談svn版本庫遷移
【一.引言】 看了很多的關於svn版本庫遷移的部落格,寫的都挺好的。但在自己實踐的過程中還是沒有那一篇能讓我不查別的東西的。也就是說網上什麼都有但是自己用的時候還需要查好多的東西。算是做筆記吧。方便
CentOS [缺陷庫管理工具JIRA]最新Linux版本jira6.3.6安裝漢化破解以及資料遷移
JIRA 是澳大利亞 Atlassian 公司開發的一款優秀的問題跟蹤管理軟體工具,可以對各種型別的問題進行跟蹤管理,包括缺陷、任務、需求、改進等。JIRA採用J2EE技術,能夠跨平臺部署。它正被廣泛的開源軟體組織,以及全球著名的公司使用。 JIRA產品非常完善且功能強
Kylin實踐(三)--跨叢集元資料遷移
Kylin跨叢集元資料遷移第一步:在待遷移叢集上備份元資料,命令如下:$KYLIN_HOME/bin/metastore.sh backup看到如下提示時即為備份成功:metadata store backed up to /opt/kylin/apache-kylin-2.