hbase面試題

1.hbase的特色是什麼？

　答：1)hbase是一個分佈式的，基於列式存儲的數據庫，基於hadoop的hdfs存儲，zookeeper進行管理。

　　   2)hbase 適合存儲半結構化或非結構化的數據，對於數據結構字段不夠肯定或者雜亂無章很難按照一個概念去抽取的數據。

　　   3)hbase爲null的數據不會被存儲

　　　4)基於的表包含rowKey，時間戳和列族，新寫入數據時，時間戳更新，同時能夠查詢到之前的版本

　　　5）hbase是主從結構，hmaster做爲主節點，hregionServer做爲從節點

2.hbase如何導入數據？

　　使用 MapReduce Job 方式，根據 Hbase API 編寫 java 腳本，將文本文件用文件流的方式截取，而後存儲到多個字符串數組中，在 put 方法下，經過對錶中的列族進行 for 循環遍歷列名，用 if 判斷列名後進行 for 循環調用 put.add 的方法對列族下每個列進行設值，每一個列族下有幾個了就賦值幾回！沒有表先對先建立表。 

 3.hbase 的存儲結構？ 　　

　　答： Hbase 中的每張表都經過行鍵(rowkey)按照必定的範圍被分割成多個子表（HRegion），默認一個 HRegion 超過 256M 就要被分割成兩個，由 HRegionServer 管理，管理哪些 HRegion由 Hmaster 分配。 HRegion 存取一個子表時，會建立一個 HRegion 對象，而後對錶的每一個列族（Column Family）建立一個 store 實例，每一個 store 都會有 0 個或多個 StoreFile 與之對應，每一個 StoreFile 都會對應一個 HFile， HFile 就是實際的存儲文件，所以，一個 HRegion 還擁有一個 MemStore 實例。 

4.Hbase 和 hive 有什麼區別hive 與 hbase 的底層存儲是什麼？hive是產生的緣由是什麼？habase是爲了彌補hadoop的什麼缺陷？

答案:共同點：1.hbase與hive都是架構在hadoop之上的。都是用hadoop做爲底層存儲

　　　區別：2.Hive是創建在Hadoop之上爲了減小MapReducejobs編寫工做的批處理系統，HBase是爲了支持彌補Hadoop對實時操做的缺陷的項目 。

　　　　　　3.想象你在操做RMDB數據庫，若是是全表掃描，就用Hive+Hadoop,若是是索引訪問，就用HBase+Hadoop 。

　　　　　　4.Hive query就是MapReduce jobs能夠從5分鐘到數小時不止，HBase是很是高效的，確定比Hive高效的多。

　　　　　　5.Hive自己不存儲和計算數據，它徹底依賴於HDFS和MapReduce，Hive中的表純邏輯。

　　　　　　6.hive借用hadoop的MapReduce來完成一些hive中的命令的執行

　　　　　　7.hbase是物理表，不是邏輯表，提供一個超大的內存hash表，搜索引擎經過它來存儲索引，方便查詢操做。

　　　　　　8.hbase是列存儲。

　　　　　　9.hdfs做爲底層存儲，hdfs是存放文件的系統，而Hbase負責組織文件。

　　　　　　10.hive須要用到hdfs存儲文件，須要用到MapReduce計算框架。

 

5.解釋下 hbase 實時查詢的原理

　　答：實時查詢，能夠認爲是從內存中查詢，通常響應時間在 1 秒內。 HBase 的機制是數據先寫入到內存中，當數據量達到必定的量（如 128M），再寫入磁盤中， 在內存中，是不進行數據的更新或合併操做的，只增長數據，這使得用戶的寫操做只要進入內存中就能夠當即返回，保證了 HBase I/O 的高性能。 

 6.列簇怎麼建立比較好？(<=2)

答： rowKey 最好要建立有規則的 rowKey，即最好是有序的。 HBase 中一張表最好只建立一到兩個列族比較好，由於 HBase 不能很好的處理多個列族。

 7.描述 Hbase 中 scan 和 get 的功能以及實現的異同.

1.按指定RowKey 獲取惟一一條記錄， get方法（org.apache.hadoop.hbase.client.Get）Get 的方法處理分兩種 : 設置了 ClosestRowBefore 和沒有設置的 rowlock .主要是用來保證行的事務性，即每一個 get 是以一個 row 來標記的.一個 row 中能夠有不少 family 和 column.

2.按指定的條件獲取一批記錄， scan 方法(org.apache.Hadoop.hbase.client.Scan)實現條件查詢功能使用的就是 scan 方式.1)scan 能夠經過 setCaching 與 setBatch 方法提升速度(以空間換時間)； 2)scan 能夠經過 setStartRow 與 setEndRow 來限定範圍([start， end]start 是閉區間， end 是開區間)。範圍越小，性能越高。3)scan 能夠經過 setFilter 方法添加過濾器，這也是分頁、多條件查詢的基礎。

3.全表掃描，即直接掃描整張表中全部行記錄 

8.請詳細描述 Hbase 中一個 Cell 的結構

HBase 中經過 row 和 columns 肯定的爲一個存貯單元稱爲 cell。Cell：由{row key, column(=<family> + <label>), version}是惟一肯定的單元 cell中的數據是沒有類型的，所有是字節碼形式存貯 

 

9.請描述 Hbase 中 scan 對象的 setCache 和 setBatch 方法的使用. 

cache：

 在默認狀況下，若是你須要從hbase中查詢數據，在獲取結果ResultScanner時，hbase會在你每次調用ResultScanner.next（）操做時對返回的每一個Row執行一次RPC操做。即便你使用ResultScanner.next(int nbRows)時也只是在客戶端循環調用RsultScanner.next()操做，你能夠理解爲hbase將執行查詢請求以迭代器的模式設計，在執行next（）操做時纔會真正的執行查詢操做，而對每一個Row都會執行一次RPC操做。

     所以顯而易見的就會想若是我對多個Row返回查詢結果才執行一次RPC調用，那麼就會減小實際的通信開銷。這個就是hbase配置屬性「hbase.client.scanner.caching」的由來，設置cache能夠在hbase配置文件中顯示靜態的配置，也能夠在程序動態的設置。

 

     cache值得設置並非越大越好，須要作一個平衡。cache的值越大，則查詢的性能就越高，可是與此同時，每一次調用next（）操做都須要花費更長的時間，由於獲取的數據更多而且數據量大了傳輸到客戶端須要的時間就越長，一旦你超過了maximum heap the client process 擁有的值，就會報outofmemoryException異常。當傳輸rows數據到客戶端的時候，若是花費時間過長，則會拋出ScannerTimeOutException異常。

 

batch：

     在cache的狀況下，咱們通常討論的是相對比較小的row，那麼若是一個Row特別大的時候應該怎麼處理呢？要知道cache的值增長，那麼在client process 佔用的內存就會隨着row的增大而增大。在hbase中一樣爲解決這種狀況提供了相似的操做：Batch。能夠這麼理解，cache是面向行的優化處理，batch是面向列的優化處理。它用來控制每次調用next（）操做時會返回多少列，好比你設置setBatch（5），那麼每個Result實例就會返回5列，若是你的列數爲17的話，那麼就會得到四個Result實例，分別含有5,5,5,2個列。

 

下面會以表格的形式來幫助理解，假設咱們擁有10Row，每一個row擁有2個family，每一個family擁有10個列。（也就是說每一個Row含有20列）

caching	batch	Results	RPCs	Notes
1	1	200	201	額外的一個RPC是用來判斷scan是否完成
200	1	200	2
2000	100	10	1	超過的部分沒有用處，可是判斷scan也在那一個RPC 中完成
2	100	10	6	10/2 +1 (額外的判斷開銷）
2	10	20	11
5	100	10	3
5	20	10	3
10	10	20	3

 

RPCs=(Rows* Cols per Row) / Min(Cols per Row, Batch size) / Scanner caching

 

上圖引用自hbase權威指南，是用來表示一個RPC call的構成。

10.簡述 HBASE 中 compact 用途是什麼，何時觸發，分爲哪兩種,有什麼區別，有哪些相關配置參數？

　　在 hbase 中每當有 memstore 數據 flush 到磁盤以後，就造成一個 storefile，當 storeFile 的數量達到必定程度後，就須要將 storefile 文件來進行 compaction 操做。

　　Compact 的做用：

　　　　　　　　　　1>.合併文件

　　　　　　　　　　2>.清除過時，多餘版本的數據

　　　　　　　　　　3>.提升讀寫數據的效率

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

　　minor and major. 這兩種 compaction 方式的區別是：

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

　　　　二、 Major 操做是對 Region 下的 HStore 下的全部 StoreFile 執行合併操做，最終的結果是整理合並出一個文件。簡述 Hbase filter 的實現原理是什麼？結合實際項目經驗，寫出幾個使用 filter 的場景HBase 爲篩選數據提供了一組過濾器，經過這個過濾器能夠在 HBase 中的數據的多個維度（行，列，數據版本）上進行對數據的篩選操做，也就是說過濾器最終可以篩選的數據可以細化到具體的一個存儲單元格上（由行鍵，列名，時間戳定位）。 RowFilter、 PrefixFilter。。。hbase的filter是經過scan設置的，因此是基於scan的查詢結果進行過濾.過濾器的類型不少，可是能夠分爲兩大類——比較過濾器，專用過濾器過濾器的做用是在服務端判斷數據是否知足條件，而後只將知足條件的數據返回給客戶端；如在進行訂單開發的時候，咱們使用rowkeyfilter過濾出某個用戶的全部訂單

　11.　Hbase 內部是什麼機制

　　在 HBase 中不管是增長新行仍是修改已有行，其內部流程都是相同的。 HBase 接到命令後存下變化信息，或者寫入失敗拋出異常。默認狀況下，執行寫入時會寫到兩個地方：預寫式日誌（write-ahead log，也稱 HLog）和 MemStore。 HBase 的默認方式是把寫入動做記錄在這兩個地方，以保證數據持久化。只有當這兩個地方的變化信息都寫入並確認後，才認爲寫動做完成。MemStore 是內存裏的寫入緩衝區， HBase 中數據在永久寫入硬盤以前在這裏累積。當MemStore 填滿後，其中的數據會刷寫到硬盤，生成一個 HFile。 HFile 是 HBase 使用的底層存儲格式。 HFile 對應於列族，一個列族能夠有多個 HFile，但一個 HFile 不能存儲多個列族的數據。在集羣的每一個節點上，每一個列族有一個 MemStore。大型分佈式系統中硬件故障很常見， HBase 也不例外。設想一下，若是 MemStore 尚未刷寫，服務器就崩潰了，內存中沒有寫入硬盤的數據就會丟失。 HBase 的應對辦法是在寫動做完成以前先寫入 WAL。 HBase 集羣中每臺服務器維護一個 WAL 來記錄發生的變化。WAL 是底層文件系統上的一個文件。直到 WAL 新記錄成功寫入後，寫動做才被認爲成功完成。這能夠保證 HBase 和支撐它的文件系統知足持久性。大多數狀況下， HBase 使用Hadoop 分佈式文件系統（HDFS）來做爲底層文件系統。若是 HBase 服務器宕機，沒有從 MemStore 裏刷寫到 HFile 的數據將能夠經過回放WAL 來恢復。你不須要手工執行。 Hbase 的內部機制中有恢復流程部分來處理。每臺HBase 服務器有一個 WAL，這臺服務器上的全部表（和它們的列族）共享這個 WAL。你可能想到，寫入時跳過 WAL 應該會提高寫性能。但咱們不建議禁用 WAL，除非你願意在出問題時丟失數據。若是你想測試一下，以下代碼能夠禁用 WAL： 注意：不寫入 WAL 會在 RegionServer 故障時增長丟失數據的風險。關閉 WAL，出現故障時 HBase 可能沒法恢復數據，沒有刷寫到硬盤的全部寫入數據都會丟失。 

12.HBase 宕機如何處理

答：宕機分爲 HMaster 宕機和 HRegisoner 宕機，若是是 HRegisoner 宕機， HMaster 會將其所管理的 region 從新分佈到其餘活動的 RegionServer 上，因爲數據和日誌都持久在 HDFS中，該操做不會致使數據丟失。因此數據的一致性和安全性是有保障的。若是是 HMaster 宕機， HMaster 沒有單點問題， HBase 中能夠啓動多個 HMaster，經過Zookeeper 的 Master Election 機制保證總有一個 Master 運行。即 ZooKeeper 會保證總會有一個 HMaster 在對外提供服務。

 13.致使Hbase掛掉的場景

致使Hbase掛掉的場景HMasterHMaster會出現異常(執行abort())中止的場景以下：1.zk異常致使的master中止服務是最多見的場景，涉及操做包含但不限於如下：  a)Zk連接超時，超時時間經過zookeeper.session.timeout配置，默認爲3分鐘, 若是fail.fast.expired.active.master配置的值爲false（默認爲false），則不會當即abort，而是會嘗試恢復zk的過時session；  b)在打開region後，須要從zk中刪除opened節點，若是zk有該節點，可是刪除失敗；  c)在split region過程當中，從zk刪除split節點時；  d)Master節點改變時；  e)從zk中建立unassigned節點時；  f)在下線disabled的regoin時，從zk中刪除disabled的region若是發生zk異常；  g)還有不少操做zk的節點時若是出現異常。2.在assign時，若是設置region爲offlined狀態，可是region以前的狀態不是closed或者offlined；3.在assign時，若是沒法從.META.表中讀取region信息；4.把新的hbase集羣加入到正在運行的hbase集羣時，若是zk的/hbase/unassigned節點沒有數據；5.使用線程池批量分配region時，若是出現未被捕獲的異常，實現方式以下：6.在啓動master的服務線程時，出現了異常；7.在hdfs中檢查hbase日誌路徑時，發現了dead的server時，需從hdfs中讀出log，若是出現io異常須要檢查hdfs文件系統，若是fsOk狀態爲true，可是經過FSUtils工具類進行檢查時出現io異常；8.在校驗而且分配-ROOT-的region時，若是zk異常，或者其它異常（其它異常會重試10次），好比：「-ROOT- is onlined on the dead server」。 HRegionServerHRegionServer會出現異常中止(執行abort())服務的場景以下：1.在讀寫hdfs時若是出現IOException異常，此時會發起hdfs的文件系統檢查（checkFileSystem）1.          2.Regionserver的服務線程出現了未捕獲異常；3.在啓動HRegionServer時出現異常；4.在進行HLog回滾時，出現異常；5.在flush memstore時，若是持久化失敗，會重啓RS，在重啓中把hlog的內容從新加載到memstore；6.出現zk異常，包括但不限於如下場景：  a)Zk連接超時，超時時間經過zookeeper.session.timeout配置，默認爲3分鐘，與master不一樣，若是zk操做不會重試；  b)啓動HRegionServer時出現KeeperException異常；   c)在進行split操做時，若是出現異常會進行回滾操做，在回滾過程當中須要從zk中刪除region的spliting狀態，若是刪除時出現KeeperException或者回滾的其它操做出現異常；  d)在打開region時，出現了KeeperException異常；  e)在進行hbase集羣複製時，不少與zk交互的操做出現KeeperException異常時均會致使abort；7.在close region時，若是出現異常，好比：不能成功的flush memstore；8.Flush memstore時，若是HLog發現該region已經在flush則會強制終止JVM，採用的是Runtime.getRuntime().halt(1)方法，該方法不會執行正常退出的關閉鉤子，從而不會flush RS的全部region，也不會遷移region，只有等待ZK的session超時後master纔會發現該RS不可用，作遷移工做。總結Hbase掛掉的可能性有不少，主要由zk或者hdfs的問題致使，所以zk、hdfs的可用對於hbase極其重要，關於zk：1.zk若是中止了服務則在不少時候會致使master、rs掛掉，hbase集羣基本上就失去了服務的能力，所以zk必定要是穩定可靠的，當client已經於rs創建了連接，這時zk掛掉，若是不進行split等小數與zk交互失敗會致使觸發rs的abort()的操做時rs仍是能夠提供服務的；2.若是rs/master進行了長時間的gc或者改動了服務器時間，致使出現zk的session超時會致使rs/master中止服務，目前已經出現了2次由於服務器時間變化致使hbase中止服務的事故;3.別輕易人爲改變zk的hbase節點數據，master/rs在進行不少操做時會比較依賴zk的數據，若是發現不符合預期可能會致使master/rs中止服務，尤爲是master。Master經過ZK知道RS是否可用，通常狀況下RS在中止服務時均會正常退出，在正常退出時會從ZK中刪除/hbase/rs/$regionserver的節點，Master會監聽該節點的被刪除，從而較快的(速度取決於全部region關閉時間)對該RS負責的region進行從新分配，若是是強制退出，好比 kill -9或者出現HRegionServer掛掉的第8條時則只有等待ZK的session超時時纔會刪除RS在ZK的節點（RS在ZK中添加節點時採用的是CreateMode.EPHEMERAL模式，該模式建立的節點會在session關閉時自動刪除），那時Master纔會進行從新assign。Kill RS的進程也是正常退出（不能使用kill -9強制退出），RS使用Runtime的addShutdownHook方法註冊了jvm關閉鉤子，在關閉鉤子中會執行RS的退出邏輯，實際上hbase-daemon.sh的中止RS就是採用kill。