1、HBase 系統架構圖組成部件說明 Client： 使用HBase RPC機制與HMaster和HRegionServer進行通信 Client與HMaster進行通信進行管理類操作 Client與HRegionServer進行數據讀寫類操作 Zookeeper： Zookeeper Quorum存儲-ROOT-表地址、HMaster地址 HRegionServer把自己以Ephedral方式注冊到Zookeeper中，HMaster隨時感知各個HRegionServer的健康狀況 Zookeeper避免HMast

2、er單點問題 HMaster： HMaster沒有單點問題，HBase中可以啟動多個HMaster，通過Zookeeper的Master Election機制保證總有一個Master在運行 主要負責Table和Region的管理工作： 1 管理用戶對表的增刪改查操作 2 管理HRegionServer的負載均衡，調整Region分布 3 Region Split后，負責新Region的分布 4 在HRegionServer停機后，負責失效HRegionServer上Region遷移 HRegionServer：&#

3、160;HBase中最核心的模塊，主要負責響應用戶I/O請求，向HDFS文件系統中讀寫數據HRegionServer管理一些列HRegion對象； 每個HRegion對應Table中一個Region，HRegion由多個HStore組成； 每個HStore對應Table中一個Column Family的存儲； Column Family就是一個集中的存儲單元，故將具有相同IO特性的Column放在一個Column Family會更高效HStore： HBase存儲的核心。由MemStore和StoreFile組成。 MemStore是Sorte

4、d Memory Buffer。用戶寫入數據的流程：Client寫入 -> 存入MemStore，一直到MemStore滿 -> Flush成一個StoreFile，直至增長到一定閾值 -> 觸發Compact合并操作 -> 多個StoreFile合并成一個StoreFile，同時進行版本合并和數據刪除 -> 當StoreFiles Compact后，逐步形成越來越大的StoreFile -> 單個StoreFile大小超過一定閾值后，觸發Split操作，把當前Region Split成2個Region，Region會下線，新Split出的2個孩子Regio

5、n會被HMaster分配到相應的HRegionServer上，使得原先1個Region的壓力得以分流到2個Region上。由此過程可知，HBase只是增加數據，有所得更新和刪除操作，都是在Compact階段做的，所以，用戶寫操作只需要進入到內存即可立即返回，從而保證I/O高性能。HLog 引入HLog原因： 在分布式系統環境中，無法避免系統出錯或者宕機，一旦HRegionServer意外退出，MemStore中的內存數據就會丟失，引入HLog就是防止這種情況 工作機制： 每個HRegionServer中都會有一個HLog對象，HLog是一個實現Write

6、 Ahead Log的類，每次用戶操作寫入Memstore的同時，也會寫一份數據到HLog文件，HLog文件定期會滾動出新，并刪除舊的文件(已持久化到StoreFile中的數據)。當HRegionServer意外終止后，HMaster會通過Zookeeper感知，HMaster首先處理遺留的HLog文件，將不同region的log數據拆分，分別放到相應region目錄下，然后再將失效的region重新分配，領取到這些region的HRegionServer在Load Region的過程中，會發現有歷史HLog需要處理，因此會Replay HLog中的數據到MemStore中，然后flush到S

7、toreFiles，完成數據恢復。HBase存儲格式 HBase中的所有數據文件都存儲在Hadoop HDFS文件系統上，格式主要有兩種： 1 HFile HBase中KeyValue數據的存儲格式，HFile是Hadoop的二進制格式文件，實際上StoreFile就是對HFile做了輕量級包裝，即StoreFile底層就是HFile 2 HLog File，HBase中WAL（Write Ahead Log） 的存儲格式，物理上是Hadoop的Sequence FileHFile圖片解釋： HFile文件不定長，長度固定的塊只有兩個：Trailer和F

8、ileInfo Trailer中指針指向其他數據塊的起始點 File Info中記錄了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等 Data Index和Meta Index塊記錄了每個Data塊和Meta塊的起始點 Data Block是HBase I/O的基本單元，為了提高效率，HRegionServer中有基于LRU的Block Cache機制 每個Data塊的大小可以在創建一個Table的時候通過參數指定，大號的Block

9、有利于順序Scan，小號Block利于隨機查詢 每個Data塊除了開頭的Magic以外就是一個個KeyValue對拼接而成, Magic內容就是一些隨機數字，目的是防止數據損壞HFile里面的每個KeyValue對就是一個簡單的byte數組。這個byte數組里面包含了很多項，并且有固定的結構。KeyLength和ValueLength：兩個固定的長度，分別代表Key和Value的長度 Key部分：Row Length是固定長度的數值，表示RowKey的長度，Row 就是RowKey Column Family Length是固定長度的數值，表示Family的長度&

10、#160;接著就是Column Family，再接著是Qualifier，然后是兩個固定長度的數值，表示Time Stamp和Key Type（Put/Delete） Value部分沒有這么復雜的結構，就是純粹的二進制數據HLog FileHLog文件就是一個普通的Hadoop Sequence File，Sequence File 的Key是HLogKey對象，HLogKey中記錄了寫入數據的歸屬信息，除了table和region名字外，同時還包括 sequence number和timestamp，timestamp是“寫入時間”，sequence number的起始值為0，或者

11、是最近一次存入文件系統中sequence number。 HLog Sequece File的Value是HBase的KeyValue對象，即對應HFile中的KeyValue結束語：這篇文章是我專門在網上弄下來的，算是hbase部分的終極篇吧，我的服務端的源碼系列也要基于這個順序來開展。一、HBASE 簡介 HBase是一個分布式的、面向列的開源數據庫，該技術來源于 Fay Chang 所撰寫的Google論文"Bigtable：一個結構化數據的分布式存儲系統"。就像Bigtable利用了Google文件系統（File S

12、ystem）所提供的分布式數據存儲一樣，HBase在Hadoop之上提供了類似于Bigtable的能力。HBase是Apache的Hadoop項目的子項目。HBase不同于一般的關系數據庫，它是一個適合于非結構化數據存儲的數據庫。另一個不同的是HBase基于列的而不是基于行的模式。 hbase是bigtable的開源山寨版本。是建立的hdfs之上，提供高可靠性、高性能、列存儲、可伸縮、實時讀寫的數據庫系統。它介于nosql和RDBMS之間，僅能通過主鍵(row key)和主鍵的range來檢索數據，僅支持單行事務(可通過hive支持來實現多表join等復雜操作)。主要用來存儲非結構化

13、和半結構化的松散數據。與hadoop一樣，Hbase目標主要依靠橫向擴展，通過不斷增加廉價的商用服務器，來增加計算和存儲能力。 HBase中的表一般有這樣的特點：1 大：一個表可以有上億行，上百萬列2 面向列:面向列(族)的存儲和權限控制，列(族)獨立檢索。3 稀疏:對于為空(null)的列，并不占用存儲空間，因此，表可以設計的非常稀疏。二、邏輯視圖 HBase以表的形式存儲數據。表有行和列組成。列劃分為若干個列族(row family)Row Keycolumn-family1column-family2column-family3colum

14、n1column1column1column2column3column1key1t1:abct2:gdxdf t4:dfadst3:hellot2:world   key2t3:abct1:gdxdf t4:dfadst3:hello t2:dfdsfat3:dfdf key3 t2:dfadfasdt1:dfdasddsf   t2:dfxxdfasd t1: Row Key與nosql數據庫們一樣,row key是用來檢索記錄的主鍵。訪問hbase table

15、中的行，只有三種方式：1 通過單個row key訪問2 通過row key的range3 全表掃描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

16、,21,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行鍵必須用0作左填充。行的一次讀寫是原子操作 (不論一次讀寫多少列)。這個設計決策能夠使用戶很容易的理解程序在對同一個行進行并發更新操作時的行為。 列族hbase表中的每個列，都歸屬與某個列族。列族是表的chema的一部分(而列不是)，必須在使用表之前定義。列名都以列族作為前綴。例如courses:history ， courses:math 都屬于 courses 這個列族。訪問控制、磁盤和內存的使用統計都是在列族層面進行的。實際應用中，

17、列族上的控制權限能幫助我們管理不同類型的應用：我們允許一些應用可以添加新的基本數據、一些應用可以讀取基本數據并創建繼承的列族、一些應用則只允許瀏覽數據（甚至可能因為隱私的原因不能瀏覽所有數據）。 時間戳HBase中通過row和columns確定的為一個存貯單元稱為cell。每個 cell都保存著同一份數據的多個版本。版本通過時間戳來索引。時間戳的類型是 64位整型。時間戳可以由hbase(在數據寫入時自動 )賦值，此時時間戳是精確到毫秒的當前系統時間。時間戳也可以由客戶顯式賦值。如果應用程序要避免數據版本沖突，就必須自己生成具有唯一性的時間戳。每個

18、60;cell中，不同版本的數據按照時間倒序排序，即最新的數據排在最前面。為了避免數據存在過多版本造成的的管理 (包括存貯和索引)負擔，hbase提供了兩種數據版本回收方式。一是保存數據的最后n個版本，二是保存最近一段時間內的版本（比如最近七天）。用戶可以針對每個列族進行設置。 Cell由row key, column( =<family> + <label>), version 唯一確定的單元。cell中的數據是沒有類型的，全部是字節碼形式存貯。 三、物理存儲1 已經提到過，Table中的所有行都按照row

19、key的字典序排列。2 Table 在行的方向上分割為多個Hregion。 3 region按大小分割的，每個表一開始只有一個region，隨著數據不斷插入表，region不斷增大，當增大到一個閥值的時候，Hregion就會等分會兩個新的Hregion。當table中的行不斷增多，就會有越來越多的Hregion。 4 Hregion是Hbase中分布式存儲和負載均衡的最小單元。最小單元就表示不同的Hregion可以分布在不同的HRegion server上。但一個Hregion是不會拆分到多個server上的。 5 HRegion雖然是分布式存儲的最小單

20、元，但并不是存儲的最小單元。事實上，HRegion由一個或者多個Store組成，每個store保存一個columns family。每個Strore又由一個memStore和0至多個StoreFile組成。如圖：StoreFile以HFile格式保存在HDFS上。 HFile分為六個部分：Data Block 段保存表中的數據，這部分可以被壓縮Meta Block 段 (可選的)保存用戶自定義的kv對，可以被壓縮。File Info 段Hfile的元信息，不被壓縮，用戶也可以在這一部分添加自己的元信息。Data Block Index 

21、;段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。DataB

22、lock Index采用LRU機制淘汰。HFile的Data Block，Meta Block通常采用壓縮方式存儲，壓縮之后可以大大減少網絡IO和磁盤IO，隨之而來的開銷當然是需要花費cpu進行壓縮和解壓縮。目標Hfile的壓縮支持兩種方式：Gzip，Lzo。 HLog(WAL log)WAL 意為Write ahead log(/wiki/Write-ahead_logging)，類似mysql中的binlog,用來做災難恢復只用，Hlog記錄數據的所有變更,一旦數據修改，就可以從log中進行恢復。每個Region Server

23、維護一個Hlog,而不是每個Region一個。這樣不同region(來自不同table)的日志會混在一起，這樣做的目的是不斷追加單個文件相對于同時寫多個文件而言，可以減少磁盤尋址次數，因此可以提高對table的寫性能。帶來的麻煩是，如果一臺region server下線，為了恢復其上的region，需要將region server上的log進行拆分，然后分發到其它region server上進行恢復。HLog文件就是一個普通的Hadoop Sequence File，Sequence File 的Key是HLogKey對象，HLogKey中記錄了寫入數據的歸屬信息，除了table和r

24、egion名字外，同時還包括 sequence number和timestamp，timestamp是"寫入時間"，sequence number的起始值為0，或者是最近一次存入文件系統中sequence number。HLog Sequece File的Value是HBase的KeyValue對象，即對應HFile中的KeyValue，可參見上文描述。 四、系統架構Client1 包含訪問hbase的接口，client維護著一些cache來加快對hbase的訪問，比如regione的位置信息。 Zookeeper1 保證任

25、何時候，集群中只有一個master2 存貯所有Region的尋址入口。3 實時監控Region Server的狀態，將Region server的上線和下線信息實時通知給Master4 存儲Hbase的schema,包括有哪些table，每個table有哪些column family Master1 為Region server分配region2 負責region server的負載均衡3 發現失效的region server并重新分配其上的region4 GFS上的垃圾文件回收5 處理schema更新請求

26、0;Region Server1 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)

27、所在的regionbigtable 使用三層類似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.表每行保存

28、一個region的位置信息，row key 采用表名+表的最后一樣編碼而成。3 為了加快訪問，.META.表的全部region都保存在內存中。假設，.META.表的一行在內存中大約占用1KB。并且每個region限制為128MB。那么上面的三層結構可以保存的region數目為：(128MB/1KB) * (128MB/1KB) = = 2(34)個region4 client會將查詢過的位置信息保存緩存起來，緩存不會主動失效，因此如果client上的緩存全部失效，則需要進行6次網絡來回，才能定位到正確的region(其中三次用來發現緩存失效，另外三次用來獲取位置信息)。&#

29、160;讀寫過程上文提到，hbase使用MemStore和StoreFile存儲對表的更新。數據在更新時首先寫入Log(WAL log)和內存(MemStore)中，MemStore中的數據是排序的，當MemStore累計到一定閾值時，就會創建一個新的MemStore，并且將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成為一個StoreFile。于此同時，系統會在zookeeper中記錄一個redo point，表示這個時刻之前的變更已經持久化了。(minor compact)當系統出現意外時，可能導致內存(MemStore)中的數據丟失，此時使用Log(WAL

30、log)來恢復checkpoint之后的數據。前面提到過StoreFile是只讀的，一旦創建后就不可以再修改。因此Hbase的更新其實是不斷追加的操作。當一個Store中的StoreFile達到一定的閾值后，就會進行一次合并(major compact),將對同一個key的修改合并到一起，形成一個大的StoreFile，當StoreFile的大小達到一定閾值后，又會對 StoreFile進行split，等分為兩個StoreFile。由于對表的更新是不斷追加的，處理讀請求時，需要訪問Store中全部的 StoreFile和MemStore，將他們的按照row key進行合并，

31、由于StoreFile和MemStore都是經過排序的，并且StoreFile帶有內存中索引，合并的過程還是比較快。寫請求處理過程 1 client向region server提交寫請求2 region server找到目標region3 region檢查數據是否與schema一致4 如果客戶端沒有指定版本，則獲取當前系統時間作為數據版本5 將更新寫入WAL log6 將更新寫入Memstore7 判斷Memstore的是否需要flush為Store文件。 region分配任何時刻，一個region只能分配給一個region serv

32、er。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的會