百億級(jí)話單存儲(chǔ)查詢(xún)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

歐陽(yáng)秀平　李婷婷　陳榮添　朱旭明

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

百億級(jí)話單存儲(chǔ)查詢(xún)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

歐陽(yáng)秀平李婷婷陳榮添朱旭明

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

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

話單查詢(xún)；HBase；高效性；高可靠性

1　引言

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

2　研究背景

2.1HBase簡(jiǎn)介

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

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

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

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

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

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

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

圖2　短信記錄查詢(xún)定位算法流程

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

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

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

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

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

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

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

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

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

RowKey=PhoneNumber+Time+Random

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

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

短信分為兩種：SP短信和點(diǎn)對(duì)點(diǎn)短信，SP短信是指通過(guò)SP端口號(hào)批量下發(fā)給用戶(hù)的短信，而點(diǎn)對(duì)點(diǎn)短信是指兩個(gè)用戶(hù)之間互相發(fā)送的短信，兩種短信記錄需要分開(kāi)，本系統(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表示主叫號(hào)碼，calledNum表示被叫號(hào)碼，scCallType表示呼叫類(lèi)別，firstDVTime表示首次下發(fā)時(shí)間，registerTime表示MO時(shí)間，sendOutTime表示MT時(shí)間，languageType表示編碼方案，retryCount表示重發(fā)次數(shù)，messageStatus表示發(fā)送返回狀態(tài)碼，messageLength表示消息長(zhǎng)度。

(2)sp索引表

sp_index(spIndexRowkey,columns:spRowkey)

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

點(diǎn)對(duì)點(diǎn)信息表

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表示主叫號(hào)碼，calledNum表示被叫號(hào)碼，scCallType表示呼叫類(lèi)別，firstDVTime表示首次下發(fā)時(shí)間，registerTime表示MO時(shí)間，sendOutTime表示MT時(shí)間，languageType表示編碼方案，retryCount表示重發(fā)次數(shù)，messageStatus表示發(fā)送返回狀態(tài)碼，messageLength表示消息長(zhǎng)度，messageInfo表示短信內(nèi)容（經(jīng)過(guò)加密處理）。

(3)點(diǎn)對(duì)點(diǎn)索引表

p2p_index(p2pIndexRowkey,columns:p2pRowkey)

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

3.3查詢(xún)性能測(cè)試

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

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

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

圖3　單線程查詢(xún)客戶(hù)端結(jié)果表

4　結(jié)論

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

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