海量短信快速查詢系統(tǒng)

喻麗春

(福州外語外貿(mào)學(xué)院, 福建 福州 350202)

0 引 言

目前4 G網(wǎng)絡(luò)已經(jīng)全面普及，隨著移動互聯(lián)網(wǎng)的發(fā)展，電信運營商的用戶量和業(yè)務(wù)量急劇增多。由于移動支付等移動手機(jī)應(yīng)用的增多，短信驗證碼的使用日益廣泛，用戶對短信詳單的查詢需求也越來越多。為了支撐用戶在發(fā)生短信收發(fā)丟失問題時，隨時隨地進(jìn)行短信詳單數(shù)據(jù)查詢，迫切需要建立一個查詢速度快、周期長、方式多樣化的海量短信詳單查詢系統(tǒng)[1]。由于用戶量較大，每天產(chǎn)生的短信數(shù)據(jù)量達(dá)到數(shù)千萬級別。如何在海量的短信數(shù)據(jù)中根據(jù)用戶手機(jī)號和時間范圍快速查詢短信收發(fā)詳情成為當(dāng)前需要解決的首要問題。

傳統(tǒng)的短信查詢系統(tǒng)一般采用關(guān)系數(shù)據(jù)庫(如oracle，mysql等)。由于數(shù)據(jù)量較大，傳統(tǒng)數(shù)據(jù)庫在短信數(shù)據(jù)保存時一般只保留一周，無法支撐周期較長的短信數(shù)據(jù)查詢，而且查詢速度較慢，無法滿足用戶快速查詢短信收發(fā)情況的需求，在用戶投訴短信收發(fā)故障時，客服人員無法及時對用戶投訴進(jìn)行響應(yīng)和處理。

海量短信數(shù)據(jù)如何高效地存儲、組織、管理與發(fā)布,提高處理和分發(fā)效率,已成為迫切需要解決的問題。非關(guān)系型數(shù)據(jù)庫HBase的產(chǎn)生為這些問題提供了一種良好的解決方案[2-3]。

HBase是一種基于分布式文件系統(tǒng)hadoop的開源分布式數(shù)據(jù)庫，它是Google Bigtable架構(gòu)設(shè)計的一個開源實現(xiàn)，目前,最新版本幾乎實現(xiàn)了Bigtable的所有功能。和傳統(tǒng)的基于行模式的數(shù)據(jù)庫不同，HBase是基于列模式非結(jié)構(gòu)化數(shù)據(jù)存儲的數(shù)據(jù)庫，具有穩(wěn)定可靠、性能較高、靈活伸縮等特點[4]，比較適合用來實現(xiàn)海量短信快速查詢系統(tǒng)。

基于HBase的海量短信快速查詢系統(tǒng)包括三個部分;1)短信采集入庫;2)短信數(shù)據(jù)存儲模型設(shè)計;3)短信查詢接口實現(xiàn)。

1 短信采集入庫

要實現(xiàn)海量短信查詢系統(tǒng)，首先要實現(xiàn)短信數(shù)據(jù)采集入庫。

1.1 原始數(shù)據(jù)采集

短信按照類型分類可以分為P2P短信、在信短信、互通短信。這些短信通過短信網(wǎng)關(guān)采集。根據(jù)短信網(wǎng)關(guān)數(shù)據(jù)源采集協(xié)議的分類可以分為文件采集和數(shù)據(jù)庫采集。為了統(tǒng)一處理過程，針對數(shù)據(jù)庫采集，使用jdbc方式采集生成原始文件保存到采集服務(wù)器。針對FTP文件采集程序保存到采集服務(wù)器。為了保證數(shù)據(jù)的及時性，根據(jù)數(shù)據(jù)源特點，采用主動式采集,即通過定時輪訓(xùn)，發(fā)現(xiàn)數(shù)據(jù)源產(chǎn)生新數(shù)據(jù)，并且馬上啟動采集。

1.2 數(shù)據(jù)解析轉(zhuǎn)換

針對數(shù)據(jù)原始文件，使用文本處理工具awk解析文件，統(tǒng)一解析轉(zhuǎn)換為統(tǒng)一的tsv文件格式。統(tǒng)一轉(zhuǎn)換后的數(shù)據(jù)格式見表1。

表1 短信入庫統(tǒng)一格式

1.3 短信數(shù)據(jù)入庫

采集的數(shù)據(jù)最終要保存到HBase數(shù)據(jù)庫。研究發(fā)現(xiàn)，采集數(shù)據(jù)存儲到HBase的方法有以下三種[5]。

1)將采集數(shù)據(jù)格式化，轉(zhuǎn)換為HFile格式(即HBase在hadoop系統(tǒng)上的存儲格式)。然后通過HBase自帶的bulkload工具導(dǎo)入到HBase數(shù)據(jù)庫。這種導(dǎo)入方式生成HFile較慢，但生成文件后導(dǎo)入速度非?？?，幾乎與文件拷貝速度一樣。

2)通過Map Reduce的方式導(dǎo)入HBase數(shù)據(jù)庫，這種方式導(dǎo)入速度相對較快，但占用資源較大，當(dāng)系統(tǒng)資源不足時，導(dǎo)入方式明顯較慢。

3)通過JAVA編碼調(diào)用HBase API，使用多線程、多客戶端入庫。該入庫方式同樣存在占用系統(tǒng)資源較高問題。

三種入庫方式對比發(fā)現(xiàn)，方式1)入庫效率最高，能夠保證數(shù)據(jù)采集和入庫的及時性。具體采集入庫步驟如圖1所示。

圖1 短信采集入庫流程

1)針對數(shù)據(jù)庫短信數(shù)據(jù)源，按數(shù)據(jù)源提供的最小數(shù)據(jù)粒度導(dǎo)出短信數(shù)據(jù)到文件，同時進(jìn)行預(yù)處理。生成HBase數(shù)據(jù)庫能夠識別的HFile格式文件。針對文件格式的短信數(shù)據(jù)源，通過awk腳本，對原始文件進(jìn)行預(yù)處理轉(zhuǎn)換為HFile格式文件。

2)將HFile格式文件put到hadoop分布式文件系統(tǒng)。

3)使用HBase自帶的批量導(dǎo)入工具importTsv將HFile文件導(dǎo)入到HBase數(shù)據(jù)庫。

2 短信數(shù)據(jù)存儲設(shè)計

與關(guān)系數(shù)據(jù)庫一樣，HBase也是用表來存儲數(shù)據(jù)。HBase的表可以很大，單個表可以存儲上百億行的數(shù)據(jù)。表由行和列組織，一行可以包含一個或多個列。一個或多個列又形成一個列族(column family)，每個列族對應(yīng)唯一的一個行鍵(row key)。同一個列族的數(shù)據(jù)按照行鍵的字典順序存儲在同一個HFile里面。因此，庫表行鍵的設(shè)計將直接影響數(shù)據(jù)的查詢性能。經(jīng)常一起讀取的數(shù)據(jù)最好保存在一起，以提高查詢速度。

要實現(xiàn)海量短信的秒級查詢，rowkey的設(shè)計是最為重要的環(huán)節(jié)。在客服進(jìn)行短信查詢時，查詢條件涉及以下幾個條件：

1)短信類型：包含SP、在信、互通、點對點。

2)短信收發(fā)：短信接收、短信發(fā)送、同時查詢接收和發(fā)送。

3)短信范圍：短信發(fā)送的時間范圍，可以支持6個月時間跨度的短信查詢。

要查詢的短信結(jié)果內(nèi)容字段如下：

發(fā)送時間，到達(dá)時間，發(fā)送狀態(tài)，發(fā)送號碼，接收號碼，短信內(nèi)容。

當(dāng)前短信數(shù)據(jù)量預(yù)估大概每天3 000萬條，按1條1 k計算，預(yù)估1 d有30 G左右的數(shù)據(jù)量。性能要求上盡量做到準(zhǔn)實時采集，前臺查詢響應(yīng)時間需控制到2 s左右，數(shù)據(jù)保存周期半年以上。

為了高效率利用存儲空間，在對短信數(shù)據(jù)存儲時，使用HBase提供的壓縮存儲功能。綜合比較了幾種壓縮效率和壓縮比,這里選擇Snappy算法[6]進(jìn)行壓縮，壓縮比大約為22%。為了達(dá)到快速查詢的目標(biāo)，在存儲時將短信數(shù)據(jù)分為短信索引表和短信詳單表。

2.1 短信索引表設(shè)計

短信索引表設(shè)計見表2。

表2 短信索引表

根據(jù)查詢條件，結(jié)合rowkey設(shè)計原則，長度越短越好，唯一性、散列性，rowkey采用如下組合字符串：

rowkey=手機(jī)號+業(yè)務(wù)類型(0-sp，1-行業(yè)，2-互通，3-點對點)+發(fā)送狀態(tài)(0-發(fā)送，1接收)+發(fā)送日期(yyyymmddhh24miss)+短信序列末尾四位。

正常情況下，普通手機(jī)號碼同一秒內(nèi)發(fā)送的短信條數(shù)較少，因此，通過取短信序列號末尾四位足以保證rowkey的唯一性，同時也能盡可能地縮短rowkey。表數(shù)據(jù)壓縮算法采用snappy算法，設(shè)置庫表的TTL為15 552 000 s，即數(shù)據(jù)超時時間為180 d。當(dāng)數(shù)據(jù)入庫后超過180 d，數(shù)據(jù)將被自動刪除。

短信索引表建表語句如下：

create ‘t_sms_index‘, {name => ’cf’, COMPRESSION => 'SNAPPY', TTL => ‘15552000’}

2.2 短信詳單表設(shè)計

根據(jù)要查詢的短信結(jié)果內(nèi)容字段,短信詳單設(shè)計見表3。

表3 短信詳單

短信詳單表建表語句如下：

Create ‘t_sms_info‘，{name => ’cf’, COMPRESSION => 'SNAPPY', TTL => ‘15552000’}

3 短信查詢接口設(shè)計

3.1 遠(yuǎn)程Web調(diào)用協(xié)議

目前為止，REST、SOAP、XML-RPC是三種最常用的遠(yuǎn)程Web調(diào)用協(xié)議[7-8]。其中，SOAP和XML-RPC都是基于XML進(jìn)行消息交換，性能差不多，但由于SOAP更為成熟，目前已經(jīng)逐漸取代XML-RPC協(xié)議。REST協(xié)議雖然在成熟度上不如SOAP，但其具有調(diào)用效率高、簡單易用等突出特點。考慮到短信查詢接口的運行效率和查詢性能。這里選擇REST協(xié)議作為短信查詢接口實現(xiàn)協(xié)議，同時為了減少傳輸過程中的數(shù)據(jù)冗余，選擇使用json消息代替XML消息作為數(shù)據(jù)傳輸格式。

3.2 查詢接口設(shè)計實現(xiàn)

為了接口的易用性，接口需要實現(xiàn)分頁查詢功能，支持的查詢參數(shù)見表4。

表4 查詢參數(shù)表

REST接口設(shè)計如下：

public SmSInfoList getSmsList(@QueryParam("phonenum")String phonenum, @QueryParam("msgtype")String msgtype, @QueryParam("querytype")String querytype, @QueryParam("fromdate")String fromdate, @QueryParam("todate")String todate, @QueryParam("pagesize")int pagesize, @QueryParam("pagenum")int pagenum)

客戶端通過請求如下url：

http://127.0.0.1:50000/smsservice/query?phonenum=13000000001&querytype=0&msgtype=1&fromdate=20180109134500&todate=20180109140000&pagesize=100&pagenum=1

即可返回消息采用json格式如下：

{

"currentnum": 2, ##表示當(dāng)前返回條數(shù)

"errormsg": "", ##錯誤信息，result字段為1時，該字段有值。

"pagenum": 1, ##頁碼

"pagesize": 100, ##每頁條數(shù)

"result": 0, ##查詢結(jié)果，0表示成功，1表示失敗

"size": 2, ##總條數(shù)

"smsList": [{ ##短信列表

"destNum": 1300000001, ##被叫號碼

"msgContent": "簡單！下載點******", ##短信內(nèi)容

"msgStatus": "成功", ##短信中心狀態(tài)

"msgType": "接收", ##短信類型

"recvTime": 20180109134502, ##短信中心接收時間

"srcNum": 10010, ##主叫號碼

"transTime": 20180109134504 ##短信中心發(fā)送時間

}, {

"destNum": 1300000001,

"msgContent": "******",

"msgStatus": "成功",

"msgType": "接收",

"recvTime": 20180109134500,

"srcNum": 10010,

"transTime": 20180109134502

}]

}

Apache CXF 是一個開源的 WebService 框架，可以用來構(gòu)建和開發(fā) WebService，這些服務(wù)可以支持SOAP、HTTP等多種協(xié)議，這里采用Apache CXF框架來實現(xiàn)REST接口。查詢接口的實現(xiàn)流程如圖2所示。

圖2 查詢接口實現(xiàn)流程圖

4 查詢性能驗證

Apache Jmeter是Apache組織開發(fā)的基于Java的壓力測試工具[9]。為了驗證接口的調(diào)用效率，這里使用Apache Jmeter對接口進(jìn)行測試。首先在測試計劃里創(chuàng)建線程組，線程數(shù)為100，共調(diào)用接口100次，設(shè)置好http請求參數(shù)后，點擊運行，測試結(jié)果圖形如圖3所示。

從圖3可以看出，多次調(diào)用，每次接口調(diào)用時長總體較為穩(wěn)定，耗時均小于1 s。

測試聚合報告見表5。

表5 測試聚合報告

從表5可以看出，總共調(diào)用了100次http請求，全部調(diào)用成功。其中調(diào)用最長耗時為1.043 s，最短耗時為0.540 s，平均每次請求響應(yīng)時間為0.685 s。實驗結(jié)果表明，海量短信查詢設(shè)計能夠滿足短信秒級快速查詢的要求。

5 結(jié) 語

基于HBase的海量短信快速查詢，充分利用HBase數(shù)據(jù)庫特點，通過查詢條件設(shè)計構(gòu)造rowkey，將短信存儲分為索引表和短信詳情表分開存儲。查詢時先范圍掃描索引表，再批量通過Key值獲取詳細(xì)短信信息。該查詢設(shè)計極大地提升了查詢速度，相對于傳統(tǒng)海量數(shù)據(jù)查詢系統(tǒng)是一個巨大的改進(jìn)，為客服人員快速解決客戶投訴問題帶來了巨大的便利。