HBase架構介紹

http://www.cnblogs.com/csyuan/p/6543018.html

1. HBase框架簡單介紹

HBase是一個分佈式的、面向列的開源數據庫，它不同於一般的關係數據庫,是一個適合於非結構化數據存儲的數據庫。另一個不同的是HBase基於列的而不是基於行的模式。HBase使用和 BigTable非常相同的數據模型。用戶存儲數據行在一個表裏。一個數據行擁有一個可選擇的鍵和任意數量的列，一個或多個列組成一個ColumnFamily，一個Fmaily下的列位於一個HFile中，易於緩存數據。表是疏鬆的存儲的，因此用戶可以給行定義各種不同的列。在HBase中數據按主鍵排序，同時表按主鍵劃分爲多個Region。

在分佈式的生產環境中，HBase 需要運行在 HDFS 之上，以 HDFS 作爲其基礎的存儲設施。HBase 上層提供了訪問的數據的 Java API 層，供應用訪問存儲在 HBase 的數據。在 HBase 的集羣中主要由 Master 和 Region Server 組成，以及 Zookeeper，具體模塊如下圖所示：

簡單介紹一下 HBase 中相關模塊的作用：

• Master
  HBase Master用於協調多個Region Server，偵測各個RegionServer之間的狀態，並平衡RegionServer之間的負載。HBaseMaster還有一個職責就是負責分配Region給RegionServer。HBase允許多個Master節點共存，但是這需要Zookeeper的幫助。不過當多個Master節點共存時，只有一個Master是提供服務的，其他的Master節點處於待命的狀態。當正在工作的Master節點宕機時，其他的Master則會接管HBase的集羣。
• Region Server
  對於一個RegionServer而言，其包括了多個Region。RegionServer的作用只是管理表格，以及實現讀寫操作。Client直接連接RegionServer，並通信獲取HBase中的數據。對於Region而言，則是真實存放HBase數據的地方，也就說Region是HBase可用性和分佈式的基本單位。如果當一個表格很大，並由多個CF組成時，那麼表的數據將存放在多個Region之間，並且在每個Region中會關聯多個存儲的單元（Store）。
• Zookeeper
  對於 HBase 而言，Zookeeper的作用是至關重要的。首先Zookeeper是作爲HBase Master的HA解決方案。也就是說，是Zookeeper保證了至少有一個HBase Master 處於運行狀態。並且Zookeeper負責Region和Region Server的註冊。其實Zookeeper發展到目前爲止，已經成爲了分佈式大數據框架中容錯性的標準框架。不光是HBase，幾乎所有的分佈式大數據相關的開源框架，都依賴於Zookeeper實現HA。

2. Hbase數據模型

2.1 邏輯視圖

基本概念：

• RowKey：是Byte array，是表中每條記錄的“主鍵”，方便快速查找，Rowkey的設計非常重要；
• Column Family：列族，擁有一個名稱(string)，包含一個或者多個相關列；
• Column：屬於某一個columnfamily，familyName:columnName，每條記錄可動態添加；
• Version Number：類型爲Long，默認值是系統時間戳，可由用戶自定義；
• Value(Cell)：Byte array。

2.2 物理模型：

• 每個column family存儲在HDFS上的一個單獨文件中，空值不會被保存。
• Key 和 Version number在每個column family中均有一份；
• HBase爲每個值維護了多級索引，即：
• 表在行的方向上分割爲多個Region；
• Region是Hbase中分佈式存儲和負載均衡的最小單元，不同Region分佈到不同RegionServer上。
• Region按大小分割的，隨着數據增多，Region不斷增大，當增大到一個閥值的時候，Region就會分成兩個新的Region；
• Region雖然是分佈式存儲的最小單元，但並不是存儲的最小單元。每個Region包含着多個Store對象。每個Store包含一個MemStore或若干StoreFile，StoreFile包含一個或多個HFile。MemStore存放在內存中，StoreFile存儲在HDFS上。

2.3 ROOT表和META表

HBase的所有Region元數據被存儲在.META.表中，隨着Region的增多，.META.表中的數據也會增大，並分裂成多個新的Region。爲了定位.META.表中各個Region的位置，把.META.表中所有Region的元數據保存在-ROOT-表中，最後由Zookeeper記錄-ROOT-表的位置信息。所有客戶端訪問用戶數據前，需要首先訪問Zookeeper獲得-ROOT-的位置，然後訪問-ROOT-表獲得.META.表的位置，最後根據.META.表中的信息確定用戶數據存放的位置，如下圖所示。

-ROOT-表永遠不會被分割，它只有一個Region，這樣可以保證最多只需要三次跳轉就可以定位任意一個Region。爲了加快訪問速度，.META.表的所有Region全部保存在內存中。客戶端會將查詢過的位置信息緩存起來，且緩存不會主動失效。如果客戶端根據緩存信息還訪問不到數據，則詢問相關.META.表的Region服務器，試圖獲取數據的位置，如果還是失敗，則詢問-ROOT-表相關的.META.表在哪裏。最後，如果前面的信息全部失效，則通過ZooKeeper重新定位Region的信息。所以如果客戶端上的緩存全部是失效，則需要進行6次網絡來回，才能定位到正確的Region。

一個完整分佈式的HBase的組成示意圖如下，後面我們再詳細談其工作原理。

3. 高可用

3.1 Write-Ahead-Log（WAL）保障數據高可用

我們理解下HLog的作用。HBase中的HLog機制是WAL的一種實現，而WAL（一般翻譯爲預寫日誌）是事務機制中常見的一致性的實現方式。每個RegionServer中都會有一個HLog的實例，RegionServer會將更新操作（如 Put，Delete）先記錄到 WAL（也就是HLo）中，然後將其寫入到Store的MemStore，最終MemStore會將數據寫入到持久化的HFile中（MemStore 到達配置的內存閥值）。這樣就保證了HBase的寫的可靠性。如果沒有 WAL，當RegionServer宕掉的時候，MemStore 還沒有寫入到HFile，或者StoreFile還沒有保存，數據就會丟失。或許有的讀者會擔心HFile本身會不會丟失，這是由 HDFS 來保證的。在HDFS中的數據默認會有3份。因此這裏並不考慮 HFile 本身的可靠性。

HFile由很多個數據塊（Block）組成，並且有一個固定的結尾塊。其中的數據塊是由一個Header和多個Key-Value的鍵值對組成。在結尾的數據塊中包含了數據相關的索引信息，系統也是通過結尾的索引信息找到HFile中的數據。

3.2 組件高可用

• Master容錯：Zookeeper重新選擇一個新的Master。如果無Master過程中，數據讀取仍照常進行，但是，region切分、負載均衡等無法進行；
• RegionServer容錯：定時向Zookeeper彙報心跳，如果一旦時間內未出現心跳，Master將該RegionServer上的Region重新分配到其他RegionServer上，失效服務器上“預寫”日誌由主服務器進行分割並派送給新的RegionServer；
• Zookeeper容錯：Zookeeper是一個可靠地服務，一般配置3或5個Zookeeper實例。

4. HBase讀寫流程

上圖是RegionServer數據存儲關係圖。上文提到，HBase使用MemStore和StoreFile存儲對錶的更新。數據在更新時首先寫入HLog和MemStore。MemStore中的數據是排序的，當MemStore累計到一定閾值時，就會創建一個新的MemStore，並且將老的MemStore添加到Flush隊列，由單獨的線程Flush到磁盤上，成爲一個StoreFile。與此同時，系統會在Zookeeper中記錄一個CheckPoint，表示這個時刻之前的數據變更已經持久化了。當系統出現意外時，可能導致MemStore中的數據丟失，此時使用HLog來恢復CheckPoint之後的數據。
StoreFile是隻讀的，一旦創建後就不可以再修改。因此Hbase的更新其實是不斷追加的操作。當一個Store中的StoreFile達到一定閾值後，就會進行一次合併操作,將對同一個key的修改合併到一起，形成一個大的StoreFile。當StoreFile的大小達到一定閾值後，又會對 StoreFile進行切分操作，等分爲兩個StoreFile。

4.1 寫操作流程

• (1) Client通過Zookeeper的調度，向RegionServer發出寫數據請求，在Region中寫數據。
• (2) 數據被寫入Region的MemStore，直到MemStore達到預設閾值。
• (3) MemStore中的數據被Flush成一個StoreFile。
• (4) 隨着StoreFile文件的不斷增多，當其數量增長到一定閾值後，觸發Compact合併操作，將多個StoreFile合併成一個StoreFile，同時進行版本合併和數據刪除。
• (5) StoreFiles通過不斷的Compact合併操作，逐步形成越來越大的StoreFile。
• (6) 單個StoreFile大小超過一定閾值後，觸發Split操作，把當前Region Split成2個新的Region。父Region會下線，新Split出的2個子Region會被HMaster分配到相應的RegionServer上，使得原先1個Region的壓力得以分流到2個Region上。

可以看出HBase只有增添數據，所有的更新和刪除操作都是在後續的Compact歷程中舉行的，使得用戶的寫操作只要進入內存就可以立刻返回，實現了HBase I/O的高機能。

4.2 讀操作流程

• (1) Client訪問Zookeeper，查找-ROOT-表，獲取.META.表信息。
• (2) 從.META.表查找，獲取存放目標數據的Region信息，從而找到對應的RegionServer。
• (3) 通過RegionServer獲取需要查找的數據。
• (4) Regionserver的內存分爲MemStore和BlockCache兩部分，MemStore主要用於寫數據，BlockCache主要用於讀數據。讀請求先到MemStore中查數據，查不到就到BlockCache中查，再查不到就會到StoreFile上讀，並把讀的結果放入BlockCache。