HBase相關面試題整理
作者：尹正傑
版權聲明：原創作品，謝絕轉載！否則將追究法律責任。
一.Hbase熱點(數據傾斜)問題， 讀寫請求會集中到某一個RegionServer上如何處理
產生熱點問題的原因： (1)hbase的中的數據是按照字典序排序的，當大量連續的rowkey集中寫在個別的region，各個region之間數據分布不均衡； (2)創建表時沒有提前預分區，創建的表默認只有一個region，大量的數據寫入當前region (3)創建表已經提前預分區，但是設計的rowkey沒有規律可循
熱點問題的解決方案： (1)隨機數+業務主鍵，如果想讓最近的數據快速get到，可以將時間戳加上。 (2)Rowkey設計越短越好，不要超過10~100個字節 (3)映射regionNo，這樣既可以讓數據均勻分布到各個region中，同時可以根據startkey和endkey可以get到同一批數據
二.Hbase查詢一條記錄的方法是什么？Hbase寫入一條記錄的方法是什么？
Hbase查詢單一數據采用的是get方法，寫入數據的方法為put方法
題目簡單時，可以在回答問題時，稍微深入的講解實現思路，比如讀寫流程。但如果你對HBase的讀寫流程不太清楚就別說，因為說的越多破綻就越多。
三.描述hbase的rowkey的設計原理
Rowkey設計時需要遵循三大原則： (1)唯一性原則: 這個很好理解，RowKey的角色類似於關系型數據庫當中的主鍵，因此Rowkey不能重復。 舉個例子,使用用戶姓名作為RowKey就很不適合，究其原因是因為姓名太容易重復了,如果非要用姓名作為RowKey就得考慮加一些后綴來做區分。 rowkey在設計上保證其唯一性。rowkey是按照字典順序排序存儲的，因此，設計rowkey的時候，要充分利用這個排序的特點，將經常讀取的數據存儲到一塊，將最近可能會被訪問的數據放到一塊。
(2)長度原則: 而設計太長會導致占用更多的存儲空間影響查詢效率，設計的太短對業務要求查詢也不是特方便。因此在能滿足查詢條件的情況下，RowKey設計的越短越好。 雖然RowKey最大長度是64KB，實際應用中長度一般為10-100bytes。以byte[] 形式保存，一般設計成定長。 建議越短越好，不要超過16個字節，原因如下： (a)數據的持久化文件HFile中是按照KeyValue存儲的，如果rowkey過長，比如超過100字節，1000w行數據，光rowkey就要占用100*1000w=10億個字節，將近1G數據，這樣會極大影響HFile的存儲效率； (b)MemStore將緩存部分數據到內存，如果rowkey字段過長，內存的有效利用率就會降低，系統不能緩存更多的數據，這樣會降低檢索效率。 (c)目前操作系統都是64位系統，內存8字節對齊，控制在16個字節，8字節的整數倍利用了操作系統的最佳特性。 (3)散列原則: 讓RowKey沒有規律，可以實現均勻分配。 如果rowkey按照時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將rowkey的高位作為散列字段，由程序隨機生成，低位放時間字段，這樣將提高數據均衡分布在每個RegionServer，以實現負載均衡的幾率。 如果沒有散列字段，首字段直接是時間信息，所有的數據都會集中在一個RegionServer上，這樣在數據檢索的時候負載會集中在個別的RegionServer上，造成熱點問題，會降低查詢效率. 常見的散列手段如下: (a)加鹽： 這里所說的加鹽不是密碼學中的加鹽，而是在rowkey的前面增加隨機數，具體就是給rowkey分配一個隨機前綴以使得它和之前的rowkey的開頭不同。 分配的前綴種類數量應該和你想使用數據分散到不同的region的數量一致。加鹽之后的rowkey就會根據隨機生成的前綴分散到各個region上，以避免熱點. (b)哈希： 哈希會使同一行永遠用一個前綴加鹽。哈希也可以使負載分散到整個集群，但是讀卻是可以預測的。使用確定的哈希可以讓客戶端重構完整的rowkey，可以使用get操作准確獲取某一個行數據。 (c)反轉： 第三種防止熱點的方法時反轉固定長度或者數字格式的rowkey。這樣可以使得rowkey中經常改變的部分(最沒有意義的部分)放在前面。這樣可以有效的隨機rowkey，但是犧牲了rowkey的有序性。 反轉rowkey的例子以手機號為rowkey，可以將手機號反轉后的字符串作為rowkey，這樣的就避免了以手機號那樣比較固定開頭導致熱點問題。 (d)時間戳反轉： 一個常見的數據處理問題是快速獲取數據的最近版本，使用反轉的時間戳作為rowkey的一部分對這個問題十分有用，可以用Long.Max_Value - timestamp追加到key的末尾。 例如[key][reverse_timestamp] ,[key]的最新值可以通過scan [key]獲得[key]的第一條記錄，因為HBase中rowkey是有序的，第一條記錄是最后錄入的數據。比如需要保存一個用戶的操作記錄，按照操作時間倒序排序，在設計rowkey的時候，可以這樣設計[userId反轉][Long.Max_Value - timestamp]，在查詢用戶的所有操作記錄數據的時候，直接指定反轉后的userId，startRow是[userId反轉][000000000000],stopRow是[userId反轉][Long.Max_Value - timestamp]如果需要查詢某段時間的操作記錄，startRow是[user反轉][Long.Max_Value - 起始時間]，stopRow是[userId反轉][Long.Max_Value - 結束時間]
四.Hbase中compact的用途是什么，什么時候觸發，分為哪兩種，有什么區別。
Compact的用途:
在HBase中，每當memstore的數據flush到磁盤后，就形成一個storefile，當storefile的數量越來越大時，會嚴重影響HBase的讀性能 ，HBase內部的compact處理流程是為了解決MemStore Flush之后，文件數目太多，導致讀數據性能大大下降的一種自我調節手段，它會將文件按照某種策略進行合並，大大提升HBase的數據讀性能。 主要起到如下幾個作用： (1)合並文件 (2)清除刪除、過期、多余版本的數據 (3)提高讀寫數據的效率 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線程，周期輪詢
五.Hbase的原理,regionserver掛了,如何恢復數據？新的數據從Hlog里讀出來是如何恢復的?
引起RegionServer宕機的原因各種各樣，有因為Full GC導致、網絡異常導致、官方Bug導致（close wait端口未關閉）以及DataNode異常導致等等。
HBase檢測宕機是通過Zookeeper實現的， 正常情況下RegionServer會周期性向Zookeeper發送心跳，一旦發生宕機，心跳就會停止，超過一定時間（SessionTimeout）Zookeeper就會認為RegionServer宕機離線，並將該消息通知給Master。
一旦RegionServer發生宕機，HBase Master通過zookeeper集群會馬上檢測到這種宕機，並且在檢測到宕機之后會將宕機RegionServer上的所有Region重新分配到集群中其他正常RegionServer上去，再根據HLog進行丟失數據恢復，恢復完成之后就可以對外提供服務，整個過程都是自動完成的，並不需要人工介入.
六.講一下Hbase，Hbase二級索引用過嗎
默認情況下，Hbase只支持rowkey的查詢，對於多條件的組合查詢的應用場景，不夠給力。
如果將多條件組合查詢的字段都拼接在RowKey中顯然又不太可能，全表掃描再結合過濾器篩選出目標數據(太低效)，所以通過設計HBase的二級索引來解決這個問題。
這里所謂的二級索引其實就是創建新的表，並建立各列值（family：column）與行鍵（rowkey）之間的映射關系。這種方式需要額外的存儲空間，屬於一種以空間換時間的方式
七.Hbase如何優化的
博主推薦閱讀： https://www.cnblogs.com/yinzhengjie2020/p/12275462.html
八.Hbase中查詢表名為test，rowkey為userl開頭的
HBase Shell:
scan 'test', FILTER => "PrefixFilter ('userl')"
HBase JavaAPI: Scan scan = new Scan(); Filter filter = new PrefixFilter(Bytes.toBytes("userl")); scan.setFilter(filter);
九.Hbase表的設計有哪些注意點
題目主要考核hbase表的設計要素：rowkey, family, column, cell, value, timestamp。
設計hbase表時需要了解：
(1)行鍵的結構是什么的並且要包含什么內容
(2)表有多少個列族？
(3)列族中都要放什么數據？
(4)每個列族中有多少個列？
(5)列名是什么？盡管列名在創建表時不需要指定，你讀寫數據是需要用到它們。
(6)單元數據需要包含哪些信息？
(7)每個單元數據需要存儲的版本數量是多少？
十.HBase與mysql得區別
數據存儲的方式:
Mysql面向行存儲數據，整個行的數據是一個整體，存儲在一起。
HBase面向列存儲數據，整個列的數據是一個整體，存儲在一起，有利於壓縮和統計
數據之間的關系
Mysql存儲關系型數據，結構化數據
Hbase存儲的非關系型數據，存儲結構化和非結構化數據
事務處理
Mysql數據庫存在事務，因為着重於計算（算法）
Hbase數據庫側重於海量數據的存儲，所以沒有事務的概念
儲存容量
Hbase依托於Hadoop，容量非常大，一般都以PB級為單位存儲
Mysql存儲數據依賴於所在的硬件設備
十一.HBase 數據存儲，客戶需要存儲三個字段的數據（ID：：VALUE：：TIMESTAMP），為了滿足統計需求，客戶希望將100萬個測試點的數據在Hbase中存儲，每個測試點一年中每五分鍾的數據作為一行存儲，請確認這要定義存儲格式是否合理，請給出最佳的解決方案
可以采用測試點作為rowkey，每5分鍾的測試點數據作為列存儲
十二.Hbase,hive和redis的區別
Hive基於MR程序，將HQL轉換為MR執行。效率比較低，不適合實時數據訪問
Hbase基於Hadoop數據存儲，存儲海量數據，而且擁有自己的查詢操作
Redis適合做緩存。
十三.HBASE預分區（分區鍵&分區號）的作用及原理
作用： 防止數據熱點以及數據傾斜 提高數據讀寫效率
博主推薦閱讀: https://www.cnblogs.com/yinzhengjie2020/p/12914075.html
十四.Hbase的region划分，每次划分大小都一樣嗎
不是都一樣大，涉及到middleKey查詢。
十五.其它
Hbase構建二級索引如何保證索引與數據的一致？
淺談一下HBASE的讀寫原理？
描述hbase的scan和get功能以及實現的異同？