轉(zhuan)載自：//www.sysdb.cn/index.php/2016/01/10/hbase_principle/ ，感謝(xie)原作者(zhe)。

簡介

　　HBase —— Hadoop Database的(de)(de)(de)(de)(de)(de)(de)簡稱，Google BigTable的(de)(de)(de)(de)(de)(de)(de)另一種開源實現方式，從問(wen)世之(zhi)初，就為(wei)了解決用(yong)大(da)量廉(lian)價(jia)的(de)(de)(de)(de)(de)(de)(de)機(ji)器高速存(cun)取(qu)(qu)海量數(shu)(shu)(shu)據(ju)(ju)(ju)、實現數(shu)(shu)(shu)據(ju)(ju)(ju)分(fen)布(bu)(bu)(bu)式存(cun)儲(chu)提供可靠(kao)的(de)(de)(de)(de)(de)(de)(de)方案。從功能上(shang)來講，HBase不(bu)(bu)折不(bu)(bu)扣是一個(ge)數(shu)(shu)(shu)據(ju)(ju)(ju)庫(ku)(ku)，與(yu)我們(men)熟悉的(de)(de)(de)(de)(de)(de)(de)Oracle、MySQL、MSSQL等一樣，對外提供數(shu)(shu)(shu)據(ju)(ju)(ju)的(de)(de)(de)(de)(de)(de)(de)存(cun)儲(chu)和讀取(qu)(qu)服務。而(er)(er)從應用(yong)的(de)(de)(de)(de)(de)(de)(de)角(jiao)度來說，HBase與(yu)一般的(de)(de)(de)(de)(de)(de)(de)數(shu)(shu)(shu)據(ju)(ju)(ju)庫(ku)(ku)又(you)有(you)所區別，HBase本身的(de)(de)(de)(de)(de)(de)(de)存(cun)取(qu)(qu)接口相(xiang)當簡單，不(bu)(bu)支持復雜的(de)(de)(de)(de)(de)(de)(de)數(shu)(shu)(shu)據(ju)(ju)(ju)存(cun)取(qu)(qu)，更不(bu)(bu)支持SQL等結(jie)構化(hua)的(de)(de)(de)(de)(de)(de)(de)查詢(xun)(xun)語言；HBase也(ye)沒(mei)有(you)除了rowkey以外的(de)(de)(de)(de)(de)(de)(de)索引，所有(you)的(de)(de)(de)(de)(de)(de)(de)數(shu)(shu)(shu)據(ju)(ju)(ju)分(fen)布(bu)(bu)(bu)和查詢(xun)(xun)都依賴rowkey。所以，HBase在表的(de)(de)(de)(de)(de)(de)(de)設計上(shang)會(hui)有(you)很嚴格(ge)的(de)(de)(de)(de)(de)(de)(de)要求。架構上(shang)，HBase是分(fen)布(bu)(bu)(bu)式數(shu)(shu)(shu)據(ju)(ju)(ju)庫(ku)(ku)的(de)(de)(de)(de)(de)(de)(de)典范，這點(dian)比較像MongoDB的(de)(de)(de)(de)(de)(de)(de)sharding模式，能根據(ju)(ju)(ju)鍵值的(de)(de)(de)(de)(de)(de)(de)大(da)小(xiao)，把數(shu)(shu)(shu)據(ju)(ju)(ju)分(fen)布(bu)(bu)(bu)到不(bu)(bu)同(tong)的(de)(de)(de)(de)(de)(de)(de)存(cun)儲(chu)節點(dian)上(shang)，MongoDB根據(ju)(ju)(ju)configserver來定位數(shu)(shu)(shu)據(ju)(ju)(ju)落在哪個(ge)分(fen)區上(shang)，HBase通過(guo)訪問(wen)Zookeeper來獲取(qu)(qu)-ROOT-表所在地(di)址，通過(guo)-ROOT-表得到相(xiang)應.META.表信息，從而(er)(er)獲取(qu)(qu)數(shu)(shu)(shu)據(ju)(ju)(ju)存(cun)儲(chu)的(de)(de)(de)(de)(de)(de)(de)region位置(zhi)。

架構

　　上面(mian)提(ti)到，HBase是一個分(fen)布(bu)式的(de)架構，除去底層存儲的(de)HDFS外，HBase本(ben)身從功能上可以分(fen)為(wei)三(san)塊：Zookeeper群(qun)、Master群(qun)和(he)RegionServer群(qun)。

• Zookeeper群(qun)：HBase集群(qun)中不可缺少的重要部分，主要用于存儲(chu)Master地址、協調Master和RegionServer等(deng)上下(xia)線、存儲(chu)臨時數據(ju)等(deng)等(deng)。
• Master群：Master主要(yao)是做一(yi)些管理(li)操(cao)作(zuo)，如：region的(de)分配，手動管理(li)操(cao)作(zuo)下發等等，一(yi)般數(shu)據的(de)讀(du)寫操(cao)作(zuo)并(bing)不(bu)需(xu)(xu)要(yao)經過Master集群，所以(yi)Master一(yi)般不(bu)需(xu)(xu)要(yao)很高的(de)配置即可。
• RegionServer群：RegionServer群是真正數(shu)據存儲的地方，每個RegionServer由若干(gan)個region組(zu)成，而一(yi)個region維護了一(yi)定區間rowkey值的數(shu)據，整個結(jie)構(gou)如下圖(tu)：

　　上(shang)圖中，Zookeeper(簡稱ZK)是(shi)一個(ge)集(ji)群(qun)(qun)，通(tong)常有(you)奇數個(ge)ZK服(fu)務組成(cheng)。Master為了服(fu)務可(ke)用性，也建議部(bu)署(shu)成(cheng)集(ji)群(qun)(qun)方式，因為 Master是(shi)整(zheng)個(ge)管(guan)理操作的(de)發(fa)(fa)起(qi)者，如果Master一旦發(fa)(fa)生意外停(ting)機(ji)，整(zheng)個(ge)集(ji)群(qun)(qun)將會無法進行(xing)管(guan)理操作，所以(yi)Master也必須有(you)多個(ge)，當然多個(ge) Master也有(you)主從(cong)(cong)之(zhi)分(fen)，如何區(qu)分(fen)哪(na)(na)個(ge)是(shi)主，哪(na)(na)個(ge)是(shi)從(cong)(cong)？關鍵看哪(na)(na)個(ge)Master能(neng)競(jing)(jing)爭到ZK上(shang)對(dui)應Master目錄(lu)下的(de)鎖，持有(you)該目錄(lu)鎖的(de)Master 為主Master，其他從(cong)(cong)Master輪詢競(jing)(jing)爭該鎖，所以(yi)一旦主Master發(fa)(fa)生意外停(ting)機(ji)，從(cong)(cong)Master很快會因為競(jing)(jing)爭到Master文件(jian)夾上(shang)的(de)鎖而(er)接管(guan)服(fu)務。

　　RegionServer(簡稱RS)在(zai)(zai)非(fei)(fei)Replication模式下(xia)(xia)，整(zheng)個(ge)系統中都是(shi)(shi)唯一的(de)(de)(de)(de)(de)，也就(jiu)是(shi)(shi)說，在(zai)(zai)整(zheng)個(ge)非(fei)(fei)Replication的(de)(de)(de)(de)(de) HBase集群中，每臺(tai)RS上保存(cun)的(de)(de)(de)(de)(de)數(shu)(shu)據都不(bu)一樣，所以(yi)相對于前(qian)面兩(liang)者，該(gai)模式下(xia)(xia)的(de)(de)(de)(de)(de)RS并不(bu)是(shi)(shi)高可用的(de)(de)(de)(de)(de)，至(zhi)少RS可能存(cun)在(zai)(zai)單(dan)點(dian)(dian)故障的(de)(de)(de)(de)(de)問(wen)(wen)題，但是(shi)(shi)由于 HBase內部數(shu)(shu)據分region存(cun)儲和region可以(yi)遷(qian)移的(de)(de)(de)(de)(de)機制(zhi)，RS服務的(de)(de)(de)(de)(de)單(dan)點(dian)(dian)故障可能會在(zai)(zai)極小(xiao)代價下(xia)(xia)很快恢復，但是(shi)(shi)一旦停掉的(de)(de)(de)(de)(de)RS上有(you) -ROOT-或者.META.表的(de)(de)(de)(de)(de)region，那后果(guo)還是(shi)(shi)比較嚴重，因為數(shu)(shu)據節(jie)點(dian)(dian)的(de)(de)(de)(de)(de)RS停機，只會在(zai)(zai)短時間(jian)內影(ying)響該(gai)臺(tai)RS上的(de)(de)(de)(de)(de)region不(bu)可訪問(wen)(wen)，等 到region遷(qian)移完成后即可恢復，如果(guo)是(shi)(shi)-ROOT-、.META.所在(zai)(zai)的(de)(de)(de)(de)(de)RS停機，整(zheng)個(ge)HBase的(de)(de)(de)(de)(de)新的(de)(de)(de)(de)(de)求情都將受到影(ying)響，因為需要通過.META. 表來路(lu)由，從(cong)而尋找到region所在(zai)(zai)RS的(de)(de)(de)(de)(de)地址。

數據組織(zhi)

　　整個架構中，ZK用(yong)(yong)于(yu)服務協(xie)調和(he)整個集群運(yun)行過程中部分信息(xi)的保(bao)存(cun)和(he)-ROOT-表地址(zhi)定位，Master用(yong)(yong)于(yu)集群內部管理，所以(yi)剩下的RS主要用(yong)(yong)于(yu)處理數據。

　　RS是(shi)(shi)處理數(shu)據的(de)(de)主要場所，那(nei)么在RS內部(bu)的(de)(de)數(shu)據是(shi)(shi)怎么分(fen)(fen)(fen)布的(de)(de)？其實(shi)RS本身只(zhi)是(shi)(shi)一(yi)(yi)(yi)個(ge)(ge)容(rong)器(qi)，其定義了一(yi)(yi)(yi)些功(gong)能線(xian)程(cheng)，比如：數(shu)據合并線(xian)程(cheng) (compact thread)、storeFile分(fen)(fen)(fen)割線(xian)程(cheng)(split thread)等等。容(rong)器(qi)中(zhong)的(de)(de)主要對象就是(shi)(shi)region，region是(shi)(shi)一(yi)(yi)(yi)個(ge)(ge)表根據自(zi)身rowkey范圍劃(hua)分(fen)(fen)(fen)的(de)(de)一(yi)(yi)(yi)部(bu)分(fen)(fen)(fen)，一(yi)(yi)(yi)個(ge)(ge)表可(ke)以(yi)(yi)被劃(hua)分(fen)(fen)(fen)成若(ruo)干部(bu)分(fen)(fen)(fen)，也(ye)(ye)就 是(shi)(shi)若(ruo)干個(ge)(ge)region，region可(ke)以(yi)(yi)根據rowkey范圍不(bu)(bu)同(tong)(tong)而被分(fen)(fen)(fen)布在不(bu)(bu)同(tong)(tong)的(de)(de)RS上(shang)(當然(ran)也(ye)(ye)可(ke)以(yi)(yi)在同(tong)(tong)一(yi)(yi)(yi)個(ge)(ge)RS上(shang)，但(dan)不(bu)(bu)建議這么做)。一(yi)(yi)(yi)個(ge)(ge)RS上(shang)可(ke)以(yi)(yi) 包(bao)含(han)多個(ge)(ge)表的(de)(de)region，也(ye)(ye)可(ke)以(yi)(yi)只(zhi)包(bao)含(han)一(yi)(yi)(yi)個(ge)(ge)表的(de)(de)部(bu)分(fen)(fen)(fen)region，RS和(he)表是(shi)(shi)兩個(ge)(ge)不(bu)(bu)同(tong)(tong)的(de)(de)概(gai)念(nian)。

　　這(zhe)里(li)(li)還有(you)一(yi)(yi)(yi)個概念——列(lie)(lie)(lie)簇(cu)(cu)(cu)(cu)(cu)。對HBase有(you)一(yi)(yi)(yi)些了解的(de)(de)人，或多(duo)或少聽(ting)說過(guo)：HBase是(shi)(shi)一(yi)(yi)(yi)個列(lie)(lie)(lie)式(shi)存(cun)(cun)(cun)儲(chu)(chu)(chu)的(de)(de)數(shu)據(ju)(ju)庫，而(er)這(zhe)個列(lie)(lie)(lie)式(shi)存(cun)(cun)(cun)儲(chu)(chu)(chu)中(zhong)的(de)(de)列(lie)(lie)(lie)，其實是(shi)(shi)區別于 一(yi)(yi)(yi)般數(shu)據(ju)(ju)庫的(de)(de)列(lie)(lie)(lie)，這(zhe)里(li)(li)的(de)(de)列(lie)(lie)(lie)的(de)(de)概念，就是(shi)(shi)列(lie)(lie)(lie)簇(cu)(cu)(cu)(cu)(cu)，列(lie)(lie)(lie)簇(cu)(cu)(cu)(cu)(cu)，顧名思(si)義就是(shi)(shi)很多(duo)列(lie)(lie)(lie)的(de)(de)集(ji)合，而(er)在(zai)(zai)數(shu)據(ju)(ju)存(cun)(cun)(cun)儲(chu)(chu)(chu)上(shang)來(lai)講(jiang)，不同列(lie)(lie)(lie)簇(cu)(cu)(cu)(cu)(cu)的(de)(de)數(shu)據(ju)(ju)，一(yi)(yi)(yi)定(ding)(ding)是(shi)(shi)分開存(cun)(cun)(cun)儲(chu)(chu)(chu)的(de)(de)，即使(shi)是(shi)(shi)在(zai)(zai)同一(yi)(yi)(yi)個 region內部，不同的(de)(de)列(lie)(lie)(lie)簇(cu)(cu)(cu)(cu)(cu)也存(cun)(cun)(cun)儲(chu)(chu)(chu)在(zai)(zai)不同的(de)(de)文(wen)件(jian)夾中(zhong)，這(zhe)樣(yang)做的(de)(de)好處是(shi)(shi)，一(yi)(yi)(yi)般我們定(ding)(ding)義列(lie)(lie)(lie)簇(cu)(cu)(cu)(cu)(cu)的(de)(de)時候，通(tong)常(chang)會(hui)把類似的(de)(de)數(shu)據(ju)(ju)放入(ru)同一(yi)(yi)(yi)個列(lie)(lie)(lie)簇(cu)(cu)(cu)(cu)(cu)，不同的(de)(de)列(lie)(lie)(lie)簇(cu)(cu)(cu)(cu)(cu)分開存(cun)(cun)(cun) 儲(chu)(chu)(chu)，有(you)利于數(shu)據(ju)(ju)的(de)(de)壓(ya)縮，并(bing)且(qie)HBase本身支持多(duo)種壓(ya)縮方式(shi)。

原理

　　前面(mian)介紹了HBase的一般架構，我(wo)們(men)知(zhi)道(dao)了HBase有(you)ZK、Master和(he)(he)RS等(deng)組成，本(ben)節(jie)我(wo)們(men)來介紹下HBase的基本(ben)原理，從數據(ju)訪問(wen)、RS路(lu)由到RS內部緩存、數據(ju)存儲和(he)(he)刷寫再到region的合并和(he)(he)拆分等(deng)等(deng)功能。

RegionServer定位(wei)

　　訪問(wen)HBase通過HBase客戶(hu)端(或(huo)API)進行(xing)，整個HBase提供給外部的(de)地址(zhi)，其實是ZK的(de)入(ru)口，前(qian)面也介紹了，ZK中有保存 -ROOT-所在的(de)RS地址(zhi)，從-ROOT-表(biao)可(ke)以獲取(qu).META.表(biao)信息，根據.META.表(biao)可(ke)以獲取(qu)region在RS上的(de)分布，整個region尋 址(zhi)過程大(da)致(zhi)如下(xia)：

1. 首先，Client通過訪問ZK來請求目標數據的地址。
2. ZK中保存了-ROOT-表的地址，所以ZK通過訪問-ROOT-表來請求數據地址。
3. 同樣，-ROOT-表中保存的是.META.的信息，通過訪問.META.表來獲取具體的RS。
4. .META.表查詢到具體RS信息后返回具體RS地址給Client。
5. Client端獲取到目標地址后，然后直接向該地址發送數據請求。

上(shang)述過程其實是一個三層(ceng)索引結(jie)構，從ZK獲(huo)取(qu)-ROOT-信息(xi)，再(zai)從-ROOT-獲(huo)取(qu).META.表信息(xi)，最后從.META.表中查到RS地(di)址后緩(huan)存。這(zhe)里有(you)幾個問題：

• 既然ZK中能保存-ROOT-信息，那么為什么不把.META.信息直接保存在ZK中，而需要通過-ROOT-表來定位？
• Client查找到目標地址后，下一次請求還需要走ZK –> -ROOT- –>.META.這個流程么？

　　先來回答第(di)一(yi)個(ge)問(wen)題(ti)：為什么不直接(jie)把(ba).META.表(biao)(biao)信(xin)息直接(jie)保存(cun)(cun)到ZK中(zhong)(zhong)？主要是為了保存(cun)(cun)的數(shu)據量考慮，ZK中(zhong)(zhong)不宜保存(cun)(cun)大量數(shu)據，而.META.表(biao)(biao) 主要是保存(cun)(cun)Region和RS的映射信(xin)息，region的數(shu)量沒有具體(ti)約束，只要在內存(cun)(cun)允許的范圍內，region數(shu)量可(ke)以有很(hen)多(duo)，如果保存(cun)(cun)在ZK 中(zhong)(zhong)，ZK的壓力(li)會(hui)很(hen)大。所(suo)以，通過一(yi)個(ge)-ROOT-表(biao)(biao)來轉(zhuan)存(cun)(cun)到RS中(zhong)(zhong)是一(yi)個(ge)比(bi)較理想的方案，相比(bi)直接(jie)保存(cun)(cun)在ZK中(zhong)(zhong)，也(ye)就(jiu)多(duo)了一(yi)層-ROOT-表(biao)(biao)的查(cha)詢，對 性能來說影響不大。

　　第二個(ge)問(wen)(wen)題(ti)：每(mei)(mei)次訪(fang)(fang)問(wen)(wen)都需要(yao)走ZK –> -ROOT- —> .META.的流(liu)(liu)程么？當(dang)然(ran)不需要(yao)，Client端有緩(huan)存(cun)(cun)，第一(yi)(yi)次查詢到相應region所(suo)在(zai)RS后(hou)(hou)，這(zhe)個(ge)信息將被(bei)緩(huan)存(cun)(cun)到Client端，以(yi)后(hou)(hou)每(mei)(mei)次訪(fang)(fang)問(wen)(wen)都 直接從緩(huan)存(cun)(cun)中(zhong)獲(huo)(huo)取(qu)RS地(di)(di)址即可。當(dang)然(ran)這(zhe)里(li)有個(ge)意外：訪(fang)(fang)問(wen)(wen)的region若果在(zai)RS上發生了(le)(le)改變，比如(ru)被(bei)balancer遷移到其他RS上了(le)(le)，這(zhe)個(ge)時候，通 過緩(huan)存(cun)(cun)的地(di)(di)址訪(fang)(fang)問(wen)(wen)會(hui)出現異(yi)常，在(zai)出現異(yi)常的情況下，Client需要(yao)重新(xin)走一(yi)(yi)遍(bian)上面的流(liu)(liu)程來(lai)獲(huo)(huo)取(qu)新(xin)的RS地(di)(di)址。總體來(lai)說，region的變動只會(hui)在(zai)極少數 情況下發生，一(yi)(yi)般變動不會(hui)很大(da)，所(suo)以(yi)在(zai)整個(ge)集群(qun)訪(fang)(fang)問(wen)(wen)過程中(zhong)，影響可以(yi)忽略。

Region數據(ju)寫入

　　HBase通過ZK –> -ROOT- –>.META.的訪(fang)問(wen)獲(huo)取RS地址后，直接向(xiang)該(gai)RS上進行數據寫入(ru)操(cao)作，整個過程如下(xia)圖：

　　Client通過三(san)層索引(yin)獲(huo)得RS的(de)(de)地址后(hou)，即可向指(zhi)定RS的(de)(de)對應region進行數(shu)(shu)據(ju)寫(xie)入(ru)，HBase的(de)(de)數(shu)(shu)據(ju)寫(xie)入(ru)采用WAL(write ahead log)的(de)(de)形式，先寫(xie)log，后(hou)寫(xie)數(shu)(shu)據(ju)。HBase是一個append類型的(de)(de)數(shu)(shu)據(ju)庫，沒(mei)有(you)關(guan)系型數(shu)(shu)據(ju)庫那么復雜的(de)(de)操(cao)作(zuo)(zuo)，所以記錄HLog的(de)(de)操(cao)作(zuo)(zuo)都(dou)(dou)是簡(jian)單(dan)的(de)(de) put操(cao)作(zuo)(zuo)(delete/update操(cao)作(zuo)(zuo)都(dou)(dou)被轉(zhuan)化為(wei)put進行)

HLog

HLog寫(xie)入

　　HLog是(shi)HBase實現WAL方式(shi)產(chan)生的(de)日志信(xin)息(xi)，其(qi)內(nei)部是(shi)一(yi)個簡(jian)單的(de)順序(xu)日志，每個RS上的(de)region都共享一(yi)個HLog，所有(you)對于該RS上的(de) region數據(ju)寫入(ru)都被(bei)記錄到該HLog中。HLog的(de)主(zhu)要作(zuo)用(yong)就是(shi)在RS出(chu)現意(yi)外崩潰(kui)的(de)時候，可以盡量多的(de)恢復數據(ju)，這里說是(shi)盡量多，因為(wei)在一(yi)般(ban)情況 下，客戶端為(wei)了提高性能，會(hui)把HLog的(de)auto flush關掉，這樣HLog日志的(de)落(luo)盤(pan)全靠操作(zuo)系統保(bao)證，如果(guo)出(chu)現意(yi)外崩潰(kui)，短時間內(nei)沒有(you)被(bei)fsync的(de)日志會(hui)被(bei)丟失。

HLog過(guo)期(qi)

　　HLog的(de)大量(liang)寫入(ru)會造成HLog占用存儲空間會越來越大，HBase通過(guo)HLog過(guo)期(qi)(qi)的(de)方式進(jin)(jin)行HLog的(de)清理，每個RS內(nei)部都有一個HLog監(jian)控線程(cheng)在運(yun)行，其周期(qi)(qi)可(ke)以通過(guo)hbase.master.cleaner.interval進(jin)(jin)行配置。

　　HLog在數據從memstore flush到(dao)底層存儲上后，說明該(gai)段HLog已經不再(zai)被(bei)需要，就會被(bei)移動(dong)到(dao).oldlogs這個目錄下，HLog監(jian)控(kong)線程監(jian)控(kong)該(gai)目錄下的HLog，當(dang)該(gai)文 件夾下的HLog達(da)到(dao)hbase.master.logcleaner.ttl設置(zhi)的過期條件后，監(jian)控(kong)線程立即(ji)刪除過期的HLog。

Memstore

數據存儲

　　memstore是region內部緩存，其(qi)大(da)小通過HBase參數(shu)hbase.hregion.memstore.flush.size進(jin)行(xing)配 置。RS在寫完(wan)HLog以(yi)后，數(shu)據寫入的(de)下一個目標就是region的(de)memstore，memstore在HBase內部通過LSM-tree結構組 織，所以(yi)能夠(gou)合并(bing)大(da)量(liang)對于相同rowkey上的(de)更新操(cao)作(zuo)。

　　正是由(you)于(yu)memstore的(de)存在，HBase的(de)數(shu)據(ju)寫(xie)入(ru)都是異步的(de)，而(er)且性能非常不錯(cuo)，寫(xie)入(ru)到memstore后，該次寫(xie)入(ru)請求(qiu)就可以(yi)被返(fan) 回，HBase即認為該次數(shu)據(ju)寫(xie)入(ru)成(cheng)功。這里有一點需要說明，寫(xie)入(ru)到memstore中的(de)數(shu)據(ju)都是預先按照rowkey的(de)值進行排序的(de)，這樣有利(li)于(yu)后續數(shu) 據(ju)查找。

數據(ju)刷盤

　　Memstore中的(de)數據在一定條(tiao)件下(xia)會進行刷(shua)寫操作，使數據持久化(hua)到相(xiang)應的(de)存儲設(she)備上，觸(chu)發(fa)memstore刷(shua)盤的(de)操作有多種不同的(de)方式如下(xia)圖：

　　以上1,2,3都可以觸發(fa)memstore的flush操作(zuo)，但是實(shi)現的方(fang)式不同(tong)：

• 1通過(guo)全局(ju)內存控(kong)制，觸發memstore刷盤操作(zuo)。

　　　　在該種情況下(xia)，RS中所有region的(de)(de)memstore內存(cun)占(zhan)用都沒達到(dao)刷(shua)盤條件，但整體的(de)(de)內存(cun)消耗(hao)已經(jing)到(dao)一(yi)個非(fei)常(chang)危險(xian)的(de)(de)范圍，如果持(chi)續下(xia)去，很(hen)有可能造成(cheng)RS的(de)(de)OOM，這(zhe)個時候，需要進行memstore的(de)(de)刷(shua)盤，從而釋放內存(cun)。

　　memstore整(zheng)體內存占用上限(xian)通(tong)過參(can)數hbase.regionserver.global.memstore.upperLimit進行設 置，當然在達到(dao)上限(xian)后，memstore的刷(shua)寫也不是(shi)一直進行，在內存下降到(dao) hbase.regionserver.global.memstore.lowerLimit配置的值(zhi)后，即停止memstore的刷(shua)盤操作。這樣做(zuo)， 主要是(shi)為了防止長時(shi)間的memstore刷(shua)盤，會影(ying)響整(zheng)體的性(xing)能。

• 2手動觸發memstore刷盤操作(zuo)

　　　　HBase提供(gong)API接口(kou)，運行(xing)通(tong)過外部調(diao)用進行(xing)memstore的(de)刷盤

• 3 memstore上限觸發數據刷(shua)盤(pan)

　　　　前面提到(dao)memstore的大小通過(guo)hbase.hregion.memstore.flush.size進行(xing)設置(zhi)，當(dang)region中memstore的數據(ju)量達到(dao)該值時(shi)，會自動(dong)觸發memstore的刷盤(pan)操作。

刷盤影響

　　memstore在(zai)不同的條件下會觸發數(shu)據(ju)刷盤，那(nei)么整個數(shu)據(ju)在(zai)刷盤過(guo)程中，對region的數(shu)據(ju)寫入等有什(shen)么影響？

　　memstore的數(shu)據刷盤，對(dui)region的直(zhi)接影響就是(shi)：在(zai)數(shu)據刷盤開始到(dao)結束這段時(shi)間內，該region上的訪問都是(shi)被(bei)拒絕的，這里主(zhu)要是(shi)因 為在(zai)數(shu)據刷盤結束時(shi)，RS會對(dui)改region做(zuo)一個snapshot，同時(shi)HLog做(zuo)一個checkpoint操作(zuo)，通知(zhi)ZK哪些HLog可以被(bei)移 到(dao).oldlogs下。從前面圖上也可以看到(dao)，在(zai)memstore寫(xie)盤開始，相(xiang)應region會被(bei)加上UpdateLock鎖，寫(xie)盤結束后該鎖被(bei)釋放(fang)。

StoreFile

　　memstore在(zai)(zai)觸發刷(shua)盤操作后會(hui)被(bei)寫(xie)入底層(ceng)存儲，每(mei)次memstore的(de)(de)刷(shua)盤就會(hui)相應生(sheng)成一個存儲文件(jian)HFile，storeFile即HFile在(zai)(zai)HBase層(ceng)的(de)(de)輕量級分裝。

　　數據(ju)量(liang)的(de)(de)持續寫(xie)入，造成memstore的(de)(de)頻繁flush，每次flush都會產(chan)生(sheng)一個HFile，這樣(yang)底層存儲設(she)備上的(de)(de)HFile文(wen)(wen)(wen)件(jian)數量(liang)將會越(yue) 來(lai)越(yue)多(duo)。不管是HDFS還是Linux下常(chang)用的(de)(de)文(wen)(wen)(wen)件(jian)系統如Ext4、XFS等，對小而多(duo)的(de)(de)文(wen)(wen)(wen)件(jian)上的(de)(de)管理(li)都沒(mei)有大文(wen)(wen)(wen)件(jian)來(lai)的(de)(de)有效，比如小文(wen)(wen)(wen)件(jian)打開需要消耗(hao)更多(duo) 的(de)(de)文(wen)(wen)(wen)件(jian)句柄；在大量(liang)小文(wen)(wen)(wen)件(jian)中進(jin)行指(zhi)定rowkey數據(ju)的(de)(de)查(cha)(cha)詢(xun)(xun)性能沒(mei)有在少量(liang)大文(wen)(wen)(wen)件(jian)中查(cha)(cha)詢(xun)(xun)來(lai)的(de)(de)快等等。

Compact

　　大(da)量HFile的產(chan)生(sheng)，會(hui)消耗更多(duo)的文件句柄，同時會(hui)造成RS在(zai)數據查詢(xun)等的效率大(da)幅度下降(jiang)，HBase為(wei)解決這個問(wen)題，引入(ru)了compact操作(zuo)，RS通過(guo)compact把大(da)量小的HFile進(jin)行文件合并，生(sheng)成大(da)的HFile文件。

　　RS上的(de)compact根據(ju)功能(neng)的(de)不(bu)同，可以分為兩種(zhong)不(bu)同類型，即：minor compact和major compact。

• Minor Compact

　　　　minor compact又叫(jiao)small compact，在RS運行過(guo)程中會頻繁進(jin)行，主要通過(guo)參(can)(can)數(shu)hbase.hstore.compactionThreshold進(jin)行控制，該參(can)(can)數(shu)配置了 HFile數(shu)量(liang)在滿足該值時，進(jin)行minor compact，minor compact只(zhi)選取region下部分HFile進(jin)行compact操作(zuo)，并且(qie)選取的(de)HFile大小不能超過(guo) hbase.hregion.max.filesize參(can)(can)數(shu)設置。

• Major Compact

　　　　相反major compact也(ye)被(bei)稱(cheng)之為(wei)large compact，major compact會對整個(ge)region下相同(tong)列(lie)簇(cu)的(de)(de)(de)所有HFile進行compact，也(ye)就是(shi)說major compact結束后，同(tong)一個(ge)列(lie)簇(cu)下的(de)(de)(de)HFile會被(bei)合并成(cheng)一個(ge)。major compact是(shi)一個(ge)比較長的(de)(de)(de)過程，對底(di)層I/O的(de)(de)(de)壓力相對較大。

　　　　major compact除了合并HFile外(wai)，另外(wai)一個重(zhong)要(yao)功能(neng)(neng)就是(shi)清理(li)(li)過(guo)(guo)期或者被刪除的數據。前面提(ti)到過(guo)(guo)，HBase的delete操作也是(shi)通過(guo)(guo)append的 方式(shi)寫(xie)入，一旦(dan)某(mou)些數據在HBase內(nei)(nei)部(bu)被刪除了，在內(nei)(nei)部(bu)只(zhi)是(shi)被簡(jian)單標記(ji)為刪除，真正(zheng)在存儲層面沒有進行(xing)數據清理(li)(li)，只(zhi)有通過(guo)(guo)major compact對HFile進行(xing)重(zhong)組(zu)時(shi)，被標記(ji)為刪除的數據才能(neng)(neng)被真正(zheng)的清理(li)(li)。

　　　　compact操(cao)(cao)(cao)作都有特定(ding)(ding)的線程進(jin)行，一(yi)般情況下不(bu)會影響RS上(shang)數據寫入的性能，當(dang)然也有例外：在(zai)compact操(cao)(cao)(cao)作速度跟(gen)不(bu)上(shang)region中 HFile增長速度時(shi)，為了(le)安全考慮，RS會在(zai)HFile達(da)到一(yi)定(ding)(ding)數量時(shi)，對寫入進(jin)行鎖定(ding)(ding)操(cao)(cao)(cao)作，直到HFile通(tong)過compact降(jiang)到一(yi)定(ding)(ding)的范圍內(nei)才釋(shi)放(fang) 鎖。

Split

　　compact將多個HFile合(he)并單個HFile文(wen)件，隨著(zhu)數(shu)據(ju)(ju)(ju)量的(de)不斷(duan)寫入，單個HFile也會(hui)(hui)越來(lai)越大(da)(da)，大(da)(da)量小的(de)HFile會(hui)(hui)影(ying)響數(shu)據(ju)(ju)(ju)查(cha)詢(xun)性 能，大(da)(da)的(de)HFile也會(hui)(hui)，HFile越大(da)(da)，相對的(de)在HFile中搜(sou)索的(de)指定rowkey的(de)數(shu)據(ju)(ju)(ju)花的(de)時間也就越長，HBase同(tong)樣(yang)提(ti)供了region的(de) split方(fang)案來(lai)解決大(da)(da)的(de)HFile造成數(shu)據(ju)(ju)(ju)查(cha)詢(xun)時間過長問(wen)題(ti)。

　　一個較(jiao)大的(de)region通(tong)過split操(cao)作，會生(sheng)成兩(liang)個小的(de)region，稱(cheng)之(zhi)為Daughter，一般Daughter中的(de)數(shu)據是根據rowkey的(de)之(zhi)間(jian)點進行切分的(de)，region的(de)split過程大致如下圖：

1. region先(xian)更改ZK中該region的狀(zhuang)態為(wei)SPLITING。
2. Master檢測到(dao)region狀(zhuang)態(tai)改(gai)變(bian)。
3. region會(hui)在存儲(chu)目錄下新(xin)建.split文(wen)件夾(jia)用于保存split后的daughter region信息。
4. Parent region關(guan)閉數據寫(xie)入并(bing)觸發flush操作(zuo)，保證(zheng)所有寫(xie)入Parent region的數據都能持(chi)久化。
5. 在.split文件夾下新建兩個(ge)region，稱之為daughter A、daughter B。
6. Daughter A、Daughter B拷貝(bei)到HBase根目錄下，形(xing)成(cheng)兩個新的region。
7. Parent region通知修改.META.表后下(xia)線，不再提供(gong)服(fu)務。
8. Daughter A、Daughter B上線，開始向(xiang)外提供服務(wu)。
9. 如(ru)果開啟了balance_switch服務，split后的(de)region將(jiang)會被重新分布。

上(shang)面1 ~ 9就是(shi)region split的(de)整個過程(cheng)，split過程(cheng)非常快，速度基本(ben)會在(zai)秒(miao)級內，那么(me)在(zai)這么(me)快的(de)時間內，region中的(de)數據怎么(me)被(bei)重新組織(zhi)的(de)？

其(qi)實，split只(zhi)是簡(jian)單的(de)(de)把region從邏輯上劃分成(cheng)兩個，并沒(mei)有涉及到(dao)底層數(shu)據的(de)(de)重組，split完(wan)成(cheng)后(hou)，Parent region并沒(mei)有被(bei)銷毀(hui)，只(zhi)是被(bei)做(zuo)下(xia)線處理，不再(zai)對外(wai)部提供服(fu)務。而新產(chan)生(sheng)的(de)(de)region Daughter A和Daughter B，內(nei)部的(de)(de)數(shu)據只(zhi)是簡(jian)單的(de)(de)到(dao)Parent region數(shu)據的(de)(de)索(suo)引(yin)，Parent region數(shu)據的(de)(de)清(qing)理在Daughter A和Daughter B進行major compact以后(hou)，發現已經沒(mei)有到(dao)其(qi)內(nei)部數(shu)據的(de)(de)索(suo)引(yin)后(hou)，Parent region才會被(bei)真正的(de)(de)清(qing)理。

HBase設計

　　HBase是(shi)(shi)一個分(fen)布式數據庫，其性(xing)能的(de)好壞主(zhu)要(yao)取決于內部表的(de)設計和資源的(de)分(fen)配是(shi)(shi)否(fou)合(he)理。

表的(de)設計

Rowkey設計

　　rowkey是HBase實(shi)現分(fen)(fen)布(bu)式的(de)基礎，HBase通過(guo)rowkey范圍(wei)劃分(fen)(fen)不(bu)同的(de)region，分(fen)(fen)布(bu)式系(xi)統(tong)的(de)基本要(yao)求就是在任何(he)時候，系(xi)統(tong)的(de) 訪(fang)問都不(bu)要(yao)出現明顯的(de)熱點現象，所以(yi)(yi)rowkey的(de)設計至關重(zhong)要(yao)，一般我(wo)們建議rowkey的(de)開始部(bu)分(fen)(fen)以(yi)(yi)hash或(huo)者(zhe)MD5進行散列，盡量(liang)做到 rowkey的(de)頭部(bu)是均勻分(fen)(fen)布(bu)的(de)。禁止采用(yong)(yong)時間、用(yong)(yong)戶id等明顯有分(fen)(fen)段(duan)現象的(de)標志(zhi)直(zhi)接當(dang)作(zuo)rowkey來(lai)使用(yong)(yong)。

列簇設(she)計(ji)

　　HBase的(de)表(biao)設計(ji)(ji)(ji)時，根據不(bu)同(tong)需求有不(bu)同(tong)選(xuan)擇，需要做(zuo)在線(xian)查(cha)詢的(de)數據表(biao)，盡量不(bu)要設計(ji)(ji)(ji)多(duo)個列(lie)(lie)簇(cu)(cu)，我們知道，不(bu)同(tong)的(de)列(lie)(lie)簇(cu)(cu)在存(cun)儲上(shang)是(shi)被(bei)分開(kai)的(de)，多(duo)列(lie)(lie)簇(cu)(cu)設計(ji)(ji)(ji)會造成在數據查(cha)詢的(de)時候讀取更多(duo)的(de)文件(jian)，從而消耗更多(duo)的(de)I/O。

TTL設計

　　選擇合適的數(shu)(shu)據過(guo)(guo)(guo)期時間也是表(biao)設計中需要注意(yi)的一(yi)點，HBase中允許列簇定義(yi)數(shu)(shu)據過(guo)(guo)(guo)期時間，數(shu)(shu)據一(yi)旦超過(guo)(guo)(guo)過(guo)(guo)(guo)期時間，可以被major compact進行清理。大(da)量無用歷史數(shu)(shu)據的殘余，會造(zao)成region體積增大(da)，影響查(cha)詢(xun)效(xiao)率。

Region設計

　　一般地，region不宜設(she)計成很(hen)大(da)，除(chu)非(fei)應用對階(jie)段性(xing)性(xing)能要求很(hen)多(duo)，但(dan)是(shi)在將來運(yun)行(xing)一段時間(jian)(jian)可以(yi)接受停服處理。region過(guo)大(da)會導致(zhi)major compact調用的周期變長(chang)，而(er)單(dan)次major compact的時間(jian)(jian)也相應變長(chang)。major compact對底層I/O會造成壓力，長(chang)時間(jian)(jian)的compact操作可能會影響數據的flush，compact的周期變長(chang)會導致(zhi)許多(duo)刪(shan)除(chu)或(huo)者(zhe)過(guo)期的數據 不能被及時清理，對數據的讀取速度(du)等都有影響。

　　相反，小(xiao)的region意味(wei)著major compact會相對頻繁，但是(shi)由于region比較(jiao)小(xiao)，major compact的相對時間較(jiao)快(kuai)，而(er)且相對較(jiao)多的major compact操作，會加速過期數據(ju)的清理。

　　當然，小region的(de)(de)設(she)計(ji)意味著更多(duo)的(de)(de)region split風險，region容量過(guo)(guo)小，在數(shu)據量達到上限后，region需(xu)要進(jin)行split來拆分，其實split操作在整個HBase運行過(guo)(guo)程中，是 被不怎么希(xi)望出現的(de)(de)，因為(wei)一(yi)旦(dan)發生split，涉及(ji)到數(shu)據的(de)(de)重組(zu)，region的(de)(de)再分配等一(yi)系列問題(ti)。所以我們在設(she)計(ji)之初就需(xu)要考慮到這些(xie)問題(ti)，盡(jin)量避免 region的(de)(de)運行過(guo)(guo)程中發生split。

　　HBase可以通過(guo)在表創建(jian)的(de)(de)時候(hou)進行region的(de)(de)預(yu)分(fen)配來解決運行過(guo)程中(zhong)region的(de)(de)split產生，在表設計的(de)(de)時候(hou)，預(yu)先分(fen)配足夠多的(de)(de) region數(shu)，在region達到上(shang)限(xian)前(qian)，至少(shao)有部分(fen)數(shu)據(ju)會過(guo)期(qi)，通過(guo)major compact進行清(qing)理后， region的(de)(de)數(shu)據(ju)量始(shi)終維持在一(yi)個平衡狀態。

　　region數(shu)量的設計還需要考(kao)慮內(nei)存上(shang)的限制，通過前面的介紹我們知(zhi)道每個region都有memstore，memstore的數(shu)量與region數(shu)量和region下列簇的數(shu)量成(cheng)正比：

　　一個(ge)RS下memstore內(nei)存消耗：

　　　　Memory = memstore大小 * region數量 * 列簇(cu)數量

　　如(ru)果不進行前期數(shu)據量估(gu)算和region的預分配，通過不斷(duan)的split產生新的region，容易(yi)導致因為內存不足而出現(xian)OOM現(xian)象。

參(can)考

　　//blog.csdn.net/yangjinming24/article/details/51918132

　　//blog.csdn.net/woshiwanxin102213/article/details/17584043

　　//blog.csdn.net/FrankieWang008/article/details/41965543

　　//lxw1234.com/archives/2016/09/719.htm