陳娜+張金娟+劉智瓊+徐歆壹

【摘要】隨著移動(dòng)互聯(lián)網(wǎng)的快速發(fā)展，電信運(yùn)營商內(nèi)部各種IT系統(tǒng)中的數(shù)據(jù)出現(xiàn)了“大數(shù)據(jù)”的特征，既有的技術(shù)架構(gòu)和路線已無法高效處理如此海量的數(shù)據(jù)。針對(duì)流量經(jīng)營大數(shù)據(jù)管理和大數(shù)據(jù)服務(wù)中海量DPI數(shù)據(jù)的數(shù)據(jù)入庫和數(shù)據(jù)查詢場景，提出了一種基于Hadoop的分布式數(shù)據(jù)服務(wù)架構(gòu)，并設(shè)計(jì)出在該架構(gòu)下的數(shù)據(jù)入庫和查詢性能的優(yōu)化算法，通過模擬數(shù)據(jù)的實(shí)驗(yàn)對(duì)性能優(yōu)化算法進(jìn)行了驗(yàn)證。

【關(guān)鍵詞】大數(shù)據(jù)HadoopHBase性能優(yōu)化

中圖分類號(hào)：TP39文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1006-1010(2014)-07-0058-06

1 引言

隨著3G網(wǎng)絡(luò)的成熟和智能終端的普及，移動(dòng)互聯(lián)網(wǎng)上的數(shù)據(jù)呈現(xiàn)爆炸式的增長，電信運(yùn)營商為適應(yīng)移動(dòng)互聯(lián)網(wǎng)時(shí)代激烈的競爭，也提出了角色轉(zhuǎn)型的戰(zhàn)略，不斷推出各種新業(yè)務(wù)和新應(yīng)用，引導(dǎo)用戶的行為模式從傳統(tǒng)的“語音+短信+增值業(yè)務(wù)”的模式轉(zhuǎn)變?yōu)椤罢Z音+應(yīng)用+流量”的模式。各種新業(yè)務(wù)和新應(yīng)用層出不窮，趨向多元化，這使得電信運(yùn)營商內(nèi)部各種IT系統(tǒng)中的數(shù)據(jù)也出現(xiàn)了大數(shù)據(jù)的特征，一是數(shù)據(jù)類型繁多；二是數(shù)據(jù)價(jià)值分散；三是處理速度快，時(shí)效性要求高。既有的技術(shù)架構(gòu)和路線，已經(jīng)無法高效處理如此海量的數(shù)據(jù)，例如DPI數(shù)據(jù)。

近年來，大數(shù)據(jù)處理的技術(shù)架構(gòu)涌現(xiàn)出了眾多新技術(shù)，其中由Apache基金會(huì)開發(fā)的Hadoop開源架構(gòu)應(yīng)用最廣泛，在電信企業(yè)內(nèi)部也已有部分IT系統(tǒng)在嘗試使用Hadoop架構(gòu)。本文針對(duì)海量DPI數(shù)據(jù)的數(shù)據(jù)入庫和數(shù)據(jù)查詢場景，提出一種基于Hadoop的分布式數(shù)據(jù)服務(wù)架構(gòu)，同時(shí)，設(shè)計(jì)出在該架構(gòu)下的數(shù)據(jù)入庫和查詢性能的優(yōu)化算法，并通過模擬數(shù)據(jù)的實(shí)驗(yàn)對(duì)性能優(yōu)化算法進(jìn)行了驗(yàn)證。

2 系統(tǒng)功能架構(gòu)設(shè)計(jì)

在功能架構(gòu)上，本系統(tǒng)采用“三層結(jié)構(gòu)”的設(shè)計(jì)思想，應(yīng)用系統(tǒng)在邏輯上按“數(shù)據(jù)服務(wù)層、業(yè)務(wù)處理層和接入層”三層結(jié)構(gòu)設(shè)計(jì)。將接入層獨(dú)立出來使得系統(tǒng)的訪問和使用更靈活方便，易于實(shí)現(xiàn)個(gè)性化和客戶化；將業(yè)務(wù)處理層和數(shù)據(jù)服務(wù)層分開可以屏蔽業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)、組織和訪問的細(xì)節(jié)，實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)的充分共享，從而實(shí)現(xiàn)橫向組合。系統(tǒng)功能架構(gòu)如圖1所示。

（1）數(shù)據(jù)服務(wù)層

數(shù)據(jù)服務(wù)層為整個(gè)系統(tǒng)提供分布式的數(shù)據(jù)服務(wù)，其中包括分布式文件系統(tǒng)HDFS、分布式數(shù)據(jù)庫HBase、分布式協(xié)調(diào)器Zookeeper和業(yè)務(wù)實(shí)例化部分。

（2）業(yè)務(wù)處理層

業(yè)務(wù)處理層構(gòu)建于數(shù)據(jù)服務(wù)層之上，封裝了整個(gè)系統(tǒng)的核心業(yè)務(wù)處理邏輯。其中包括接口服務(wù)與查詢管理、數(shù)據(jù)ETL、索引定制、數(shù)據(jù)服務(wù)、系統(tǒng)管理功能。

（3）接入層

接入層實(shí)現(xiàn)本系統(tǒng)和外部系統(tǒng)的接口，其中包括輸入接口和輸出接口。本系統(tǒng)輸入接口采用文件接口，輸出接口采用Web Service消息接口。

3 驗(yàn)證數(shù)據(jù)和實(shí)驗(yàn)環(huán)境描述

實(shí)驗(yàn)選擇的驗(yàn)證數(shù)據(jù)是流量經(jīng)營DPI數(shù)據(jù)，DPI數(shù)據(jù)是基于DPI技術(shù)獲取的TCP/IP應(yīng)用層數(shù)據(jù)，基于此能夠?qū)?shù)據(jù)內(nèi)容進(jìn)行分析，因此DPI數(shù)據(jù)在流量經(jīng)營業(yè)務(wù)背景下具有很重要的意義。

（1）數(shù)據(jù)特性

實(shí)驗(yàn)選擇流量經(jīng)營DPI數(shù)據(jù)的數(shù)據(jù)特性如表1所示：

表1DPI數(shù)據(jù)的數(shù)據(jù)特性

業(yè)務(wù)類型 文件編碼方式 原始記錄字段數(shù) 需入庫的記錄字段數(shù) 需入庫記錄數(shù)/億

HTTP業(yè)務(wù) ASCII 65 14 25

WAP業(yè)務(wù) ASCII 40 14 25

（2）驗(yàn)證方法和評(píng)估指標(biāo)

實(shí)驗(yàn)主要驗(yàn)證50億DPI數(shù)據(jù)的入庫、查詢性能和整個(gè)系統(tǒng)的高可用性，具體的驗(yàn)證方法和評(píng)估指標(biāo)如表2所示：

表2評(píng)估指標(biāo)

評(píng)估點(diǎn) 評(píng)估指標(biāo)

50億數(shù)據(jù)的入庫性能 入庫總耗時(shí)（LTC）、每秒入庫記錄數(shù)（RNPS）

50億數(shù)據(jù)的查詢性能 平均查詢響應(yīng)時(shí)長（ATRT）、平均事務(wù)處理能力（TPS）

（3）硬件配置

實(shí)驗(yàn)的主機(jī)環(huán)境為6臺(tái)DL380 Gen8，CPU為E5-2630*1（12核），內(nèi)存16G，聯(lián)機(jī)磁盤各300GB，構(gòu)建分布式文件系統(tǒng)的存儲(chǔ)各2T；實(shí)驗(yàn)網(wǎng)絡(luò)帶寬采用千兆以太網(wǎng)絡(luò)。

4 入庫性能優(yōu)化

入庫性能相關(guān)的因素主要包括Region分裂率、CPU使用率、磁盤I/O使用率、網(wǎng)絡(luò)I/O使用率、HBase內(nèi)核參數(shù)優(yōu)化度和入庫應(yīng)用程序優(yōu)化度。通過深入研究，本文提出入庫的極限性能測評(píng)算法如下：

（1）

其中，WIO是單臺(tái)機(jī)器的I/O帶寬，單位為kB/s；Scdr是要入庫的單條話單的大小，單位是kB；C1是HDFS文件系統(tǒng)保留的副本系數(shù)；C2是整個(gè)集群的機(jī)器數(shù)。R2和R1代表性能測試結(jié)束和開始時(shí)的Htable Region個(gè)數(shù)，當(dāng)R2大于R1時(shí)說明有Region分裂產(chǎn)生，最理想的性能值是R2=R1，表示沒有Region發(fā)生過分裂。指的是集群所有服務(wù)器的平均CPU使用率，這里取分段值：

當(dāng)CPU使用率平均值≥80%時(shí)，=1；當(dāng)60%≤CPU使用率平均值＜80%時(shí)，=0.7；當(dāng)CPU使用率平均值＜60%時(shí)，=0；指集群所有服務(wù)器的平均I/O使用率，取值規(guī)則和相同；指集群所有服務(wù)器的平均網(wǎng)絡(luò)帶寬使用率，取值規(guī)則和相同；λ1表示HBase內(nèi)核參數(shù)優(yōu)化度和入庫應(yīng)用程序優(yōu)化度，此值越小說明平臺(tái)和應(yīng)用程序越優(yōu)化，取值范圍為[0,1]。當(dāng)其為0時(shí)則達(dá)到理論的最優(yōu)程度。

根據(jù)實(shí)驗(yàn)環(huán)境，對(duì)K系列參數(shù)做如下設(shè)置：k1為Region分裂系數(shù)，在DL380 Gen8集群環(huán)境下為常數(shù)130；k2為CPU影響系數(shù)，在DL380 Gen8集群環(huán)境下為常數(shù)50 000；k3為磁盤I/O影響系數(shù)，在DL380 Gen8集群環(huán)境下為常數(shù)60 000；k4為網(wǎng)絡(luò)影響系數(shù)，在千兆以太網(wǎng)環(huán)境下為常數(shù)60 000；k5為軟系數(shù)，表示軟件層面的優(yōu)化系數(shù)，該值為常數(shù)120 000。當(dāng)HBase的內(nèi)核參數(shù)未做任何優(yōu)化時(shí)λ1的經(jīng)驗(yàn)值為0.85左右，當(dāng)HBase內(nèi)核參數(shù)和應(yīng)用做下文的10項(xiàng)優(yōu)化后，λ1的經(jīng)驗(yàn)值為0.1。

4.1HBase內(nèi)核參數(shù)優(yōu)化

HBase內(nèi)核參數(shù)的優(yōu)化是對(duì)入庫極限性能測評(píng)算法中因子λ1的優(yōu)化，主要包括以下5個(gè)方面：

（1）hbase.hregion.max.filesize的設(shè)置

HBase中hfile的默認(rèn)最大值（hbase.hregion.max.filesize）是256MB，hbase.hregion.max.filesize不宜過大或過小[1]。對(duì)于流量經(jīng)營DPI離線應(yīng)用，調(diào)整為128MB會(huì)更加合適一些。

（2）hbase.regionserver.handler.count的設(shè)置

RegionServer端開啟的RPC監(jiān)聽器實(shí)例個(gè)數(shù)，也即RegionServer能夠處理的I/O請(qǐng)求線程數(shù)，默認(rèn)是10。因流量經(jīng)營DPI數(shù)據(jù)為多線程并發(fā)入庫，故調(diào)整該值到50。

（3）hbase.hregion.memstore.block.multiplier設(shè)置

這個(gè)參數(shù)的作用是當(dāng)memstore的大小增至超過hbase.hregion.memstore.flush.size的2倍時(shí)，block所有請(qǐng)求，遏制風(fēng)險(xiǎn)進(jìn)一步擴(kuò)大，該參數(shù)的默認(rèn)值是2。因流量經(jīng)營DPI數(shù)據(jù)寫操作的量非常大，故調(diào)整該值為3。

（4）hbase.hstore.blockingStoreFiles設(shè)置

block寫請(qǐng)求會(huì)嚴(yán)重影響當(dāng)前RegionServer的響應(yīng)時(shí)間，但過多的storefile也會(huì)影響讀性能[2]。為了獲取較平滑的響應(yīng)時(shí)間，流量經(jīng)營DPI數(shù)據(jù)入庫設(shè)置該值為無限大。

endprint

（5）hfile.block.cache.size設(shè)置

storefile的讀緩存占用Heap的大小百分比為20%，該值直接影響數(shù)據(jù)讀的性能。流量經(jīng)營DPI數(shù)據(jù)主要是提供數(shù)據(jù)的查詢服務(wù)，為提高讀數(shù)據(jù)的性能，設(shè)置該值為0.4。

4.2預(yù)分Region數(shù)量

預(yù)分Region數(shù)量是對(duì)入庫極限性能測評(píng)算法中因子（R2-R1）部分的優(yōu)化。為規(guī)避Hregion分裂導(dǎo)致的額外資源耗費(fèi)對(duì)系統(tǒng)性能的影響，根據(jù)需要入庫的數(shù)據(jù)量大小提前預(yù)分好所有的Region，可以提高系統(tǒng)的總體性能。

4.3使用Snappy壓縮算法

使用Snappy壓縮算法對(duì)DPI的入庫數(shù)據(jù)進(jìn)行壓縮是對(duì)入庫極限性能測評(píng)算法中因子、和的優(yōu)化。入庫前文件總大小為509GB，入庫后數(shù)據(jù)保留3份，HDFS文件系統(tǒng)共使用269.79G，相對(duì)壓縮比為0.53。若按照單條DPI數(shù)據(jù)的絕對(duì)壓縮率計(jì)算，壓縮率可以達(dá)到15%左右。使用Snappy壓縮算法后，大幅降低了系統(tǒng)總體的I/O吞吐量，進(jìn)而也大幅提高了入庫的性能。

4.4寫表操作的性能優(yōu)化

寫表操作的性能優(yōu)化是對(duì)入庫極限性能測評(píng)算法中因子λ1的優(yōu)化，主要包括以下5個(gè)方面：

（1）Auto Flush設(shè)置

通過調(diào)用HTable.setAutoFlush(false)方法可以將HTable寫客戶端的自動(dòng)flush關(guān)閉，這樣可以批量寫入數(shù)據(jù)到HBase，而不是有一條put就執(zhí)行一次更新，只有當(dāng)put填滿客戶端寫緩存時(shí)，才實(shí)際向HBase服務(wù)端發(fā)起寫請(qǐng)求[3]。默認(rèn)情況下auto flush是開啟的。

（2）Write Buffer設(shè)置

通過調(diào)用HTable.setWriteBufferSize(writeBufferSize)方法可以設(shè)置HTable客戶端的寫buffer大小，如果新設(shè)置的buffer小于當(dāng)前寫buffer中的數(shù)據(jù)時(shí)，buffer將會(huì)被flush到服務(wù)端。其中，writeBufferSize的單位是byte，可以根據(jù)實(shí)際寫入數(shù)據(jù)量的多少來設(shè)置該值[3]。

（3）WAL Flag設(shè)置

在HBase中，客戶端向集群中的RegionServer提交數(shù)據(jù)時(shí)，首先會(huì)先寫WAL日志，只有當(dāng)WAL日志寫成功后，再接著寫MemStore，然后客戶端被通知提交數(shù)據(jù)成功；如果寫WAL日志失敗，客戶端則被通知提交失敗。這樣可以做到RegionServer宕機(jī)后的數(shù)據(jù)恢復(fù)。因此，對(duì)于相對(duì)不太重要的數(shù)據(jù)，可以在Put/Delete操作時(shí)，通過調(diào)用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函數(shù)，放棄寫WAL日志，從而提高數(shù)據(jù)寫入的性能[4]。

（4）批量寫

通過調(diào)用HTable.put(Put)方法可以將一個(gè)指定的row key記錄寫入HBase，同樣HBase提供了另一個(gè)方法：通過調(diào)用HTable.put(List)方法可以將指定的row key列表，批量寫入多行記錄。這樣做的好處是批量執(zhí)行，只需要一次網(wǎng)絡(luò)I/O開銷，這對(duì)于對(duì)數(shù)據(jù)實(shí)時(shí)性要求高、網(wǎng)絡(luò)傳輸RTT高的情景，可帶來明顯的性能提升[5]。

（5）多線程并發(fā)寫

在客戶端開啟多個(gè)HTable寫線程，每個(gè)寫線程負(fù)責(zé)一個(gè)HTable對(duì)象的flush操作，這樣結(jié)合定時(shí)flush和寫buffer（writeBufferSize），既能保證在數(shù)據(jù)量小的時(shí)候，數(shù)據(jù)可以在較短時(shí)間內(nèi)被flush（如1s內(nèi)），同時(shí)又能保證在數(shù)據(jù)量大的時(shí)候，寫buffer一滿就及時(shí)進(jìn)行flush[6]。

4.5入庫性能結(jié)果對(duì)比分析

通過以上優(yōu)化，入庫50億數(shù)據(jù)優(yōu)化前后最終測試結(jié)果對(duì)比如表3所示：

表3數(shù)據(jù)優(yōu)化前后入庫性能結(jié)果對(duì)比

記錄數(shù)/億 優(yōu)化前LTC 優(yōu)化前RNPS/（萬條·s-1） 優(yōu)化后LTC 優(yōu)化后RNPS/（萬條·s-1）

50 11小時(shí)46分 11.8 5小時(shí)20秒 28.1

根據(jù)表3數(shù)據(jù)可得優(yōu)化前的集群入庫效率為11.8萬條/s，優(yōu)化后的集群入庫效率為28.1萬條/s。再結(jié)合入庫的極限性能測評(píng)算法對(duì)以上結(jié)果進(jìn)行分析：

（1）優(yōu)化前結(jié)果分析

結(jié)論一：優(yōu)化前實(shí)際入庫速率11.8萬條/s遠(yuǎn)小于極限性能=29.2萬條/s，優(yōu)化前的入庫性能只達(dá)到極限性能的40.4%，總體上還有很大的優(yōu)化空間；

結(jié)論二：Region數(shù)量分裂了244次，磁盤I/O出現(xiàn)瓶頸，需控制Region的分裂，降低磁盤的總體I/O。

結(jié)論三：根據(jù)以上性能測評(píng)算法計(jì)算出的優(yōu)化前入庫速率為11.6萬條/s，與實(shí)際測試結(jié)果11.8萬條/s近似。

（2）優(yōu)化后結(jié)果分析

結(jié)論一：優(yōu)化后實(shí)際入庫速率28.1萬條/s接近極限性能29.2萬條/s，優(yōu)化后的入庫性能達(dá)到極限入庫性能的96.2%；

結(jié)論二：優(yōu)化后的Region未發(fā)生分裂，磁盤I/O、網(wǎng)絡(luò)I/O、CPU使用率均未出現(xiàn)瓶頸；

結(jié)論三：根據(jù)以上性能測評(píng)算法計(jì)算出的優(yōu)化后入庫速率為28萬條/s，與實(shí)際測試結(jié)果28.1萬條/s近似。

5 查詢性能優(yōu)化

查詢性能相關(guān)的因素包括：查詢服務(wù)中間件吞吐量、查詢尋址次數(shù)、查詢集群規(guī)模、查詢應(yīng)用優(yōu)化程度。實(shí)驗(yàn)選擇的查詢中間件為tomcat。通過驗(yàn)證，單臺(tái)DL380 Gen8機(jī)器讀取內(nèi)存的查詢性能為300；用戶并發(fā)查詢ATRT為0.18s，TPS為1 429TPS，以上兩值不同的硬件平臺(tái)取值不一樣。通過深入研究，本文提出查詢的極限性能測評(píng)算法如下：

（2）

（3）

其中，表示查詢的平均事務(wù)響應(yīng)時(shí)間，R1表示做一次查詢HBase的路由尋址次數(shù)，該值與應(yīng)用設(shè)計(jì)有關(guān)，不同的設(shè)計(jì)最終路由尋址次數(shù)可能不一樣；λ1表示查詢應(yīng)用的優(yōu)化度，取值范圍為[0,1]，當(dāng)該值為0時(shí)說明查詢應(yīng)用已經(jīng)達(dá)到最優(yōu)程度，根據(jù)經(jīng)驗(yàn)當(dāng)應(yīng)用未做任何優(yōu)化時(shí)λ1的經(jīng)驗(yàn)值為0.9，當(dāng)應(yīng)用做了下文中的6項(xiàng)優(yōu)化后，λ1的經(jīng)驗(yàn)值為0.1。

表示查詢的平均事務(wù)處理能力，R1、λ1、C1的含義與計(jì)算公式中的因子含義相同。k1表示路由系數(shù)，在DL380 Gen8集群環(huán)境下為常數(shù)65；k2表示應(yīng)用優(yōu)化系數(shù)，在DL380 Gen8集群環(huán)境下為常數(shù)600。

5.1RowKey的設(shè)計(jì)

RowKey的設(shè)計(jì)是對(duì)查詢性能評(píng)估算法中R1因子的優(yōu)化。HTable的RowKey是用來檢索記錄的主鍵，訪問HBase Table的方式只有三種，分別是通過單個(gè)RowKey訪問、通過RowKey的range訪問、全表掃描。因而RowKey的設(shè)計(jì)就與查詢條件緊密相關(guān)，RowKey的設(shè)計(jì)好壞也直接影響到查詢的性能和查詢條件的靈活性。

流量經(jīng)營DPI數(shù)據(jù)的查詢條件是根據(jù)用戶號(hào)碼和時(shí)間范圍來檢索該號(hào)碼在該時(shí)間范圍內(nèi)的所有記錄，那么流量經(jīng)營DPI數(shù)據(jù)的Htable RowKey設(shè)計(jì)為：手機(jī)號(hào)碼MDN（15位）+開始時(shí)間Start Time（14位）+協(xié)議類型ProtocolID（2位）+時(shí)長DURATION（9位）。因以上字段的數(shù)據(jù)在檢索和排序時(shí)都是按數(shù)字序來排序的，因而所有字段都按固定長度拼接，長度不足則左補(bǔ)0。按照以上設(shè)計(jì)，當(dāng)按照手機(jī)號(hào)碼和開始時(shí)間查詢記錄時(shí)，可以直接通過-ROOT-表尋址、.META.表尋址兩次即可找到本次查詢所對(duì)應(yīng)的Region。

5.2負(fù)載均衡設(shè)計(jì)

負(fù)載均衡設(shè)計(jì)是對(duì)查詢性能評(píng)估算法中C1因子的優(yōu)化。查詢服務(wù)的吞吐量易受限于單臺(tái)PCServer的處理能力，經(jīng)過試驗(yàn)，DL380 Gen8的查詢平均時(shí)延不超過0.05s的情況下，最大允許的并發(fā)查詢用戶數(shù)為120個(gè)。那么在PCServer集群環(huán)境下查詢服務(wù)也須使用分布式結(jié)構(gòu)，且各主機(jī)對(duì)查詢請(qǐng)求負(fù)載均衡[7]。按照以上依據(jù)，采用Nginx+Tomcat的負(fù)載均衡架構(gòu)，將查詢消息通過Nginx負(fù)載均衡分發(fā)到4臺(tái)主機(jī)上。按照該負(fù)載均衡的設(shè)計(jì)，經(jīng)過試驗(yàn)，4臺(tái)主機(jī)在查詢時(shí)延不超過0.05s的情況下，最大允許的并發(fā)用戶數(shù)達(dá)到450個(gè)。

5.3查詢應(yīng)用的優(yōu)化

讀表操作是對(duì)查詢性能評(píng)估算法中因子λ1的優(yōu)化，具體優(yōu)化點(diǎn)包括以下6點(diǎn)：

（1）多HTable并發(fā)讀

創(chuàng)建多個(gè)HTable客戶端用于讀操作，提高讀數(shù)據(jù)的吞吐量。

（2）Scanner Caching

通過調(diào)用HTable.setScannerCaching(int scannerCaching)可以設(shè)置HBase scanner一次從服務(wù)端抓取的數(shù)據(jù)條數(shù)，默認(rèn)情況下一次一條。通過將此值設(shè)置成一個(gè)合理的值，可以減少scan過程中next()的時(shí)間開銷[7]。

（3）Scan Attribute Selection

scan時(shí)指定需要的Column Family，可以減少網(wǎng)絡(luò)傳輸數(shù)據(jù)量，否則默認(rèn)scan操作會(huì)返回整行所有Column Family的數(shù)據(jù)[8]。

（4）Close ResultScanner

通過scan取完數(shù)據(jù)后，關(guān)閉ResultScanner，否則RegionServer可能會(huì)出現(xiàn)資源爭用的問題。

（5）批量讀

通過調(diào)用HTable.get(Get)方法可以根據(jù)一個(gè)指定的RowKey獲取一行記錄，同樣HBase提供了另一個(gè)方法：通過調(diào)用HTable.get(List)方法可以根據(jù)一個(gè)指定的RowKey列表，批量獲取多行記錄，只需要一次網(wǎng)絡(luò)I/O開銷，對(duì)于對(duì)數(shù)據(jù)實(shí)時(shí)性要求高而且網(wǎng)絡(luò)傳輸RTT高的情景，可帶來明顯的性能提升[9]。

（6）緩存查詢結(jié)果

對(duì)于頻繁查詢HBase的應(yīng)用場景，可以考慮在應(yīng)用程序中做緩存，當(dāng)有新的查詢請(qǐng)求時(shí)，首先在緩存中查找，如果存在則直接返回，不再查詢HBase；否則對(duì)HBase發(fā)起讀請(qǐng)求查詢，然后在應(yīng)用程序中將查詢結(jié)果緩存起來。至于緩存的替換策略，可以考慮LRU等常用的策略[9]。

5.4查詢性能結(jié)果對(duì)比分析

通過以上優(yōu)化，查詢50億數(shù)據(jù)優(yōu)化前后最終測試結(jié)果如表4所示：

表4數(shù)據(jù)優(yōu)化前后查詢性能結(jié)果對(duì)比

查詢

方法 虛擬用戶數(shù)/個(gè) 優(yōu)化前ATRT/s 優(yōu)化前TPS 優(yōu)化后ATRT/s 優(yōu)化后TPS

查50億 300 0.785 219 0.039 4 626

結(jié)合查詢的極限性能測評(píng)算法對(duì)以上結(jié)果進(jìn)行分析：

（1）優(yōu)化前

結(jié)論一：每次查詢的尋址次數(shù)為4次，比理論最小尋址次數(shù)多了2次，可優(yōu)化HTable表設(shè)計(jì)和RowKey設(shè)計(jì)，減少查詢的尋址次數(shù)；

結(jié)論二：查詢的應(yīng)用只部署在1臺(tái)機(jī)器上，需使用負(fù)載均衡的分布式查詢，發(fā)揮所有機(jī)器的作用；

結(jié)論三：根據(jù)以上性能測評(píng)算法計(jì)算出的和為0.785與224，與實(shí)際測試結(jié)果0.785和219近似。

（2）優(yōu)化后

結(jié)論一：每次查詢的尋址次數(shù)為2次，已經(jīng)達(dá)到最優(yōu)的查詢尋址路徑；

結(jié)論二：查詢的應(yīng)用使用是分布在6臺(tái)機(jī)器上的，充分發(fā)揮了每臺(tái)機(jī)器的作用；

結(jié)論三：根據(jù)以上性能測評(píng)算法計(jì)算出的和為0.04和4 614，與實(shí)際測試結(jié)果0.039與4 626近似。

6 結(jié)論

本文論述了電信企業(yè)在流量經(jīng)營背景下，基于Hadoop平臺(tái)的一種新的數(shù)據(jù)服務(wù)架構(gòu)?；贖adoop平臺(tái)搭建的分布式數(shù)據(jù)服務(wù)系統(tǒng)可以提供海量數(shù)據(jù)的高速入庫與查詢性能。同時(shí)本文通過真實(shí)實(shí)驗(yàn)數(shù)據(jù)，總結(jié)了在該架構(gòu)下性能優(yōu)化的一般方案和性能計(jì)算模型，通過這些性能優(yōu)化方案可以將數(shù)據(jù)服務(wù)的質(zhì)量提升到新的高度。

參考文獻(xiàn)：

[1] 蔡斌,陳湘萍. Hadoop技術(shù)內(nèi)幕：深入解析Hadoop Common和HDFS架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)原理[M]. 北京: 機(jī)械工業(yè)出版社, 2013.

[2] 董西成. Hadoop技術(shù)內(nèi)幕：深入解析MapReduce架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)原理[M]. 北京: 機(jī)械工業(yè)出版社, 2013.

[3] Lars George. HBase: The Definitive Guide[M]. O'Reilly, 2012.

[4] 陳能技,郭柏雅. 性能測試診斷分析與優(yōu)化[M]. 北京: 電子工業(yè)出版社, 2012.

[5] Apache. HUG8: January HBase User Group at StumbleUpon[EB/OL]. (2010-07-27). http://www.meetup.com/hbaseusergroup/events/12241393/.

[6] Apache. The Apache HBaseTM Reference Guide[EB/OL]. (2013-06-11). http://hbase.apache.org/book.html#configuration.

[7] 林偉偉. 一種改進(jìn)的Hadoop數(shù)據(jù)放置策略[J]. 華南理工大學(xué)學(xué)報(bào)：自然科學(xué)版, 2012(1): 36-39.

[8] 張榆,馬友忠,孟小峰. 一種基于HBase的高效空間關(guān)鍵字查詢策略[J]. 小型微型計(jì)算機(jī)系統(tǒng), 2012(10): 72-74.

[9] European Conference, ServiceWave 2011 4th. Enhancing Query Support in HBase via an Extended Coprocessors Framework[C]. 2011.★

作者簡介

陳娜：高級(jí)工程師，碩士畢業(yè)于華中科技大學(xué)，現(xiàn)任職于中國電信股份有限公司廣州研究院，主要從事電信IT支撐系統(tǒng)的相關(guān)研究工作。

張金娟：工程師，碩士畢業(yè)于華南理工大學(xué)通信與信息系統(tǒng)專業(yè)，現(xiàn)任職于中國電信股份有限公司廣州研究院，主要從事IT系統(tǒng)性能評(píng)測及調(diào)優(yōu)方面的工作和研究。

劉智瓊：高級(jí)工程師，碩士畢業(yè)于湖南大學(xué)，現(xiàn)任職于中國電信股份有限公司廣州研究院，研究方向?yàn)殡娦胚\(yùn)營商支撐系統(tǒng)。

endprint

5.2負(fù)載均衡設(shè)計(jì)

負(fù)載均衡設(shè)計(jì)是對(duì)查詢性能評(píng)估算法中C1因子的優(yōu)化。查詢服務(wù)的吞吐量易受限于單臺(tái)PCServer的處理能力，經(jīng)過試驗(yàn)，DL380 Gen8的查詢平均時(shí)延不超過0.05s的情況下，最大允許的并發(fā)查詢用戶數(shù)為120個(gè)。那么在PCServer集群環(huán)境下查詢服務(wù)也須使用分布式結(jié)構(gòu)，且各主機(jī)對(duì)查詢請(qǐng)求負(fù)載均衡[7]。按照以上依據(jù)，采用Nginx+Tomcat的負(fù)載均衡架構(gòu)，將查詢消息通過Nginx負(fù)載均衡分發(fā)到4臺(tái)主機(jī)上。按照該負(fù)載均衡的設(shè)計(jì)，經(jīng)過試驗(yàn)，4臺(tái)主機(jī)在查詢時(shí)延不超過0.05s的情況下，最大允許的并發(fā)用戶數(shù)達(dá)到450個(gè)。

5.3查詢應(yīng)用的優(yōu)化

讀表操作是對(duì)查詢性能評(píng)估算法中因子λ1的優(yōu)化，具體優(yōu)化點(diǎn)包括以下6點(diǎn)：

（1）多HTable并發(fā)讀

創(chuàng)建多個(gè)HTable客戶端用于讀操作，提高讀數(shù)據(jù)的吞吐量。

（2）Scanner Caching

通過調(diào)用HTable.setScannerCaching(int scannerCaching)可以設(shè)置HBase scanner一次從服務(wù)端抓取的數(shù)據(jù)條數(shù)，默認(rèn)情況下一次一條。通過將此值設(shè)置成一個(gè)合理的值，可以減少scan過程中next()的時(shí)間開銷[7]。

（3）Scan Attribute Selection

scan時(shí)指定需要的Column Family，可以減少網(wǎng)絡(luò)傳輸數(shù)據(jù)量，否則默認(rèn)scan操作會(huì)返回整行所有Column Family的數(shù)據(jù)[8]。

（4）Close ResultScanner

通過scan取完數(shù)據(jù)后，關(guān)閉ResultScanner，否則RegionServer可能會(huì)出現(xiàn)資源爭用的問題。

（5）批量讀

通過調(diào)用HTable.get(Get)方法可以根據(jù)一個(gè)指定的RowKey獲取一行記錄，同樣HBase提供了另一個(gè)方法：通過調(diào)用HTable.get(List)方法可以根據(jù)一個(gè)指定的RowKey列表，批量獲取多行記錄，只需要一次網(wǎng)絡(luò)I/O開銷，對(duì)于對(duì)數(shù)據(jù)實(shí)時(shí)性要求高而且網(wǎng)絡(luò)傳輸RTT高的情景，可帶來明顯的性能提升[9]。

（6）緩存查詢結(jié)果

對(duì)于頻繁查詢HBase的應(yīng)用場景，可以考慮在應(yīng)用程序中做緩存，當(dāng)有新的查詢請(qǐng)求時(shí)，首先在緩存中查找，如果存在則直接返回，不再查詢HBase；否則對(duì)HBase發(fā)起讀請(qǐng)求查詢，然后在應(yīng)用程序中將查詢結(jié)果緩存起來。至于緩存的替換策略，可以考慮LRU等常用的策略[9]。

5.4查詢性能結(jié)果對(duì)比分析

通過以上優(yōu)化，查詢50億數(shù)據(jù)優(yōu)化前后最終測試結(jié)果如表4所示：

表4數(shù)據(jù)優(yōu)化前后查詢性能結(jié)果對(duì)比

查詢

方法 虛擬用戶數(shù)/個(gè) 優(yōu)化前ATRT/s 優(yōu)化前TPS 優(yōu)化后ATRT/s 優(yōu)化后TPS

查50億 300 0.785 219 0.039 4 626

結(jié)合查詢的極限性能測評(píng)算法對(duì)以上結(jié)果進(jìn)行分析：

（1）優(yōu)化前

結(jié)論一：每次查詢的尋址次數(shù)為4次，比理論最小尋址次數(shù)多了2次，可優(yōu)化HTable表設(shè)計(jì)和RowKey設(shè)計(jì)，減少查詢的尋址次數(shù)；

結(jié)論二：查詢的應(yīng)用只部署在1臺(tái)機(jī)器上，需使用負(fù)載均衡的分布式查詢，發(fā)揮所有機(jī)器的作用；

結(jié)論三：根據(jù)以上性能測評(píng)算法計(jì)算出的和為0.785與224，與實(shí)際測試結(jié)果0.785和219近似。

（2）優(yōu)化后

結(jié)論一：每次查詢的尋址次數(shù)為2次，已經(jīng)達(dá)到最優(yōu)的查詢尋址路徑；

結(jié)論二：查詢的應(yīng)用使用是分布在6臺(tái)機(jī)器上的，充分發(fā)揮了每臺(tái)機(jī)器的作用；

結(jié)論三：根據(jù)以上性能測評(píng)算法計(jì)算出的和為0.04和4 614，與實(shí)際測試結(jié)果0.039與4 626近似。

6 結(jié)論

本文論述了電信企業(yè)在流量經(jīng)營背景下，基于Hadoop平臺(tái)的一種新的數(shù)據(jù)服務(wù)架構(gòu)?；贖adoop平臺(tái)搭建的分布式數(shù)據(jù)服務(wù)系統(tǒng)可以提供海量數(shù)據(jù)的高速入庫與查詢性能。同時(shí)本文通過真實(shí)實(shí)驗(yàn)數(shù)據(jù)，總結(jié)了在該架構(gòu)下性能優(yōu)化的一般方案和性能計(jì)算模型，通過這些性能優(yōu)化方案可以將數(shù)據(jù)服務(wù)的質(zhì)量提升到新的高度。

參考文獻(xiàn)：

[1] 蔡斌,陳湘萍. Hadoop技術(shù)內(nèi)幕：深入解析Hadoop Common和HDFS架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)原理[M]. 北京: 機(jī)械工業(yè)出版社, 2013.

[2] 董西成. Hadoop技術(shù)內(nèi)幕：深入解析MapReduce架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)原理[M]. 北京: 機(jī)械工業(yè)出版社, 2013.

[3] Lars George. HBase: The Definitive Guide[M]. O'Reilly, 2012.

[4] 陳能技,郭柏雅. 性能測試診斷分析與優(yōu)化[M]. 北京: 電子工業(yè)出版社, 2012.

[5] Apache. HUG8: January HBase User Group at StumbleUpon[EB/OL]. (2010-07-27). http://www.meetup.com/hbaseusergroup/events/12241393/.

[6] Apache. The Apache HBaseTM Reference Guide[EB/OL]. (2013-06-11). http://hbase.apache.org/book.html#configuration.

[7] 林偉偉. 一種改進(jìn)的Hadoop數(shù)據(jù)放置策略[J]. 華南理工大學(xué)學(xué)報(bào)：自然科學(xué)版, 2012(1): 36-39.

[8] 張榆,馬友忠,孟小峰. 一種基于HBase的高效空間關(guān)鍵字查詢策略[J]. 小型微型計(jì)算機(jī)系統(tǒng), 2012(10): 72-74.

[9] European Conference, ServiceWave 2011 4th. Enhancing Query Support in HBase via an Extended Coprocessors Framework[C]. 2011.★

作者簡介

陳娜：高級(jí)工程師，碩士畢業(yè)于華中科技大學(xué)，現(xiàn)任職于中國電信股份有限公司廣州研究院，主要從事電信IT支撐系統(tǒng)的相關(guān)研究工作。

張金娟：工程師，碩士畢業(yè)于華南理工大學(xué)通信與信息系統(tǒng)專業(yè)，現(xiàn)任職于中國電信股份有限公司廣州研究院，主要從事IT系統(tǒng)性能評(píng)測及調(diào)優(yōu)方面的工作和研究。

劉智瓊：高級(jí)工程師，碩士畢業(yè)于湖南大學(xué)，現(xiàn)任職于中國電信股份有限公司廣州研究院，研究方向?yàn)殡娦胚\(yùn)營商支撐系統(tǒng)。

endprint

5.2負(fù)載均衡設(shè)計(jì)

負(fù)載均衡設(shè)計(jì)是對(duì)查詢性能評(píng)估算法中C1因子的優(yōu)化。查詢服務(wù)的吞吐量易受限于單臺(tái)PCServer的處理能力，經(jīng)過試驗(yàn)，DL380 Gen8的查詢平均時(shí)延不超過0.05s的情況下，最大允許的并發(fā)查詢用戶數(shù)為120個(gè)。那么在PCServer集群環(huán)境下查詢服務(wù)也須使用分布式結(jié)構(gòu)，且各主機(jī)對(duì)查詢請(qǐng)求負(fù)載均衡[7]。按照以上依據(jù)，采用Nginx+Tomcat的負(fù)載均衡架構(gòu)，將查詢消息通過Nginx負(fù)載均衡分發(fā)到4臺(tái)主機(jī)上。按照該負(fù)載均衡的設(shè)計(jì)，經(jīng)過試驗(yàn)，4臺(tái)主機(jī)在查詢時(shí)延不超過0.05s的情況下，最大允許的并發(fā)用戶數(shù)達(dá)到450個(gè)。

5.3查詢應(yīng)用的優(yōu)化

讀表操作是對(duì)查詢性能評(píng)估算法中因子λ1的優(yōu)化，具體優(yōu)化點(diǎn)包括以下6點(diǎn)：

（1）多HTable并發(fā)讀

創(chuàng)建多個(gè)HTable客戶端用于讀操作，提高讀數(shù)據(jù)的吞吐量。

（2）Scanner Caching

通過調(diào)用HTable.setScannerCaching(int scannerCaching)可以設(shè)置HBase scanner一次從服務(wù)端抓取的數(shù)據(jù)條數(shù)，默認(rèn)情況下一次一條。通過將此值設(shè)置成一個(gè)合理的值，可以減少scan過程中next()的時(shí)間開銷[7]。

（3）Scan Attribute Selection

scan時(shí)指定需要的Column Family，可以減少網(wǎng)絡(luò)傳輸數(shù)據(jù)量，否則默認(rèn)scan操作會(huì)返回整行所有Column Family的數(shù)據(jù)[8]。

（4）Close ResultScanner

通過scan取完數(shù)據(jù)后，關(guān)閉ResultScanner，否則RegionServer可能會(huì)出現(xiàn)資源爭用的問題。

（5）批量讀

通過調(diào)用HTable.get(Get)方法可以根據(jù)一個(gè)指定的RowKey獲取一行記錄，同樣HBase提供了另一個(gè)方法：通過調(diào)用HTable.get(List)方法可以根據(jù)一個(gè)指定的RowKey列表，批量獲取多行記錄，只需要一次網(wǎng)絡(luò)I/O開銷，對(duì)于對(duì)數(shù)據(jù)實(shí)時(shí)性要求高而且網(wǎng)絡(luò)傳輸RTT高的情景，可帶來明顯的性能提升[9]。

（6）緩存查詢結(jié)果

對(duì)于頻繁查詢HBase的應(yīng)用場景，可以考慮在應(yīng)用程序中做緩存，當(dāng)有新的查詢請(qǐng)求時(shí)，首先在緩存中查找，如果存在則直接返回，不再查詢HBase；否則對(duì)HBase發(fā)起讀請(qǐng)求查詢，然后在應(yīng)用程序中將查詢結(jié)果緩存起來。至于緩存的替換策略，可以考慮LRU等常用的策略[9]。

5.4查詢性能結(jié)果對(duì)比分析

通過以上優(yōu)化，查詢50億數(shù)據(jù)優(yōu)化前后最終測試結(jié)果如表4所示：

表4數(shù)據(jù)優(yōu)化前后查詢性能結(jié)果對(duì)比

查詢

方法 虛擬用戶數(shù)/個(gè) 優(yōu)化前ATRT/s 優(yōu)化前TPS 優(yōu)化后ATRT/s 優(yōu)化后TPS

查50億 300 0.785 219 0.039 4 626

結(jié)合查詢的極限性能測評(píng)算法對(duì)以上結(jié)果進(jìn)行分析：

（1）優(yōu)化前

結(jié)論一：每次查詢的尋址次數(shù)為4次，比理論最小尋址次數(shù)多了2次，可優(yōu)化HTable表設(shè)計(jì)和RowKey設(shè)計(jì)，減少查詢的尋址次數(shù)；

結(jié)論二：查詢的應(yīng)用只部署在1臺(tái)機(jī)器上，需使用負(fù)載均衡的分布式查詢，發(fā)揮所有機(jī)器的作用；

結(jié)論三：根據(jù)以上性能測評(píng)算法計(jì)算出的和為0.785與224，與實(shí)際測試結(jié)果0.785和219近似。

（2）優(yōu)化后

結(jié)論一：每次查詢的尋址次數(shù)為2次，已經(jīng)達(dá)到最優(yōu)的查詢尋址路徑；

結(jié)論二：查詢的應(yīng)用使用是分布在6臺(tái)機(jī)器上的，充分發(fā)揮了每臺(tái)機(jī)器的作用；

結(jié)論三：根據(jù)以上性能測評(píng)算法計(jì)算出的和為0.04和4 614，與實(shí)際測試結(jié)果0.039與4 626近似。

6 結(jié)論

本文論述了電信企業(yè)在流量經(jīng)營背景下，基于Hadoop平臺(tái)的一種新的數(shù)據(jù)服務(wù)架構(gòu)?；贖adoop平臺(tái)搭建的分布式數(shù)據(jù)服務(wù)系統(tǒng)可以提供海量數(shù)據(jù)的高速入庫與查詢性能。同時(shí)本文通過真實(shí)實(shí)驗(yàn)數(shù)據(jù)，總結(jié)了在該架構(gòu)下性能優(yōu)化的一般方案和性能計(jì)算模型，通過這些性能優(yōu)化方案可以將數(shù)據(jù)服務(wù)的質(zhì)量提升到新的高度。

參考文獻(xiàn)：

[1] 蔡斌,陳湘萍. Hadoop技術(shù)內(nèi)幕：深入解析Hadoop Common和HDFS架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)原理[M]. 北京: 機(jī)械工業(yè)出版社, 2013.

[2] 董西成. Hadoop技術(shù)內(nèi)幕：深入解析MapReduce架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)原理[M]. 北京: 機(jī)械工業(yè)出版社, 2013.

[3] Lars George. HBase: The Definitive Guide[M]. O'Reilly, 2012.

[4] 陳能技,郭柏雅. 性能測試診斷分析與優(yōu)化[M]. 北京: 電子工業(yè)出版社, 2012.

[5] Apache. HUG8: January HBase User Group at StumbleUpon[EB/OL]. (2010-07-27). http://www.meetup.com/hbaseusergroup/events/12241393/.

[6] Apache. The Apache HBaseTM Reference Guide[EB/OL]. (2013-06-11). http://hbase.apache.org/book.html#configuration.

[7] 林偉偉. 一種改進(jìn)的Hadoop數(shù)據(jù)放置策略[J]. 華南理工大學(xué)學(xué)報(bào)：自然科學(xué)版, 2012(1): 36-39.

[8] 張榆,馬友忠,孟小峰. 一種基于HBase的高效空間關(guān)鍵字查詢策略[J]. 小型微型計(jì)算機(jī)系統(tǒng), 2012(10): 72-74.

[9] European Conference, ServiceWave 2011 4th. Enhancing Query Support in HBase via an Extended Coprocessors Framework[C]. 2011.★

作者簡介

陳娜：高級(jí)工程師，碩士畢業(yè)于華中科技大學(xué)，現(xiàn)任職于中國電信股份有限公司廣州研究院，主要從事電信IT支撐系統(tǒng)的相關(guān)研究工作。

張金娟：工程師，碩士畢業(yè)于華南理工大學(xué)通信與信息系統(tǒng)專業(yè)，現(xiàn)任職于中國電信股份有限公司廣州研究院，主要從事IT系統(tǒng)性能評(píng)測及調(diào)優(yōu)方面的工作和研究。

劉智瓊：高級(jí)工程師，碩士畢業(yè)于湖南大學(xué)，現(xiàn)任職于中國電信股份有限公司廣州研究院，研究方向?yàn)殡娦胚\(yùn)營商支撐系統(tǒng)。

endprint