title: (轉(zhuǎn))HBase架構(gòu)深入解析
tags:
- hbase
categories:
- Hbase
comments: true
date: 2017-03-11 21:40:00
收藏一篇很詳細介紹的 HBase 架構(gòu)的文章，圖文并茂宛畦，原文鏈接：
HBase架構(gòu)組成
HBase采用Master/Slave架構(gòu)搭建集群瘸洛，它隸屬于Hadoop生態(tài)系統(tǒng)，由以下類型節(jié)點組成：HMaster節(jié)點次和、HRegionServer節(jié)點反肋、ZooKeeper集群，而在底層踏施，它將數(shù)據(jù)存儲于HDFS中囚玫，因而涉及到HDFS的NameNode喧锦、DataNode等，總體結(jié)構(gòu)如下：
其中HMaster節(jié)點用于：
- 管理HRegionServer抓督，實現(xiàn)其負載均衡燃少。
- 管理和分配HRegion，比如在 HRegion split 時分配新的 HRegion铃在；在HRegionServer退出時遷移其內(nèi)的 HRegion 到其他 HRegionServer 上阵具。
- 實現(xiàn) DDL 操作（Data Definition Language，namespace 和 table 的增刪改定铜，column familiy 的增刪改等）阳液。
- 管理 namespace 和 table 的元數(shù)據(jù)（實際存儲在HDFS上）。
- 權(quán)限控制（ACL）揣炕。
HRegionServer節(jié)點用于：
- 存放和管理本地 HRegion帘皿。
- 讀寫 HDFS，管理 Table 中的數(shù)據(jù)畸陡。
- Client 直接通過 HRegionServer 讀寫數(shù)據(jù)（從HMaster中獲取元數(shù)據(jù)鹰溜，找到RowKey所在的 HRegion/HRegionServer 后）。
ZooKeeper集群是協(xié)調(diào)系統(tǒng)丁恭，用于：
- 存放整個 HBase集群的元數(shù)據(jù)以及集群的狀態(tài)信息曹动。
- 實現(xiàn)HMaster主從節(jié)點的 failover。
HRegion
HBase 使用 RowKey 將表水平切割成多個 HRegion牲览，從 HMaster 的角度墓陈，每個HRegion 都紀錄了它的 StartKey 和 EndKey（第一個 HRegion 的 StartKey 為空，最后一個 HRegion 的 EndKey 為空）第献，由于 RowKey 是排序的贡必，因而 Client可以通過 HMaster 快速的定位每個 RowKey 在哪個 HRegion 中。HRegion 由 HMaster 分配到相應的 HRegionServer 中庸毫，然后由 HRegionServer 負責 HRegion 的啟動和管理仔拟，和 Client 的通信，負責數(shù)據(jù)的讀(使用HDFS)岔绸。每個 HRegionServer 可以同時管理1000個左右的HRegion（這個數(shù)字怎么來的理逊？沒有從代碼中看到限制，難道是出于經(jīng)驗盒揉？超過1000個會引起性能問題晋被？）。
HMaster
HMaster 沒有單點故障問題刚盈，可以啟動多個 HMaster羡洛，通過 ZooKeeper 的 Master Election 機制保證同時只有一個 HMaster 出于 Active 狀態(tài)，其他的 HMaster 則處于熱備份狀態(tài)。一般情況下會啟動兩個 HMaster欲侮，非 Active 的 HMaster 會定期的和Active HMaster 通信以獲取其最新狀態(tài)崭闲，從而保證它是實時更新的，因而如果啟動了多個 HMaster 反而增加了 Active HMaster 的負擔威蕉。前文已經(jīng)介紹過了 HMaster 的主要用于 HRegion 的分配和管理刁俭，DDL(Data Definition Language，既Table的新建韧涨、刪除牍戚、修改等)的實現(xiàn)等，既它主要有兩方面的職責：
- 協(xié)調(diào)HRegionServer
- 啟動時 HRegion 的分配虑粥，以及負載均衡和修復時 HRegion 的重新分配如孝。
- 監(jiān)控集群中所有 HRegionServer 的狀態(tài)(通過 Heartbeat 和監(jiān)聽 ZooKeeper 中的狀態(tài))。
- Admin職能
-
創(chuàng)建娩贷、刪除第晰、修改 Table 的定義。
hmaster
ZooKeeper
ZooKeeper 為 HBase 集群提供協(xié)調(diào)服務彬祖，它管理著 HMaster 和 HRegionServer 的狀態(tài)(available/alive等)茁瘦，并且會在它們宕機時通知給 HMaster，從而 HMaster 可以實現(xiàn) HMaster 之間的 failover涧至，或?qū)﹀礄C的 HRegionServer 中的 HRegion 集合的修復(將它們分配給其他的 HRegionServer)腹躁。ZooKeeper 集群本身使用一致性協(xié)議(PAXOS協(xié)議)保證每個節(jié)點狀態(tài)的一致性桑包。
How The Components Work Together
ZooKeeper協(xié)調(diào)集群所有節(jié)點的共享信息南蓬，在HMaster和HRegionServer連接到ZooKeeper后創(chuàng)建Ephemeral節(jié)點，并使用Heartbeat機制維持這個節(jié)點的存活狀態(tài)哑了，如果某個Ephemeral節(jié)點實效赘方，則HMaster會收到通知，并做相應的處理弱左。
HBase 的第一次讀寫基本流程：
在 HBase 0.96 以前窄陡，HBase 有兩個特殊的 Table：-ROOT- 和 .META.（現(xiàn)在只有 .META），其中 -ROOT- Table 的位置存儲在 ZooKeeper拆火，它存儲了 .META. Table 的 RegionInfo 信息跳夭，并且它只能存在一個 HRegion，而 .META. Table 則存儲了用戶 Table 的 RegionInfo 信息们镜，它可以被切分成多個 HRegion币叹，因而對第一次訪問用戶 Table 時，首先從 ZooKeeper 中讀取 -ROOT- Table 所在 HRegionServer模狭；然后從該 HRegionServer 中根據(jù)請求的 TableName颈抚，RowKey 讀取 .META. Table 所在 HRegionServer；最后從該 HRegionServer 中讀取 .META. Table 的內(nèi)容而獲取此次請求需要訪問的 HRegion 所在的位置嚼鹉，然后訪問該 HRegionSever 獲取請求的數(shù)據(jù)贩汉，這需要三次請求才能找到用戶 Table 所在的位置驱富，然后第四次請求開始獲取真正的數(shù)據(jù)。當然為了提升性能匹舞，客戶端會緩存- ROOT- Table 位置以及 -ROOT-/.META. Table 的內(nèi)容褐鸥。客戶端在第一次訪問用戶Table的流程：
- 從 ZooKeeper(/hbase/meta-region-server) 中獲取 hbase:meta 的位置（HRegionServer的位置）赐稽，緩存該位置信息晶疼。
- 從 HRegionServer 中查詢用戶 Table 對應請求的 RowKey 所在的 HRegionServer，緩存該位置信息又憨。
- 從查詢到 HRegionServer 中讀取 Row翠霍。
從這個過程中，我們發(fā)現(xiàn)客戶會緩存這些位置信息蠢莺，然而第二步它只是緩存當前RowKey對應的HRegion的位置寒匙，因而如果下一個要查的RowKey不在同一個HRegion中，則需要繼續(xù)查詢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 在同一臺機器上運行，實現(xiàn)數(shù)據(jù)的本地性允乐。HRegionServer 包含多個 HRegion矮嫉，由 WAL(HLog)、 BlockCache牍疏、MemStore蠢笋、HFile 組成。
WAL 即 Write Ahead Log麸澜，在早期版本中稱為 HLog挺尿，它是 HDFS 上的一個文件，如其名字所表示的，所有寫操作都會先保證將數(shù)據(jù)寫入這個 Log 文件后编矾，才會真正更新 MemStore（內(nèi)存）熟史，最后寫入 HFile （硬盤）中。采用這種模式窄俏，可以保證HRegionServer 宕機后蹂匹，我們依然可以從該 Log 文件中讀取數(shù)據(jù)，Replay 所有的操作凹蜈，而不至于數(shù)據(jù)丟失限寞。這個 Log 文件會定期 Roll 出新的文件而刪除舊的文件(那些已持久化到 HFile 中的 Log 可以刪除)。WAL 文件存儲在 /hbase/WALs/${HRegionServer_Name} 的目錄中(在0.94之前仰坦，存儲在 /hbase/.logs/ 目錄中)履植，一般一個 HRegionServer 只有一個 WAL 實例，也就是說一個 HRegionServer 的所有 WAL 寫都是串行的(就像 log4j 的日志寫也是串行的)悄晃，這當然會引起性能問題玫霎，因而在HBase 1.0之后，通過HBASE-5699實現(xiàn)了 多個WAL并行寫(MultiWAL) 妈橄，該實現(xiàn)采用HDFS的多個管道寫庶近，以單個HRegion為單位。關于 WAL 可以參考 Wikipedia 的 Write-Ahead Logging眷蚓。
BlockCache 是一個讀緩存（讀性能的關鍵在于緩存）鼻种，即“引用局部性”原理（也應用于 CPU，分空間局部性和時間局部性沙热，空間局部性是指 CPU 在某一時刻需要某個數(shù)據(jù)叉钥，那么有很大的概率在一下時刻它需要的數(shù)據(jù)在其附近；時間局部性是指某個數(shù)據(jù)在被訪問過一次后校读，它有很大的概率在不久的將來會被再次的訪問）沼侣，將數(shù)據(jù)預讀取到內(nèi)存中祖能，以提升讀的性能歉秫。HBase 中提供兩種 BlockCache 的實現(xiàn)：默認 on-heap LruBlockCache 和 BucketCache(通常是off-heap)。通常BucketCache的性能要差于LruBlockCache养铸，然而由于GC的影響雁芙，LruBlockCache的延遲會變的不穩(wěn)定，而BucketCache 由于是自己管理 BlockCache钞螟，而不需要 GC兔甘，因而它的延遲通常比較穩(wěn)定，這也是有些時候需要選用 BucketCache 的原因鳞滨。這篇文章BlockCache101對on-heap和off-heap的BlockCache做了詳細的比較洞焙。（現(xiàn)在默認兩者搭配使用，稱為 CombinedBlockCache，效果尤佳）
HRegion 是一個 Table 中的一個 Region 在一個 HRegionServer中的表達澡匪。一個Table 可以有一個或多個 Region熔任，他們可以在一個相同的 HRegionServer 上，也可以分布在不同的 HRegionServer 上唁情，一個 HRegionServer 可以有多個 HRegion疑苔，他們分別屬于不同的 Table。HRegion 由多個 Store(HStore) 構(gòu)成甸鸟，每個 HStore 對應了一個 Table 在這個 HRegion 中的一個 Column Family（所以同屬同一個 Column Family 的列必定存在同一個 HRegion 上）惦费，即每個 Column Family 就是一個集中的存儲單元，因而最好將具有相近 IO 特性的 Column 存儲在一個 Column Family抢韭，以實現(xiàn)高效讀取(數(shù)據(jù)局部性原理薪贫，可以提高緩存的命中率)。HStore 是HBase 中存儲的核心刻恭，它實現(xiàn)了讀寫 HDFS 功能后雷，一個 HStore 由一個 MemStore 和0個或多個 StoreFile 組成。
MemStore 是一個寫緩存 (In Memory Sorted Buffer) 吠各，所有數(shù)據(jù)的寫在完成 WAL 日志寫后臀突，會寫入 MemStore 中，由 MemStore 根據(jù)一定的算法將數(shù)據(jù) Flush 到地層 HDFS 文件中 (HFile)贾漏，通常每個 HRegion 中的每個 Column Family 有一個自己的MemStore候学。
HFile(StoreFile) 用于存儲 HBase 的數(shù)據(jù) (Cell/KeyValue)。在 HFile 中的數(shù)據(jù)是按RowKey纵散、Column Family梳码、Column排序，相同的 Cell(即這三個值都一樣)伍掀，則按timestamp倒序排列掰茶。
HRegion Server 寫的實現(xiàn)
當客戶端發(fā)起一個 Put 請求時，首先它從 hbase:meta 表中查出該 Put 數(shù)據(jù)最終需要去的 HRegionServer蜜笤。然后客戶端將 Put 請求發(fā)送給相應的 HRegionServer濒蒋，在 HRegionServer 中它首先會將該 Put 操作寫入 WAL 日志文件中( Flush到磁盤中)。
寫完 WAL 日志文件后把兔，HRegionServer 根據(jù) Put 中的 TableName 和 RowKey 找到對應的 HRegion沪伙，并根據(jù) 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(底層實現(xiàn)是HFile)炬守，即一個 HStore(Column Family) 可以有0個或多個 StoreFile(HFile)牧嫉。有以下三種情況可以觸發(fā) MemStore 的 Flush 動作，需要注意的是 MemStore 的最小 Flush 單元是 HRegion 而不是單個 MemStore减途。
- 當一個 MemStore 的大小超過了 hbase.hregion.memstore.flush.size 的大小酣藻，默認128MB。此時當前的 HRegion 中所有的 MemStore 會 Flush 到 HDFS 中鳍置。
- 當全局 MemStore 的大小超過了 hbase.regionserver.global.memstore.upperLimit 的大小辽剧，默認40％的內(nèi)存使用量。此時當前 HRegionServer 中所有 HRegion 中的 MemStore 都會 Flush 到 HDFS 中税产，F(xiàn)lush 順序是 MemStore 大小的倒序怕轿，直到總體的 MemStore 使用量低于hbase.regionserver.global.memstore.lowerLimit，默認38%的內(nèi)存使用量辟拷。
- 當前 HRegionServer 中 WAL 的大小超過了 hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs 的數(shù)量撞羽，當前 HRegionServer 中所有 HRegion 中的MemStore 都會 Flush 到 HDFS 中，F(xiàn)lush 使用時間順序衫冻，最早的 MemStore 先Flush 直到 WAL 的數(shù)量少于 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 數(shù)據(jù)，其中就包括 Flush 時最大的 WAL sequence 值鸠项，以告訴 HBase 這個 StoreFile 寫入的最新數(shù)據(jù)的序列，那么在 Recover 時就直到從哪里開始子姜。在 HRegion 啟動時祟绊，這個 sequence 會被讀取楼入，并取最大的作為下一次更新時的起始 sequence。
HFile格式
HBase 的數(shù)據(jù)以 KeyValue(Cell) 的形式順序的存儲在 HFile 中牧抽，在 MemStore 的 Flush 過程中生成 HFile嘉熊，由于 MemStore 中存儲的 Cell 遵循相同的排列順序，因而 Flush 過程是順序?qū)懷锸妫覀冎来疟P的順序?qū)懶阅芎芨卟簦驗椴恍枰煌５囊苿哟疟P指針。(同 kafka)
HFile 參考 BigTable 的 SSTable 和 Hadoop 的 TFile 實現(xiàn)讲坎，從 HBase 開始到現(xiàn)在，HFile 經(jīng)歷了三個版本，其中 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 由一個魔數(shù)和一系列的 KeyValue(Cell) 組成秆撮，魔數(shù)是一個隨機的數(shù)字，用于表示這是一個Data Block類型换况，以快速監(jiān)測這個 Data Block 的格式职辨，防止數(shù)據(jù)的破壞。Data Block 的大小可以在創(chuàng)建 Column Family 時設置 (HColumnDescriptor.setBlockSize())戈二，默認值是64KB舒裤，大號的Block有利于順序Scan，小號Block利于隨機查詢觉吭，因而需要權(quán)衡（影響查詢性能腾供，因為 data block 是最小存儲單元，在查詢時是緩存在blockcache 中的最小單元）鲜滩。Meta 塊是可選的伴鳖，F(xiàn)ileInfo 是固定長度的塊，它紀錄了文件的一些Meta 信息徙硅，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY 等榜聂。Data Index 和 Meta Index 紀錄了每個 Data 塊和 Meta 塊的起始點、未壓縮時大小嗓蘑、Key 等须肆。Trailer 紀錄了 FileInfo匿乃、Data Index、Meta Index 塊的起始位置豌汇，Data Index 和 Meta Index 索引的數(shù)量等幢炸。其中 FileInfo 和 Trailer 是固定長度的。
HFile 里面的每個 KeyValue 對就是一個簡單的 byte 數(shù)組拒贱。但是這個 byte 數(shù)組里面包含了很多項宛徊，并且有固定的結(jié)構(gòu)。我們來看看里面的具體結(jié)構(gòu)：
開始是兩個固定長度的數(shù)值逻澳，分別表示Key的長度和Value的長度闸天。緊接著是Key，開始是固定長度的數(shù)值赡盘，表示 RowKey 的長度号枕，緊接著是 RowKey，然后是固定長度的數(shù)值陨享，表示 Family 的長度葱淳，然后是 Family，接著是 Qualifier抛姑，然后是兩個固定長度的數(shù)值赞厕，表示 Time Stamp 和 Key Type（Put/Delete）。Value 部分沒有這么復雜的結(jié)構(gòu)定硝，就是純粹的二進制數(shù)據(jù)了皿桑。隨著 HFile 版本遷移，KeyValue(Cell) 的格式并未發(fā)生太多變化蔬啡，只是在V3版本诲侮，尾部添加了一個可選的Tag數(shù)組。
HFileV1 版本在實際使用過程中發(fā)現(xiàn)它占用內(nèi)存多箱蟆，并且 Bloom File 和 Block Index會變的很大沟绪，而引起啟動時間變長。其中每個 HFile 的 Bloom Filter 可以增長到 100MB空猜，這在查詢時會引起性能問題绽慈，因為每次查詢時需要加載并查詢 Bloom Filter，100MB 的 Bloom Filerv會引起很大的延遲辈毯；另一個坝疼，Block Index 在一個 HRegionServer 可能會增長到總共 6GB，HRegionServer 在啟動時需要先加載所有這些 Block Index谆沃，因而增加了啟動時間钝凶。為了解決這些問題，在0.92版本中引入HFileV2版本：
在這個版本中管毙，Block Index和Bloom Filter添加到了Data Block中間腿椎，而這種設計同時也減少了寫的內(nèi)存使用量桌硫；另外夭咬，為了提升啟動速度啃炸，在這個版本中還引入了延遲讀的功能，即在HFile真正被使用時才對其進行解析卓舵。
FileV3 版本基本和 V2 版本相比南用，并沒有太大的改變，它在 KeyValue(Cell) 層面上添加了 Tag 數(shù)組的支持掏湾；并在 FileInfo 結(jié)構(gòu)中添加了和 Tag 相關的兩個字段裹虫。關于具體 HFile 格式演化介紹，可以參考這里融击。
對 HFileV2 格式具體分析筑公，它是一個多層的類B+樹索引，采用這種設計尊浪，可以實現(xiàn)查找不需要讀取整個文件：
Data Block 中的 Cell 都是升序排列匣屡，每個 block 都有它自己的 Leaf-Index，每個Block 的最后一個 Key 被放入 Intermediate-Index 中拇涤，Root-Index 指向 Intermediate-Index捣作。在 HFile 的末尾還有 Bloom Filter 用于快速定位沒有在某個 Data Block 中的 Row；TimeRange 信息用于給那些使用時間查詢的參考鹅士。在 HFile 打開時券躁，這些索引信息都被加載并保存在內(nèi)存中，以增加以后的讀取性能掉盅。
HBase 讀的實現(xiàn)
通過前文的描述也拜，我們知道在 HBase 寫時，相同 Cell(RowKey/ColumnFamily/Column相同) 并不保證在一起趾痘，甚至刪除一個 Cell 也只是寫入一個新的 Cell慢哈，它含有 Delete 標記，而不一定將一個 Cell 真正刪除了扼脐，因而這就引起了一個問題岸军，如何實現(xiàn)讀的問題？要解決這個問題瓦侮，我們先來分析一下相同的Cell 可能存在的位置：首先對新寫入的 Cell艰赞，它會存在于 MemStore 中；然后對之前已經(jīng) Flush 到 HDFS 中的 Cell肚吏，它會存在于某個或某些 StoreFile(HFile) 中方妖；最后，對剛讀取過的 Cell罚攀，它可能存在于 BlockCache 中党觅。既然相同的Cell可能存儲在三個地方雌澄，在讀取的時候只需要掃瞄這三個地方，然后將結(jié)果合并即可 (Merge Read)杯瞻，在 HBase 中掃瞄的順序依次是：BlockCache镐牺、MemStore、StoreFile(HFile)魁莉。其中 StoreFile 的掃瞄先會使用 Bloom Filter 過濾那些不可能符合條件的 HFile睬涧，然后使用 Block Index 快速定位 Cell，并將其加載到 BlockCache 中旗唁，然后從 BlockCache 中讀取畦浓。我們知道一個 HStore 可能存在多個 StoreFile(HFile)，此時需要掃瞄多個 HFile检疫，如果 HFile 過多又是會引起性能問題讶请。
Compaction
而過多的 HFile 會引起讀的性能問題，HBase 采用 Compaction 機制來解決這個問題屎媳，有點類似 Java 中的 GC 機制夺溢，起初 Java 不停的申請內(nèi)存而不釋放，增加性能剿牺，然而天下沒有免費的午餐企垦，最終我們還是要在某個條件下去收集垃圾，很多時候需要 Stop-The-World晒来，這種 Stop-The-World 有些時候也會引起很大的問題钞诡，因而設計是一種權(quán)衡，沒有完美的湃崩。還是類似 Java 中的 GC荧降，在 HBase 中 Compaction 分為兩種：Minor Compaction 和 Major Compaction。
Minor Compaction 是指選取一些小的攒读、相鄰的 StoreFile 將他們合并成一個更大的 StoreFile朵诫，在這個過程中不會處理已經(jīng) Deleted 或 Expired 的 Cell。更少并且更大的StoreFile薄扁。（這個是對的嗎剪返？BigTable中是這樣描述Minor Compaction的：As write operations execute, the size of the memtable in- creases. When the memtable size reaches a threshold, the memtable is frozen, a new memtable is created, and the frozen memtable is converted to an SSTable and written to GFS. This minor compaction process has two goals: it shrinks the memory usage of the tablet server, and it reduces the amount of data that has to be read from the commit log during recovery if this server dies. Incoming read and write operations can continue while compactions occur. 也就是說它將 memtable 的數(shù)據(jù)flush 的一個 HFile/SSTable 稱為一次 Minor Compaction）
Major Compaction 是指將所有的 StoreFile 合并成一個 StoreFile，在這個過程中邓梅，標記為 Deleted 的 Cell 會被刪除脱盲，而那些已經(jīng) Expired 的 Cell 會被丟棄，那些已經(jīng)超過最多版本數(shù)的 Cell 會被丟棄日缨。一次 Major Compaction 的結(jié)果是一個 HStore 只有一個 StoreFile 存在钱反。Major Compaction 可以手動或自動觸發(fā)，然而由于它會引起很多的IO操作而引起性能問題，因而它一般會被安排在周末面哥、凌晨等集群比較閑的時間哎壳。
更形象一點，如下面兩張圖分別表示 Minor Compaction 和 Major Compaction尚卫。
HRegion Split
最初归榕，一個 Table 只有一個 HRegion，隨著數(shù)據(jù)寫入增加焕毫，如果一個 HRegion 到達一定的大小蹲坷，就需要 Split 成兩個 HRegion驶乾，這個大小由 hbase.hregion.max.filesize 指定邑飒，默認為10GB。當 split 時级乐，兩個新的 HRegion 會在同一個 HRegionServer 中創(chuàng)建疙咸，它們各自包含父 HRegion 一半的數(shù)據(jù)，當 Split 完成后风科，父 HRegion 會下線撒轮，而新的兩個子 HRegion 會向 HMaster 注冊上線，處于負載均衡的考慮贼穆，這兩個新的 HRegion 可能會被 HMaster 分配到其他的 HRegionServer 中题山。關于Split的詳細信息，可以參考這篇文章：《Apache HBase Region Splitting and Merging》故痊。
HRegion負載均衡
在 HRegion Split 后顶瞳，兩個新的 HRegion 最初會和之前的父 HRegion 在相同的 HRegionServer 上，出于負載均衡的考慮愕秫，HMaster 可能會將其中的一個甚至兩個重新分配的其他的 HRegionServer中慨菱，此時會引起有些
HRegionServer 處理的數(shù)據(jù)在其他節(jié)點上，直到下一次 Major Compaction 將數(shù)據(jù)從遠端的節(jié)點移動到本地節(jié)點戴甩。
HRegionServer Recovery
當一臺 HRegionServer 宕機時符喝，由于它不再發(fā)送 Heartbeat 給 ZooKeeper 而被監(jiān)測到，此時 ZooKeeper 會通知 HMaster甜孤，HMaster 會檢測到哪臺 HRegionServer 宕機协饲，它將宕機的 HRegionServer 中的 HRegion 重新分配給其他的 HRegionServer，同時 HMaster 會把宕機的 HRegionServer 相關的 WAL 拆分分配給相應的
HRegionServer (將拆分出的WAL文件寫入對應的目的 HRegionServer 的 WAL 目錄中缴川，并寫入對應的 DataNode中）茉稠，從而這些 HRegionServer 可以 Replay 分到的 WAL 來重建 MemStore。
HBase架構(gòu)簡單總結(jié)
在NoSQL中二跋，存在著名的CAP理論战惊，即 Consistency、Availability、Partition Tolerance 不可全得吞获，目前市場上基本上的 NoSQL 都采用 Partition Tolerance 以實現(xiàn)數(shù)據(jù)得水平擴展况凉，來處理 Relational DataBase 遇到的無法處理數(shù)據(jù)量太大的問題，或引起的性能問題各拷，因而只有剩下 C 和 A 可以選擇刁绒。HBase 在兩者之間選擇了Consistency，然后使用多個 HMaster 以及支持 HRegionServer 的 failure 監(jiān)控烤黍、ZooKeeper 引入作為協(xié)調(diào)者等各種手段來解決 Availability 問題知市，然而當網(wǎng)絡的 Split-Brain(Network Partition) 發(fā)生時，它還是無法完全解決 Availability 的問題速蕊。從這個角度上嫂丙，Cassandra 選擇了A，即它在網(wǎng)絡 Split-Brain 時還是能正常寫规哲，而使用其他技術(shù)來解決 Consistency 的問題跟啤，如讀的時候觸發(fā) Consistency 判斷和處理，這是設計上的限制唉锌。
