Labs 導(dǎo)讀

HBase是一種分布式的、面向列的開源數(shù)據(jù)庫，底層基于LSM樹構(gòu)建實(shí)現(xiàn)，通過順序?qū)懖僮?，寫性能大幅提升，讀取時需要將內(nèi)存中的數(shù)據(jù)和磁盤中的數(shù)據(jù)合并，犧牲了一部分讀性能，適用于寫多讀少的場景。

Part 01、 讀寫流程  

RegionServer是HBase系統(tǒng)中最核心的組件，主要負(fù)責(zé)用戶數(shù)據(jù)寫入、讀取等基礎(chǔ)操作，其內(nèi)部結(jié)構(gòu)如下所示： 

圖片

HBase通過Client連接RegionServer進(jìn)行數(shù)據(jù)讀寫，一張表會被水平切分成多個Region，每個Region負(fù)責(zé)自己區(qū)域的數(shù)據(jù)讀寫請求。一個Region由多個Store組成，每個Store存放對應(yīng)列簇的數(shù)據(jù)，比如一個表中有兩個列簇，這個表的所有Region就都會包含兩個Store。

HBase數(shù)據(jù)從RegionServer的讀寫位置，在HBase0.96版本后，只依賴于hbase:meta表，hbase:meta表存儲了所有用戶HRegion的位置信息，hbase:meta的一個rowkey就對應(yīng)一個Region，meta表只有一個列簇info，每一行數(shù)據(jù)又分為4列，如下所示。 

圖片

每條MetaData的數(shù)據(jù)信息約1KB左右，假如HRegion設(shè)置為2GB，可以支持2^21個Region，最多可以支持存儲4PB的數(shù)據(jù)，對于一般的集群來說已經(jīng)夠用。Meta表在整個HBase集群中只會存在一個，不會分裂split，位置在ZooKeeper的/hbase/meta-region-server節(jié)點(diǎn)上，在第一次讀取后緩存在客戶端。HBase讀寫優(yōu)化，需要從RegionServer和Client端同時進(jìn)行優(yōu)化，分析讀寫流程，資源消耗，以及參數(shù)調(diào)優(yōu)配置。

Part 02、  寫性能優(yōu)化  

先簡要分析下HBase數(shù)據(jù)寫入的流程，如下圖所示：

圖片

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

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

在MemStore Flush過程中，還會在尾部追加一些meta數(shù)據(jù)，其中就包括Flush時最大的WAL Sequence值，以告訴HBase這個StoreFile寫入的最新數(shù)據(jù)的序列，那么在Recover時就直到從哪里開始。在HRegion啟動時，這個sequence會被讀取，并取最大的作為下一次更新時的起始Sequence。

在HBase數(shù)據(jù)寫入的過程中，會遇到寫性能較差、數(shù)據(jù)根本寫入異常問題，可以考慮從下圖的思路進(jìn)行優(yōu)化：

圖片

2.1 客戶端寫優(yōu)化

2.1.1 WAL寫入優(yōu)化

數(shù)據(jù)寫入流程可以理解為一次順序?qū)慦AL（Write Ahead Log）加上一次寫緩存，如果業(yè)務(wù)上能夠忍受小分部數(shù)據(jù)丟失，且需要極限提高寫入速度，可以考慮禁用WAL，缺點(diǎn)就是系統(tǒng)crash的時候會丟一部分?jǐn)?shù)據(jù)，且無法做跨集群的replication。WAL 的持久化分為四個等級：

● SKIP_WAL：只寫緩存不寫HLog日志，數(shù)據(jù)有丟失的風(fēng)險。

● ASYNC_WAL：異步將數(shù)據(jù)寫入HLog日志中。

● SYNC_WAL：同步將數(shù)據(jù)寫入日志文件中，并沒有真正落盤。

● FSYNC_WAL：同步將數(shù)據(jù)寫入日志文件并強(qiáng)制落盤。

默認(rèn)如果用戶沒有指定持久化等級，HBase使用SYNC_WAL等級持久化數(shù)據(jù)，可根據(jù)業(yè)務(wù)關(guān)注點(diǎn)，在WAL機(jī)制和寫入吞吐量之間作出選擇，用戶可以通過客戶端設(shè)置WAL持久化策略。除了在創(chuàng)建表的時候直接設(shè)置WAL存儲級別，也可以通過客戶端設(shè)置WAL持久化等級，put.setDurability(Durability.SYNC_WAL);

2.1.2 PUT批量優(yōu)化

HBase分別提供了單條PUT以及批量PUT的API接口，使用批量PUT接口可以減少客戶端到RegionServer之間的RPC連接數(shù)，提高寫入吞吐量。如果對數(shù)據(jù)實(shí)時性要求不是特別嚴(yán)格，可以考慮開啟異步批量提交，用戶可以設(shè)置setAutoFlush(false)，客戶端緩存達(dá)到閾值（默認(rèn)2M）后批量提交給RegionServer。

能夠減少RPC調(diào)用的次數(shù)，將數(shù)據(jù)從client端提交給server端的任務(wù)交給HBase來處理，提高吞吐量；缺點(diǎn)是如果客戶端異常，緩存數(shù)據(jù)可能丟失。

2.1.3 大KeyValue優(yōu)化

KeyValue大小對寫入性能影響巨大。如果太大，會對性能產(chǎn)生很大的影響，會導(dǎo)致集群寫入忽然變慢、數(shù)據(jù)堆積，影響集群整體的業(yè)務(wù)。

RowKey的最大長度限制為64KB，但在實(shí)際應(yīng)用中最多不會超過100B。這是由于HBase的Rowkey會按照rowkey+columnFamily+qualifier+timestamp組成的cell被多次冗余存儲，RowKey越大，浪費(fèi)的內(nèi)存和硬盤資源也會越多。Value過大也會對性能產(chǎn)生很大的影響，也會影響到HBase的響應(yīng)速度。一般有下面的2種解決方法：

● Value過大，建議拆成多列存儲，每次返回需要的值或者將Value存儲到HDFS上，在HBase中存儲URL。

● 使用HBase2.0后的MOB特性，將Meta數(shù)據(jù)和MOB數(shù)據(jù)分開放到不同的文件中，存儲文檔、圖片等二進(jìn)制數(shù)據(jù)有極佳的性能。

2.1.4 Bulkload導(dǎo)入優(yōu)化

對于離線導(dǎo)入數(shù)據(jù)的業(yè)務(wù)場景，可使用Bulkload導(dǎo)入。Bulkload是一個MapReduce程序，輸出HFile文件，雖然實(shí)時性差，但是吞吐量大，效率高，可減少對HBase服務(wù)器壓力，提升集群整體的性能。

2.2 服務(wù)端寫優(yōu)化

2.2.1 Region數(shù)量過少優(yōu)化

通過業(yè)務(wù)的數(shù)據(jù)量大小預(yù)估Region分區(qū)，在建表時進(jìn)行預(yù)分區(qū)，達(dá)到充分利用多server并行處理的能力。在預(yù)分區(qū)如果發(fā)現(xiàn)部分Region負(fù)載以及請求量不均勻，需要切分部分請求到負(fù)載高的Region，然后等待HBase集群進(jìn)行負(fù)載均衡。如果想立刻解決，則可以使用命令將部分Region遷移到其他RegionServer節(jié)點(diǎn)上，以達(dá)到充分利用服務(wù)器資源，負(fù)載均衡。

2.2.2 寫入請求均衡優(yōu)化

檢查RowKey設(shè)計以及預(yù)分區(qū)策略，保證寫入請求均衡。針對Get查詢?yōu)橹鞯谋?，可以使用Hash預(yù)分區(qū)策略；針對Scan為主的表，可使用分段預(yù)分區(qū)的策略。

2.2.3 使用SSD存儲WAL優(yōu)化

影響寫的性能就是WAL的寫，SSD能很大的降低其響應(yīng)時間，將WAL文件寫到SSD上，對于寫性能會有非常大的提升。使用HDFS Archival Storage機(jī)制，配置HDFS的部分文件目錄為SSD介質(zhì)。hbase.wal.storage.policy默認(rèn)為none，用戶可以指定ONESSD（WAL一個副本寫入SSD介質(zhì)）或者ALLSSD（WAL的三個副本全部寫入SSD介質(zhì)）。

Part 03、 讀性能優(yōu)化  

HBase數(shù)據(jù)查詢鏈路，相對寫鏈路比較復(fù)雜，在HBase寫數(shù)據(jù)時，相同的Cell(RowKey /ColumnFamily /Column 相同)并不保證在一起，刪除一個Cell也只是寫入一個新的Cell，標(biāo)記為Delete，需要從BlockCache、MemStore、StoreFile(HFile)中依次掃描，再將將結(jié)果合并即可(Merge Read)，流程如下圖所示：

圖片

其中StoreFile的掃描，先會使用Bloom Filter過濾那些不可能符合條件的HFile，然后使用Block Index快速定位Cell，并將其加載到BlockCache中，然后從BlockCache中讀取。我們知道一個HStore可能存在多個StoreFile(HFile)，此時需要掃瞄多個HFile，如果HFile過多會引起性能問題。在HBase數(shù)據(jù)查詢的過程，會遇到數(shù)據(jù)查詢過慢問題，可從下圖思路進(jìn)行優(yōu)化：

圖片

3.1客戶端讀優(yōu)化

3.1.1 Get/Scan讀請求優(yōu)化

對于Get使用批量請求，HBase分別提供了單條Get以及批量Get的API接口，使用批量Get接口可以減少客戶端到RegionServer之間的RPC連接數(shù)，提高讀取吞吐量。

對于Scan設(shè)置客戶端緩存，在HBase總RPC次數(shù)調(diào)整到比較合理的前提下，可以考慮將大Scan場景下將Scan緩存從100增大到500或者1000，用以減少RPC次數(shù)。

3.1.2指定列簇或列優(yōu)化

在客戶端查詢時盡量指定列簇或者列進(jìn)行精確查詢，過濾不必要的列族或者列，減少Region的數(shù)據(jù)查詢和網(wǎng)絡(luò)數(shù)據(jù)傳輸。

3.1.3離線讀禁止緩存優(yōu)化

離線批量讀取請求設(shè)置禁用緩存，scan.setCacheBlocks(false)，適用于離線的全表掃秒，如MapReduce，此時使用緩存不僅無法提升性能，可能還會適得其反。

3.1.4布隆過濾器使用優(yōu)化

在任何業(yè)務(wù)都應(yīng)該設(shè)置布隆過濾器，用空間換取時間。默認(rèn)設(shè)置為row，除非確定業(yè)務(wù)隨機(jī)查詢類型為row+column，這是布隆過濾器設(shè)置為rowcol（適合大量指定column的場景，這種場景下占用的緩存內(nèi)存以及磁盤的量會增加）。

3.2服務(wù)端讀優(yōu)化

3.2.1讀請求負(fù)載均衡優(yōu)化

對于數(shù)據(jù)吞吐量較大，且一次查詢返回的數(shù)據(jù)量較大的場景，則Rowkey必須進(jìn)行散列化處理，同時建表必須進(jìn)行預(yù)分區(qū)處理。針對Get查詢?yōu)橹鞯谋恚梢允褂肏ash預(yù)分區(qū)策略，表數(shù)據(jù)均勻分布；針對Scan掃描為主的表，可使用分段預(yù)分區(qū)的策略，在兼顧業(yè)務(wù)場景的情況下，設(shè)計Rowkey，在滿足查詢需求的前提下盡量對數(shù)據(jù)打散并進(jìn)行負(fù)載均衡。

3.2.2 BlockCache緩存優(yōu)化

如果JVM內(nèi)存配置量小于20G，BlockCache策略選擇LRUBlockCache；否則選擇 BucketCache策略的offhea模式。如果是offheap模式，也可以根據(jù)業(yè)務(wù)場景的讀寫比例來配置堆中讀寫heap的比例，默認(rèn)堆中讀寫緩存均占heap的40%，即讀寫均衡。

3.2.3 HFile數(shù)量控制優(yōu)化

一個Store中包含多個HFile文件，文件越多檢索所需的IO次數(shù)越多，讀取延遲也越高。文件數(shù)量通常取決于minorCompaction的執(zhí)行策略，一般和兩個配置參數(shù)有關(guān)hbase.hstore.compactionThreshold 和 hbase.hstore.compaction.max.size，前者表示一個store中的文件數(shù)超過閾值就應(yīng)該進(jìn)行合并；后者表示參與合并的文件大小最大是多少，超過此大小的文件不能參與合并?？梢圆榭碦egionServer級別以及Region級別的HFile數(shù)量，確認(rèn)HFile文件是否過多。hbase.hstore.compactionThreshold設(shè)置不能太大，默認(rèn)為3個。

3.2.4 MajorCompaction優(yōu)化

MajorCompaction可將一個Store下的所有文件合并成一個，并在合并的過程中將修改和刪除的數(shù)據(jù)一共處理完成，釋放硬盤資源。由于配置文件中默認(rèn)的MajorCompaction是定時按表執(zhí)行，且消耗資源很大，對系統(tǒng)性能影響同樣很大，所以對于讀取延遲以及系統(tǒng)性能波動敏感的業(yè)務(wù)通常不建議開啟自動MajorCompaction，而是利用腳本定時或者手動在業(yè)務(wù)低峰期觸發(fā)；對于延遲不敏感的業(yè)務(wù)可以開啟自動MajorCompaction，但是建議限制流量。

3.2.5 數(shù)據(jù)本地化

Hbase的數(shù)據(jù)在寫的時候是本地化，但是當(dāng)Region被遷移的時候，數(shù)據(jù)可能就不再滿足本地化性了，直到完成Compaction，才能恢復(fù)數(shù)據(jù)本地化。盡量避免Region無故遷移。對于本地化率較低的節(jié)點(diǎn)，可以在業(yè)務(wù)低峰期執(zhí)行MajorCompaction。

Part 04、  總結(jié) 

HBase讀寫的優(yōu)化，需要考慮業(yè)務(wù)的使用場景，預(yù)先評估好集群的合理規(guī)模，對讀寫的場景進(jìn)行資源消耗量化分析，從而更好的進(jìn)行RowKey設(shè)計，對Region的預(yù)分區(qū)，盡量將數(shù)據(jù)分散到各個Region上，保證讀寫請求均衡，降低Compactiont對業(yè)務(wù)的影響，降低數(shù)據(jù)存儲容量和網(wǎng)絡(luò)資源消耗。在HBase眾多配置參數(shù)中，選擇合理的配置組合，達(dá)到讀寫的最優(yōu)配置。