經(jīng)典Hbase面試7題（附答案）
?Hbase
Hbase是怎么寫數(shù)據(jù)的？?
HDFS和HBase各自使用場景?
Hbase的存儲結構?
熱點現(xiàn)象（數(shù)據(jù)傾斜）怎么產(chǎn)生的，以及解決方法有哪些?
HBase的 rowkey 設計原則?
HBase的列簇設計?
HBase 中 compact 用途是什么，什么時候觸發(fā)，分為哪兩種，有什么區(qū)別
1. Hbase是怎么寫數(shù)據(jù)的？
Client寫入 -> 存入MemStore，一直到MemStore滿 -> Flush成一個StoreFile，直至增長到一定閾值 -> 觸發(fā)Compact合并操作 -> 多個StoreFile合并成一個StoreFile，同時進行版本合并和數(shù)據(jù)刪除 -> 當StoreFiles Compact后，逐步形成越來越大的StoreFile -> 單個StoreFile大小超過一定閾值后（默認10G），觸發(fā)Split操作，把當前Region Split成2個Region，Region會下線，新Split出的2個孩子Region會被HMaster分配到相應的HRegionServer 上，使得原先1個Region的壓力得以分流到2個Region上
由此過程可知，HBase只是增加數(shù)據(jù)，沒有更新和刪除操作，用戶的更新和刪除都是邏輯層面的，在物理層面，更新只是追加操作，刪除只是標記操作。
用戶寫操作只需要進入到內存即可立即返回，從而保證I/O高性能。
2. HDFS和HBase各自使用場景
首先一點需要明白：Hbase是基于HDFS來存儲的。
HDFS：?
一次性寫入，多次讀取。
保證數(shù)據(jù)的一致性。
主要是可以部署在許多廉價機器中，通過多副本提高可靠性，提供了容錯和恢復機制。
HBase：?
瞬間寫入量很大，數(shù)據(jù)庫不好支撐或需要很高成本支撐的場景。
數(shù)據(jù)需要長久保存，且量會持久增長到比較大的場景。
HBase不適用與有 join，多級索引，表關系復雜的數(shù)據(jù)模型。
大數(shù)據(jù)量（100s TB級數(shù)據(jù)）且有快速隨機訪問的需求。如：淘寶的交易歷史記錄。數(shù)據(jù)量巨大無容置疑，面向普通用戶的請求必然要即時響應。
業(yè)務場景簡單，不需要關系數(shù)據(jù)庫中很多特性（例如交叉列、交叉表，事務，連接等等）。
3. Hbase的存儲結構
Hbase 中的每張表都通過行鍵(rowkey)按照一定的范圍被分割成多個子表（HRegion），默認一個HRegion 超過256M 就要被分割成兩個，由HRegionServer管理，管理哪些 HRegion 由 Hmaster 分配。HRegion 存取一個子表時，會創(chuàng)建一個 HRegion 對象，然后對表的每個列族（Column Family）創(chuàng)建一個 store 實例， 每個 store 都會有 0 個或多個 StoreFile 與之對應，每個 StoreFile 都會對應一個HFile，HFile 就是實際的存儲文件，一個 HRegion 還擁有一個 MemStore實例。
4. 熱點現(xiàn)象（數(shù)據(jù)傾斜）怎么產(chǎn)生的，以及解決方法有哪些
熱點現(xiàn)象：
某個小的時段內，對HBase的讀寫請求集中到極少數(shù)的Region上，導致這些region所在的RegionServer處理請求量驟增，負載量明顯偏大，而其他的RgionServer明顯空閑。
熱點現(xiàn)象出現(xiàn)的原因：
HBase中的行是按照rowkey的字典順序排序的，這種設計優(yōu)化了scan操作，可以將相關的行以及會被一起讀取的行存取在臨近位置，便于scan。然而糟糕的rowkey設計是熱點的源頭。
熱點發(fā)生在大量的client直接訪問集群的一個或極少數(shù)個節(jié)點（訪問可能是讀，寫或者其他操作）。大量訪問會使熱點region所在的單個機器超出自身承受能力，引起性能下降甚至region不可用，這也會影響同一個RegionServer上的其他region，由于主機無法服務其他region的請求。
熱點現(xiàn)象解決辦法：
為了避免寫熱點，設計rowkey使得不同行在同一個region，但是在更多數(shù)據(jù)情況下，數(shù)據(jù)應該被寫入集群的多個region，而不是一個。常見的方法有以下這些：
加鹽：在rowkey的前面增加隨機數(shù)，使得它和之前的rowkey的開頭不同。分配的前綴種類數(shù)量應該和你想使用數(shù)據(jù)分散到不同的region的數(shù)量一致。加鹽之后的rowkey就會根據(jù)隨機生成的前綴分散到各個region上，以避免熱點。
哈希：哈希可以使負載分散到整個集群，但是讀卻是可以預測的。使用確定的哈?？梢宰尶蛻舳酥貥嬐暾膔owkey，可以使用get操作準確獲取某一個行數(shù)據(jù)
反轉：第三種防止熱點的方法時反轉固定長度或者數(shù)字格式的rowkey。這樣可以使得rowkey中經(jīng)常改變的部分（最沒有意義的部分）放在前面。這樣可以有效的隨機rowkey，但是犧牲了rowkey的有序性。反轉rowkey的例子以手機號為rowkey，可以將手機號反轉后的字符串作為rowkey，這樣的就避免了以手機號那樣比較固定開頭導致熱點問題
時間戳反轉：一個常見的數(shù)據(jù)處理問題是快速獲取數(shù)據(jù)的最近版本，使用反轉的時間戳作為rowkey的一部分對這個問題十分有用，可以用 Long.Max_Value - timestamp 追加到key的末尾，例如[key][reverse_timestamp],[key]的最新值可以通過scan [key]獲得[key]的第一條記錄，因為HBase中rowkey是有序的，第一條記錄是最后錄入的數(shù)據(jù)。
比如需要保存一個用戶的操作記錄，按照操作時間倒序排序，在設計rowkey的時候，可以這樣設計[userId反轉] [Long.Max_Value - timestamp]，在查詢用戶的所有操作記錄數(shù)據(jù)的時候，直接指定反轉后的userId，startRow是[userId反轉][000000000000],stopRow是[userId反轉][Long.Max_Value - timestamp]
如果需要查詢某段時間的操作記錄，startRow是[user反轉][Long.Max_Value - 起始時間]，stopRow是[userId反轉][Long.Max_Value - 結束時間]HBase建表預分區(qū)：創(chuàng)建HBase表時，就預先根據(jù)可能的RowKey劃分出多個region而不是默認的一個，從而可以將后續(xù)的讀寫操作負載均衡到不同的region上，避免熱點現(xiàn)象。
5. HBase的 rowkey 設計原則
長度原則：100字節(jié)以內，8的倍數(shù)最好，可能的情況下越短越好。因為HFile是按照 keyvalue 存儲的，過長的rowkey會影響存儲效率；其次，過長的rowkey在memstore中較大，影響緩沖效果，降低檢索效率。最后，操作系統(tǒng)大多為64位，8的倍數(shù)，充分利用操作系統(tǒng)的最佳性能。
散列原則：高位散列，低位時間字段。避免熱點問題。
唯一原則：分利用這個排序的特點，將經(jīng)常讀取的數(shù)據(jù)存儲到一塊，將最近可能會被訪問 的數(shù)據(jù)放到一塊。
6. HBase的列簇設計
原則：在合理范圍內能盡量少的減少列簇就盡量減少列簇，因為列簇是共享region的，每個列簇數(shù)據(jù)相差太大導致查詢效率低下。
最優(yōu)：將所有相關性很強的 key-value 都放在同一個列簇下，這樣既能做到查詢效率最高，也能保持盡可能少的訪問不同的磁盤文件。以用戶信息為例，可以將必須的基本信息存放在一個列族，而一些附加的額外信息可以放在另一列族。
7. HBase 中 compact 用途是什么，什么時候觸發(fā)，分為哪兩種，有什么區(qū)別
在 hbase 中每當有 memstore 數(shù)據(jù) flush 到磁盤之后，就形成一個 storefile，當 storeFile的數(shù)量達到一定程度后，就需要將 storefile 文件來進行 compaction 操作。
Compact 的作用：?
合并文件
清除過期，多余版本的數(shù)據(jù)
提高讀寫數(shù)據(jù)的效率
HBase 中實現(xiàn)了兩種 compaction 的方式：minor and major. 這兩種 compaction 方式的區(qū)別是：
Minor 操作只用來做部分文件的合并操作以及包括 minVersion=0 并且設置 ttl 的過期版本清理，不做任何刪除數(shù)據(jù)、多版本數(shù)據(jù)的清理工作。
Major 操作是對 Region 下的 HStore 下的所有 StoreFile 執(zhí)行合并操作，最終的結果是整理合并出一個文件。