HBase 在統(tǒng)一內(nèi)容平臺(tái)業(yè)務(wù)的優(yōu)化實(shí)踐
一、業(yè)務(wù)簡(jiǎn)介
統(tǒng)一內(nèi)容平臺(tái)主要承擔(dān)vivo內(nèi)容生態(tài)的內(nèi)容審核、內(nèi)容理解、內(nèi)容智作和內(nèi)容分發(fā)等核心功能，通過(guò)聚合全網(wǎng)內(nèi)容，建設(shè)行業(yè)級(jí)的業(yè)務(wù)中臺(tái)和內(nèi)容生態(tài)，為上下游提供優(yōu)質(zhì)可靠的一站式服務(wù)，目前服務(wù)的業(yè)務(wù)方包括視頻業(yè)務(wù)、泛信息流業(yè)務(wù)等。
作為一個(gè)內(nèi)容中臺(tái)，每天要新增存儲(chǔ)大量圖文和視頻內(nèi)容來(lái)滿足分發(fā)的需要。與此同時(shí)，對(duì)這些內(nèi)容加工處理的數(shù)據(jù)也都需要存儲(chǔ)，包括基礎(chǔ)信息，分類標(biāo)簽信息，審核信息等等。而且不僅僅是需要存儲(chǔ)的數(shù)據(jù)量級(jí)很大，對(duì)數(shù)據(jù)的讀取和寫(xiě)入操作也非常頻繁，當(dāng)前對(duì)數(shù)據(jù)庫(kù)的讀寫(xiě)主要集中在兩個(gè)方面：
- 核心鏈路的內(nèi)容處理包含了大量對(duì)內(nèi)容特征信息的讀取和寫(xiě)入操作；
- 對(duì)外提供的查詢服務(wù)會(huì)產(chǎn)生很多回源查詢數(shù)據(jù)庫(kù)的操作。
在經(jīng)過(guò)多年累積后，當(dāng)前存儲(chǔ)的數(shù)據(jù)量越變?cè)酱?，并且可以預(yù)見(jiàn)數(shù)據(jù)量級(jí)會(huì)不斷膨脹下去，如何選擇一種可靠的存儲(chǔ)選型，來(lái)保證服務(wù)穩(wěn)定性和擴(kuò)展性成了當(dāng)前項(xiàng)目架構(gòu)的重中之重。
二、存在的問(wèn)題
在選用HBase之前，內(nèi)容平臺(tái)核心數(shù)據(jù)的存儲(chǔ)以Mongodb為主要存儲(chǔ)選型，但是在日常的使用中，發(fā)現(xiàn)存儲(chǔ)側(cè)存在如下一些痛點(diǎn)問(wèn)題：
- 核心數(shù)據(jù)量大，大表有20TB 以上，總存儲(chǔ) 60TB 以上，Mongodb 的存儲(chǔ)架構(gòu)，無(wú)法滿足良好擴(kuò)展性要求；
- 訪問(wèn)查詢流量大，需要承載智慧push、泛信息流、視頻推薦側(cè)的大回源查詢流量，保持查詢接口高性能；
- 為了維護(hù)Mongodb的穩(wěn)定性，需要定期切換 Mongodb 數(shù)據(jù)庫(kù)主從節(jié)點(diǎn)，重做實(shí)例，需要運(yùn)維長(zhǎng)期投入，維護(hù)成本高。
所以我們迫切需要尋找一個(gè)更適合當(dāng)前場(chǎng)景的數(shù)據(jù)庫(kù)來(lái)滿足業(yè)務(wù)請(qǐng)求量和存儲(chǔ)大小日益增長(zhǎng)的需求，并且要求具備高性能、高穩(wěn)定、可擴(kuò)展、低維護(hù)成本的特性。
三、存儲(chǔ)選型
經(jīng)過(guò)一些調(diào)研后發(fā)現(xiàn)HBase的一些特性能很好地滿足當(dāng)前場(chǎng)景的要求。
（1）高性能
HBase采用的是Key/Value的列式存儲(chǔ)方式（對(duì)比Mongodb是行式數(shù)據(jù)庫(kù)），同一個(gè)列族的數(shù)據(jù)存放在一個(gè)文件中，隨著文件的增長(zhǎng)會(huì)進(jìn)行分裂，分散到其他機(jī)器上，所以即使隨著數(shù)據(jù)量增大，也不會(huì)導(dǎo)致讀寫(xiě)性能的下降。HBase具備毫秒級(jí)的讀寫(xiě)性能，如果寫(xiě)入數(shù)據(jù)量大，還可以使用bulkload導(dǎo)入數(shù)據(jù)的方式進(jìn)行高效入庫(kù)。
（2）高擴(kuò)展性、高容錯(cuò)性
HBase的存儲(chǔ)是基于Hadoop的，Hadoop實(shí)現(xiàn)了一個(gè)分布式文件系統(tǒng)（HDFS），HDFS的副本機(jī)制使得其具有高容錯(cuò)性的特點(diǎn)，并且HDFS的Federation機(jī)制使得其具有高擴(kuò)展性?；贖adoop意味著HBase與生俱來(lái)的超強(qiáng)擴(kuò)展性和高容錯(cuò)性。
（3）強(qiáng)一致性
HBase的數(shù)據(jù)是強(qiáng)一致性的，從CAP理論來(lái)看，HBase是屬于CP的。CAP 定理表明，在存在網(wǎng)絡(luò)分區(qū)的情況下，一致性和可用性必須二選一。HBase在寫(xiě)入數(shù)據(jù)時(shí)，先把操作的記錄寫(xiě)入到預(yù)寫(xiě)日志中（Write-ahead log，WAL），然后再被加載到Memstore的。就算某個(gè)節(jié)點(diǎn)機(jī)器宕掉了，由于WAL的數(shù)據(jù)是存儲(chǔ)在HDFS上的，所以數(shù)據(jù)并不會(huì)丟失，后續(xù)可以通過(guò)讀取預(yù)寫(xiě)日志恢復(fù)內(nèi)容。
（4）列值支持多版本
HBase的多版本特性可以針對(duì)某個(gè)列族控制列值的版本數(shù)，默認(rèn)是1，即每個(gè)key保存一個(gè)版本，同一個(gè)rowkey的情況下，后面的列值會(huì)覆蓋前面的列值?？梢詣?dòng)態(tài)修改列族的版本數(shù)，每個(gè)版本使用時(shí)間戳進(jìn)行標(biāo)記，默認(rèn)是寫(xiě)入時(shí)間作為該版本的時(shí)間戳，也可以在寫(xiě)入時(shí)指定時(shí)間戳。
綜合以上特性，HBase是非常適合當(dāng)前項(xiàng)目對(duì)數(shù)據(jù)庫(kù)選型的要求。
四、HBase 優(yōu)化實(shí)踐
隨著HBase在整個(gè)項(xiàng)目中逐步擴(kuò)大使用，也發(fā)現(xiàn)了一些使用規(guī)范問(wèn)題以及一些查詢的性能問(wèn)題。比如查詢毛刺比較多、夜間Compact期間耗時(shí)比較高、流量高峰期的時(shí)候少量請(qǐng)求會(huì)有延遲。針對(duì)這些問(wèn)題，我們從下面四個(gè)方面，對(duì)HBase的使用進(jìn)行了優(yōu)化。
4.1 集群升級(jí)
剛開(kāi)始使用HBase的時(shí)候，我們使用的HBase集群版本是1.2版本的，此版本存在諸多弊端，如：RIT（Region-In-Transition）問(wèn)題頻發(fā)、請(qǐng)求延時(shí)突刺、建刪表速度慢、meta 表穩(wěn)定性差、節(jié)點(diǎn)故障恢復(fù)速度慢等問(wèn)題。我們?cè)谑褂眠^(guò)程發(fā)現(xiàn)的主要問(wèn)題是響應(yīng)時(shí)間突刺問(wèn)題，該問(wèn)題會(huì)導(dǎo)致我們實(shí)時(shí)查詢接口在回源時(shí)超時(shí)較多，導(dǎo)致接口的響應(yīng)時(shí)間有突刺被下游業(yè)務(wù)方熔斷，影響業(yè)務(wù)查詢。與HBase團(tuán)隊(duì)討論與評(píng)估后，決定將業(yè)務(wù)使用的集群升級(jí)到HBase 2.4.8 版本。該版本在公司較多的業(yè)務(wù)場(chǎng)景中已經(jīng)得到驗(yàn)證，可以解決大部分1.2.0版本存在的痛點(diǎn)問(wèn)題，可以大幅提升讀寫(xiě)性能，有效降低讀毛刺，單機(jī)處理性能的提升可減少20%左右機(jī)器成本。
下面是集群升級(jí)后的讀寫(xiě)平均耗時(shí)對(duì)比圖?？梢钥吹皆谏?jí)之前，平均響應(yīng)時(shí)間經(jīng)常會(huì)有一些突刺，最高能達(dá)到超過(guò)10s，升級(jí)后幾乎不存在這么高的平均響應(yīng)時(shí)間突刺，能保持在10ms以下，偶爾較高也是幾十毫秒級(jí)別。
升級(jí)前
升級(jí)后
4.2 連接池使用和連接預(yù)熱
HBase Connection 創(chuàng)建對(duì)象并不是簡(jiǎn)單對(duì)應(yīng)一個(gè)socket連接，需要與Zookeeper以及HMaster、RegionServer都建立連接，所以該過(guò)程是一個(gè)非常耗資源的過(guò)程，一般只創(chuàng)建一個(gè) Connection 實(shí)例，其它地方共享該實(shí)例。在Connection初始化之后，用connection下的getTable方法實(shí)現(xiàn)對(duì)表格的連接。為了減少與表格連接帶來(lái)的網(wǎng)絡(luò)開(kāi)銷，我們建立了對(duì)不同表格的連接池來(lái)管理客戶端和服務(wù)端的連接。大致流程圖如下圖所示。
通過(guò)建立連接池，帶來(lái)了以下三點(diǎn)優(yōu)勢(shì)：
（1）對(duì)表和表之間進(jìn)行了連接資源隔離，避免互相影響；
（2）對(duì)連接實(shí)現(xiàn)了復(fù)用，減少了創(chuàng)建連接的網(wǎng)絡(luò)開(kāi)銷；
（3）防止突增的流量帶來(lái)的影響，實(shí)現(xiàn)平滑處理流量。
此外，圖中可以看到，在程序啟動(dòng)階段，可以實(shí)現(xiàn)對(duì)HBase表連接的預(yù)熱，提前建立對(duì)表格的連接，可以有效避免在程序啟動(dòng)階段由于大量建立連接導(dǎo)致讀寫(xiě)的響應(yīng)時(shí)間變長(zhǎng)，影響整體性能。
連接池通過(guò)使用Apache Commons Pool提供的GenericObjectPool通用對(duì)象池來(lái)實(shí)現(xiàn)，GenericObjectPool包含豐富的配置選項(xiàng)，能夠定期回收空閑對(duì)象，并且支持對(duì)象驗(yàn)證，具有強(qiáng)大的線程安全性和可擴(kuò)展性。然后將不同表格的連接池對(duì)象放到本地緩存LoadingCache中，LoadingCache底層通過(guò)LRU算法實(shí)現(xiàn)對(duì)最久遠(yuǎn)且沒(méi)有使用的數(shù)據(jù)的淘汰，保證沒(méi)有使用的表格連接能及時(shí)釋放。通過(guò)使用第三方的對(duì)象池和本地緩存，建立了對(duì)HBase表格的連接池，并且實(shí)現(xiàn)了預(yù)加載，減少了一些讀寫(xiě)HBase的開(kāi)銷，降低了讀寫(xiě)耗時(shí)，對(duì)于剛啟動(dòng)服務(wù)時(shí)的讀寫(xiě)突刺帶來(lái)了一些改善。
4.3 按列讀取
HBase建表的時(shí)候是不需要確定列的，因?yàn)榱惺强勺兊?，它非常靈活，唯一需要確定的就是列族。一張表的很多屬性比如過(guò)期時(shí)間、數(shù)據(jù)塊緩存以及是否壓縮等都是定義在列族上，而不是定義在表上或者列上，這一點(diǎn)做法跟以往的數(shù)據(jù)庫(kù)有很大的區(qū)別。同一個(gè)表里的不同列族可以有完全不同的屬性配置，但是同一個(gè)列族內(nèi)的所有列都會(huì)有相同的屬性。一個(gè)沒(méi)有列族的表是沒(méi)有意義的，因?yàn)榱斜仨氁蕾嚵凶宥嬖?，所以在HBase中一個(gè)列的名稱前面總是帶著它所屬的列族。列族存在使得HBase會(huì)把相同列族的列盡量放在同一臺(tái)機(jī)器上，不同列族的列分布在不同的機(jī)器上。
一般情況下，從客戶端發(fā)起請(qǐng)求讀取數(shù)據(jù)，到數(shù)據(jù)返回大致有如下幾步：
- 客戶端從ZooKeeper中獲取meta表所在regionServer節(jié)點(diǎn)信息。
- 客戶端訪問(wèn)meta表所在的regionServer節(jié)點(diǎn)，獲取region所在節(jié)點(diǎn)信息。
- 客戶端訪問(wèn)具體region所在regionServer，找到對(duì)應(yīng)的region。
- 首先從blockCache中讀取數(shù)據(jù)，存在則返回，不存在則去memstore中讀取數(shù)據(jù)，存在則返回，不存在去storeFile（HFile）中讀取數(shù)據(jù)，存在會(huì)先將數(shù)據(jù)寫(xiě)入到blockCache中，然后返回?cái)?shù)據(jù)，不存在則返回空。
簡(jiǎn)單的示意圖如下所示：
整個(gè)過(guò)程中如果讀取字段過(guò)多，或者字段長(zhǎng)度過(guò)大，那么返回所有列的數(shù)據(jù)會(huì)導(dǎo)致大量無(wú)效的數(shù)據(jù)傳輸，進(jìn)而導(dǎo)致集群網(wǎng)絡(luò)帶寬等系統(tǒng)資源被大量占用，必然導(dǎo)致讀取性能降低，所以需要減少一些不必要字段的查詢。
Get類是HBase官方提供的查詢類，在該類中主要有以下幾個(gè)方法提供來(lái)實(shí)現(xiàn)減少字段讀?。?/p>
- addFamily：添加要取出的列族；
- addColumn：添加要取出的列；
- setTimeRange：設(shè)置要取出的版本范圍；
- setMaxVersions：設(shè)置取出版本數(shù)量。
當(dāng)前項(xiàng)目中沒(méi)有使用到HBase的版本范圍和版本數(shù)量的特性，但是主要場(chǎng)景使用的表字段都比較多（如內(nèi)容的基本屬性能達(dá)到上百個(gè)字段），或者字段的大小都比較大（如內(nèi)容解析的一些向量字段），原本在查詢時(shí)，都是直接讀取所有字段，導(dǎo)致很多字段其實(shí)不需要使用也被一直讀取，浪費(fèi)性能。通過(guò)改用按列讀取的方式來(lái)實(shí)現(xiàn)不同場(chǎng)景下不同字段的查詢，避免了超過(guò)一半無(wú)用字段的返回，平均響應(yīng)時(shí)間也下降了一些。
4.4 compact優(yōu)化
HBase是基于LSM樹(shù)存儲(chǔ)模型的分布式NoSQL數(shù)據(jù)庫(kù)。LSM樹(shù)相比于普遍使用在各種數(shù)據(jù)庫(kù)的B+樹(shù)來(lái)說(shuō)，能夠獲得較高隨機(jī)寫(xiě)性能的同時(shí)，也能保持可靠的隨機(jī)讀性能。在進(jìn)行讀請(qǐng)求的時(shí)候，LSM樹(shù)要把多個(gè)子樹(shù)（類似B+樹(shù)結(jié)構(gòu)）進(jìn)行歸并查詢， 因此歸并查詢的子樹(shù)數(shù)越少，查詢的性能就越高。當(dāng)MemStore超過(guò)閥值的時(shí)候，就要flush到HDFS上生成一個(gè)HFile。因此隨著不斷寫(xiě)入，HFile的數(shù)量將會(huì)越來(lái)越多，根據(jù)前面所述，HFile數(shù)量過(guò)多會(huì)降低讀性能。為了避免對(duì)讀性能的影響，可以對(duì)這些HFile進(jìn)行compact操作，把多個(gè)HFile合并成一個(gè)HFile。compact操作需要對(duì)HBase的數(shù)據(jù)進(jìn)行多次的重新讀寫(xiě)，因此這個(gè)過(guò)程會(huì)產(chǎn)生大量的IO?？梢钥吹絚ompact操作的本質(zhì)就是以IO操作換取后續(xù)的讀性能的提高。
HBase的compact是針對(duì)HRegion的HFile文件進(jìn)行操作的。compact操作分為major和minor兩種。major compaction會(huì)把所有的HFile都compact為一個(gè)HFile，并同時(shí)忽略標(biāo)記為delete的KeyValue（被刪除的KeyValue只有在compact過(guò)程中才真正被"刪除"），可以想象major compaction會(huì)產(chǎn)生大量的IO操作，對(duì)HBase的讀寫(xiě)性能產(chǎn)生影響。minor則只會(huì)選擇數(shù)個(gè)HFile文件compact為一個(gè)HFile，minor的過(guò)程一般較快，而且IO相對(duì)較低。在業(yè)務(wù)高峰期間，都會(huì)禁止major操作，只在業(yè)務(wù)空閑的時(shí)段定時(shí)執(zhí)行。
hbase.hstore.compaction.throughput.higher.bound是HBase中控制HFile文件合并（compaction）速度的參數(shù)之一。它指定了一個(gè)HFile文件每秒最大合并數(shù)據(jù)大小的上限，以字節(jié)為單位。如果一個(gè)HFile文件的大小超過(guò)了這個(gè)上限，HBase就會(huì)嘗試將其分裂成較小的文件來(lái)加快合并速度。通過(guò)調(diào)整該參數(shù)，可以控制HBase在什么條件下開(kāi)始嘗試合并HFile文件。較小的值會(huì)導(dǎo)致更頻繁的文件合并，也會(huì)降低HBase的性能。較大的值則可能導(dǎo)致HFile文件的大小增長(zhǎng)過(guò)快，從而影響讀取性能。
hbase.hstore.compaction.throughput.lower.bound也是HBase中控制HFile文件合并速度的參數(shù)之一。它指定了一個(gè)HFile文件每秒最小合并數(shù)據(jù)大小的下限，以字節(jié)為單位。當(dāng)合并速度達(dá)到這個(gè)下限時(shí)，HBase會(huì)停止合并更小的HFile文件，而等待更多的數(shù)據(jù)到達(dá)之后再進(jìn)行合并操作。與higher.bound參數(shù)相比，lower.bound參數(shù)更加影響文件合并頻率和性能。過(guò)高的值會(huì)導(dǎo)致較少的文件合并和較大的HFile文件，這會(huì)影響讀取性能和寫(xiě)入并發(fā)性。反之，過(guò)低的值會(huì)導(dǎo)致過(guò)于頻繁的文件合并，從而占用過(guò)多的CPU和磁盤(pán)I/O資源，影響整個(gè)HBase集群的性能。針對(duì)Compact對(duì)業(yè)務(wù)耗時(shí)的影響，我們對(duì)Compact 操作進(jìn)行了限流，并且通過(guò)多次測(cè)試調(diào)整Compact上文提到的兩個(gè)限流的閾值，取得了非常好的效果。Compact期間的耗時(shí)下降了70%y以上。下圖展示了采取限流前后的耗時(shí)對(duì)比。
4.5 字段級(jí)版本管理
除了上述提到的優(yōu)化點(diǎn)，我們也探索了一些HBase的其它特性，以備將來(lái)用來(lái)優(yōu)化其他方面。上文提到，通過(guò)對(duì)HBase進(jìn)行按列讀取數(shù)據(jù)，可以減少get查詢的時(shí)間，通常意義來(lái)講，列（也就是每個(gè)字段）已經(jīng)是每條數(shù)據(jù)的最基本單位了，但是HBase中的數(shù)據(jù)粒度比傳統(tǒng)數(shù)據(jù)結(jié)構(gòu)更細(xì)一級(jí)，同一個(gè)位置的數(shù)據(jù)還細(xì)分成多個(gè)版本，一個(gè)列上可以存儲(chǔ)多個(gè)版本的值，多個(gè)版本的值被存儲(chǔ)在多個(gè)單元格里面，多個(gè)版本之間用版本號(hào)（ version）來(lái)區(qū)分。所以，唯一確定一條結(jié)果的表達(dá)式應(yīng)該是行鍵:列族:列:版本號(hào)（rowkey:column family:column:version）。不過(guò)，版本號(hào)通常是可以省略的，如果寫(xiě)入時(shí)不寫(xiě)版本號(hào)，每個(gè)列或者單元格的值都被賦予一個(gè)時(shí)間戳，這個(gè)時(shí)間戳默認(rèn)是由系統(tǒng)制定的，當(dāng)然寫(xiě)入時(shí)也可以由用戶顯式指定具體的版本號(hào)。在查詢時(shí)如果不指定版本號(hào)，HBase默認(rèn)獲取最后一個(gè)版本的數(shù)據(jù)返回給你。當(dāng)然也可以指定版本號(hào)返回需要的其他版本的數(shù)據(jù)。簡(jiǎn)單的示意圖如下所示：
同時(shí)HBase為了避免數(shù)據(jù)存在過(guò)多的版本造成不必要的負(fù)擔(dān)，HBase提供了兩種數(shù)據(jù)版本的回收方式，一是按照數(shù)量維度，保存最后的n個(gè)版本，二是按照時(shí)間維度，保存最近一段時(shí)間的版本數(shù)據(jù)，比如保存一個(gè)月。通過(guò)多版本同時(shí)存儲(chǔ)，對(duì)于一些有時(shí)序要求的場(chǎng)景非常友好，通過(guò)指定版本的時(shí)間戳，可以避免在已經(jīng)更新了新數(shù)據(jù)的情況下，被舊數(shù)據(jù)覆蓋。當(dāng)前我們建表是都是只指定了一個(gè)版本，使用也都是用的以時(shí)間戳為版本號(hào)的默認(rèn)版本，沒(méi)有采取版本管理的措施，不同單元格可以記錄多版本的特性可以考慮應(yīng)用于字段更新時(shí)記錄下多個(gè)版本的數(shù)據(jù)，在不影響讀寫(xiě)效率的情況下，方便后續(xù)在沒(méi)有相關(guān)日志的情況下，回溯最近幾次更新的值，并且可以防止誤操作或數(shù)據(jù)損壞，因?yàn)橛脩艨梢曰謴?fù)到之前的版本數(shù)據(jù)。此外我們的系統(tǒng)中存在一些通過(guò)消息隊(duì)列異步更新場(chǎng)景，此時(shí)可以使用消息體中的時(shí)間戳作為當(dāng)前版本號(hào)，這樣可以在多線程消費(fèi)時(shí)，也能保證消費(fèi)的時(shí)序性，因?yàn)榈桶姹镜陌姹咎?hào)無(wú)法更新高版本的版本號(hào)。
五、總結(jié)
本文在對(duì)統(tǒng)一內(nèi)容平臺(tái)在數(shù)據(jù)庫(kù)選型分析和優(yōu)化的基礎(chǔ)上，簡(jiǎn)要介紹了HBase在實(shí)際使用中的一些優(yōu)化方案，經(jīng)優(yōu)化后，項(xiàng)目整體讀取和寫(xiě)入性能都有比較明顯的提升，較好的保障了統(tǒng)一內(nèi)容平臺(tái)業(yè)務(wù)的穩(wěn)定性，并且大大降低了業(yè)務(wù)側(cè)的運(yùn)維成本。Hbase本身就具備強(qiáng)大的功能，在大數(shù)據(jù)領(lǐng)域有獨(dú)有的優(yōu)勢(shì)，但是在不同的業(yè)務(wù)場(chǎng)景，對(duì)于HBase的要求也是不一樣的，可以結(jié)合具體的實(shí)際情況，從使用的數(shù)據(jù)庫(kù)版本、從HBase底層機(jī)制的調(diào)參、從客戶端調(diào)用機(jī)制的優(yōu)化等多方面挖掘，探索更適合業(yè)務(wù)的方式，希望本文中提到的一些優(yōu)化方案能給讀者帶來(lái)一些啟發(fā)。
