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

（中國聯通廣東省分公司，廣東　廣州　510627）

百億級話單存儲查詢系統設計與實現

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

（中國聯通廣東省分公司，廣東廣州510627）

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

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

1　引言

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

2　研究背景

2.1HBase簡介

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

2.2系統架構

廣東聯通短信存儲查詢系統是采用基于Hadoop的 HBase分布式列式數據庫實現的，該系統由Client（客戶端）、Zookeeper（協調系統）、Master（管理者）和Region Server（存儲數據）四個角色組成，廣東聯通短信存儲查詢系統架構圖如圖1所示。

圖1　短信存儲查詢系統總體架構圖

系統共6臺x86服務器，由三臺Zookeeper服務器組成Zookeeper cluster，四臺Region server服務器組成Region server cluster，一臺服務器可同時擔任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，負責Region Server的負載均衡。Region Server維護Master分配給它的Region，處理Region的I/O請求。

短信話單數據導入到HBase集群后，HBase中所有的數據文件都存儲在Hadoop HDFS文件系統上，以HFile的格式進行存儲，HFile是HBase中KeyValue數據的存儲格式，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　系統實現

3.1話單數據入庫

HBase數據入庫有三種方式：（1）生成HFile方式，使用bulkload導入工具生成HFile的過程比較慢，生成HFile后寫入HBase非?？?，基本上就是HDFS上的mv過程，但是適合初次入庫；（2）MapReduce方式，開始會很快，但是由于Mapreduce和HBase競爭資源，到一個特定的時間點會變很慢；（3）JavaAPI方式，多客戶端，多線程同時入庫，目前看來是最好的方式，Client和RegionServer分開，硬盤讀寫分開，瓶頸只在網絡和內存上，但是只提供API，易用性是短板。

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

此測試是為了研究多線程導入速率與線程數的關系，因此只是將數據導入同一個表，測試程序中每個線程分別讀取一個本地文件，同時寫入一個表中，結果見表1。

表1　線程數與導入速率的關系

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

3.2存儲表結構設計

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

RowKey=PhoneNumber+Time+Random

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

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

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

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

(2)sp索引表

sp_index(spIndexRowkey,columns:spRowkey)

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

(3)點對點索引表

p2p_index(p2pIndexRowkey,columns:p2pRowkey)

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

3.3查詢性能測試

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

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

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

圖3　單線程查詢客戶端結果表

4　結論

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

[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

歐陽秀平，男，廣東人，碩士，工程師，研究方向：移動互聯網、大數據、信息化。