現(xiàn)如今，人們對(duì)基于HBase的產(chǎn)品的讀寫速度要求越來越高。在理想情況下，人們希望HBase 可以在保證其可靠的持久存儲(chǔ)的前提下能并擁有內(nèi)存數(shù)據(jù)讀寫的速度。為此，在HBase2.0中引入Accordion算法。

Hbase RegionServer 負(fù)責(zé)將數(shù)據(jù)劃分到多個(gè)Region中。RegionServer 內(nèi)部（垂直）的可伸縮性能對(duì)于最終用戶體驗(yàn)以及整個(gè)系統(tǒng)的利用率至關(guān)重要。Accordion 算法通過提高對(duì)RAM利用來提升RegionServer擴(kuò)展性。這樣就使得內(nèi)存中可以存放更多數(shù)據(jù)，從而降低了對(duì)磁盤的讀取頻率(即降低了HBase中磁盤占用和寫入方法，更多的讀寫RAM，降低了對(duì)于磁盤的IO訪問）。在HBase2.0之前，這些指標(biāo)是不能同時(shí)滿足的，并且相互限制，在引入Accordion之后，這一狀況得到了改善。

[[228381]]

Accordion算法來源于HBase核心架構(gòu)LSM算法。在HBase Region 中，數(shù)據(jù)是按照key-value形式映射為可查找的存放，其中put進(jìn)來的新數(shù)據(jù)以及一些topmost（靠前）數(shù)據(jù)存放在內(nèi)存中（MemStore），其余的為不變的HDFS文件，即HFile。當(dāng)MemStore寫滿時(shí)，數(shù)據(jù)被flush到硬盤里，生成新的HFile文件。HBase采用多版本并發(fā)控制，MemStore將所有修改后的數(shù)據(jù)存儲(chǔ)為獨(dú)立版本。一條數(shù)據(jù)的多個(gè)版本可能同時(shí)存儲(chǔ)在MemStore和HFile中。當(dāng)讀取一條多版本數(shù)據(jù)時(shí)，根據(jù)key從HBase掃描BlockCache中的HFile獲取最新的版本數(shù)據(jù)。為了降低對(duì)磁盤的訪問頻率，HFiles在后臺(tái)合并（即壓縮過程，刪除多余的cells，創(chuàng)建更大的文件）。

LSM通過將隨機(jī)讀寫轉(zhuǎn)換為順序讀寫，從而提高了寫入性能。之前的設(shè)計(jì)并未采用壓縮內(nèi)存數(shù)據(jù)，主要原因是在LSM樹設(shè)計(jì)當(dāng)初，RAM還是非常緊缺的資源，因此MemStore的容量很小。隨著硬件不斷提升，RegionServer管理的整個(gè)MemStore可能為數(shù)千兆字節(jié)，這就為HBase優(yōu)化留下了大量空間。

Accordion算法重新將LSM應(yīng)用于MemStore，以便當(dāng)數(shù)據(jù)仍在RAM中時(shí)可以消除冗余和其他開銷。這樣做可以減少flush到HDFS的頻率，從而降低了寫入放大和磁盤占用。 隨著flush次數(shù)的減少，MemStore寫入磁盤的頻率會(huì)降低，進(jìn)而提高HBase寫入性能。磁盤上的數(shù)據(jù)較少也意味著對(duì)塊緩存的壓力較小，提高了讀取的響應(yīng)時(shí)間。最終，減少對(duì)磁盤寫入也意味著在后臺(tái)壓縮次數(shù)降低，即讀取和寫入周期將縮短?？偠灾?，內(nèi)存壓縮算法的效果可以被看作是一個(gè)催化劑，它使整個(gè)系統(tǒng)的運(yùn)行速度更快。

目前Accordion提供了兩個(gè)級(jí)別的內(nèi)存壓縮：basic 級(jí)別和 eager 級(jí)別。前者適用于所有數(shù)據(jù)更新的優(yōu)化，后者對(duì)于高數(shù)據(jù)流的應(yīng)用非常有用，如生產(chǎn)-消費(fèi)隊(duì)列，購物車，共享計(jì)數(shù)器等。所有這些使用案例都會(huì)對(duì)rowkey進(jìn)行頻繁更新，生成多個(gè)冗余版本的數(shù)據(jù)，這些情況下Accordion算法將發(fā)揮其價(jià)值。但另一方面，eager 級(jí)壓縮優(yōu)化可能會(huì)增加計(jì)算開銷（更多內(nèi)存副本和垃圾收集），這可能會(huì)影響數(shù)據(jù)寫入的響應(yīng)時(shí)間。如果MemStore使用堆內(nèi)MemStore-本地分配緩沖區(qū)（MSLAB），這會(huì)導(dǎo)致開銷增大。所以建議不要將此配置與eager級(jí)壓縮結(jié)合使用。

如何使用

內(nèi)存壓縮可以在全局和列族級(jí)別配置。目前支持三種級(jí)別配置：none（傳統(tǒng)實(shí)現(xiàn)），basic和eager。默認(rèn)情況下，所有表都是basic內(nèi)存壓縮。此配置可以在hbase-site.xml中修改，如下所示：

<property> 
        <name> hbase.hregion.compacting.memstore.type </name> 
        <value> <none|basic|eager> </value> 
</property> 

也可在HBase shell中為每個(gè)列族進(jìn)行單獨(dú)配置，如下所示：

create '<tablename>'， 
    {NAME =>'<cfname>'， 
    IN_MEMORY_COMPACTION =>' <NONE|BASIC|EAGER>' } 

性能提高

通過利用YCSB（Yahoo Cloud Service Benchmark）對(duì)HBase進(jìn)行了全面測試。試驗(yàn)中采用數(shù)據(jù)集大小為100-200 GB，結(jié)果表明Accordion算法對(duì)于HBase性能有顯著的提升。

Heavy-tailed (Zipf)分布：在測試負(fù)載中國，rowkey遵循大多數(shù)現(xiàn)實(shí)生活場景中出現(xiàn)的Zipf分布。在這種情況下，當(dāng)100％的操作是寫入操作時(shí)，Accordion實(shí)現(xiàn)寫入放大率降低30％，寫入吞吐量提高20％，GC降低22％。當(dāng)50％的操作是讀取時(shí)，tail讀取延遲降低12％。

均勻分布：第二個(gè)測試中rowkey都均衡分布。當(dāng)100％的操作是寫入操作時(shí)，Accordion的寫入放大率降低25％，寫入吞吐量提高50％，GC降低36％。tail讀取延遲不受影響（由于沒有本地化）。

Accordion如何工作

High Level設(shè)計(jì)：

Accordion引入了MemStore的內(nèi)部壓縮（CompactingMemStore）實(shí)現(xiàn)方法。與默認(rèn)的MemStore相比，Accordion將所有數(shù)據(jù)保存在一個(gè)整的數(shù)據(jù)結(jié)構(gòu)中用segment來管理。最新的segment，稱為active segment，是可變的，可用來接收Put操作，若active segment達(dá)到overflow條件（默認(rèn)情況下32MB，MemStore的25%大?。鼈儗?huì)被移到in-memory pipeline 中，并設(shè)為不可變segment，我們稱這一過程為in-memory flush。Get操作通過掃描這些 segment和HFiles 取數(shù)據(jù)（后者操作通過塊緩存進(jìn)行訪問，與平常訪問HBase一樣）。

CompactingMemStore 可能會(huì)不時(shí)在后臺(tái)合并多個(gè)不可變segment，從而形成更大的segment。因此，pipeline是“會(huì)呼吸的”（擴(kuò)張和收縮），類似于手風(fēng)琴波紋管，所以我們也將Accordion 譯為手風(fēng)琴。

當(dāng)RegionServer 刷入一個(gè)或多個(gè)MemStore到磁盤釋放內(nèi)存時(shí)，它會(huì)刷入 CompactingMemStore中已經(jīng)移入pipeline中的segment到磁盤?；驹硎茄娱LMemStore有效管理內(nèi)存的生命周期，以減少整體I/O。當(dāng)flush發(fā)生時(shí)，pipeline中所有的segment 段將被移出合成一個(gè)快照， 通過合并和流式傳輸形成新的HFile。圖1展示了CompactingMemStore與傳統(tǒng)設(shè)計(jì)的結(jié)構(gòu)。

圖1. CompactingMemStore與DefaultMemStore

Segment結(jié)構(gòu)：

與默認(rèn)的MemStore類似，CompactingMemStore在單元存儲(chǔ)之上維護(hù)一個(gè)索引，這樣可以通過key快速搜索。兩者不同的是，MemStore索引實(shí)現(xiàn)是通過Java skiplist （ConcurrentSkipListMap--一種動(dòng)態(tài)但奢侈的數(shù)據(jù)結(jié)構(gòu)）管理大量小對(duì)象。CompactingMemStore 則在不可變的segment 索引之上實(shí)現(xiàn)了高效且節(jié)省空間的扁平化布局。這種優(yōu)化可以幫助所有壓縮策略減少RAM開銷，甚至可以使數(shù)據(jù)幾乎不存在冗余。當(dāng)將一個(gè)Segment加入pipeline中，CompactingMemStore 就將其索引序列化為一個(gè)名為CellArrayMap 的有序數(shù)組，該數(shù)組可以快速進(jìn)行二進(jìn)制搜索。

CellArrayMap既支持從Java堆內(nèi)直接分配單元，也支持MSLAB的自定義分配（堆內(nèi)或堆外），實(shí)現(xiàn)差異通過被索引引用的KeyValue對(duì)象抽象出來（圖2）。CellArrayMap本身始終分配在堆內(nèi)。

圖2.具有扁平CellArrayMap索引和MSLAB單元存儲(chǔ)的不可變Segment

壓縮算法：

內(nèi)存中壓縮算法在pipeline中的Segment上維護(hù)了一個(gè)單一的扁平化索引。這樣的設(shè)計(jì)節(jié)省了存儲(chǔ)空間，尤其是當(dāng)數(shù)據(jù)項(xiàng)很小時(shí)，可以及時(shí)將數(shù)據(jù)刷入磁盤。單個(gè)索引可使搜索操作在單一空間進(jìn)行，因此縮短了tail讀取延遲。

當(dāng)一個(gè)active segment被刷新到內(nèi)存時(shí)，它將排列到壓縮pipeline中，并會(huì)立即觸發(fā)一個(gè)異步合并調(diào)度任務(wù)。該調(diào)度任務(wù)將同時(shí)掃描pipeline中的所有Segment（類似于磁盤上的壓縮）并將它們的索引合并為一個(gè)。basic和eager 壓縮策略之間的差異體現(xiàn)在它們處理單元數(shù)據(jù)的方式上。basic壓縮不會(huì)消除冗余數(shù)據(jù)版本以避免物理復(fù)制，它只是重新排列KeyValue對(duì)象的引用。eager壓縮則相反，它會(huì)過濾出冗余數(shù)據(jù)，但這是以額外的計(jì)算和數(shù)據(jù)遷移為代價(jià)的。例如，在MSLAB存儲(chǔ)器中，surviving 單元被復(fù)制到新創(chuàng)建的MSLAB中。

未來的壓縮可能會(huì)在basic壓縮策略和eager壓縮策略之間實(shí)現(xiàn)自動(dòng)選擇。例如，該算法可能會(huì)在一段時(shí)間內(nèi)嘗試eager壓縮，并根據(jù)所傳遞的值（如：數(shù)據(jù)被刪除的比例）安排下一次壓縮。這種方法可以減輕系統(tǒng)管理員的先驗(yàn)決定，并適應(yīng)不斷變化的訪問模式。