hbase 架構

[翻譯]HbaseArchitecture

HBase架構

原文地址：http://wiki.apache.org/hadoop/Hbase/HbaseArchitecture

本文來自博客園逖靖寒 http://gpcuster.cnblogs.com

關於HBase，有一篇非常容易入門的文章，可以參考：Understanding HBase and BigTable

介紹

爲了更好地理解本文所講的內容，強烈建議您先去閱讀Google的論文Bigtable paper。

HBase是一個Apache開源項目，它的目標是提供一個在Hadoop分佈式環境中運行的類似於BigTable的存儲系統。正如同Google將BigTable架設在自己的分佈式存儲系統GFS中一樣，HBase基於HDFS。

數據在邏輯上被組織成爲表，行和列。我們可以使用類似於iterator的接口來遍歷我們的行數據，同時也可以通過行的值來獲取這一列的值。同一個行對應多個不同版本的列值。

數據模型

HBase使用的數據模型和Bigtable類似。應用程序將數據行存儲在打上標籤的表中。一個數據行包含有一個排好序的行鍵值和任意長度的列值。

一個列名的格式爲"<family>:<label>" ，其中<family> 與 <label> 可以爲任意的字節數組。一個表的<family>集合是固定的。如果希望修改一個表的<family>字段，需要使用管理員來操作。不過，你可以在任何時候新增加一個<label> 而無需事先聲明它。HBase在磁盤上按照<family>儲存數據，所以一個<family>裏的所有項應該有相同的讀/寫方式。

默認每次將一行數據進行鎖定，行數據的寫入時原子操作，不過它可以對一行數據進行鎖定，然後同時進行讀和寫的操作。

我們也可以一次性鎖定多個行數據，不過這個操作需要我們現實去指定纔可以。

概念模型

從概念上來看，一個表由多個數據行組成，每一個數據行中的列不一定有值。下面的這個例子來自Bigtable Paper。

Row Key	Time Stamp	Column "contents:"	Column "anchor:"		Column "mime:"
"com.cnn.www"	t9		"anchor:cnnsi.com"	"CNN"
	t8		"anchor:my.look.ca"	"CNN.com"
	t6	"<html>..."			"text/html"
	t5	"<html>..."
	t3	"<html>..."

物理存儲模型

從概念上看，表數據是按照稀疏的行來存儲的，但是物理上，他們是按照列來存儲的。理解這個概念對考慮表的設計和程序設計時非常重要的。

回到先前的那個例子，按照物理存儲的圖如下：

Row Key	Time Stamp	Column "contents:"
"com.cnn.www"	t6	"<html>..."
	t5	"<html>..."
	t3	"<html>..."

Row Key	Time Stamp	Column "anchor:"
"com.cnn.www"	t9	"com.cnn.www" "CNN"
	t8	"anchor:my.look.ca" "CNN.com"

Row Key	Time Stamp	Column "mime:"
"com.cnn.www"	t6	"text/html"

從上面的圖示可以看出來：空的列並沒有被存儲，因爲他們並不需要面向列的存儲格式。所以一個當請求列值爲"contents:" 的時候，會返回空值。

如果請求數據的時候，沒有提供timestamp的值，那麼最新的數據將返回最新的值，並且在實際的存儲中，所有的值也是按照timestamps降序排列的。

行的範圍：區域

對於一個程序而言，數據表是由一系列按升序排序的數據列組成，數據行按照名字的升序，時間戳按照降序。在物理上，數據表被拆分成多個數據行的區域（這個概念對於在Bigtable中就是tablet）。每一個數據行的區域包含從開始行（包含）到中止行（排除）。所有的數據行的區域構成一個數據表。與Bigtable不同的是，在Bigtable中，一個數據行區域有表名和結束行值決定，而HBase由表名和開始行值決定。

在區域中的每一個列族都被一個稱爲HStore的對象管理。每一個HStore由一個或多個MapFiles（這是Hadoop中的一個文件類型）組成。HStore的概念類似於Google的SSTable。MapFiles一旦被關閉，就是不可修改的類型了。MapFiles被存儲在Hadoop的HDFS中，其他不同的點如下：

MapFiles目前還無法進行內存的映射。
MapFiles由一些稀疏的索引文件來維護，而SSTable在其文件的最後。
HBase擴展了MapFiles，所以使用bloom filter的時候可以提高查找的性能。

架構與實現

HBase由以下三個主要構件組成：

HBaseMaster (類似於Bigtable master server)
HRegionServer(類似於Bigtable tablet server)
HBase Client, 由org.apache.hadoop.hbase.client.HTable定義

下面，我們以此討論這幾個部分。

HBaseMaster

HBaseMaster負責給HRegionServer分配區域。第一個分配的區域就是ROOT區域，它用於定位所有的META區域。每一個META區域用於定位一些列用戶區域。一旦所有的META區域被分配好了以後，master便開始分配用戶區域給HReginServer，同時維護每一個HReginServer的負載平衡。

同時HBaseMaster還含有一個指向包含有ROOT區域的HReginServer地址。

同時，HBaseMaster會監控每一臺HReginServer的健康狀況，如果某一臺HReginServer不可用，它將會把不可用的HReginServer來提供服務的HLog和表由其他HReginServer來提供。

另外，HBaseMaster還負責對數據表進行管理，比如讓表處於有效（online）或失效（offline）的狀態，改變表的結構（增加或者減少列族），等等。

與Bigtable不同的是，目前，如果HBaseMaster失效了，整個集羣就會關閉。在Bigtable中，即使Master機器失效了，Tabletserver還是可以提供服務的。Bigtable使用了而外的鎖管理機制，而我們的HBase使用的單點訪問模式：所有的HReginServer都訪問HBaseMaster。

The META Table

META 表存儲了所有的用戶區域的信息，同時包括HReginServer對象的信息，其中有每一個行值的開始到結束的鍵值，一個表是否有效或失效，每一個HReginServer的地址，等等。META 表的大小隨着用戶區域的增加而增加。

The ROOT Table

ROOT表被限制在一個區域中，它指定了所有的META表信息。這些信息包括每一個META所處的區域和HReginServer信息。

ROOT表和META表每一行的大小大概是1KB左右。每一個區域的大小是256MB，這意味着ROOT表可以裝載2.6 x 10⁵ META區域，轉化成用戶區域就是6.9 x 10¹⁰，轉化成可以存儲的字節數就是1.8 x 10¹⁹ (2⁶⁴) 。

HRegionServer

HReginServer負責處理用戶的讀和寫的操作。HReginServer通過與HBaseMaster通信獲取自己需要服務的數據表，並向HBaseMaster反饋自己的運行狀況。

Write Requests

當一個寫的請求到來的時候，它首先會寫到一個叫做HLog的write-ahead log中。HLog被緩存在內存中，稱爲Memcache，每一個HStore只能有一個Memcache。

Read Requests

當一起讀取的請求到來的時候，HReginServer會先在Memcache中尋找該數據，當找不到的時候，纔會去在MapFiles 中尋找。

Cache Flushes

當Memcache到達配置的大小以後，將會創建一個MapFile，將其寫到磁盤中去。這將減少HReginServer的內存壓力。

在讀和寫的過程中，Cache flushes將會經常發生。當創建一個新的MapFile的時候，讀和寫的操作會被掛起，知道新的MapFile創建好，並被加入到HStroe的管理中後纔可以使用。

Compactions

當一定數量的MapFiles超過一個配置的閥值之後，壓縮操作就會開始執行。壓縮操作的主要工作就是週期性地將一些MapFiles合併成一個MapFile。

在執行壓縮操作的過程中，HReginServer的讀和寫操作將被掛起，直到操作執行完畢。

Region Splits

當一個HStore所管理的MapFiles超過一個配置（當前是256MB）的值以後，將會執行區域的切分操作。區域的切分操作將原先的區域對半分割爲2個新的區域。

在進行區域切分的操作過程中，讀和寫的操作將被掛起，直到完成爲止。

HBase Client

HBase Client負責尋找提供需求數據的HReginServer。在這個過程中，HBase Client將首先與HBaseMaster通信，找到ROOT區域。這個操作是Client和Master之間僅有的通信操作。

一旦ROOT區域被找到以後，Client就可以通過掃描ROOT區域找到相應的META區域去定位實際提供數據的HReginServer。

當定位到提供數據的HReginServer以後，Client就可以通過這個HReginServer找到需要的數據了。

這些信息將會被Client緩存起來，當下次請求的時候，就不需要走上面的這個流程了。

當這些區域中的某個區域不可用的時候，Client將會逆向執行上面的過程，直到找到實際提供數據的HReginServer爲止。

Client API

參考Javadoc中關於HTable和HBaseAdmin的介紹。

Scanner API

爲了獲取一個Scanner，需要實例化一個HTable，然後調用他的getScanner方法。這個方法將返回一個Scanner對象，通過這個對象你可以使用next和close的方法。