Hbase體系結構理解

1. Hbase的集羣架構

    首先hbase是hadoop的一個組件.而hadoop內部有不少的組件，這些組件幾乎都依賴於hadoop最核心的兩個東西創建起來的,一個是hdfs文件系統，另外一個是mapreduce。固然hbase也不例外。

    hbase其實就是一個非關係型的數據庫系統，能夠將他和關係型數據庫mysql類比一下，可能會便於

理解。

                                                                                                （此圖引用於百度百科）

    Hbase有3種搭建方式：本地模式，僞分佈模式和集羣模式。那麼通常狀況下，咱們便於學習Hbase的各類特性，只須要搭建僞分佈模式便可。僞分佈模式和集羣模式的區別就是，hbase這個系統的全部守護進程所有運行在一個物理節點上和真正的分佈在不一樣的物理節點之上。

    那麼不管是僞分佈和集羣模式。其集羣都包含幾個主要的守護進程：HMaster，HRegionserver，zookeeper，以及client。那麼咱們經過命令行或者JavaApi或其餘方式來使用Hbase時，都是經過client向hbase發送命令的。

    簡單理解一下各個守護進程的做用：HMaster並不像hdfs中的Namenode那樣，維護了整個系統的元數據，負責與client交互以實現對分節點的管理控制等所有統籌功能。Hmaster不負責與client有太多的交互，大部分狀況下是由zookeeper來與client通訊，而後實現對hbase的使用和管理。同時元數據也是由zookeeper來維護的，包括各個regionserver的地址等等。

    下面是一個簡單的總結這二者各自的分工：

• Zookeeper

    保證任什麼時候候，集羣中只有一個running master

    存貯全部Region 的尋址入口

    實時監控Region Server 的狀態，將Region server 的上線和下線信息，實時通知給Master

    存儲Hbase 的schema,包括有哪些table，每一個table 有哪些column family

• Master能夠啓動多個HMaster，經過Zookeeper的Master Election機制保證總有一個Master運行

    爲Region server 分配region

    負責region server 的負載均衡

    發現失效的region server 並從新分配其上的region

2. Hbase的存儲方式和結構

    要講Hbase的存儲方式，咱們從兩方面來描述，一個是邏輯存儲方式和物理的存儲方式。（好比mysql中的二維關係表就是關係型數據庫的邏輯存儲結構，而這些表在硬盤上實際的存儲形式即是所謂的物理存儲方式）。

     Hbase的邏輯存儲方式:

         表是稀疏表，因此能夠類別mysql的關係表來理解，可是實際上並非一回事。首先表有行健，列簇，列名，時間簇等幾個概念。一個表定義之初，應該給出其表名，列簇信息。一行中，有多個固定的列簇，每一個列簇下在插入數據時能夠設置任意的列名。由一個行健，一個列簇+列名能夠標定一個表中的單元格，而一個單元格中有由時間戳區分不一樣版本的值。表中的全部信息實際上都是以二進制形式存儲的。不像關係表中支持那麼多的數據類型。因此若是要用各類數據類型，只能由本身在程序中進行維護。

   Hbase的物理存儲方式：

   Hbase的數據實際上是由Hmaster進行配置，實際上存在各個Hregionserver中的。一個稀疏表是按行健進行排序和存儲。這些表會按行被拆分爲多個region存儲道不一樣的regionserver中，一個regionserver中能夠存儲多region。這些region對應了表中的不一樣部分的行，而這些行實際也被劃分爲不一樣的文件存儲，劃分方式便是列簇，一個列簇一個文件，因此稱之爲面向列的數據庫。那麼這些文件其實是放在hdfs裏的，也就是以block的形式存儲在硬盤上的。

   那麼表是按rowkey的字典順序來存儲的，簡單來講，就是對於rowkey，從左到右，譯成ascii碼來比大小排序。因此呢因爲這個緣由，在設計rowkey時，最好不要直接把時間戳這樣的數據直接做爲rowkey，由於這樣會致使新產生的數據因爲其時間戳都在一個範圍內，致使存儲的時候所有擁擠到某一個regionserver中。通常能夠在時間戳前面加上散列值，設計成：（散列值：時間戳）這樣的形式