HBase

hbase 介紹

一、簡介

history

started by chad walters and jim

2006.11 G release paper on BigTable

2007.2 inital HBase prototype created as Hadoop contrib

2007.10 First useable Hbase

2008.1 Hadoop become Apache top-level project and Hbase becomes subproject

2008.10 Hbase 0.18,0.19 released

hbase是bigtable的開源山寨版本。是建立的hdfs之上，提供高可靠性、高性能、列存儲、可伸縮、實時讀寫的資料庫系統。

它介于nosql和RDBMS之間，僅能通過主鍵(row key)和主鍵的range來檢索資料，僅支援單行事務(可通過hive支援來實作多表join等複雜操作)。主要用來存儲非結構化和半結構化的松散資料。

與hadoop一樣，Hbase目标主要依靠橫向擴充，通過不斷增加廉價的商用伺服器，來增加計算和存儲能力。

HBase中的表一般有這樣的特點：

1 大：一個表可以有上億行，上百萬列

2 面向列:面向列(族)的存儲和權限控制，列(族)獨立檢索。

3 稀疏:對于為空(null)的列，并不占用存儲空間，是以，表可以設計的非常稀疏。

下面一幅圖是Hbase在Hadoop Ecosystem中的位置。

二、邏輯視圖

HBase以表的形式存儲資料。表有行和列組成。列劃分為若幹個列族(row family)

Row Key	column-family1	column-family2	column-family3
column1	column1	column1	column2	column3	column1
key1	t1:abc t2:gdxdf	t4:dfads t3:hello t2:world
key2	t3:abc t1:gdxdf	t4:dfads t3:hello	t2:dfdsfa t3:dfdf
key3	t2:dfadfasd t1:dfdasddsf	t2:dfxxdfasd t1:taobao.com

Row Key

與nosql資料庫們一樣,row key是用來檢索記錄的主鍵。通路hbase table中的行，隻有三種方式：

1 通過單個row key通路

2 通過row key的range

3 全表掃描

Row key行鍵 (Row key)可以是任意字元串(最大長度是 64KB，實際應用中長度一般為 10-100bytes)，在hbase内部，row key儲存為位元組數組。

存儲時，資料按照Row key的字典序(byte order)排序存儲。設計key時，要充分排序存儲這個特性，将經常一起讀取的行存儲放到一起。(位置相關性)

注意：

字典序對int排序的結果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行鍵必須用0作左填充。

行的一次讀寫是原子操作 (不論一次讀寫多少列)。這個設計決策能夠使使用者很容易的了解程式在對同一個行進行并發更新操作時的行為。

列族

hbase表中的每個列，都歸屬與某個列族。列族是表的chema的一部分(而列不是)，必須在使用表之前定義。列名都以列族作為字首。例如courses:history，courses:math 都屬于courses 這個列族。

通路控制、磁盤和記憶體的使用統計都是在列族層面進行的。實際應用中，列族上的控制權限能幫助我們管理不同類型的應用：我們允許一些應用可以添加新的基本資料、一些應用可以讀取基本資料并建立繼承的列族、一些應用則隻允許浏覽資料（甚至可能因為隐私的原因不能浏覽所有資料）。

時間戳

HBase中通過row和columns确定的為一個存貯單元稱為cell。每個 cell都儲存着同一份資料的多個版本。版本通過時間戳來索引。時間戳的類型是 64位整型。時間戳可以由hbase(在資料寫入時自動 )指派，此時時間戳是精确到毫秒的目前系統時間。時間戳也可以由客戶顯式指派。如果應用程式要避免資料版本沖突，就必須自己生成具有唯一性的時間戳。每個 cell中，不同版本的資料按照時間倒序排序，即最新的資料排在最前面。

為了避免資料存在過多版本造成的的管理 (包括存貯和索引)負擔，hbase提供了兩種資料版本回收方式。一是儲存資料的最後n個版本，二是儲存最近一段時間内的版本（比如最近七天）。使用者可以針對每個列族進行設定。

Cell

由{row key, column(=<family> + <label>), version} 唯一确定的單元。cell中的資料是沒有類型的，全部是位元組碼形式存貯。

三、實體存儲

1 已經提到過，Table中的所有行都按照row key的字典序排列。

2 Table 在行的方向上分割為多個Hregion。

3 region按大小分割的，每個表一開始隻有一個region，随着資料不斷插入表，region不斷增大，當增大到一個閥值的時候，Hregion就會等分會兩個新的Hregion。當table中的行不斷增多，就會有越來越多的Hregion。

4 Hregion是Hbase中分布式存儲和負載均衡的最小單元。最小單元就表示不同的Hregion可以分布在不同的HRegion server上。但一個Hregion是不會拆分到多個server上的。

5 HRegion雖然是分布式存儲的最小單元，但并不是存儲的最小單元。

事實上，HRegion由一個或者多個Store組成，每個store儲存一個columns family。

每個Strore又由一個memStore和0至多個StoreFile組成。如圖：

StoreFile以HFile格式儲存在HDFS上。

HFile的格式為：

Trailer部分的格式:

HFile分為六個部分：

Data Block 段–儲存表中的資料，這部分可以被壓縮

Meta Block 段 (可選的)–儲存使用者自定義的kv對，可以被壓縮。

File Info 段–Hfile的元資訊，不被壓縮，使用者也可以在這一部分添加自己的元資訊。

Data Block Index 段–Data Block的索引。每條索引的key是被索引的block的第一條記錄的key。

Meta Block Index段 (可選的)–Meta Block的索引。

Trailer–這一段是定長的。儲存了每一段的偏移量，讀取一個HFile時，會首先讀取Trailer，Trailer儲存了每個段的起始位置(段的Magic Number用來做安全check)，然後，DataBlock Index會被讀取到記憶體中，這樣，當檢索某個key時，不需要掃描整個HFile，而隻需從記憶體中找到key所在的block，通過一次磁盤io将整個block讀取到記憶體中，再找到需要的key。DataBlock Index采用LRU機制淘汰。

HFile的Data Block，Meta Block通常采用壓縮方式存儲，壓縮之後可以大大減少網絡IO和磁盤IO，随之而來的開銷當然是需要花費cpu進行壓縮和解壓縮。

目标Hfile的壓縮支援兩種方式：Gzip，Lzo。

HLog(WAL log)

WAL 意為Write ahead log(http://en.wikipedia.org/wiki/Write-ahead_logging)，類似mysql中的binlog,用來做災難恢複隻用，Hlog記錄資料的所有變更,一旦資料修改，就可以從log中進行恢複。

每個Region Server維護一個Hlog,而不是每個Region一個。這樣不同region(來自不同table)的日志會混在一起，這樣做的目的是不斷追加單個檔案相對于同時寫多個檔案而言，可以減少磁盤尋址次數，是以可以提高對table的寫性能。帶來的麻煩是，如果一台region server下線，為了恢複其上的region，需要将region server上的log進行拆分，然後分發到其它region server上進行恢複。

HLog檔案就是一個普通的Hadoop Sequence File，Sequence File 的Key是HLogKey對象，HLogKey中記錄了寫入資料的歸屬資訊，除了table和region名字外，同時還包括 sequence number和timestamp，timestamp是”寫入時間”，sequence number的起始值為0，或者是最近一次存入檔案系統中sequence number。HLog Sequece File的Value是HBase的KeyValue對象，即對應HFile中的KeyValue，可參見上文描述。

四、系統架構

Client

1 包含通路hbase的接口，client維護着一些cache來加快對hbase的通路，比如regione的位置資訊。

Zookeeper

1 保證任何時候，叢集中隻有一個master

2 存貯所有Region的尋址入口。

3 實時監控Region Server的狀态，将Region server的上線和下線資訊實時通知給Master

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

Master

1 為Region server配置設定region

2 負責region server的負載均衡

3 發現失效的region server并重新配置設定其上的region

4 GFS上的垃圾檔案回收

5 處理schema更新請求

Region Server

1 Region server維護Master配置設定給它的region，處理對這些region的IO請求

2 Region server負責切分在運作過程中變得過大的region

可以看到，client通路hbase上資料的過程并不需要master參與（尋址通路zookeeper和region server，資料讀寫通路regione server），master僅僅維護者table和region的中繼資料資訊，負載很低。

五、關鍵算法/流程

region定位

系統如何找到某個row key (或者某個 row key range)所在的region

bigtable 使用三層類似B+樹的結構來儲存region位置。

第一層是儲存zookeeper裡面的檔案，它持有root region的位置。

第二層root region是.META.表的第一個region其中儲存了.META.z表其它region的位置。通過root region，我們就可以通路.META.表的資料。

.META.是第三層，它是一個特殊的表，儲存了hbase中所有資料表的region 位置資訊。

說明：

1 root region永遠不會被split，保證了最需要三次跳轉，就能定位到任意region 。

2.META.表每行儲存一個region的位置資訊，row key 采用表名+表的最後一樣編碼而成。

3 為了加快通路，.META.表的全部region都儲存在記憶體中。

假設，.META.表的一行在記憶體中大約占用1KB。并且每個region限制為128MB。

那麼上面的三層結構可以儲存的region數目為：

(128MB/1KB) * (128MB/1KB) = = 2(34)個region

4 client會将查詢過的位置資訊儲存緩存起來，緩存不會主動失效，是以如果client上的緩存全部失效，則需要進行6次網絡來回，才能定位到正确的region(其中三次用來發現緩存失效，另外三次用來擷取位置資訊)。

讀寫過程

上文提到，hbase使用MemStore和StoreFile存儲對表的更新。

資料在更新時首先寫入Log(WAL log)和記憶體(MemStore)中，MemStore中的資料是排序的，當MemStore累計到一定門檻值時，就會建立一個新的MemStore，并且将老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成為一個StoreFile。于此同時，系統會在zookeeper中記錄一個redo point，表示這個時刻之前的變更已經持久化了。(minor compact)

當系統出現意外時，可能導緻記憶體(MemStore)中的資料丢失，此時使用Log(WAL log)來恢複checkpoint之後的資料。

前面提到過StoreFile是隻讀的，一旦建立後就不可以再修改。是以Hbase的更新其實是不斷追加的操作。當一個Store中的StoreFile達到一定的門檻值後，就會進行一次合并(major compact),将對同一個key的修改合并到一起，形成一個大的StoreFile，當StoreFile的大小達到一定門檻值後，又會對StoreFile進行split，等分為兩個StoreFile。

由于對表的更新是不斷追加的，處理讀請求時，需要通路Store中全部的StoreFile和MemStore，将他們的按照row key進行合并，由于StoreFile和MemStore都是經過排序的，并且StoreFile帶有記憶體中索引，合并的過程還是比較快。

寫請求處理過程

1 client向region server送出寫請求

2 region server找到目标region

3 region檢查資料是否與schema一緻

4 如果用戶端沒有指定版本，則擷取目前系統時間作為資料版本

5 将更新寫入WAL log

6 将更新寫入Memstore

7 判斷Memstore的是否需要flush為Store檔案。

region配置設定

任何時刻，一個region隻能配置設定給一個region server。master記錄了目前有哪些可用的region server。以及目前哪些region配置設定給了哪些region server，哪些region還沒有配置設定。當存在未配置設定的region，并且有一個region server上有可用空間時，master就給這個region server發送一個裝載請求，把region配置設定給這個region server。region server得到請求後，就開始對此region提供服務。

region server上線

master使用zookeeper來跟蹤region server狀态。當某個region server啟動時，會首先在zookeeper上的server目錄下建立代表自己的檔案，并獲得該檔案的獨占鎖。由于master訂閱了server目錄上的變更消息，當server目錄下的檔案出現新增或删除操作時，master可以得到來自zookeeper的實時通知。是以一旦region server上線，master能馬上得到消息。

region server下線

當region server下線時，它和zookeeper的會話斷開，zookeeper而自動釋放代表這台server的檔案上的獨占鎖。而master不斷輪詢server目錄下檔案的鎖狀态。如果master發現某個region server丢失了它自己的獨占鎖，(或者master連續幾次和region server通信都無法成功),master就是嘗試去擷取代表這個region server的讀寫鎖，一旦擷取成功，就可以确定：

1 region server和zookeeper之間的網絡斷開了。

2 region server挂了。

的其中一種情況發生了，無論哪種情況，region server都無法繼續為它的region提供服務了，此時master會删除server目錄下代表這台region server的檔案，并将這台region server的region配置設定給其它還活着的同志。

如果網絡短暫出現問題導緻region server丢失了它的鎖，那麼region server重新連接配接到zookeeper之後，隻要代表它的檔案還在，它就會不斷嘗試擷取這個檔案上的鎖，一旦擷取到了，就可以繼續提供服務。

master上線

master啟動進行以下步驟:

1 從zookeeper上擷取唯一一個代碼master的鎖，用來阻止其它master成為master。

2 掃描zookeeper上的server目錄，獲得目前可用的region server清單。

3 和2中的每個region server通信，獲得目前已配置設定的region和region server的對應關系。

4 掃描.META.region的集合，計算得到目前還未配置設定的region，将他們放入待配置設定region清單。

master下線

由于master隻維護表和region的中繼資料，而不參與表資料IO的過程，master下線僅導緻所有中繼資料的修改被當機(無法建立删除表，無法修改表的schema，無法進行region的負載均衡，無法處理region上下線，無法進行region的合并，唯一例外的是region的split可以正常進行，因為隻有region server參與)，表的資料讀寫還可以正常進行。是以master下線短時間内對整個hbase叢集沒有影響。從上線過程可以看到，master儲存的資訊全是可以備援資訊（都可以從系統其它地方收集到或者計算出來），是以，一般hbase叢集中總是有一個master在提供服務，還有一個以上的’master’在等待時機搶占它的位置。

==============================================================================

附注

HBase列存儲

從概念上，一個表格是一些行的集合，每行包含一個行關鍵字（和一個可選的時間戳），和一些可能有資料的列（稀疏）。下面的例子很好的說明了問題：

實體模型

在概念上表格是一個稀疏的行/列矩陣，但是在實體上，它們按照列存儲。這是我們的一個重要設計考慮。

上面“概念上的”表格在實體上的存儲方式如下所示：

請大家注意，在上面的圖中，沒有存儲空的單元格。是以查詢時間戳為t8的“content:”将傳回null，同樣查詢時間戳為t9，“anchor:”值為“my.look.ca”的項也傳回null。

不過，如果沒有指明時間戳，那麼應該傳回指定列的最新資料值，并且最新的值在表格裡也時最先找到的，因為它們是按照時間排序的。是以，查詢“contents:”而不指明時間戳，将傳回t6時刻的資料；查詢“anchor:”的“my.look.ca”而不指明時間戳，将傳回t8時刻的資料。

 --------------------------------------------------------

HBas資料模型

HBase資料庫使用了和Bigtable非常相似的資料模型。使用者在表格裡存儲許多資料行。每個資料行都包括一個可排序的關鍵字，和任意數目的列。表格是稀疏的，是以同一個表格裡的行可能有非常不同的列，隻要使用者喜歡這樣做。

列名是“<族名>:<标簽>”形式，其中<族名>和<标簽>可以是任意字元串。一個表格的<族名>集合（又叫“列族”集合）是固定的，除非你使用管理者權限來改變表格的列族。不過你可以在任何時候添加新的<标簽>。HBase在磁盤上按照列族儲存資料，是以一個列族裡的所有項應該有相同的讀/寫方式。

寫操作是行鎖定的，你不能一次鎖定多行。所有對行的寫操作預設是原子的。

所有資料庫更新操作都有時間戳。HBase對每個資料單元，隻存儲指定個數的最新版本。用戶端可以查詢“從某個時刻起的最新資料”，或者一次得到所有的資料版本。

•

在下面的JSON資料中,我們看到整個資料結構是一個map,并且map中每一個key對應一個包含 "A"和"B"的map.假設整個下面資料是一個table,那麼它有"1"."aaaaa","aaaab","xyz","zzzzz"這幾個行,每一個行有一個"A"和"B"的map.在HBase的術語中, 稱"A"和"B"為列組.

{

     "1" : {

              "A" : "x",

              "B" : "z" },

     "aaaaa" : {

              "A" : "y",

               "B" : "w" },

     "aaaab" : {

             "A" : "world",

             "B" : "ocean" },

     "xyz" : {

            "A" : "hello",

            "B" : "there" },

      "zzzzz" : {

            "A" : "woot",

             "B" : "1337" }

}

在HBase中一個列組通過限定詞或叫做标簽使每一個列組能夠包含許多的列.

{

       "aaaaa" : {

                          "A" : {

                                      "foo" : "y",

                                       "bar" : "d" },

                        "B" : { "" : "w" } },

       "aaaab" : {

                           "A" : {

                                     "foo" : "world",

                                      "bar" : "domination" },

                          "B" : { "" : "ocean" } },

       "zzzzz" : {

                        "A" : {

                                   "catch_phrase" : "woot", }

                       "B" : { "" : "1337" } }

}

在上面的例子中,在"aaaaa"的行中,列組"A"包含兩個列:"foo"和"bar",列組"B"僅僅有一個限定詞為空字元竄""的列.當我們向HBase擷取資料時,你必須提供完整的列名字"<列組>:<限定詞>".是以上面的例子中行"aaaaa"和"aaaab"都包含三個列:"A:foo", "A:bar"和"B:".盡管在行中列組是固定的,但是同一個列中限定詞可以是不同的,就像行"zzzzz"中列組"A"中隻有一個列"catch_phrase".最後的次元是時間戳(timestamp).所有的在HBase中存儲的資料都有一個用時間戳表示的版本或者你自己通過指定時間戳來插入或擷取資料.

{

     "aaaaa" : {

                       "A" : {

                                  "foo" : {

                                             15 : "y",

                                              4 : "m" },

                                  "bar" : {

                                             15 : "d", }

                                },

                      "B" : {

                                   "" : {

                                              6 : "w"

                                              3 : "o"

                                              1 : "w" }

                                         }

                               }

}

每一個列可以指定多少版本的資料被儲存在每一個單元.在上面的例子中行"aaaaa"的列"A:foo"包含兩個倒序時間戳排列的資料15和4,列"B"包含由三個倒序時間戳排列的資料.一般的應用程式隻是簡單(不通過時間戳)的請求一個單元的資料.在這種條件下,HBase隻是簡單地傳回最新的版本,即時間戳最大的版本.要擷取"A:foo"傳回"y",要擷取"B"傳回"w".如果應用程式在一個行中請求時帶上時間戳,HBase将會傳回小于或等于請求時間戳的資料.接着上面的例子如果程式請求"A:foo"帶上時間戳10,傳回"m",加上時間戳3,傳回null.

每一個行可以多個列族,每一個列族可以包含無數個列,每一個列都可以有一個不同于其他列的時間戳.在通用資料庫中當表建立時我們就已經定義了列,如果修改表結構的話會非常困難(比如:添加一列).在HBase中我們可以很輕松地添加一個列族或列

 --------------------------------------------

Facebook 選擇了HBase

因為他們對他們的應用進行了監視，并明白他們到底需要什麼。他們所需要的是一個可以處理以下兩種類型的資料模式： 

1. 一小組經常變化的臨時資料； 

2. 一組不斷增加但很少通路的資料。 

　　這很有道理。目前收件箱裡的郵件你隻會看一次，之後你很少會再去翻看這些電子郵件。這兩種類似的資料是如此不同，是以有人也許在想應該使用兩種不同的系統。不過，很明顯，HBase 能夠很好地處理這兩種類型的資料。他們如何處理正常的搜尋功能，尚不清楚，因為這并非 HBase 的優勢所在，不過，HBase 可以內建多個搜尋系統。 

Facebook 系統的一些關鍵點： 

● HBase： 

○ 具有比Cassandra更簡潔的一緻性模型。 

○ 對于他們的資料模式具有很好的擴充能力和處理能力。 

○ 大多數功能能夠滿足他們的需求：自動加載平衡和故障轉移、壓縮支援功能、單個伺服器的多碎片功能等。 

○ HBase 所使用的檔案系統HDFS，支援複制、端對端校驗和，以及自動再次平衡。 

○ Facebook 的營運團隊具有豐富的HDFS使用經驗，因為Facebook是Hadoop的大使用者，而Hadoop使用 HDFS作為它的分布式檔案系統。 

● Haystack 用于存儲附件。 

● 從無到有，編寫可自定義的應用程式伺服器，其目的是為了滿足多個不同來源流入的大量資訊。 

● 使用者發現服務（user discovery service）建構于 Zookeeper 之上。 

● 對于以下功能可通路架構服務：電子郵件賬号驗證、好友關系、隐私決策以及發送決策（通過聊天工具或短信發送一條消息？） 

● 保持小團隊做大事情的一貫作風，15 位工程師在一年内釋出了 20 項新的架構服務。 

● Facebook将不會對單個資料庫平台進行标準化，對于不同的任務他們将使用不同的平台。

 ----------------------------------------------------------------------------------------

HBase架構圖