您好,登錄后才能下訂單哦!
這篇文章主要介紹“HBase1.x優化本地數據舉例分析”,在日常操作中,相信很多人在HBase1.x優化本地數據舉例分析問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”HBase1.x優化本地數據舉例分析”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
現象:
由于同事反應生產上在HBase Shell中,通過 get ‘表’,‘rowkey’ 獲取數據的時候,經常會出現,連續多次執行同一條get命令,前面N-1次可能沒問題,到了第N次就卡住了,時間一長就報超時的錯誤。
我看了下后臺日志也沒有太明顯的錯誤,其他方法都試了也沒解決掉這個問題,后來好好想了下,這個集群最近一段時間通過BulkLoad方式導入了40TB左右的數據,里面肯定會有很多小的HFile和需要清理的文件。由于生產環境major compation都是關閉掉的,都是通過手動執行。
于是我百度找了個Shell批量執行腳本,晚上對所有表跑了下major compaction,大約執行了有2個多小時,第二天早上發現問題已修復,且HBase監控界面的RegionSrever數據本地化率(data locality),從原來的19%提升到了99%,于是我找了找相關的東西。
1.什么是HBase的數據本地化率?
Data Locality用來衡量region服務的數據即region的HFile位于本地的百分比。
在hadoop生產環境中, hdfs通常為設置為三個副本,假如當前RegionA處于datanode1,當數據a通過從Memstore中Flush到HFile時,三副本為(datanode1,datanode2,datanode3),數據b寫入三副本是(datanode1,datanode3,datanode5),數據c寫入三副本(datanode1,datanode4,datanode6),可以看出來a、b、c三份數據寫入的時候肯定會在本地datanode1上寫入一份,其他兩份按照datanode的寫入機制進行分配;數據都在本地可以讀到,因此數據本地率是100%。現在假設RegionA被遷移到了datanode2上,只有數據a有一份數據在該節點上,其他數據(b和c)讀取只能遠程跨節點讀,本地率就為33%(假設a,b和c的數據大小相同)。
2.數據本地化率低的原因
由本地化率的定義我們知道,數據本地化率低的原因肯定是region和hfile數據不在同一個節點上,會產生大量的跨網絡IO請求,必然會導致讀請求延遲較高,那什么時候才會導致region的遷移呢?下面是我個人的理解,可能理解的不太全面,如果后面有更深層次的問題我會給大家完善進來。
1).當數據持續寫入,單個region的大小達到hbase.hregion.max.filesize(默認值10GB)會自動進行Split,假如一直向RegionA持續寫入數據,當RegionA大小超過10GB,會分離成兩個子RegionB、RegionC,如果我們集群開啟了
2).其他情況也可能導致Region的遷移,Regionserver服務宕機,手動move使region遷移到其他節點,導致數據本地化率降低。
3.如何提升數據本地化率
1.關閉HBase的Region負債均衡(balance)
2.regionserver重啟后,手動move到原來節點(如果生產region比較多,這個操作比較繁瑣)
3.major compaction的時候,使得一個region擁有的所有數據都轉移到region這臺機子上來,從而確保本地化,major compaction時間會持續比較長,整個過程會消耗大量系統資源,對上層業務有比較大的影響。因此線上業務都會將關閉自動觸發Major Compaction功能,改為手動在業務低峰期觸發大合并。
Region拆分詳解請查看我的另外一篇文章:
注意:
如果RegionServer接手了一個Region,那么大多數數據塊不在本地的NameNode上,讀寫性能會有下降,但會在后續的Compact過程中逐漸將文件寫入本地的DataNode,從而恢復Data Locality。
到此,關于“HBase1.x優化本地數據舉例分析”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。