HBase面試題有哪些

本篇內容主要講解“HBase面試題有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“HBase面試題有哪些”吧!

1. HBase是什么？HBase的特點是什么？

1. Hbase一個分布式的基于列式存儲的數據庫，基于Hadoop的 hdfs 存儲，zookeeper 進行管理。

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

3. Hbase 為 null 的記錄不會被存儲。

4. 基于的表包含 rowkey，時間戳，和列族。新寫入數據時，時間戳更新， 同時可以查詢到以前的版本。

5. hbase 是主從架構。hmaster 作為主節點，hregionserver 作為從節點。

6. 大：一個表可以有數十億行，上百萬列；

7. 無模式：每行都有一個可排序的主鍵和任意多的列，列可以根據需要動態的增加，同一
   張表中不同的行可以有截然不同的列；

8. 面向列：面向列（族）的存儲和權限控制，列（族）獨立檢索；

9. 稀疏：空（null）列并不占用存儲空間，表可以設計的非常稀疏；

10. 數據多版本：每個單元中的數據可以有多個版本，默認情況下版本號自動分配，是單元
    格插入時的時間戳；

11. 數據類型單一：Hbase 中的數據都是字符串，沒有類型。
     

2. HBase如何導入數據？

1. 通過HBase API進行批量寫入數據；

2. 使用Sqoop工具批量導數到HBase集群；

3. 使用MapReduce批量導入；

4. HBase BulkLoad的方式。

5. HBase 通過Hive 關聯導入數據

HBase API 跟 MapReduce寫入方式在面對大數據量寫入的時候效率會很低下，因為它們都是通過請求regionserver將數據寫入，這期間數據會先寫入memstore，memstore達到閾值后會刷寫到磁盤生成hfile文件，hfile文件過多時會發生compaction，如果region大小過大時也會發生split。這些因素都會影響hbase數據寫入的效率，因此在面臨大數據寫入時，這兩種方式是不合適的。

而bulkload正好解決了這個問題，bulkload 工具是將數據直接寫入到hfile文件中，寫入完畢后，通知hbase去加載這些hfile文件，因此可以避免上述耗時的因素，大大增加了數據寫入的效率。下面就來講述下如何利用bulkloan加載數據。

4. Hbase 和 hive 有什么區別？hive 與 hbase 的底層存儲是什么？hive 是產生的原因是什么？habase 是為了彌補 hadoop 的什么缺陷?

共同點：

1. hbase與hive都是架構在hadoop之上的。都是用hadoop作為底層存儲。

區別：

1. Hive是建立在Hadoop之上為了減少MapReduce jobs編寫工作的批處理系統，HBase是為了支持彌補Hadoop對實時操作的缺陷的項目 。

2. 想象你在操作RMDB數據庫，如果是全表掃描，就用Hive+Hadoop，如果是索引訪問，就用HBase+Hadoop；

3. Hive query就是MapReduce jobs可以從5分鐘到數小時不止，HBase是非常高效的，肯定比Hive高效的多；

4. Hive本身不存儲和計算數據，它完全依賴于 HDFS 和 MapReduce，Hive中的表純邏輯；

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

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

7. hbase是列存儲；

8. hdfs 作為底層存儲，hdfs 是存放文件的系統，而 Hbase 負責組織文件；

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

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

實時查詢，可以認為是從內存中查詢，一般響應時間在 1 秒內。HBase 的機制是數據先寫入到內存中，當數據量達到一定的量（如 128M），再寫入磁盤中， 在內存中，是不進行數據的更新或合并操作的，只增加數據，這使得用戶的寫操作只要進入內存中就可以立即返回，保證了 HBase I/O 的高性能

6. 描述 Hbase 的 rowKey 的設計原則

聯系 region 和 rowkey 關系說明，設計可參考以下三個原則.

     1. rowkey 長度原則
rowkey 是一個二進制碼流，可以是任意字符串，最大長度 64kb，實際應用中一般為 10-100bytes，以 byte[] 形式保存，一般設計成定長。建議越短越好，不要超過 16 個字節， 原因如下：

數據的持久化文件 HFile 中是按照 KeyValue 存儲的，如果 rowkey 過長會極大影響 HFile 的存儲效率 MemStore 將緩存部分數據到內存，如果 rowkey 字段過長，內存的有效利用率就會降低，系統不能緩存更多的數據，這樣會降低檢索效率

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

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

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 方式

3. 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， CF，Columns， version}是唯一確定的單元cell 中的數據是沒有類型的，全部是字節碼形式存貯。

9. 簡述 HBASE 中 compact 用途是什么，什么時候觸發，分為哪兩種，有什么區別，有哪些相關配置參數？

在 hbase 中每當有 memstore 數據 flush 到磁盤之后，就形成一個 storefile， 當 storeFile 的數量達到一定程度后，就需要將 storefile 文件來進行 compaction 操作。Compact 的作用：

1. 合并文件

2. 清除過期，多余版本的數據

3. 提高讀寫數據的效率

10. HBase 中實現了兩種 compaction 的方式 ： minor and major這兩種compaction 方式的區別是：

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

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

3. Minor and Major 合并規則

11. 簡述 Hbase filter 的實現原理是什么？結合實際項目經驗，寫出幾個使用filter 的場景。

HBase 為篩選數據提供了一組過濾器，通過這個過濾器可以在 HBase 中的數據的多個維度（行，列，數據版本）上進行對數據的篩選操作，也就是說過濾器最終能夠篩選的數據能夠細化到具體的一個存儲單元格上（由行鍵， 列名，時間戳定位）。

RowFilter、PrefixFilter。hbase 的 filter 是通過 scan 設置的，所以是基于 scan 的查詢結果進行過濾. 過濾器的類型很多，但是可以分為兩大類——比較過濾器，專用過濾器。過濾器的作用是在服務端判斷數據是否滿足條件，然后只將滿足條件的數據返回給客戶端；如在進行訂單開發的時候，我們使用 rowkeyfilter 過濾出某個用戶的所有訂單。

12. 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 可能無法恢復數據，沒有刷寫到硬盤的所有寫入數據都會丟失。

13. HBase 宕機如何處理？

宕機分為 HMaster 宕機和 HRegisoner 宕機.

如果是 HRegisoner 宕機，HMaster 會將其所管理的 region 重新分布到其他活動的 RegionServer 上，由于數據和日志都持久在 HDFS 中，該操作不會導致數據丟失,所以數據的一致性和安全性是有保障的。

如果是 HMaster 宕機， HMaster 沒有單點問題， HBase 中可以啟動多個HMaster，通過 Zookeeper 的 Master Election 機制保證總有一個 Master 運行。即ZooKeeper 會保證總會有一個 HMaster 在對外提供服務。

14. HRegionServer宕機如何處理？

1. ZooKeeper 會監控 HRegionServer 的上下線情況，當 ZK 發現某個 HRegionServer 宕機之后會通知 HMaster 進行失效備援；

2. HRegionServer 會停止對外提供服務，就是它所負責的 region 暫時停止對外提供服務

3. HMaster 會將該 HRegionServer 所負責的 region 轉移到其他 HRegionServer 上，并且會對 HRegionServer 上存在 memstore 中還未持久化到磁盤中的數據進行恢復;

4. 這個恢復的工作是由 WAL重播 來完成，這個過程如下：

1. wal實際上就是一個文件，存在/hbase/WAL/對應RegionServer路徑下
2. 宕機發生時，讀取該RegionServer所對應的路徑下的wal文件，然后根據不同的region切分成不同的臨時文件recover.edits
3. 當region被分配到新的RegionServer中，RegionServer讀取region時會進行是否存在recover.edits，如果有則進行恢復

15. hbase寫數據 和 讀數據過程獲取region存儲位置信息

寫數據和讀數據一般都會獲取hbase的region的位置信息。大概步驟為：

1. 從zookeeper中獲取.ROOT.表的位置信息，在zookeeper的存儲位置為/hbase/root-region-server；

2. 根據.ROOT.表中信息，獲取.META.表的位置信息；

3. META.表中存儲的數據為每一個region存儲位置；

向hbase表中插入數據

hbase中緩存分為兩層：Memstore 和 BlockCache

1. 首先寫入到 WAL文件 中，目的是為了數據不丟失；

2. 再把數據插入到 Memstore緩存中，當 Memstore達到設置大小閾值時，會進行flush進程；

3. flush過程中，需要獲取每一個region存儲的位置。

從hbase中讀取數據

BlockCache 主要提供給讀使用。讀請求先到 Memtore中查數據，查不到就到 BlockCache 中查，再查不到就會到磁盤上讀，并把讀的結果放入 BlockCache 。

BlockCache 采用的算法為 LRU（最近最少使用算法），因此當 BlockCache 達到上限后，會啟動淘汰機制，淘汰掉最老的一批數據。

一個 RegionServer 上有一個 BlockCache 和N個 Memstore，它們的大小之和不能大于等于 heapsize * 0.8，否則 hbase 不能啟動。默認 BlockCache 為 0.2，而 Memstore 為 0.4。對于注重讀響應時間的系統，應該將 BlockCache 設大些，比如設置BlockCache =0.4，Memstore=0.39。這會加大緩存命中率。

15. HBase優化方法

優化手段主要有以下四個方面

1. 減少調整

減少調整這個如何理解呢？HBase中有幾個內容會動態調整，如region（分區）、HFile，所以通過一些方法來減少這些會帶來I/O開銷的調整

Region
如果沒有預建分區的話，那么隨著region中條數的增加，region會進行分裂，這將增加I/O開銷，所以解決方法就是根據你的RowKey設計來進行預建分區，減少region的動態分裂。

HFile
HFile是數據底層存儲文件，在每個memstore進行刷新時會生成一個HFile，當HFile增加到一定程度時，會將屬于一個region的HFile進行合并，這個步驟會帶來開銷但不可避免，但是合并后HFile大小如果大于設定的值，那么HFile會重新分裂。為了減少這樣的無謂的I/O開銷，建議估計項目數據量大小，給HFile設定一個合適的值

2. 減少啟停

數據庫事務機制就是為了更好地實現批量寫入，較少數據庫的開啟關閉帶來的開銷，那么HBase中也存在頻繁開啟關閉帶來的問題。

     1. 關閉Compaction，在閑時進行手動Compaction

因為HBase中存在Minor Compaction和Major Compaction，也就是對HFile進行合并，所謂合并就是I/O讀寫，大量的HFile進行肯定會帶來I/O開銷，甚至是I/O風暴，所以為了避免這種不受控制的意外發生，建議關閉自動Compaction，在閑時進行compaction

     2. 批量數據寫入時采用BulkLoad

如果通過HBase-Shell或者JavaAPI的put來實現大量數據的寫入，那么性能差是肯定并且還可能帶來一些意想不到的問題，所以當需要寫入大量離線數據時建議使用BulkLoad

3. 減少數據量

雖然我們是在進行大數據開發，但是如果可以通過某些方式在保證數據準確性同時減少數據量，何樂而不為呢？

     1. 開啟過濾，提高查詢速度
開啟BloomFilter，BloomFilter是列族級別的過濾，在生成一個StoreFile同時會生成一個MetaBlock，用于查詢時過濾數據

     2. 使用壓縮：一般推薦使用Snappy和LZO壓縮

4. 合理設計

在一張HBase表格中RowKey和ColumnFamily的設計是非常重要，好的設計能夠提高性能和保證數據的準確性

1. RowKey設計：應該具備以下幾個屬性

• 散列性：散列性能夠保證相同相似的rowkey聚合，相異的rowkey分散，有利于查詢

• 簡短性：rowkey作為key的一部分存儲在HFile中，如果為了可讀性將rowKey設計得過長，那么將會增加存儲壓力

• 唯一性：rowKey必須具備明顯的區別性

• 業務性：舉些例子

假如我的查詢條件比較多，而且不是針對列的條件，那么rowKey的設計就應該支持多條件查詢
如果我的查詢要求是最近插入的數據優先，那么rowKey則可以采用叫上Long.Max-時間戳的方式，這樣rowKey就是遞減排列
     2. 列族的設計

      列族的設計需要看應用場景

      多列族設計的優劣

優勢：
HBase中數據時按列進行存儲的，那么查詢某一列族的某一列時就不需要全盤掃描，只需要掃描某一列族，減少了讀I/O；
其實多列族設計對減少的作用不是很明顯，適用于讀多寫少的場景。

劣勢：
降低了寫的I/O性能。原因如下：數據寫到store以后是先緩存在memstore中，同一個region中存在多個列族則存在多個store，每個store都一個memstore，當其實memstore進行flush時，屬于同一個region的store中的memstore都會進行flush，增加I/O開銷。

16. 為什么不建議在 HBase 中使用過多的列族

在 Hbase 的表中，每個列族對應 Region 中的一個Store，Region的大小達到閾值時會分裂，因此如果表中有多個列族，則可能出現以下現象：

1. 一個Region中有多個Store，如果每個CF的數據量分布不均勻時，比如CF1為100萬，CF2為1萬，則Region分裂時導致CF2在每個Region中的數據量太少，查詢CF2時會橫跨多個Region導致效率降低。

2. 如果每個CF的數據分布均勻，比如CF1有50萬，CF2有50萬，CF3有50萬，則Region分裂時導致每個CF在Region的數據量偏少，查詢某個CF時會導致橫跨多個Region的概率增大。

3. 多個CF代表有多個Store，也就是說有多個MemStore(2MB)，也就導致內存的消耗量增大，使用效率下降。

4. Region 中的 緩存刷新 和 壓縮 是基本操作，即一個CF出現緩存刷新或壓縮操作，其它CF也會同時做一樣的操作，當列族太多時就會導致IO頻繁的問題。

17. 為什么有HDFS還要用HBase?

• 延遲: Mapreduce編程框架延遲較高,無法滿足大規模數據實時處理應用的需求

• 訪問: HDFS面向批量訪問而不是隨機訪問

為什么用HBase而不用傳統關系型數據庫? / 關系型數據庫和HBase有什么區別?

• 數據類型: 傳統關系型數據庫有豐富的數據類型,HBase把數據存儲為未經解釋的字符串

• 數據操作: 關系數據庫包含了豐富的操作，可涉及復雜的多表連接,而HBase只有簡單的插入查詢刪除清空等,不涉及表與表的連接

• 存儲模式: 關系數據庫基于行存儲,HBase基于列存儲

• 數據索引: 關系數據庫可構建復雜的多個索引以提高檢索效率；HBase只有一個索引:行鍵(RowKey),經過巧妙地設計,通過rowkey索引或掃描，不會使系統慢下來

• 數據維護: 關系數據庫更新會覆蓋原值,HBase則是生成一個新的版本,舊數據依然保留

• 可伸縮性: 關系數據庫很難實現橫向擴展,而HBase能夠容易地通過在集群中增加或減少硬件實現性能地伸縮

18.理解

• 一個HBase表, 由多個Region組成,這些Region可以不在一個Region Server上；

• 根據RowKey切分Region,某個或某個連續范圍內的RowKey會被切分到一個Region

• 一個Store 對應 一個列族的數據,但一個列族由于Region的切分,可能對應多個store

• 尋址過程客戶端只需要詢問Zookeeper服務器，不需要連接Master服務器

到此，相信大家對“HBase面試題有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！