基于Hadoop平臺的電信大數(shù)據(jù)入庫及查詢性能優(yōu)化研究

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

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

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

中圖分類號：TP39文獻標識碼：A文章編號：1006-1010(2014)-07-0058-06

1 引言

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

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

2 系統(tǒng)功能架構設計

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

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

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

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

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

（3）接入層

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

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

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

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

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

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

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

HTTP業(yè)務 ASCII 65 14 25

WAP業(yè)務 ASCII 40 14 25

（2）驗證方法和評估指標

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

表2評估指標

評估點 評估指標

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

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

（3）硬件配置

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

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

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

（1）

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

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

根據(jù)實驗環(huán)境，對K系列參數(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)絡影響系數(shù)，在千兆以太網(wǎng)環(huán)境下為常數(shù)60 000；k5為軟系數(shù)，表示軟件層面的優(yōu)化系數(shù)，該值為常數(shù)120 000。當HBase的內核參數(shù)未做任何優(yōu)化時λ1的經(jīng)驗值為0.85左右，當HBase內核參數(shù)和應用做下文的10項優(yōu)化后，λ1的經(jīng)驗值為0.1。

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

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

（1）hbase.hregion.max.filesize的設置

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

（2）hbase.regionserver.handler.count的設置

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

（3）hbase.hregion.memstore.block.multiplier設置

這個參數(shù)的作用是當memstore的大小增至超過hbase.hregion.memstore.flush.size的2倍時，block所有請求，遏制風險進一步擴大，該參數(shù)的默認值是2。因流量經(jīng)營DPI數(shù)據(jù)寫操作的量非常大，故調整該值為3。

（4）hbase.hstore.blockingStoreFiles設置

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

endprint

（5）hfile.block.cache.size設置

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

4.2預分Region數(shù)量

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

4.3使用Snappy壓縮算法

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

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

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

（1）Auto Flush設置

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

（2）Write Buffer設置

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

（3）WAL Flag設置

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

（4）批量寫

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

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

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

4.5入庫性能結果對比分析

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

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

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

50 11小時46分 11.8 5小時20秒 28.1

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

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

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

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

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

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

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

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

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

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

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

（2）

（3）

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

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

5.1RowKey的設計

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

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

5.2負載均衡設計

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

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

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

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

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

（2）Scanner Caching

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

（3）Scan Attribute Selection

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

（4）Close ResultScanner

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

（5）批量讀

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

（6）緩存查詢結果

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

5.4查詢性能結果對比分析

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

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

查詢

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

查50億 300 0.785 219 0.039 4 626

結合查詢的極限性能測評算法對以上結果進行分析：

（1）優(yōu)化前

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

結論二：查詢的應用只部署在1臺機器上，需使用負載均衡的分布式查詢，發(fā)揮所有機器的作用；

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

（2）優(yōu)化后

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

結論二：查詢的應用使用是分布在6臺機器上的，充分發(fā)揮了每臺機器的作用；

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

6 結論

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

參考文獻：

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

[2] 董西成. Hadoop技術內幕：深入解析MapReduce架構設計與實現(xiàn)原理[M]. 北京: 機械工業(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] 林偉偉. 一種改進的Hadoop數(shù)據(jù)放置策略[J]. 華南理工大學學報：自然科學版, 2012(1): 36-39.

[8] 張榆,馬友忠,孟小峰. 一種基于HBase的高效空間關鍵字查詢策略[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.★

作者簡介

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

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

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

endprint

5.2負載均衡設計

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

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

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

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

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

（2）Scanner Caching

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

（3）Scan Attribute Selection

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

（4）Close ResultScanner

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

（5）批量讀

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

（6）緩存查詢結果

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

5.4查詢性能結果對比分析

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

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

查詢

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

查50億 300 0.785 219 0.039 4 626

結合查詢的極限性能測評算法對以上結果進行分析：

（1）優(yōu)化前

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

結論二：查詢的應用只部署在1臺機器上，需使用負載均衡的分布式查詢，發(fā)揮所有機器的作用；

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

（2）優(yōu)化后

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

結論二：查詢的應用使用是分布在6臺機器上的，充分發(fā)揮了每臺機器的作用；

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

6 結論

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

參考文獻：

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

[2] 董西成. Hadoop技術內幕：深入解析MapReduce架構設計與實現(xiàn)原理[M]. 北京: 機械工業(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] 林偉偉. 一種改進的Hadoop數(shù)據(jù)放置策略[J]. 華南理工大學學報：自然科學版, 2012(1): 36-39.

[8] 張榆,馬友忠,孟小峰. 一種基于HBase的高效空間關鍵字查詢策略[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.★

作者簡介

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

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

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

endprint

5.2負載均衡設計

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

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

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

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

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

（2）Scanner Caching

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

（3）Scan Attribute Selection

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

（4）Close ResultScanner

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

（5）批量讀

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

（6）緩存查詢結果

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

5.4查詢性能結果對比分析

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

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

查詢

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

查50億 300 0.785 219 0.039 4 626

結合查詢的極限性能測評算法對以上結果進行分析：

（1）優(yōu)化前

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

結論二：查詢的應用只部署在1臺機器上，需使用負載均衡的分布式查詢，發(fā)揮所有機器的作用；

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

（2）優(yōu)化后

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

結論二：查詢的應用使用是分布在6臺機器上的，充分發(fā)揮了每臺機器的作用；

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

6 結論

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

參考文獻：

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

[2] 董西成. Hadoop技術內幕：深入解析MapReduce架構設計與實現(xiàn)原理[M]. 北京: 機械工業(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] 林偉偉. 一種改進的Hadoop數(shù)據(jù)放置策略[J]. 華南理工大學學報：自然科學版, 2012(1): 36-39.

[8] 張榆,馬友忠,孟小峰. 一種基于HBase的高效空間關鍵字查詢策略[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.★

作者簡介

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

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

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

endprint