HBase快速入門系列(10) | HBase知識點總結(建議收藏！)

大家好，我是不溫卜火，是一名計算機學院大數據專業大二的學生，昵稱來源于成語—不溫不火，本意是希望自己性情溫和。作為一名互聯網行業的小白，博主寫博客一方面是為了記錄自己的學習過程，另一方面是總結自己所犯的錯誤希望能夠幫助到很多和自己一樣處于起步階段的萌新。但由于水平有限，博客中難免會有一些錯誤出現，有紕漏之處懇請各位大佬不吝賜教！暫時只有csdn這一個平臺，博客主頁：https://buwenbuhuo.blog.csdn.net/

此篇為大家帶來的是HBase知識點總結(建議！)。

目錄

1. 讀寫請求會集中到某一個RegionServer上 如何處理（數據傾斜）

2. hbase查詢一條記錄的方法是什么？Hbase寫入一條記錄的方法是什么？

3. 描述hbase的rowkey的設計原理

4. hbase中compact的用途是什么，什么時候觸發，分為哪兩種，有什么區別。

5. Hbase的原理 regionserver掛了 如何恢復數據 ？新的數據從Hlog里讀出來是如何恢復的

6. 講一下Hbase，Hbase二級索引用過嗎

7. Hbase如何優化的

8. hbase中查詢表名為buwenbuhuo，rowkey為user開頭的

9. hbase表的設計有哪些注意點

10. HBase與mysql得區別

標注： 此處為反爬蟲標記：讀者可自行忽略

1

2

原文地址：https://buwenbuhuo.blog.csdn.net/

1. 讀寫請求會集中到某一個RegionServer上 如何處理（數據傾斜）

產生熱點問題的原因：

hbase的中的數據是按照字典序排序的，當大量連續的rowkey集中寫在個別的region，各個region之間數據分布不均衡；

創建表時沒有提前預分區，創建的表默認只有一個region，大量的數據寫入當前region

創建表已經提前預分區，但是設計的rowkey沒有規律可循

熱點問題的解決方案：

隨機數+業務主鍵，如果想讓最近的數據快速get到，可以將時間戳加上。

Rowkey設計越短越好，不要超過10~100個字節

映射regionNo，這樣既可以讓數據均勻分布到各個region中，同時可以根據startkey和endkey可以get到同一批數據

2. hbase查詢一條記錄的方法是什么？Hbase寫入一條記錄的方法是什么？

Hbase查詢單一數據采用的是get方法，寫入數據的方法為put方法(可在回答時說些具體的實現思路)

3. 描述hbase的rowkey的設計原理

Rowkey設計時需要遵循三大原則：

唯一性原則

rowkey在設計上保證其唯一性。rowkey是按照字典順序排序存儲的，因此，設計rowkey的時候，要充分利用這個排序的特點，將經常讀取的數據存儲到一塊，將最近可能會被訪問的數據放到一塊。

長度原則

rowkey是一個二進制碼流，可以是任意字符串，最大長度 64kb ，實際應用中一般為10-100bytes，以byte[] 形式保存，一般設計成定長。建議越短越好，不要超過16個字節，原因如下：數據的持久化文件HFile中是按照KeyValue存儲的，如果rowkey過長，比如超過100字節，1000w行數據，光rowkey就要占用100*1000w=10億個字節，將近1G數據，這樣會極大影響HFile的存儲效率；MemStore將緩存部分數據到內存，如果rowkey字段過長，內存的有效利用率就會降低，系統不能緩存更多的數據，這樣會降低檢索效率。目前操作系統都是64位系統，內存8字節對齊，控制在16個字節，8字節的整數倍利用了操作系統的最佳特性。

散列原則

如果rowkey按照時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將rowkey的高位作為散列字段，由程序隨機生成，低位放時間字段，這樣將提高數據均衡分布在每個RegionServer，以實現負載均衡的幾率。如果沒有散列字段，首字段直接是時間信息，所有的數據都會集中在一個RegionServer上，這樣在數據檢索的時候負載會集中在個別的RegionServer上，造成熱點問題，會降低查詢效率

加鹽：如果rowkey按照時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將rowkey的高位作為散列字段，由程序隨機生成，低位放時間字段，這樣將提高數據均衡分布在每個RegionServer，以實現負載均衡的幾率。如果沒有散列字段，首字段直接是時間信息，所有的數據都會集中在一個RegionServer上，這樣在數據檢索的時候負載會集中在個別的RegionServer上，造成熱點問題，會降低查詢效率加鹽：這里所說的加鹽不是密碼學中的加鹽，而是在rowkey的前面增加隨機數，具體就是給rowkey分配一個隨機前綴以使得它和之前的rowkey的開頭不同。分配的前綴種類數量應該和你想使用數據分散到不同的region的數量一致。加鹽之后的rowkey就會根據隨機生成的前綴分散到各個region上，以避免熱點

哈希：哈希會使同一行永遠用一個前綴加鹽。哈希也可以使負載分散到整個集群，但是讀卻是可以預測的。使用確定的哈希可以讓客戶端重構完整的rowkey，可以使用get操作準確獲取某一個行數據

反轉：第三種防止熱點的方法時反轉固定長度或者數字格式的rowkey。這樣可以使得rowkey中經常改變的部分（最沒有意義的部分）放在前面。這樣可以有效的隨機rowkey，但是犧牲了rowkey的有序性。反轉rowkey的例子以手機號為rowkey，可以將手機號反轉后的字符串作為rowkey，這樣的就避免了以手機號那樣比較固定開頭導致熱點問題

時間戳反轉：一個常見的數據處理問題是快速獲取數據的最近版本，使用反轉的時間戳作為rowkey的一部分對這個問題十分有用，可以用Long.Max_Value - timestamp 追加到key的末尾.

4. hbase中compact的用途是什么，什么時候觸發，分為哪兩種，有什么區別。

在HBase中，每當memstore的數據flush到磁盤后，就形成一個storefile，當storefile的數量越來越大時，會嚴重影響HBase的讀性能 ，HBase內部的compact處理流程是為了解決MemStore Flush之后，文件數目太多，導致讀數據性能大大下降的一種自我調節手段，它會將文件按照某種策略進行合并，大大提升HBase的數據讀性能。

主要起到如下幾個作用：

合并文件

清除刪除、過期、多余版本的數據

提高讀寫數據的效率

HBase中實現了兩種compaction的方式：

minor and major. Minor compactions will usually pick up a couple of the smaller adjacent StoreFiles and rewrite them as one. Minors do not drop deletes or expired cells, only major compactions do this. Sometimes a minor compaction will pick up all the StoreFiles in the Store and in this case it actually promotes itself to being a major compaction.

這兩種compaction方式的區別是：

Minor操作只用來做部分文件的合并操作以及包括minVersion=0并且設置ttl的過期版本清理，不做任何刪除數據、多版本數據的清理工作。

Major操作是對Region下的HStore下的所有StoreFile執行合并操作，最終的結果是整理合并出一個文件。

compaction觸發時機：

Memstore刷寫后，判斷是否compaction

CompactionChecker線程，周期輪詢

5. Hbase的原理 regionserver掛了 如何恢復數據 ？新的數據從Hlog里讀出來是如何恢復的

引起RegionServer宕機的原因各種各樣，有因為Full GC導致、網絡異常導致、官方Bug導致（close wait端口未關閉）以及DataNode異常導致等等

HBase檢測宕機是通過Zookeeper實現的， 正常情況下RegionServer會周期性向Zookeeper發送心跳，一旦發生宕機，心跳就會停止，超過一定時間（SessionTimeout）Zookeeper就會認為RegionServer宕機離線，并將該消息通知給Master

一旦RegionServer發生宕機，HBase都會馬上檢測到這種宕機，并且在檢測到宕機之后會將宕機RegionServer上的所有Region重新分配到集群中其他正常RegionServer上去，再根據HLog進行丟失數據恢復，恢復完成之后就可以對外提供服務，整個過程都是自動完成的，并不需要人工介入.

6. 講一下Hbase，Hbase二級索引用過嗎

默認情況下，Hbase只支持rowkey的查詢，對于多條件的組合查詢的應用場景，不夠給力。如果將多條件組合查詢的字段都拼接在RowKey中顯然又不太可能。全表掃描再結合過濾器篩選出目標數據(太低效)，所以通過設計HBase的二級索引來解決這個問題。

這里所謂的二級索引其實就是創建新的表，并建立各列值（family：column）與行鍵（rowkey）之間的映射關系。這種方式需要額外的存儲空間，屬于一種以空間換時間的方式

7. Hbase如何優化的

內存優化

垃圾回收優化:CMS, G1(Region）

JVM啟動：-Xms(1/64) –Xmx(1/4)

Region優化

預分區

禁用major合并，手動合并

客戶端優化

批處理

8. hbase中查詢表名為buwenbuhuo，rowkey為user開頭的

HBase Shell : scan 'buwenbuhuo', FILTER => "PrefixFilter ('user')" HBase JavaAPI : Scan scan = new Scan(); Filter filter = new PrefixFilter(Bytes.toBytes("user")); scan.setFilter(filter);

1

2

3

4

5

6

7

9. hbase表的設計有哪些注意點

行鍵的結構是什么的并且要包含什么內容

表有多少個列族？

列族中都要放什么數據？

每個列族中有多少個列？

列名是什么？盡管列名在創建表時不需要指定，你讀寫數據是需要用到它們。

單元數據需要包含哪些信息？

每個單元數據需要存儲的版本數量是多少？

10. HBase與mysql得區別

數據存儲的方式:

Mysql面向行存儲數據，整個行的數據是一個整體，存儲在一起。

HBase面向列存儲數據，整個列的數據是一個整體，存儲在一起，有利于壓縮和統計

數據之間的關系

Mysql存儲關系型數據，結構化數據

Hbase存儲的非關系型數據，存儲結構化和非結構化數據

事務處理

Mysql數據庫存在事務，因為著重于計算（算法）

Hbase數據庫側重于海量數據的存儲，所以沒有事務的概念

儲存容量

Hbase依托于Hadoop，容量非常大，一般都以PB級為單位存儲

Mysql存儲數據依賴于所在的硬件設備

本次的分享就到這里了,

好書不厭讀百回，熟讀課思子自知。而我想要成為全場最靚的仔，就必須堅持通過學習來獲取更多知識，用知識改變命運，用博客見證成長，用行動證明我在努力。

如果我的博客對你有幫助、如果你喜歡我的博客內容，請“” “評論”“”一鍵三連哦！聽說的人運氣不會太差，每一天都會元氣滿滿呦！如果實在要白嫖的話，那祝你開心每一天，歡迎常來我博客看看。

碼字不易，大家的支持就是我堅持下去的動力。后不要忘了關注我哦！

HBase MySQL

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。