喻麗春

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

0 引 言

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

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

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

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

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

1 短信采集入庫

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

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

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

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

針對數(shù)據(jù)原始文件，使用文本處理工具awk解析文件，統(tǒng)一解析轉換為統(tǒng)一的tsv文件格式。統(tǒng)一轉換后的數(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ù)格式化，轉換為HFile格式(即HBase在hadoop系統(tǒng)上的存儲格式)。然后通過HBase自帶的bulkload工具導入到HBase數(shù)據(jù)庫。這種導入方式生成HFile較慢，但生成文件后導入速度非?？欤瑤缀跖c文件拷貝速度一樣。

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

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

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

圖1 短信采集入庫流程

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 短信索引表設計

短信索引表設計見表2。

表2 短信索引表

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

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

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

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

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

2.2 短信詳單表設計

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

表3 短信詳單

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

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

3 短信查詢接口設計

3.1 遠程Web調用協(xié)議

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

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

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

表4 查詢參數(shù)表

REST接口設計如下：

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, ##表示當前返回條數(shù)

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

"pagenum": 1, ##頁碼

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

"result": 0, ##查詢結果，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 框架，可以用來構建和開發(fā) WebService，這些服務可以支持SOAP、HTTP等多種協(xié)議，這里采用Apache CXF框架來實現(xiàn)REST接口。查詢接口的實現(xiàn)流程如圖2所示。

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

4 查詢性能驗證

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

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

測試聚合報告見表5。

表5 測試聚合報告

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

5 結 語

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