hbase的底層原理

1.hbase的底層邏輯架構

（1）新舊版本的hbase的架構區別

這是舊版本的hbase的架構圖，一個regionserver中只有一個Hlog。

這一張是新版本的圖，每個regionserver中能夠有30個Hlog。
老版本和新版本的變更：
  - 0.96版本之前，一個regionserver只有一個HLog，而且管理元數據有.meta. -root-兩個元數據表。
  - 0.98版本之後，一個regionserver能夠有多個Hlog，而且管理元數據，只有.meta.表。

（2）hbase的中兩張特殊的表

  - .MEAT.：記錄了用戶全部表拆分出來的region映射信息（各個region的rowkey範圍，以及存在的節點），.MEAT.能夠有多個region。對應的用戶表中切分出來的每個region就對應.META.表中的一個記錄
  - -ROOT-：記錄了.META.表的 Region 信息，-ROOT-只有一個 Region，不管如何不會分裂，一樣的.META.表切分出來的一個region就是- ROO-表中的一個記錄。

（3）hbase架構角色職責

 1）client

    - Client訪問用戶表前須要首先訪問zookeeper，找到對應的-ROOT-表的region所在位置，而後訪問-ROOT-表，找到.meta.表的訪問位置，而後找到.meta.表，最後經過.meta.表找到用戶數據的位置去訪問，中間須要屢次網絡操做，而且client 端會作 cache 緩存（即若是下一次查找的記錄在上一次已經查詢了，能夠不進行以上操做，直接在緩存中獲得）

 2）zookeeper

    - zookeeper爲HBASE提供failover機制，選主master，避免單點故障，其實HBASE中的master，宕機一段時間對集羣影響不大，由於master，及時master宕機，HBASE集羣仍然能夠作：查看，上傳操做，可是不能建立和修改表。可是master宕機很長時間是不行的，由於master須要作負載。
    - 存儲全部Region 的尋址入口：-ROOT-表在哪臺服務器上。-ROOT-這張表的位置信息
    - 實時監控regionserver的狀態，將regionserver的上線和下線信息實時通知給master
    - 存儲HBASE的schema（包括有哪些 Table，每一個 Table 有哪些 Column Family）；默認狀況下： /hbase/table：是zookeeper中存儲HBASE中表名的目錄

 3）Master

    - 爲regionserver分配region（而且作負載均衡）
    - 發現失效的 RegionServer 並從新分配其上的 Region（即，若是有相應的RegionServer宕機的時候，master會將其宕機節點上的region，複製到其餘節點上），高容錯。
    - HDFS 上的垃圾文件（HBase）回收
    - 處理HBASE的schema（表的建立、刪除、修改、列簇的增長…）

 4）RegionServer

    - RegionServer 維護 Master 分配給它的 Region，處理對這些 Region 的 IO 請求（即對錶中數據的增、刪、改）
    - 負責和底層的文件系統hdfs交互，存儲數據到hdfs
    - 負責 Store 中的 HFile 的合併工做
    - RegionServer 負責 Split 在運行過程當中變得過大的 Region，負責 Compact （切分）操做

切分原則：
第一次：128*（1*1）
第二次：128*（3*3）
第三次：128*（5*5） 直到計算的結果>10G的時候，之後就按照10G切分

2.hbase的底層物理存儲原理

（1）總體物理結構

上圖是一個regionserver的存儲
  - Table中的全部行按照rowkey進行字典排序，而後根據rowkey範圍，切分出不一樣的region
  - Region的默認大小爲10G，每一個表一開始只有一個 HRegion，隨着數據不斷插入 表，HRegion 不斷增大，當增大到一個閥值的時候，HRegion 就會等分會兩個新的 HRegion。 當表中的行不斷增多，就會有愈來愈多的 HRegion
  - Region是Hbase 中分佈式存儲和負載均衡的最小單元。同一個region中的數據必定是存儲在同一個節點上的，可是region切分後，能夠存儲的不一樣的節點
  - Region雖然是負載的最小單元，可是不是物理存儲的最小單元。實際上，region由一個或者多個store組成，每個store，存儲的是region中的一個列簇中的全部數據。每一個 Strore 又由一個 MemStore 和 0 至多個 StoreFile 組成

（2）MemStore和StoreFile

   一個region由多個store組成，每個store包含一個列簇的全部數據，一個region由多個store組成，每個store包含一個列簇的全部數據。
   原理：在寫入數據的時候，現將數據寫入到Memstore，當 Memstore 中的數據量達到某個閾值，regionserver啓動flushcache 進程寫入 Storefile，每次寫入造成單獨一個 HFile。（即，當達到閾值的時候，首先會將存儲在Memstore中的數據寫入磁盤，形式爲hfile,當磁盤中有多個Hfile的時候，又會進行合併，合併成一個storefile）。

（3）storefile和hfile結構

   StoreFile 以 HFile 格式保存在 HDFS 上，請看下圖 HFile 的數據組織格式：

其中：首先 HFile 文件是不定長的，長度固定的只有其中的兩塊：Trailer 和 FileInfo。
   - Trailer：有指針，指向其餘數據塊的起始點
   - FileInfo：記錄本文件的元數據信息
   - Data：存儲的是表中的數據
   - Meta：保存用戶自定義的 kv 對
   - Data Index：data的索引，每條索引的 key 是被索引的 block 的第一條記錄的 key
   - Meta Index：Meta的索引，記錄着Meta數據的起始位置
   - Data中的magic：用於校驗，判斷是否有數據損壞
其中，除了trailer和fileinfo兩個定長的數據之外，其餘的數據均可以進行壓縮。
data中的K-V鍵值的介紹：

   兩個固定長度的數值，分別表示key的長度和value的長度。緊接着是key，開始是固定長度的數值，表示rowkey的長度，緊接着是rowkey，而後是固定長度的數值，緊接着是列簇名（最好是16），接着是 Qualifier（列名），而後是兩個固定長度的數值，表示 TimeStamp 和 KeyType（Put/Delete）。Value 部分沒有這麼複雜的結構，就是純粹的二進制數據了。

（4）Hlog---WAL

  WAL 意爲 Write ahead log，用於作災難恢復的，HLog 記錄數據的全部變動，一旦數據修改，就能夠從 Log 中 進行恢復。
  災難恢復的解釋：開始的時候region的數據時存儲在內存中的metestore，此時尚未達到閾值，數據仍在內存中，沒有持久化到磁盤，若是此時機器忽然宕機，儲存在內存的數據，會丟失，此時須要hlog進行數據的恢復。可是hlog只會保存，在沒有同步到磁盤中的那部分操做的日誌，已同步到磁盤的數據，那部分的日誌，會被存放到oldWAL目錄下，10分鐘後刪除。
  HLog 的文件結構：
    - HLog Sequence File 的 Key 是 HLogKey 對象，HLogKey 中記錄了寫入數據的歸屬信息，除 了 table 和 region 名字外，同時還包括 sequence number 和 timestamp，timestamp 是」寫入 時間」，sequence number 的起始值爲 0，或者是最近一次存入文件系統中 sequence number。
    - HLog Sequece File 的 Value 是 HBase 的 KeyValue 對象，即對應 HFile 中的 KeyValue

3.hbase的尋址機制

  介紹 ：讀寫是在regionserver上發生，每一個 RegionSever 爲必定數量的 Region 服務，若是client要對某一行數據作讀寫的時候，咱們該訪問哪個regionserver？，可使用尋址的方式解決。

（1）老版本的region的尋址機制（0.96之前）

解釋：
   - client請求zookeeper得到-root-所在的regionserver地址
   - client請求-root-所在的regionserver,獲取取.META.表的地址。client 會將-ROOT-的相關 信息 cache 下來，以便下一次快速訪問
   - client請求.META.表的regionserver，獲取訪問數據所在的regionserver的地址（仍然有緩存）
   - client請求訪問數據所在的regionserver，獲取相應的數據

（2）新的region尋址方式（0.98版本）

   - Client 請求 ZooKeeper 獲取.META.所在的 RegionServer 的地址
   - Client 請求.META.所在的 RegionServer 獲取訪問數據所在的 RegionServer 地址，Client 會將.META.的相關信息 cache 下來，以便下一次快速訪問
   - Client 請求數據所在的 RegionServer，獲取所須要的數據

4.hbase的讀寫過程

（1）讀流程：

   - 客戶端經過zookeeper以及-root-表和.mate.表找到目標數據所在的regionserver（尋址）
   - 聯繫regionserve查詢目標數據
   - Region先在memstore中查找，命中則返回
   - 若是memstore找不到，則在storefile中掃描 ， 爲了能快速的判斷要查詢的數據在不在這個 StoreFile 中，應用了 BloomFilter（布隆過濾）

（2）寫流程：

   - Client先根據rowkey找到對應的region所在的regionserver(尋址)
   - Client向regionserver提交請求
   - Regionserver找到目標region
   - Regionserver檢查數據是否與 Schema 一致
   - 若是客戶端沒有指定版本，則獲取當前系統時間做爲數據版本
   - 將更新寫入Hlog
   - 將數據寫入memstore
   - 判斷memstore的是否須要flush爲storefile
注意：
   - 數據在更新時首先寫入 HLog(WAL Log)，再寫入內存(MemStore)中，MemStore 中的數據是排序的
   - Storefile是隻讀的，一旦建立就不能在修改，所以HBASE的更新/修改實際上是不斷追加的操做，根據版本的保留策略，會將舊的數據刪除

5.master和Regionserver的工做機制

（1）Regionserver的工做機制

 1） region的分配

  任什麼時候刻，一個region只能分配一個regionserver。Master記錄了當前有哪些可用的regionserver。以及當前哪些region分配給了哪些regionserver，哪些region尚未分配。當須要分配新的region的時候，master就給一個有可用空間的regionserver發送裝載region的請求。把這個region分配個這個regionserver。

 2）RegionServer 上線

   Master 使用 zookeeper 來跟蹤 RegionServer 狀態。當某個 RegionServer 啓動時，會首先在 ZooKeeper 上的 server 目錄下創建表明本身的 znode。因爲 Master 訂閱了ZooKeeper server 目錄上的變 更消息，當 server 目錄下的文件出現新增或刪除操做時，Master 能夠獲得來自 ZooKeeper 的實時通知。所以一旦 RegionServer 上線，Master 能立刻獲得消息

 3）RegionServer 下線

  當 RegionServer 下線時，它和 zookeeper 的會話斷開，ZooKeeper 而自動釋放表明這臺 server 的文件上的獨佔鎖。Master 就能夠肯定，regionserver和zookeeper之間沒法通行了，regionserver可能宕機了。

（2）master的工做機制

 1）master的啓動步驟：

  - 從zookeeper上獲取惟一表明Active Master 的鎖，用來阻止其它 Master 成爲 Master
  - 掃描zookeeper上的server的節點，得到當前可用的regionserver節點列表。
  - 和每個regionserver通訊，得到當前分配的region和regionserver的對應關係。
  - 掃描.META. Region 的集合，計算獲得當前還未分配的region，將他們放入待分配region列表。

 2）master的下線：

  因爲master只維護表和region的元數據，而不參與數據IO的過程，master下線僅致使全部的元數據的修改被凍結（沒法建立表，沒法修改表的schema，沒法進行region的負載均衡），表的數據讀寫還能夠正常進行。所以master能夠短暫的下線。從上線過程能夠看到，Master 保存的信息全是能夠冗餘信息（均可以從系統其它地方 收集到或者計算出來）