喻麗春

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

0 引 言

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

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

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

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

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

1 短信采集入庫

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

1.1 原始數據采集

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

1.2 數據解析轉換

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

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

1.3 短信數據入庫

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

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

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

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

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

圖1 短信采集入庫流程

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

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

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

2 短信數據存儲設計

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

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

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

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

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

要查詢的短信結果內容字段如下：

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

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

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

2.1 短信索引表設計

短信索引表設計見表2。

表2 短信索引表

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

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

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

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

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

2.2 短信詳單表設計

根據要查詢的短信結果內容字段,短信詳單設計見表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更為成熟，目前已經逐漸取代XML-RPC協(xié)議。REST協(xié)議雖然在成熟度上不如SOAP，但其具有調用效率高、簡單易用等突出特點。考慮到短信查詢接口的運行效率和查詢性能。這里選擇REST協(xié)議作為短信查詢接口實現(xiàn)協(xié)議，同時為了減少傳輸過程中的數據冗余，選擇使用json消息代替XML消息作為數據傳輸格式。

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

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

表4 查詢參數表

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

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

"pagenum": 1, ##頁碼

"pagesize": 100, ##每頁條數

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

"size": 2, ##總條數

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

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

"msgContent": "簡單！下載點******", ##短信內容

"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)建線程組，線程數為100，共調用接口100次，設置好http請求參數后，點擊運行，測試結果圖形如圖3所示。

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

測試聚合報告見表5。

表5 測試聚合報告

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

5 結 語

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