Hbase存儲詳解

Hbase存儲詳解

一、概述

　　Hbase是建立的hdfs之上，提供高可靠性、高性能、列存儲、可伸縮、實時讀寫的數據庫系統。

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

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

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

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

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

　　3 稀疏:對於爲空(null)的列，並不佔用存儲空間，因此，表可以設計的非常稀疏。

 

二、邏輯視圖

　　Hbase以表的形式存儲數據。表有行和列組成。列劃分爲若干個列族(row family)

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(= + ), version} 唯一確定的單元。cell中的數據是沒有類型的，全部是字節碼形式存貯。

　　在HBase每個cell存儲單元對同一份數據有多個版本，根據唯一的時間戳來區分每個版本之間的差異，時間戳可以由HBase(在數據寫入時自動)賦值，此時時間戳是精確到毫秒的當前系統時間，也可以由自己顯示指定，按照時間戳倒序排序，最新的數據排在最前面。

 

三、物理存儲

1 Table

        Table中的所有行都按照row key的字典序排列，Table 在行的方向上分割爲多個Hregion。

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

2 HRegion

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

        Hregionserver主要負責響應用戶I/O請求，向HDFS文件系統中讀寫數據，是HBase中最核心的模塊；當用戶更新數據的時候會被分配到對應的HRegion服務器上提交修改，這些修改顯示被寫到MemStore寫緩存和服務器的Hlog文件裏面。在操作寫入Hlog之後，commit()調用纔會將其返回給客戶端；在讀取數據的時候，HRegion服務器會先訪問BlockCache讀緩存，如果緩存裏沒有改數據，纔會回到Hstores磁盤上面尋找，每一個列族都會有一個HStore集合，每一個HStore集合包含很多HstoreFile文件。

        一個HRegionServer會有多個HRegion和一個HLog。

 

3 Hstore

        HRegion雖然是分佈式存儲的最小單元，但並不是存儲的最小單元。

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

　　每個Strore又由一個memStore和0至多個StoreFile組成。StoreFile以HFile格式保存在HDFS上。

region：每個Hregionserver下有一個或多個region，每個region有一個或多個Hstore，每一個CF(column_family)對應一個Hstore，每個Hstore下有一個或多個Storefile，相當於一個Hstore實例下有多個Storefile實例，而storeFile是對Hfile的輕量級封裝，每當一個memstore容量達到閾值，就會flush到hdfs上，產生一個Hfile，Hfile有對應的合併機制，這個前面已經提到了。而當其中一個CF從memstore中flush數據的時候，其他CF也會flush數據，所以這會產生大量的磁盤IO,對整個集羣的壓力都比較大，多以CF不宜過多，一個最好。

memstore：存儲在HDFS上的數據需要按照row key 排序。而HDFS本身被設計爲順序讀寫(sequential reads/writes)，不允許修改。這樣的話，HBase就不能夠高效的寫數據，因爲要寫入到HBase的數據不會被排序，這也就意味着沒有爲將來的檢索優化。爲了解決這個問題，Hbase採用的是LSM樹的結構，HBase將最近接收到的數據緩存在內存中(in Memstore)，在持久化到HDFS之前完成排序，然後再快速的順序寫入HDFS。這樣會在Store中形成很多個小的StoreFile，當這些小的File數量達到一個閥值的時 候，Hbase會用一個線程來把這些小File合併成一個大的File。這樣，Hbase就把效率低下的文件中的插入、移動操作轉變成了單純的文件輸出、 合併操作。需要注意的一點是實際的HFile中，不僅僅只是簡單地排序的列數據的列表，詳見Apache HBase I/O – HFile。

 

HFile的格式爲：

　　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。

 

4 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，可參見上文描述。

region server會將數據保存到內存，直到達到閾值再將其刷寫到磁盤，這樣可避免很多小文件。但儘管如此仍然會有很多Hfile文件，而我們只帶內存中的數據極易丟失，斷電，宕機，存儲在內存中的數據沒來得及保存到磁盤，就會出現數據丟失，一旦丟失就找不回來。但WAL能較好的解決這個問題。每次操作都會先寫入日誌，只有日誌寫入成功後纔會告知客戶端寫入memstore，然後服務器才按照需要批量處理內存中的數據。

如果服務器崩潰，region server會回訪Hlog，通過數據回寫，來恢復服務器的內存數據。下圖顯示了寫入過程,也是一個Hbase的框架圖

 

所有的操作都會先保存到WAL，然後再傳給MemStore。整個過程是這樣的：客戶端啓動一個操作來修改數據，比如Put。每次修改都封裝到一個KeyValue對象實例中，通過RPC調用發送出去。這些調用會發送給含有匹配region的Region Server；KeyValue實例到達後，它們會被分配到管理對應行HRegion實例，數據被寫入WAL，然後被放入實際擁有記錄的MemStore中；當MemStore達到一定大小或經歷一個特定時間，數據會異步的連續的寫入到文件系統中（HFile）。如果寫入過程出現問題，WAL能保證數據不丟失，因爲WAL日誌HLog存儲在HDFS上。其他region server可以讀取日誌文件並回寫修改，恢復數據。

 

四、系統架構

　　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"在等待時機搶佔它的位置。