上善若水
In general the OO style is to use a lot of little objects with a lot of little methods that give us a lot of plug points for overriding and variation. To do is to be -Nietzsche, To bei is to do -Kant, Do be do be do -Sinatra
posts - 146,comments - 147,trackbacks - 0

前記

公司內部使用的是MapR版本的Hadoop生態系統,因而從MapR的官網看到了這篇文文章:An In-Depth Look at the HBase Architecture,原本想翻譯全文,然而如果翻譯就需要各種咬文嚼字,太麻煩,因而本文大部分使用了自己的語言,并且加入了其他資源的參考理解以及本人自己讀源碼時對其的理解,屬于半翻譯、半原創吧。

HBase架構組成

HBase采用Master/Slave架構搭建集群,它隸屬于Hadoop生態系統,由一下類型節點組成:HMaster節點、HRegionServer節點、ZooKeeper集群,而在底層,它將數據存儲于HDFS中,因而涉及到HDFS的NameNode、DataNode等,總體結構如下:

其中HMaster節點用于:
  1. 管理HRegionServer,實現其負載均衡。
  2. 管理和分配HRegion,比如在HRegion split時分配新的HRegion;在HRegionServer退出時遷移其內的HRegion到其他HRegionServer上。
  3. 實現DDL操作(Data Definition Language,namespace和table的增刪改,column familiy的增刪改等)。
  4. 管理namespace和table的元數據(實際存儲在HDFS上)。
  5. 權限控制(ACL)。
HRegionServer節點用于:
  1. 存放和管理本地HRegion。
  2. 讀寫HDFS,管理Table中的數據。
  3. Client直接通過HRegionServer讀寫數據(從HMaster中獲取元數據,找到RowKey所在的HRegion/HRegionServer后)。
ZooKeeper集群是協調系統,用于:
  1. 存放整個 HBase集群的元數據以及集群的狀態信息。
  2. 實現HMaster主從節點的failover。
HBase Client通過RPC方式和HMaster、HRegionServer通信;一個HRegionServer可以存放1000個HRegion;底層Table數據存儲于HDFS中,而HRegion所處理的數據盡量和數據所在的DataNode在一起,實現數據的本地化;數據本地化并不是總能實現,比如在HRegion移動(如因Split)時,需要等下一次Compact才能繼續回到本地化。

本著半翻譯的原則,再貼一個《An In-Depth Look At The HBase Architecture》的架構圖:

這個架構圖比較清晰的表達了HMaster和NameNode都支持多個熱備份,使用ZooKeeper來做協調;ZooKeeper并不是云般神秘,它一般由三臺機器組成一個集群,內部使用PAXOS算法支持三臺Server中的一臺宕機,也有使用五臺機器的,此時則可以支持同時兩臺宕機,既少于半數的宕機,然而隨著機器的增加,它的性能也會下降;RegionServer和DataNode一般會放在相同的Server上實現數據的本地化。

HRegion

HBase使用RowKey將表水平切割成多個HRegion,從HMaster的角度,每個HRegion都紀錄了它的StartKey和EndKey(第一個HRegion的StartKey為空,最后一個HRegion的EndKey為空),由于RowKey是排序的,因而Client可以通過HMaster快速的定位每個RowKey在哪個HRegion中。HRegion由HMaster分配到相應的HRegionServer中,然后由HRegionServer負責HRegion的啟動和管理,和Client的通信,負責數據的讀(使用HDFS)。每個HRegionServer可以同時管理1000個左右的HRegion(這個數字怎么來的?沒有從代碼中看到限制,難道是出于經驗?超過1000個會引起性能問題?來回答這個問題:感覺這個1000的數字是從BigTable的論文中來的(5 Implementation節):Each tablet server manages a set of tablets(typically we have somewhere between ten to a thousand tablets per tablet server))。

HMaster

HMaster沒有單點故障問題,可以啟動多個HMaster,通過ZooKeeper的Master Election機制保證同時只有一個HMaster出于Active狀態,其他的HMaster則處于熱備份狀態。一般情況下會啟動兩個HMaster,非Active的HMaster會定期的和Active HMaster通信以獲取其最新狀態,從而保證它是實時更新的,因而如果啟動了多個HMaster反而增加了Active HMaster的負擔。前文已經介紹過了HMaster的主要用于HRegion的分配和管理,DDL(Data Definition Language,既Table的新建、刪除、修改等)的實現等,既它主要有兩方面的職責:
  1. 協調HRegionServer
    1. 啟動時HRegion的分配,以及負載均衡和修復時HRegion的重新分配。
    2. 監控集群中所有HRegionServer的狀態(通過Heartbeat和監聽ZooKeeper中的狀態)。
  2. Admin職能
    1. 創建、刪除、修改Table的定義。

ZooKeeper:協調者

ZooKeeper為HBase集群提供協調服務,它管理著HMaster和HRegionServer的狀態(available/alive等),并且會在它們宕機時通知給HMaster,從而HMaster可以實現HMaster之間的failover,或對宕機的HRegionServer中的HRegion集合的修復(將它們分配給其他的HRegionServer)。ZooKeeper集群本身使用一致性協議(PAXOS協議)保證每個節點狀態的一致性。

How The Components Work Together

ZooKeeper協調集群所有節點的共享信息,在HMaster和HRegionServer連接到ZooKeeper后創建Ephemeral節點,并使用Heartbeat機制維持這個節點的存活狀態,如果某個Ephemeral節點實效,則HMaster會收到通知,并做相應的處理。

另外,HMaster通過監聽ZooKeeper中的Ephemeral節點(默認:/hbase/rs/*)來監控HRegionServer的加入和宕機。在第一個HMaster連接到ZooKeeper時會創建Ephemeral節點(默認:/hbasae/master)來表示Active的HMaster,其后加進來的HMaster則監聽該Ephemeral節點,如果當前Active的HMaster宕機,則該節點消失,因而其他HMaster得到通知,而將自身轉換成Active的HMaster,在變為Active的HMaster之前,它會創建在/hbase/back-masters/下創建自己的Ephemeral節點。

HBase的第一次讀寫

在HBase 0.96以前,HBase有兩個特殊的Table:-ROOT-和.META.(如BigTable中的設計),其中-ROOT- Table的位置存儲在ZooKeeper,它存儲了.META. Table的RegionInfo信息,并且它只能存在一個HRegion,而.META. Table則存儲了用戶Table的RegionInfo信息,它可以被切分成多個HRegion,因而對第一次訪問用戶Table時,首先從ZooKeeper中讀取-ROOT- Table所在HRegionServer;然后從該HRegionServer中根據請求的TableName,RowKey讀取.META. Table所在HRegionServer;最后從該HRegionServer中讀取.META. Table的內容而獲取此次請求需要訪問的HRegion所在的位置,然后訪問該HRegionSever獲取請求的數據,這需要三次請求才能找到用戶Table所在的位置,然后第四次請求開始獲取真正的數據。當然為了提升性能,客戶端會緩存-ROOT- Table位置以及-ROOT-/.META. Table的內容。如下圖所示:

可是即使客戶端有緩存,在初始階段需要三次請求才能直到用戶Table真正所在的位置也是性能低下的,而且真的有必要支持那么多的HRegion嗎?或許對Google這樣的公司來說是需要的,但是對一般的集群來說好像并沒有這個必要。在BigTable的論文中說,每行METADATA存儲1KB左右數據,中等大小的Tablet(HRegion)在128MB左右,3層位置的Schema設計可以支持2^34個Tablet(HRegion)。即使去掉-ROOT- Table,也還可以支持2^17(131072)個HRegion, 如果每個HRegion還是128MB,那就是16TB,這個貌似不夠大,但是現在的HRegion的最大大小都會設置的比較大,比如我們設置了2GB,此時支持的大小則變成了4PB,對一般的集群來說已經夠了,因而在HBase 0.96以后去掉了-ROOT- Table,只剩下這個特殊的目錄表叫做Meta Table(hbase:meta),它存儲了集群中所有用戶HRegion的位置信息,而ZooKeeper的節點中(/hbase/meta-region-server)存儲的則直接是這個Meta Table的位置,并且這個Meta Table如以前的-ROOT- Table一樣是不可split的。這樣,客戶端在第一次訪問用戶Table的流程就變成了:
  1. 從ZooKeeper(/hbase/meta-region-server)中獲取hbase:meta的位置(HRegionServer的位置),緩存該位置信息。
  2. 從HRegionServer中查詢用戶Table對應請求的RowKey所在的HRegionServer,緩存該位置信息。
  3. 從查詢到HRegionServer中讀取Row。
從這個過程中,我們發現客戶會緩存這些位置信息,然而第二步它只是緩存當前RowKey對應的HRegion的位置,因而如果下一個要查的RowKey不在同一個HRegion中,則需要繼續查詢hbase:meta所在的HRegion,然而隨著時間的推移,客戶端緩存的位置信息越來越多,以至于不需要再次查找hbase:meta Table的信息,除非某個HRegion因為宕機或Split被移動,此時需要重新查詢并且更新緩存。

hbase:meta表

hbase:meta表存儲了所有用戶HRegion的位置信息,它的RowKey是:tableName,regionStartKey,regionId,replicaId等,它只有info列族,這個列族包含三個列,他們分別是:info:regioninfo列是RegionInfo的proto格式:regionId,tableName,startKey,endKey,offline,split,replicaId;info:server格式:HRegionServer對應的server:port;info:serverstartcode格式是HRegionServer的啟動時間戳。

HRegionServer詳解

HRegionServer一般和DataNode在同一臺機器上運行,實現數據的本地性。HRegionServer包含多個HRegion,由WAL(HLog)、BlockCache、MemStore、HFile組成。
  1. WAL即Write Ahead Log,在早期版本中稱為HLog,它是HDFS上的一個文件,如其名字所表示的,所有寫操作都會先保證將數據寫入這個Log文件后,才會真正更新MemStore,最后寫入HFile中。采用這種模式,可以保證HRegionServer宕機后,我們依然可以從該Log文件中讀取數據,Replay所有的操作,而不至于數據丟失。這個Log文件會定期Roll出新的文件而刪除舊的文件(那些已持久化到HFile中的Log可以刪除)。WAL文件存儲在/hbase/WALs/${HRegionServer_Name}的目錄中(在0.94之前,存儲在/hbase/.logs/目錄中),一般一個HRegionServer只有一個WAL實例,也就是說一個HRegionServer的所有WAL寫都是串行的(就像log4j的日志寫也是串行的),這當然會引起性能問題,因而在HBase 1.0之后,通過HBASE-5699實現了多個WAL并行寫(MultiWAL),該實現采用HDFS的多個管道寫,以單個HRegion為單位。關于WAL可以參考Wikipedia的Write-Ahead Logging。順便吐槽一句,英文版的維基百科竟然能毫無壓力的正常訪問了,這是某個GFW的疏忽還是以后的常態?
  2. BlockCache是一個讀緩存,即“引用局部性”原理(也應用于CPU,分空間局部性和時間局部性,空間局部性是指CPU在某一時刻需要某個數據,那么有很大的概率在一下時刻它需要的數據在其附近;時間局部性是指某個數據在被訪問過一次后,它有很大的概率在不久的將來會被再次的訪問),將數據預讀取到內存中,以提升讀的性能。HBase中提供兩種BlockCache的實現:默認on-heap LruBlockCache和BucketCache(通常是off-heap)。通常BucketCache的性能要差于LruBlockCache,然而由于GC的影響,LruBlockCache的延遲會變的不穩定,而BucketCache由于是自己管理BlockCache,而不需要GC,因而它的延遲通常比較穩定,這也是有些時候需要選用BucketCache的原因。這篇文章BlockCache101對on-heap和off-heap的BlockCache做了詳細的比較。
  3. HRegion是一個Table中的一個Region在一個HRegionServer中的表達。一個Table可以有一個或多個Region,他們可以在一個相同的HRegionServer上,也可以分布在不同的HRegionServer上,一個HRegionServer可以有多個HRegion,他們分別屬于不同的Table。HRegion由多個Store(HStore)構成,每個HStore對應了一個Table在這個HRegion中的一個Column Family,即每個Column Family就是一個集中的存儲單元,因而最好將具有相近IO特性的Column存儲在一個Column Family,以實現高效讀取(數據局部性原理,可以提高緩存的命中率)。HStore是HBase中存儲的核心,它實現了讀寫HDFS功能,一個HStore由一個MemStore 和0個或多個StoreFile組成。
    1. MemStore是一個寫緩存(In Memory Sorted Buffer),所有數據的寫在完成WAL日志寫后,會 寫入MemStore中,由MemStore根據一定的算法將數據Flush到地層HDFS文件中(HFile),通常每個HRegion中的每個 Column Family有一個自己的MemStore。
    2. HFile(StoreFile) 用于存儲HBase的數據(Cell/KeyValue)。在HFile中的數據是按RowKey、Column Family、Column排序,對相同的Cell(即這三個值都一樣),則按timestamp倒序排列。

雖然上面這張圖展現的是最新的HRegionServer的架構(但是并不是那么的精確),但是我一直比較喜歡看以下這張圖,即使它展現的應該是0.94以前的架構。

HRegionServer中數據寫流程圖解

當客戶端發起一個Put請求時,首先它從hbase:meta表中查出該Put數據最終需要去的HRegionServer。然后客戶端將Put請求發送給相應的HRegionServer,在HRegionServer中它首先會將該Put操作寫入WAL日志文件中(Flush到磁盤中)。

寫完WAL日志文件后,HRegionServer根據Put中的TableName和RowKey找到對應的HRegion,并根據Column Family找到對應的HStore,并將Put寫入到該HStore的MemStore中。此時寫成功,并返回通知客戶端。

MemStore Flush

MemStore是一個In Memory Sorted Buffer,在每個HStore中都有一個MemStore,即它是一個HRegion的一個Column Family對應一個實例。它的排列順序以RowKey、Column Family、Column的順序以及Timestamp的倒序,如下所示:

每一次Put/Delete請求都是先寫入到MemStore中,當MemStore滿后會Flush成一個新的StoreFile(底層實現是HFile),即一個HStore(Column Family)可以有0個或多個StoreFile(HFile)。有以下三種情況可以觸發MemStore的Flush動作,需要注意的是MemStore的最小Flush單元是HRegion而不是單個MemStore。據說這是Column Family有個數限制的其中一個原因,估計是因為太多的Column Family一起Flush會引起性能問題?具體原因有待考證。
  1. 當一個HRegion中的所有MemStore的大小總和超過了hbase.hregion.memstore.flush.size的大小,默認128MB。此時當前的HRegion中所有的MemStore會Flush到HDFS中。
  2. 當全局MemStore的大小超過了hbase.regionserver.global.memstore.upperLimit的大小,默認40%的內存使用量。此時當前HRegionServer中所有HRegion中的MemStore都會Flush到HDFS中,Flush順序是MemStore大小的倒序(一個HRegion中所有MemStore總和作為該HRegion的MemStore的大小還是選取最大的MemStore作為參考?有待考證),直到總體的MemStore使用量低于hbase.regionserver.global.memstore.lowerLimit,默認38%的內存使用量。
  3. 當前HRegionServer中WAL的大小超過了hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs的數量,當前HRegionServer中所有HRegion中的MemStore都會Flush到HDFS中,Flush使用時間順序,最早的MemStore先Flush直到WAL的數量少于hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs。這里說這兩個相乘的默認大小是2GB,查代碼,hbase.regionserver.max.logs默認值是32,而hbase.regionserver.hlog.blocksize是HDFS的默認blocksize,32MB。但不管怎么樣,因為這個大小超過限制引起的Flush不是一件好事,可能引起長時間的延遲,因而這篇文章給的建議:“Hint: keep hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs just a bit above hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE.”。并且需要注意,這里給的描述是有錯的(雖然它是官方的文檔)。
在MemStore Flush過程中,還會在尾部追加一些meta數據,其中就包括Flush時最大的WAL sequence值,以告訴HBase這個StoreFile寫入的最新數據的序列,那么在Recover時就直到從哪里開始。在HRegion啟動時,這個sequence會被讀取,并取最大的作為下一次更新時的起始sequence。

HFile格式

HBase的數據以KeyValue(Cell)的形式順序的存儲在HFile中,在MemStore的Flush過程中生成HFile,由于MemStore中存儲的Cell遵循相同的排列順序,因而Flush過程是順序寫,我們直到磁盤的順序寫性能很高,因為不需要不停的移動磁盤指針。

HFile參考BigTable的SSTable和Hadoop的TFile實現,從HBase開始到現在,HFile經歷了三個版本,其中V2在0.92引入,V3在0.98引入。首先我們來看一下V1的格式:

V1的HFile由多個Data Block、Meta Block、FileInfo、Data Index、Meta Index、Trailer組成,其中Data Block是HBase的最小存儲單元,在前文中提到的BlockCache就是基于Data Block的緩存的。一個Data Block由一個魔數和一系列的KeyValue(Cell)組成,魔數是一個隨機的數字,用于表示這是一個Data Block類型,以快速監測這個Data Block的格式,防止數據的破壞。Data Block的大小可以在創建Column Family時設置(HColumnDescriptor.setBlockSize()),默認值是64KB,大號的Block有利于順序Scan,小號Block利于隨機查詢,因而需要權衡。Meta塊是可選的,FileInfo是固定長度的塊,它紀錄了文件的一些Meta信息,例如:AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等。Data Index和Meta Index紀錄了每個Data塊和Meta塊的其實點、未壓縮時大小、Key(起始RowKey?)等。Trailer紀錄了FileInfo、Data Index、Meta Index塊的起始位置,Data Index和Meta Index索引的數量等。其中FileInfo和Trailer是固定長度的。

HFile里面的每個KeyValue對就是一個簡單的byte數組。但是這個byte數組里面包含了很多項,并且有固定的結構。我們來看看里面的具體結構:

開始是兩個固定長度的數值,分別表示Key的長度和Value的長度。緊接著是Key,開始是固定長度的數值,表示RowKey的長度,緊接著是 RowKey,然后是固定長度的數值,表示Family的長度,然后是Family,接著是Qualifier,然后是兩個固定長度的數值,表示Time Stamp和Key Type(Put/Delete)。Value部分沒有這么復雜的結構,就是純粹的二進制數據了。隨著HFile版本遷移,KeyValue(Cell)的格式并未發生太多變化,只是在V3版本,尾部添加了一個可選的Tag數組。

HFileV1版本的在實際使用過程中發現它占用內存多,并且Bloom File和Block Index會變的很大,而引起啟動時間變長。其中每個HFile的Bloom Filter可以增長到100MB,這在查詢時會引起性能問題,因為每次查詢時需要加載并查詢Bloom Filter,100MB的Bloom Filer會引起很大的延遲;另一個,Block Index在一個HRegionServer可能會增長到總共6GB,HRegionServer在啟動時需要先加載所有這些Block Index,因而增加了啟動時間。為了解決這些問題,在0.92版本中引入HFileV2版本:

在這個版本中,Block Index和Bloom Filter添加到了Data Block中間,而這種設計同時也減少了寫的內存使用量;另外,為了提升啟動速度,在這個版本中還引入了延遲讀的功能,即在HFile真正被使用時才對其進行解析。

FileV3版本基本和V2版本相比,并沒有太大的改變,它在KeyValue(Cell)層面上添加了Tag數組的支持;并在FileInfo結構中添加了和Tag相關的兩個字段。關于具體HFile格式演化介紹,可以參考這里。

對HFileV2格式具體分析,它是一個多層的類B+樹索引,采用這種設計,可以實現查找不需要讀取整個文件:

Data Block中的Cell都是升序排列,每個block都有它自己的Leaf-Index,每個Block的最后一個Key被放入Intermediate-Index中,Root-Index指向Intermediate-Index。在HFile的末尾還有Bloom Filter用于快速定位那么沒有在某個Data Block中的Row;TimeRange信息用于給那些使用時間查詢的參考。在HFile打開時,這些索引信息都被加載并保存在內存中,以增加以后的讀取性能。

這篇就先寫到這里,未完待續。。。。

參考:

https://www.mapr.com/blog/in-depth-look-hbase-architecture#.VdNSN6Yp3qx
//jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable
//hbase.apache.org/book.html
//www.searchtb.com/2011/01/understanding-hbase.html
//research.google.com/archive/bigtable-osdi06.pdf
posted on 2015-08-22 17:44 DLevin 閱讀(57941) 評論(0)  編輯  收藏 所屬分類: HBase 、Architecture

只有注冊用戶登錄后才能發表評論。


網站導航:
 
{ganrao} 四肖期期中准一免费118 姚记棋牌app官网 白小姐中特网必选~肖 通化大嘴棋牌官方下 捕鱼游戏怎么玩打哪里 南粤36选7 好彩3 北京麻将官网下载 财神透密二码 分分彩官方软件下载 四川麻将(血战到底 捕鱼在线下载 五分彩为什么要带人赚钱 哈尔滨大众麻将免费下载 管家婆资料大全管家婆 喜乐彩票app下载 随便玩长沙麻将下载