歐陽秀平　李婷婷　陳榮添　朱旭明

（中國聯(lián)通廣東省分公司，廣東　廣州　510627）

百億級話單存儲查詢系統(tǒng)設(shè)計與實現(xiàn)

歐陽秀平李婷婷陳榮添朱旭明

（中國聯(lián)通廣東省分公司，廣東廣州510627）

隨著廣東聯(lián)通市場規(guī)模的擴大，產(chǎn)品與技術(shù)的不斷發(fā)展，業(yè)務(wù)數(shù)據(jù)量呈現(xiàn)指數(shù)級增長，客戶對話單詳單查詢的要求越來越高，對海量數(shù)據(jù)的高效插入和讀取變得越來越重要。面對上百億條話單記錄，如何保證查詢的高效性、高可靠性、高可用性成為了首要科研課題。本文提出利用HBase技術(shù)可在廉價服務(wù)器上搭建起大規(guī)模結(jié)構(gòu)化存儲集群，而且查詢速率可以達到秒級。

話單查詢；HBase；高效性；高可靠性

1　引言

隨著廣東聯(lián)通業(yè)務(wù)量的不斷發(fā)展以及運營商間市場競爭日益激烈，客戶對話單詳單查詢要求也越來越高，查詢方式也日益豐富。為支持客戶通過營業(yè)廳、自助終端機、互聯(lián)網(wǎng)終端及移動智能終端等方式隨時隨地進行詳單查詢，迫切需要建立一個支持高并發(fā)、查詢響應(yīng)快速、支持長期歷史數(shù)據(jù)查詢的詳單查詢系統(tǒng)，提升詳單查詢的服務(wù)能力，提高客戶滿意度。本文以短信話單為例子，廣東聯(lián)通全省的短信量一天就達到2～6億條，尤其是月初，會有大量的SP短信下發(fā)，短信存儲周期為三個月，如何在將近300億條短信記錄中快速查詢并且得到快速響應(yīng)成了首要問題。原系統(tǒng)采用RMDBS技術(shù)，隨著廣東聯(lián)通用戶量的不斷增長，雖然點對點短信有逐年下降的趨勢，但是SP短信數(shù)據(jù)量卻是在節(jié)節(jié)攀升。原系統(tǒng)在此時已經(jīng)不能滿足快速查詢響應(yīng)的需求，導(dǎo)致影響客服人員處理投訴時的效率。在此背景下，廣東聯(lián)通實現(xiàn)了采用HBase分布式列式存儲數(shù)據(jù)庫為核心的短信話單存儲查詢系統(tǒng)，在百億條話單記錄中查詢能達到秒級的效應(yīng)，大大提高了查詢效率，為客服人員解決客戶投訴問題帶來了巨大的便利。

2　研究背景

2.1HBase簡介

HBase是分布式、面向列的存儲系統(tǒng)，提供實時讀寫和隨機訪問海量數(shù)據(jù)集。最基本的單位是列Column，一列或多列形成一行，并由唯一的行鍵Rowkey來確定存儲。一個表中有若干行，其中每列可能有多個版本，默認(rèn)版本號是在單元格插入時由HBase自動分配的時間戳Time Stamp。一行由若干列組成，若干列又構(gòu)成一個列簇ColumnFamily，常見的引用列的格式為family:qualifier，qualifer是任意的字節(jié)數(shù)組。

2.2系統(tǒng)架構(gòu)

廣東聯(lián)通短信存儲查詢系統(tǒng)是采用基于Hadoop的 HBase分布式列式數(shù)據(jù)庫實現(xiàn)的，該系統(tǒng)由Client（客戶端）、Zookeeper（協(xié)調(diào)系統(tǒng)）、Master（管理者）和Region Server（存儲數(shù)據(jù)）四個角色組成，廣東聯(lián)通短信存儲查詢系統(tǒng)架構(gòu)圖如圖1所示。

圖1　短信存儲查詢系統(tǒng)總體架構(gòu)圖

系統(tǒng)共6臺x86服務(wù)器，由三臺Zookeeper服務(wù)器組成Zookeeper cluster，四臺Region server服務(wù)器組成Region server cluster，一臺服務(wù)器可同時擔(dān)任Zookeeper角色和Region server角色，一臺作為Master，一臺作為Client。Client包含訪問HBase的接口，維護一些cache比如Region的位置信息等，可以加快對HBase的訪問。Zookeeper存儲了所有Region的尋址入口，可以實時監(jiān)控Region Server的狀態(tài)，將Region Server的實時動態(tài)消息通知Master。Master為Region Server分配Region，負(fù)責(zé)Region Server的負(fù)載均衡。Region Server維護Master分配給它的Region，處理Region的I/O請求。

短信話單數(shù)據(jù)導(dǎo)入到HBase集群后，HBase中所有的數(shù)據(jù)文件都存儲在Hadoop HDFS文件系統(tǒng)上，以HFile的格式進行存儲，HFile是HBase中KeyValue數(shù)據(jù)的存儲格式，HFile是Hadoop的二進制格式文件，StoreFile是對HFile做了輕量級的包裝，即StoreFile底層就是HFile。

短信記錄查詢時，HBase Client端連接Zookeeper Qurom，通過Zookeeper組建Client獲得管理-ROOT-Region的Server，Client訪問管理-ROOT-的Server，-ROOT-表存儲了-META表的Region索引，在-META-中記錄了HBase所有表信息，從而獲得Region這一行的信息。短信記錄定位的算法流程如圖2所示。

圖2　短信記錄查詢定位算法流程

3　系統(tǒng)實現(xiàn)

3.1話單數(shù)據(jù)入庫

HBase數(shù)據(jù)入庫有三種方式：（1）生成HFile方式，使用bulkload導(dǎo)入工具生成HFile的過程比較慢，生成HFile后寫入HBase非?？欤旧暇褪荋DFS上的mv過程，但是適合初次入庫；（2）MapReduce方式，開始會很快，但是由于Mapreduce和HBase競爭資源，到一個特定的時間點會變很慢；（3）JavaAPI方式，多客戶端，多線程同時入庫，目前看來是最好的方式，Client和RegionServer分開，硬盤讀寫分開，瓶頸只在網(wǎng)絡(luò)和內(nèi)存上，但是只提供API，易用性是短板。

本系統(tǒng)采用Java API的入庫方式，Java的API方式是采用Put進行入庫，但是該方式每添加一條記錄默認(rèn)就會調(diào)用一次RPC，影響入庫效率。于是將HTable的setAutoFlush設(shè)置成false，使其支持客戶端批量更新，用Scanner來控制一次性緩存量，當(dāng)Put填完客戶端再一次性調(diào)用RPC發(fā)送到服務(wù)端，并且修改WAL方式，將wirteToWAL設(shè)置成false提高了部分性能。在大量數(shù)據(jù)入庫時往往會因為觸發(fā)compaction而影響入庫效率，我們經(jīng)過優(yōu)化將major_compaction修改成閑時觸發(fā)，而不是在入庫時觸發(fā)compaction，大大提高了入庫效率。

此測試是為了研究多線程導(dǎo)入速率與線程數(shù)的關(guān)系，因此只是將數(shù)據(jù)導(dǎo)入同一個表，測試程序中每個線程分別讀取一個本地文件，同時寫入一個表中，結(jié)果見表1。

表1　線程數(shù)與導(dǎo)入速率的關(guān)系

可見，增加線程數(shù)可以在一定程度上提高導(dǎo)入速率。本系統(tǒng)最后采用單客戶端同時啟動10個線程導(dǎo)入方式。

3.2存儲表結(jié)構(gòu)設(shè)計

HBase是以表的形式存儲數(shù)據(jù)，最基本的單位是列（Column），一列或多列形成一行（Row），若干列又構(gòu)成一個列簇（ColumnFamily），并且由唯一的行健（RowKey）來確定存儲，一個ColumnFamily的所有列存儲在同一個HFile里。庫表結(jié)構(gòu)設(shè)計得好與否直接影響到系統(tǒng)的查詢性能，最關(guān)鍵是庫表的Rowkey的設(shè)計，HBase的Table每一行存在一個唯一的Rowkey，并且是按照字典序列進行排列，Rowkey的設(shè)計如下所示：

RowKey=PhoneNumber+Time+Random

PhoneNumber是用戶的手機號或者SP端口號，Time是指該條話單記錄的時間，Random是五位隨機數(shù)，由于SP會在同一時間內(nèi)發(fā)送大量記錄，為了確保RowKey的唯一性，所以加入了5為Random數(shù)。

在邏輯上，HBase的表數(shù)據(jù)按照Rowkey進行字典排序，RowKey實際上是數(shù)據(jù)表的一級索引（Primary Index），由于HBase本身沒有二級索引（Secondary Index）機制，基于索引檢索數(shù)據(jù)只能單純地依靠Rowkey，為了支持多條件查詢，一般的做法是將所有可能作為查詢條件的字段拼接到Rowkey字段中，但是無論怎么設(shè)計，單一的Rowkey固有的局限性決定了它不可能有效地支持多條件查詢。為了同時滿足一條話單記錄支持主叫號碼查詢和被叫號碼查詢，不局限于單一的Rowkey在復(fù)雜查詢上的局限性，本系統(tǒng)提出了建立二級索引表很好地解決了該問題。

短信分為兩種：SP短信和點對點短信，SP短信是指通過SP端口號批量下發(fā)給用戶的短信，而點對點短信是指兩個用戶之間互相發(fā)送的短信，兩種短信記錄需要分開，本系統(tǒng)總共涉及4張表，表結(jié)構(gòu)如下所示：

(1)sp信息表

sp(spRowkey,columns:callingNum,columns:calledNum, columns:scCallType,columns:firstDVTime,columns:register-Time,columns:sendOutTime,columns:languageType,columns: retryCount,columns:messageStatus,columns:messageLength)

其中spRowkey是唯一標(biāo)示符，是由calledNum+register-Time+random組成，callingNum表示主叫號碼，calledNum表示被叫號碼，scCallType表示呼叫類別，firstDVTime表示首次下發(fā)時間，registerTime表示MO時間，sendOutTime表示MT時間，languageType表示編碼方案，retryCount表示重發(fā)次數(shù)，messageStatus表示發(fā)送返回狀態(tài)碼，messageLength表示消息長度。

(2)sp索引表

sp_index(spIndexRowkey,columns:spRowkey)

其中spIndexRowkey是唯一標(biāo)示符，是由callingNum+ registerTime+random組成，而spRowkey即sp信息表的Rowkey，由calledNum+registerTime+random組成。

點對點信息表

sp(p2pRowkey,columns:callingNum,columns:calledNum, columns:scCallType,columns:firstDVTime,columns:register-Time,columns:sendOutTime,columns:languageType,columns: retryCount,columns:messageStatus,columns:messageLength, columns:messageInfo)

其中p2pRowkey是唯一標(biāo)示符，是由callingNum+registerTime+random組成，callingNum表示主叫號碼，calledNum表示被叫號碼，scCallType表示呼叫類別，firstDVTime表示首次下發(fā)時間，registerTime表示MO時間，sendOutTime表示MT時間，languageType表示編碼方案，retryCount表示重發(fā)次數(shù)，messageStatus表示發(fā)送返回狀態(tài)碼，messageLength表示消息長度，messageInfo表示短信內(nèi)容（經(jīng)過加密處理）。

(3)點對點索引表

p2p_index(p2pIndexRowkey,columns:p2pRowkey)

其中p2pIndexRowkey是唯一標(biāo)示符，是由calledNum+ registerTime+random組成，而p2pRowkey即點對點信息表的Rowkey，由callingNum+registerTime+random組成。

3.3查詢性能測試

查詢情況分為三種情況：只輸入主叫號碼、只輸入被叫號碼、既輸入主叫又輸入被叫。根據(jù)查詢的需求，結(jié)合HBase的Rowkey唯一性，如果只輸入被叫號碼，直接查詢sp表即可，如果只輸入主叫號碼，則先查詢sp_index表找到sp表的Rowkey，再查詢sp表。

點對點表結(jié)構(gòu)設(shè)計和SP的表結(jié)構(gòu)類似，只是比SP的少了一列短信信息詳情，如果只輸入主叫號碼，直接查詢p2p表即可，如果只輸入被叫號碼，則先查詢p2p_index表找到p2p的Rowkey，再查詢p2p表。

使用單線程查詢客戶端，在指定時間范圍內(nèi)的所有HBase表中查詢某個指定手機號的所有記錄。HBase會按順序依次查詢所有時間范圍內(nèi)符合條件的記錄，測試結(jié)果見圖3，其中橫坐標(biāo)表示天，縱坐標(biāo)表示查詢耗費時間，單位為秒。

圖3　單線程查詢客戶端結(jié)果表

4　結(jié)論

本文介紹了基于分布式列式數(shù)據(jù)庫HBase的百億級話單存儲查詢系統(tǒng)方案設(shè)計與實現(xiàn)，該系統(tǒng)不僅提高了話單存儲查詢系統(tǒng)的查詢效率，對百億級的話單數(shù)能夠達到秒級的響應(yīng)，而且還提高了系統(tǒng)的靈活度，HBase提供了橫向擴展的能力，可以隨時根據(jù)業(yè)務(wù)量的發(fā)展情況添加或減少集群的節(jié)點，并且不會影響到集群其他節(jié)點的正常工作。此外還提高了系統(tǒng)的健壯性和可靠性，HBase集群內(nèi)部的Balance機制，可以使數(shù)據(jù)均勻分布在各個節(jié)點上，不會出現(xiàn)舊系統(tǒng)的設(shè)備存儲不均衡的情況。集群的數(shù)據(jù)有冗余備份，如果某臺設(shè)備出現(xiàn)宕機，集群的Master節(jié)點會將該臺設(shè)備的數(shù)據(jù)拷貝到其他節(jié)點上進行存儲，這種靈活的機制確保了集群數(shù)據(jù)不丟失。

[1]Jin Y，Deyu T，Yi Z．A distributed storage model for EHR based on HBase[C]//Information Management，Innovation Management and Industrial Engineering(ICIII)，2011 International Conference on．IEEE，2011，2：369-372．

[2]Chen Q K，Zhou L．HBase-based storage system for large-scale data in wireless sensor network[J]．Journal of Computer Applications，2012，32(7)：1920-1923．

[3]Vora M N．Hadoop-HBase for large-scale data[C]//Computer Science and Network Technology(ICCSNT)，2011 International Conference on. IEEE，2011，1：601-605．

[4]Franke C，Morin S，Chebotko A，et al．Distributed semantic web data management in HBase and MySQL cluster[C]//Cloud Computing (CLOUD)，2011 IEEE International Conference on．IEEE，2011：105-112．

[5]Huang J，Ouyang X，Jose J，et al．High-performance design of hbase with rdma over infiniband[C]//Parallel&Distributed Processing Symposium(IPDPS)，2012 IEEE 26th International．IEEE，2012：774-785．

[6]Konishetty V K，Kumar K A，Voruganti K，et al．Implementation and evaluation of scalable data structure over HBase[C]//Proceedings of the International Conference on Advances in Computing，Communications and Informatics．ACM，2012：1010-1018．

[7]Bai J．Feasibility analysis of big log data real time search based on Hbase and ElasticSearch[C]//Natural Computation(ICNC)，2013 Ninth International Conference on．IEEE，2013：1166-1170．

[8]Barton S，Dohnal V，Rigaux P．Similarity search in a very large scale using Hadoop and HBase[R]．Technical report，CEDRIC-Cnam，2012.

[9]Liu Jun，Li Tingting．Mining And Modeling the Dynamic Patterns of Service Providers in Cellular Data Network based on Big Data Analysis，China Communication，2013，12：25-36．

[10]Li Tingting，Liu Jun．Characterizing Service Providers Traffic of Mobile Internet Services in Cellular Data Network[C]//Intelligent Human-Machine Systems and Cybernetics，2013 5th International Conference on．IEEE，2013，1：134-139．

Design and Implementation of Call Bill Query and Store System in Ten Billion Level

Ouyang XiupingLi TingtingChen RongtianZhu Xuming
(China Unicom Guangdong Branch,Guangzhou 510627,Guangdong)

With the expansion of market size in Guangdong Unicom and the development of products and technology,the amount of business data is exponentially growing.The request of call bills query is higher and higher.The insertion and reading of massive data becomes more and more important.Facing with tens of billions of call records,it has become a major research topic that how to ensure the query efficiency,reliability and availability.This paper uses HBase technology in cheap server to build up large-scale structured storage clusters.The query rates can be in second level.

query HBase;high efficiency;high reliability

TP311.52

A

1008-6609(2016)06-0084-04

歐陽秀平，男，廣東人，碩士，工程師，研究方向：移動互聯(lián)網(wǎng)、大數(shù)據(jù)、信息化。