建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
Labs 導(dǎo)讀
HBase是一種分布式的、面向列的開(kāi)源數(shù)據(jù)庫(kù)，底層基于LSM樹(shù)構(gòu)建實(shí)現(xiàn)，通過(guò)順序?qū)懖僮?，?xiě)性能大幅提升，讀取時(shí)需要將內(nèi)存中的數(shù)據(jù)和磁盤(pán)中的數(shù)據(jù)合并，犧牲了一部分讀性能，適用于寫(xiě)多讀少的場(chǎng)景。
Part 01、 讀寫(xiě)流程
RegionServer是HBase系統(tǒng)中最核心的組件，主要負(fù)責(zé)用戶(hù)數(shù)據(jù)寫(xiě)入、讀取等基礎(chǔ)操作，其內(nèi)部結(jié)構(gòu)如下所示：
圖片
HBase通過(guò)Client連接RegionServer進(jìn)行數(shù)據(jù)讀寫(xiě)，一張表會(huì)被水平切分成多個(gè)Region，每個(gè)Region負(fù)責(zé)自己區(qū)域的數(shù)據(jù)讀寫(xiě)請(qǐng)求。一個(gè)Region由多個(gè)Store組成，每個(gè)Store存放對(duì)應(yīng)列簇的數(shù)據(jù)，比如一個(gè)表中有兩個(gè)列簇，這個(gè)表的所有Region就都會(huì)包含兩個(gè)Store。
HBase數(shù)據(jù)從RegionServer的讀寫(xiě)位置，在HBase0.96版本后，只依賴(lài)于hbase:meta表，hbase:meta表存儲(chǔ)了所有用戶(hù)HRegion的位置信息，hbase:meta的一個(gè)rowkey就對(duì)應(yīng)一個(gè)Region，meta表只有一個(gè)列簇info，每一行數(shù)據(jù)又分為4列，如下所示。
圖片
每條MetaData的數(shù)據(jù)信息約1KB左右，假如HRegion設(shè)置為2GB，可以支持2^21個(gè)Region，最多可以支持存儲(chǔ)4PB的數(shù)據(jù)，對(duì)于一般的集群來(lái)說(shuō)已經(jīng)夠用。Meta表在整個(gè)HBase集群中只會(huì)存在一個(gè)，不會(huì)分裂split，位置在ZooKeeper的/hbase/meta-region-server節(jié)點(diǎn)上，在第一次讀取后緩存在客戶(hù)端。HBase讀寫(xiě)優(yōu)化，需要從RegionServer和Client端同時(shí)進(jìn)行優(yōu)化，分析讀寫(xiě)流程，資源消耗，以及參數(shù)調(diào)優(yōu)配置。
Part 02、 寫(xiě)性能優(yōu)化
先簡(jiǎn)要分析下HBase數(shù)據(jù)寫(xiě)入的流程，如下圖所示：
圖片
當(dāng)客戶(hù)端發(fā)起一個(gè)Put請(qǐng)求時(shí)，首先它從hbase:meta表中查出該P(yáng)ut數(shù)據(jù)最終需要去的HRegionServer。然后客戶(hù)端將Put請(qǐng)求發(fā)送給相應(yīng)的HRegionServer，在HRegionServer中它首先會(huì)將該P(yáng)ut操作寫(xiě)入WAL日志文件中(Flush 到磁盤(pán)中)。
寫(xiě)完WAL日志文件后，HRegionServer根據(jù)Put中的TableName和RowKey找到對(duì)應(yīng)的HRegion，并根據(jù)Column Family找到對(duì)應(yīng)的HStore，并將Put寫(xiě)入到該HStore的MemStore中。此時(shí)寫(xiě)成功，并返回通知客戶(hù)端。
在MemStore Flush過(guò)程中，還會(huì)在尾部追加一些meta數(shù)據(jù)，其中就包括Flush時(shí)最大的WAL Sequence值，以告訴HBase這個(gè)StoreFile寫(xiě)入的最新數(shù)據(jù)的序列，那么在Recover時(shí)就直到從哪里開(kāi)始。在HRegion啟動(dòng)時(shí)，這個(gè)sequence會(huì)被讀取，并取最大的作為下一次更新時(shí)的起始Sequence。
在HBase數(shù)據(jù)寫(xiě)入的過(guò)程中，會(huì)遇到寫(xiě)性能較差、數(shù)據(jù)根本寫(xiě)入異常問(wèn)題，可以考慮從下圖的思路進(jìn)行優(yōu)化：
圖片
2.1 客戶(hù)端寫(xiě)優(yōu)化
2.1.1 WAL寫(xiě)入優(yōu)化
數(shù)據(jù)寫(xiě)入流程可以理解為一次順序?qū)慦AL（Write Ahead Log）加上一次寫(xiě)緩存，如果業(yè)務(wù)上能夠忍受小分部數(shù)據(jù)丟失，且需要極限提高寫(xiě)入速度，可以考慮禁用WAL，缺點(diǎn)就是系統(tǒng)crash的時(shí)候會(huì)丟一部分?jǐn)?shù)據(jù)，且無(wú)法做跨集群的replication。WAL 的持久化分為四個(gè)等級(jí)：
● SKIP_WAL：只寫(xiě)緩存不寫(xiě)HLog日志，數(shù)據(jù)有丟失的風(fēng)險(xiǎn)。
● ASYNC_WAL：異步將數(shù)據(jù)寫(xiě)入HLog日志中。
● SYNC_WAL：同步將數(shù)據(jù)寫(xiě)入日志文件中，并沒(méi)有真正落盤(pán)。
● FSYNC_WAL：同步將數(shù)據(jù)寫(xiě)入日志文件并強(qiáng)制落盤(pán)。
默認(rèn)如果用戶(hù)沒(méi)有指定持久化等級(jí)，HBase使用SYNC_WAL等級(jí)持久化數(shù)據(jù)，可根據(jù)業(yè)務(wù)關(guān)注點(diǎn)，在WAL機(jī)制和寫(xiě)入吞吐量之間作出選擇，用戶(hù)可以通過(guò)客戶(hù)端設(shè)置WAL持久化策略。除了在創(chuàng)建表的時(shí)候直接設(shè)置WAL存儲(chǔ)級(jí)別，也可以通過(guò)客戶(hù)端設(shè)置WAL持久化等級(jí)，put.setDurability(Durability.SYNC_WAL);
2.1.2 PUT批量?jī)?yōu)化
HBase分別提供了單條PUT以及批量PUT的API接口，使用批量PUT接口可以減少客戶(hù)端到RegionServer之間的RPC連接數(shù)，提高寫(xiě)入吞吐量。如果對(duì)數(shù)據(jù)實(shí)時(shí)性要求不是特別嚴(yán)格，可以考慮開(kāi)啟異步批量提交，用戶(hù)可以設(shè)置setAutoFlush(false)，客戶(hù)端緩存達(dá)到閾值（默認(rèn)2M）后批量提交給RegionServer。
能夠減少RPC調(diào)用的次數(shù)，將數(shù)據(jù)從client端提交給server端的任務(wù)交給HBase來(lái)處理，提高吞吐量；缺點(diǎn)是如果客戶(hù)端異常，緩存數(shù)據(jù)可能丟失。
2.1.3 大KeyValue優(yōu)化
KeyValue大小對(duì)寫(xiě)入性能影響巨大。如果太大，會(huì)對(duì)性能產(chǎn)生很大的影響，會(huì)導(dǎo)致集群寫(xiě)入忽然變慢、數(shù)據(jù)堆積，影響集群整體的業(yè)務(wù)。
RowKey的最大長(zhǎng)度限制為64KB，但在實(shí)際應(yīng)用中最多不會(huì)超過(guò)100B。這是由于HBase的Rowkey會(huì)按照rowkey+columnFamily+qualifier+timestamp組成的cell被多次冗余存儲(chǔ)，RowKey越大，浪費(fèi)的內(nèi)存和硬盤(pán)資源也會(huì)越多。Value過(guò)大也會(huì)對(duì)性能產(chǎn)生很大的影響，也會(huì)影響到HBase的響應(yīng)速度。一般有下面的2種解決方法：
● Value過(guò)大，建議拆成多列存儲(chǔ)，每次返回需要的值或者將Value存儲(chǔ)到HDFS上，在HBase中存儲(chǔ)URL。
● 使用HBase2.0后的MOB特性，將Meta數(shù)據(jù)和MOB數(shù)據(jù)分開(kāi)放到不同的文件中，存儲(chǔ)文檔、圖片等二進(jìn)制數(shù)據(jù)有極佳的性能。
2.1.4 Bulkload導(dǎo)入優(yōu)化
對(duì)于離線導(dǎo)入數(shù)據(jù)的業(yè)務(wù)場(chǎng)景，可使用Bulkload導(dǎo)入。Bulkload是一個(gè)MapReduce程序，輸出HFile文件，雖然實(shí)時(shí)性差，但是吞吐量大，效率高，可減少對(duì)HBase服務(wù)器壓力，提升集群整體的性能。
2.2 服務(wù)端寫(xiě)優(yōu)化
2.2.1 Region數(shù)量過(guò)少優(yōu)化
通過(guò)業(yè)務(wù)的數(shù)據(jù)量大小預(yù)估Region分區(qū)，在建表時(shí)進(jìn)行預(yù)分區(qū)，達(dá)到充分利用多server并行處理的能力。在預(yù)分區(qū)如果發(fā)現(xiàn)部分Region負(fù)載以及請(qǐng)求量不均勻，需要切分部分請(qǐng)求到負(fù)載高的Region，然后等待HBase集群進(jìn)行負(fù)載均衡。如果想立刻解決，則可以使用命令將部分Region遷移到其他RegionServer節(jié)點(diǎn)上，以達(dá)到充分利用服務(wù)器資源，負(fù)載均衡。
2.2.2 寫(xiě)入請(qǐng)求均衡優(yōu)化
檢查RowKey設(shè)計(jì)以及預(yù)分區(qū)策略，保證寫(xiě)入請(qǐng)求均衡。針對(duì)Get查詢(xún)?yōu)橹鞯谋恚梢允褂肏ash預(yù)分區(qū)策略；針對(duì)Scan為主的表，可使用分段預(yù)分區(qū)的策略。
2.2.3 使用SSD存儲(chǔ)WAL優(yōu)化
影響寫(xiě)的性能就是WAL的寫(xiě)，SSD能很大的降低其響應(yīng)時(shí)間，將WAL文件寫(xiě)到SSD上，對(duì)于寫(xiě)性能會(huì)有非常大的提升。使用HDFS Archival Storage機(jī)制，配置HDFS的部分文件目錄為SSD介質(zhì)。hbase.wal.storage.policy默認(rèn)為none，用戶(hù)可以指定ONESSD（WAL一個(gè)副本寫(xiě)入SSD介質(zhì)）或者ALLSSD（WAL的三個(gè)副本全部寫(xiě)入SSD介質(zhì)）。
Part 03、 讀性能優(yōu)化
HBase數(shù)據(jù)查詢(xún)鏈路，相對(duì)寫(xiě)鏈路比較復(fù)雜，在HBase寫(xiě)數(shù)據(jù)時(shí)，相同的Cell(RowKey /ColumnFamily /Column 相同)并不保證在一起，刪除一個(gè)Cell也只是寫(xiě)入一個(gè)新的Cell，標(biāo)記為Delete，需要從BlockCache、MemStore、StoreFile(HFile)中依次掃描，再將將結(jié)果合并即可(Merge Read)，流程如下圖所示：
圖片
其中StoreFile的掃描，先會(huì)使用Bloom Filter過(guò)濾那些不可能符合條件的HFile，然后使用Block Index快速定位Cell，并將其加載到BlockCache中，然后從BlockCache中讀取。我們知道一個(gè)HStore可能存在多個(gè)StoreFile(HFile)，此時(shí)需要掃瞄多個(gè)HFile，如果HFile過(guò)多會(huì)引起性能問(wèn)題。在HBase數(shù)據(jù)查詢(xún)的過(guò)程，會(huì)遇到數(shù)據(jù)查詢(xún)過(guò)慢問(wèn)題，可從下圖思路進(jìn)行優(yōu)化：
圖片
3.1客戶(hù)端讀優(yōu)化
3.1.1 Get/Scan讀請(qǐng)求優(yōu)化
對(duì)于Get使用批量請(qǐng)求，HBase分別提供了單條Get以及批量Get的API接口，使用批量Get接口可以減少客戶(hù)端到RegionServer之間的RPC連接數(shù)，提高讀取吞吐量。
對(duì)于Scan設(shè)置客戶(hù)端緩存，在HBase總RPC次數(shù)調(diào)整到比較合理的前提下，可以考慮將大Scan場(chǎng)景下將Scan緩存從100增大到500或者1000，用以減少RPC次數(shù)。
3.1.2指定列簇或列優(yōu)化
在客戶(hù)端查詢(xún)時(shí)盡量指定列簇或者列進(jìn)行精確查詢(xún)，過(guò)濾不必要的列族或者列，減少Region的數(shù)據(jù)查詢(xún)和網(wǎng)絡(luò)數(shù)據(jù)傳輸。
3.1.3離線讀禁止緩存優(yōu)化
離線批量讀取請(qǐng)求設(shè)置禁用緩存，scan.setCacheBlocks(false)，適用于離線的全表掃秒，如MapReduce，此時(shí)使用緩存不僅無(wú)法提升性能，可能還會(huì)適得其反。
3.1.4布隆過(guò)濾器使用優(yōu)化
在任何業(yè)務(wù)都應(yīng)該設(shè)置布隆過(guò)濾器，用空間換取時(shí)間。默認(rèn)設(shè)置為row，除非確定業(yè)務(wù)隨機(jī)查詢(xún)類(lèi)型為row+column，這是布隆過(guò)濾器設(shè)置為rowcol（適合大量指定column的場(chǎng)景，這種場(chǎng)景下占用的緩存內(nèi)存以及磁盤(pán)的量會(huì)增加）。
3.2服務(wù)端讀優(yōu)化
3.2.1讀請(qǐng)求負(fù)載均衡優(yōu)化
對(duì)于數(shù)據(jù)吞吐量較大，且一次查詢(xún)返回的數(shù)據(jù)量較大的場(chǎng)景，則Rowkey必須進(jìn)行散列化處理，同時(shí)建表必須進(jìn)行預(yù)分區(qū)處理。針對(duì)Get查詢(xún)?yōu)橹鞯谋?，可以使用Hash預(yù)分區(qū)策略，表數(shù)據(jù)均勻分布；針對(duì)Scan掃描為主的表，可使用分段預(yù)分區(qū)的策略，在兼顧業(yè)務(wù)場(chǎng)景的情況下，設(shè)計(jì)Rowkey，在滿足查詢(xún)需求的前提下盡量對(duì)數(shù)據(jù)打散并進(jìn)行負(fù)載均衡。
3.2.2 BlockCache緩存優(yōu)化
如果JVM內(nèi)存配置量小于20G，BlockCache策略選擇LRUBlockCache；否則選擇 BucketCache策略的offhea模式。如果是offheap模式，也可以根據(jù)業(yè)務(wù)場(chǎng)景的讀寫(xiě)比例來(lái)配置堆中讀寫(xiě)heap的比例，默認(rèn)堆中讀寫(xiě)緩存均占heap的40%，即讀寫(xiě)均衡。
3.2.3 HFile數(shù)量控制優(yōu)化
一個(gè)Store中包含多個(gè)HFile文件，文件越多檢索所需的IO次數(shù)越多，讀取延遲也越高。文件數(shù)量通常取決于minorCompaction的執(zhí)行策略，一般和兩個(gè)配置參數(shù)有關(guān)hbase.hstore.compactionThreshold 和 hbase.hstore.compaction.max.size，前者表示一個(gè)store中的文件數(shù)超過(guò)閾值就應(yīng)該進(jìn)行合并；后者表示參與合并的文件大小最大是多少，超過(guò)此大小的文件不能參與合并?？梢圆榭碦egionServer級(jí)別以及Region級(jí)別的HFile數(shù)量，確認(rèn)HFile文件是否過(guò)多。hbase.hstore.compactionThreshold設(shè)置不能太大，默認(rèn)為3個(gè)。
3.2.4 MajorCompaction優(yōu)化
MajorCompaction可將一個(gè)Store下的所有文件合并成一個(gè)，并在合并的過(guò)程中將修改和刪除的數(shù)據(jù)一共處理完成，釋放硬盤(pán)資源。由于配置文件中默認(rèn)的MajorCompaction是定時(shí)按表執(zhí)行，且消耗資源很大，對(duì)系統(tǒng)性能影響同樣很大，所以對(duì)于讀取延遲以及系統(tǒng)性能波動(dòng)敏感的業(yè)務(wù)通常不建議開(kāi)啟自動(dòng)MajorCompaction，而是利用腳本定時(shí)或者手動(dòng)在業(yè)務(wù)低峰期觸發(fā)；對(duì)于延遲不敏感的業(yè)務(wù)可以開(kāi)啟自動(dòng)MajorCompaction，但是建議限制流量。
3.2.5 數(shù)據(jù)本地化
Hbase的數(shù)據(jù)在寫(xiě)的時(shí)候是本地化，但是當(dāng)Region被遷移的時(shí)候，數(shù)據(jù)可能就不再滿足本地化性了，直到完成Compaction，才能恢復(fù)數(shù)據(jù)本地化。盡量避免Region無(wú)故遷移。對(duì)于本地化率較低的節(jié)點(diǎn)，可以在業(yè)務(wù)低峰期執(zhí)行MajorCompaction。
Part 04、 總結(jié)
HBase讀寫(xiě)的優(yōu)化，需要考慮業(yè)務(wù)的使用場(chǎng)景，預(yù)先評(píng)估好集群的合理規(guī)模，對(duì)讀寫(xiě)的場(chǎng)景進(jìn)行資源消耗量化分析，從而更好的進(jìn)行RowKey設(shè)計(jì)，對(duì)Region的預(yù)分區(qū)，盡量將數(shù)據(jù)分散到各個(gè)Region上，保證讀寫(xiě)請(qǐng)求均衡，降低Compactiont對(duì)業(yè)務(wù)的影響，降低數(shù)據(jù)存儲(chǔ)容量和網(wǎng)絡(luò)資源消耗。在HBase眾多配置參數(shù)中，選擇合理的配置組合，達(dá)到讀寫(xiě)的最優(yōu)配置。
分享文章：淺談HBase讀寫(xiě)優(yōu)化
文章路徑：http://www.dlmjj.cn/article/codopsh.html
