導語

本專欄博文會整理日常作業與面試中最常用到的大資料相關組件與Java語言的架構、概念、知識點，方便大家進行查閱，
涉及到的面試題以及答案均為博主搜羅整理，并加上自己的理解撰寫而成，同時博主會在部分題目的下方添加管遇此題深入理解的博文連接，方便讀者的深入理解，
希望大家可以通過此篇博文對于大資料相關概念有一個更深入的理解
還有哪些想看的面試題，讀者可以在評論區補充，博主會在一天內進行更新！！！
最后預祝大家新的一年升職加薪，工資漲漲漲！

基礎問題：

Hbase是什么

1. Hbase一個分布式的基于列式存盤的資料庫,基于Hadoop的hdfs存盤，zookeeper進行管理，
2. Hbase適合存盤半結構化或非結構化資料，對于資料結構欄位不夠確定或者雜亂無章很難按一個概念去抽取的資料，
3. Hbase為null的記錄不會被存盤.
4. 基于的表包含rowkey，時間戳，和列族，新寫入資料時，時間戳更新，同時可以查詢到以前的版本.
5. hbase是主從架構，hmaster作為主節點，hregionserver作為從節點，

深入閱讀：可能是最易懂的Hbase架構原理決議

Hbase和hive的區別

Hbase和Hive在大資料架構中處在不同位置，Hbase主要解決實時資料查詢問題，Hive主要解決資料處理和計算問題，一般是配合使用，

Hbase： Hadoop database 的簡稱，也就是基于Hadoop資料庫，是一種NoSQL資料庫，主要適用于海量明細資料（十億、百億）的隨機實時查詢，如日志明細、交易清單、軌跡行為等，

Hive：Hive是Hadoop資料倉庫，嚴格來說，不是資料庫，主要是讓開發人員能夠通過SQL來計算和處理HDFS上的結構化資料，適用于離線的批量資料計算，

深入閱讀：一篇文章讓你了解Hive和HBase的區別

Hbase特點

1. 大：一個表可以有數十億行，上百萬列；
2. 無模式：每行都有一個可排序的主鍵和任意多的列，列可以根據需要動態的增加，同一
   張表中不同的行可以有截然不同的列；
3. 面向列：面向列（族）的存盤和權限控制，列（族）獨立檢索；
4. 稀疏：空（null）列并不占用存盤空間，表可以設計的非常稀疏；
5. 資料多版本：每個單元中的資料可以有多個版本，默認情況下版本號自動分配，是單元
   格插入時的時間戳；
6. 資料型別單一：Hbase 中的資料都是字串，沒有型別，

深入閱讀：可能是最易懂的Hbase架構原理決議

RowKey的設計原則

1. 唯一性原則
   rowkey在設計上保證其唯一性，rowkey是按照字典順序排序存盤的，因此，設計rowkey的時候，要充分利用這個排序的特點，將經常讀取的資料存盤到一塊，將最近可能會被訪問的資料放到一塊，
2. 長度原則
   rowkey是一個二進制碼流，可以是任意字串，最大長度 64kb ，實際應用中一般為10-100bytes，以byte[] 形式保存，一般設計成定長，建議越短越好，不要超過16個位元組，原因如下：資料的持久化檔案HFile中是按照KeyValue存盤的，如果rowkey過長，比如超過100位元組，1000w行資料，光rowkey就要占用100*1000w=10億個位元組，將近1G資料，這樣會極大影響HFile的存盤效率；MemStore將快取部分資料到記憶體，如果rowkey欄位過長，記憶體的有效利用率就會降低，系統不能快取更多的資料，這樣會降低檢索效率，目前作業系統都是64位系統，記憶體8位元組對齊，控制在16個位元組，8位元組的整數倍利用了作業系統的最佳特性，
3. 散列原則
   如果rowkey按照時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將rowkey的高位作為散列欄位，由程式隨機生成，低位放時間欄位，這樣將提高資料均衡分布在每個RegionServer，以實作負載均衡的幾率，如果沒有散列欄位，首欄位直接是時間資訊，所有的資料都會集中在一個RegionServer上，這樣在資料檢索的時候負載會集中在個別的RegionServer上，造成熱點問題，會降低查詢效率

深入閱讀：HBase之rowkey設計原則和方法

HBase 讀寫流程

HBase資料的寫入程序：
① Client 先訪問 zookeeper，找到 Meta 表，并獲取 Meta 表元資料，
② 確定當前將要寫入的資料所對應的 HRegion 和 HRegionServer 服務器，
③ Client 向該 HRegionServer 服務器發起寫入資料請求，然后 HRegionServer 收到請求
并回應，
④ Client 先把資料寫入到 HLog，以防止資料丟失，
⑤ 然后將資料寫入到 Memstore，
⑥ 如果 HLog 和 Memstore 均寫入成功，則這條資料寫入成功
⑦ 如果 Memstore 達到閾值，會把 Memstore 中的資料 flush 到 Storefile 中，
⑧ 當 Storefile 越來越多，會觸發 Compact 合并操作，把過多的 Storefile 合并成一個大
的 Storefile，
⑨ 當 Storefile 越來越大，Region 也會越來越大，達到閾值后，會觸發 Split 操作，將
Region 一分為二，

HBase資料的讀取程序：
① HRegionServer 保存著 meta 表以及表資料，要訪問表資料，首先 Client 先去訪問zookeeper，從 zookeeper 里面獲取 meta 表所在的位置資訊，即找到這個 meta 表在哪個HRegionServer 上保存著，
② 接著 Client 通過剛才獲取到的 HRegionServer 的 IP 來訪問 Meta 表所在的HRegionServer，從而讀取到 Meta，進而獲取到 Meta 表中存放的元資料，
③ Client 通過元資料中存盤的資訊，訪問對應的 HRegionServer，然后掃描所在HRegionServer 的 Memstore 和 Storefile 來查詢資料，
④ 最后 HRegionServer 把查詢到的資料回應給 Client，

深入閱讀：Hbase的資料讀寫流程

HBase中Zookeeper的作用

1. hbase regionserver向zookeeper注冊，提供hbase regionserver狀態資訊（是否在線），
2. 存放HMaster管理的表的META元資料資訊；表名、列名、key區間等，
3. Client訪問用戶資料之前需要首先訪問zookeeper中的META.表，根據META表找到用戶資料的位置去訪問，中間需要多次網路操作，不過client端會做cache快取，
4. HMaster沒有單點問題，HBase中可以啟動多個HMaster，通過Zookeeper的事件處理確保整個集群只有一個正在運行的HMaster，
5. 當HRegionServer意外終止后，HMaster會通過Zookeeper感知到，

Hbase中compact的用途

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

compact主要起到如下幾個作用：

1. 合并檔案
2. 清除洗掉、過期、多余版本的資料
3. 提高讀寫資料的效率

HBase中實作了兩種compaction的方式：minor and major，這兩種compaction方式的區別是：

1. Minor操作只用來做部分檔案的合并操作以及包括minVersion=0并且設定ttl的過期版本清理，不做任何洗掉資料、多版本資料的清理作業，
2. Major操作是對Region下的HStore下的所有StoreFile執行合并操作，最終的結果是整理合并出一個檔案，

故障排查與調優：

Hbase資料熱點問題

一、出現熱點問題原因

1. hbase的中的資料是按照字典序排序的，當大量連續的rowkey集中寫在個別的region，各個region之間資料分布不均衡；
2. 創建表時沒有提前預磁區，創建的表默認只有一個region，大量的資料寫入當前region；
3. 創建表已經提前預磁區，但是設計的rowkey沒有規律可循

二、如何解決熱點問題

1. 亂數+業務主鍵，如果想讓最近的資料快速get到，可以將時間戳加上
2. Rowkey設計越短越好，不要超過10-100個位元組
3. 映射regionNo，這樣既可以讓資料均勻分布到各個region中，同時可以根據startKey和endKey可以get到同一批資料，

HBase 優化

1. 高可用
   在 HBase 中 Hmaster 負責監控 RegionServer 的生命周期，均衡 RegionServer 的負載，如果 Hmaster 掛掉了，那么整個 HBase 集群將陷入不健康的狀態，并且此時的作業狀態并不會維持太久，所以 HBase 支持對 Hmaster 的高可用配置，
2. 預磁區
   每一個 region 維護著 startRow 與 endRowKey，如果加入的資料符合某個 region 維護的rowKey 范圍，則該資料交給這個 region 維護，那么依照這個原則，我們可以將資料所要投放的磁區提前大致的規劃好，以提高 HBase 性能 .
3. RowKey 設計
   一條資料的唯一標識就是 rowkey，那么這條資料存盤于哪個磁區，取決于 rowkey 處于哪個一個預磁區的區間內，設計 rowkey 的主要目的 ，就是讓資料均勻的分布于所有的 region中，在一定程度上防止資料傾斜，接下來我們就談一談 rowkey 常用的設計方案
4. 記憶體優化
   HBase 操作程序中需要大量的記憶體開銷，畢竟 Table 是可以快取在記憶體中的，一般會分配整個可用記憶體的 70%給 HBase 的 Java 堆，但是不建議分配非常大的堆記憶體，因為 GC 程序持續太久會導致 RegionServer 處于長期不可用狀態，一般 16~48G 記憶體就可以了，如果因為框架占用記憶體過高導致系統記憶體不足，框架一樣會被系統服務拖死，

深入閱讀：HBase性能優化完全版

HBase 宕機恢復流程

宕機分為 Master 宕機和 regionServer 宕機
Master 宕機恢復
1、Master主要負責實作集群的負載均衡和讀寫調度，沒有單點問題，所以集群中可以存在多個Master節點，
2、通過熱備方式實作Master高可用，并在zookeeper上進行注冊
3、active master會接管整個系統的元資料管理任務，zk以及meta表中的元資料，相應用戶的管理指令，創建、洗掉、修改，merge region等
regionServer宕機恢復
1、RegionServer宕機，HBase會檢測到，由于資料和日志都持久在 HDFS中，RegionServer宕機不會導致資料丟失
2、Master將宕機RegionServer上所有管理的region重新分配到集群中其它正常的RegionServer上
3、根據HLog進行丟失資料恢復，恢復之后對外提供服務

深入閱讀：HBase宕機恢復

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

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

• 一個Region中有多個Store，如果每個CF的資料量分布不均勻時，比如CF1為100萬，CF2為1萬，則Region分裂時導致CF2在每個Region中的資料量太少，查詢CF2時會橫跨多個Region導致效率降低，
• 如果每個CF的資料分布均勻，比如CF1有50萬，CF2有50萬，CF3有50萬，則Region分裂時導致每個CF在Region的資料量偏少，查詢某個CF時會導致橫跨多個Region的概率增大，
• 多個CF代表有多個Store，也就是說有多個MemStore(2MB)，也就導致記憶體的消耗量增大，使用效率下降，
• Region 中的 快取重繪 和 壓縮 是基本操作，即一個CF出現快取重繪或壓縮操作，其它CF也會同時做一樣的操作，當列族太多時就會導致IO頻繁的問題，

深入閱讀：為什么不建議在 HBase 中使用過多的列族