基于Hadoop的渠道費(fèi)用結(jié)算系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

梁偉晟

（中國(guó)移動(dòng)通信集團(tuán)廣東有限公司，廣州 510623）

0 引言

為了促進(jìn)市場(chǎng)競(jìng)爭(zhēng)和業(yè)務(wù)發(fā)展，運(yùn)營(yíng)商針對(duì)不同的業(yè)務(wù)制定相應(yīng)的費(fèi)用結(jié)算政策，渠道費(fèi)用結(jié)算系統(tǒng)統(tǒng)計(jì)渠道代理商的業(yè)務(wù)辦理情況，根據(jù)其不同業(yè)務(wù)辦理量，匹配相應(yīng)的政策規(guī)則計(jì)算出結(jié)算給渠道代理商的費(fèi)用（酬金）。為了平衡業(yè)務(wù)發(fā)展和降低管理風(fēng)險(xiǎn)，運(yùn)營(yíng)商通常設(shè)計(jì)比較復(fù)雜的費(fèi)用結(jié)算規(guī)則，針對(duì)不同的業(yè)務(wù)類別，設(shè)計(jì)不同的發(fā)放周期。渠道費(fèi)用結(jié)算系統(tǒng)承擔(dān)著酬金計(jì)算和支付的功能。酬金結(jié)算是渠道管理中的重要環(huán)節(jié)，需要一個(gè)靈活高效的系統(tǒng)提供支持。如何建立更高效的渠道費(fèi)用結(jié)算支撐體系，加快渠道代理商的資金周轉(zhuǎn)，提高渠道代理商的粘性，是亟需尋求突破的問題。在系統(tǒng)體系架構(gòu)方面目前通常采用主機(jī)加中間件、Java程序、主流數(shù)據(jù)庫Oracle的方式。由于系統(tǒng)需要采集超過十億的原始業(yè)務(wù)數(shù)據(jù)并進(jìn)行預(yù)處理，這些數(shù)據(jù)有的保存兩、三年，有的則需要長(zhǎng)期保留，在預(yù)處理過程中數(shù)據(jù)庫主機(jī)的內(nèi)存與CPU使用率和負(fù)荷較高，受限于傳統(tǒng)數(shù)據(jù)庫瓶頸，程序并發(fā)進(jìn)程數(shù)目無法進(jìn)一步提高。需要采用新的系統(tǒng)架構(gòu)，提高結(jié)算數(shù)據(jù)預(yù)處理的性能，降低數(shù)據(jù)庫的負(fù)荷，提高費(fèi)用結(jié)算的效率。

1 系統(tǒng)設(shè)計(jì)

渠道費(fèi)用結(jié)算系統(tǒng)實(shí)現(xiàn)對(duì)社會(huì)渠道酬金的計(jì)算。系統(tǒng)定期從周邊系統(tǒng)采集業(yè)務(wù)辦理及狀態(tài)數(shù)據(jù)，對(duì)外圍采集的數(shù)據(jù)進(jìn)行預(yù)處理，包括數(shù)據(jù)清洗、數(shù)據(jù)轉(zhuǎn)換等操作，然后根據(jù)酬金規(guī)則對(duì)預(yù)處理完數(shù)據(jù)進(jìn)行費(fèi)用結(jié)算，類似計(jì)費(fèi)的批價(jià)流程，最后從酬金計(jì)算結(jié)果生成酬金報(bào)表。

圖1 傳統(tǒng)系統(tǒng)架構(gòu)

Hadoop是Apache軟件基金會(huì)開發(fā)和推出的用于海量數(shù)據(jù)存儲(chǔ)和計(jì)算的分布式系統(tǒng)基礎(chǔ)架構(gòu)。Hadoop框架最核心的是：HDFS和MapReduce。HDFS為海量的數(shù)據(jù)提供了存儲(chǔ)，MapReduce為海量的數(shù)據(jù)提供了計(jì)算。用戶需要將所處理的問題轉(zhuǎn)化為MapReduce的模型，提供相應(yīng)的Map函數(shù)以及Reduce函數(shù)即可并行處理海量數(shù)據(jù)。

為提高渠道費(fèi)用結(jié)算的效率，對(duì)系統(tǒng)的數(shù)據(jù)采集、數(shù)據(jù)預(yù)處理和規(guī)則引擎進(jìn)行架構(gòu)改造。引入Hadoop框架，充分利用Hadoop的分布式存儲(chǔ)和計(jì)算能力，實(shí)現(xiàn)彈性伸縮，提高酬金預(yù)處理的性能。同時(shí)利用內(nèi)存數(shù)據(jù)庫降低計(jì)酬規(guī)則引擎對(duì)傳統(tǒng)數(shù)據(jù)庫的負(fù)荷，提高出酬效率。

（1）數(shù)據(jù)采集

使用Sqoop方式替代Dblink采集數(shù)據(jù)，數(shù)據(jù)采集后直接入庫到HDFS，業(yè)務(wù)辦理及狀態(tài)數(shù)據(jù)不再入庫到傳統(tǒng)數(shù)據(jù)庫中。

（2）數(shù)據(jù)預(yù)處理

將周邊系統(tǒng)采集的數(shù)據(jù)通過文本格式入庫到HDFS，然后利用Hive對(duì)采集數(shù)據(jù)進(jìn)行數(shù)據(jù)清洗及數(shù)據(jù)轉(zhuǎn)換操作。完成預(yù)處理的數(shù)據(jù)直接入庫到內(nèi)存數(shù)據(jù)庫中。基于MapReduce框架的分布式計(jì)算平臺(tái)，完成酬金預(yù)處理數(shù)據(jù)抽取、轉(zhuǎn)換、裝載。

（3）計(jì)酬規(guī)則引擎改造

計(jì)酬規(guī)則引擎的數(shù)據(jù)源由傳統(tǒng)數(shù)據(jù)庫改為從內(nèi)存數(shù)據(jù)庫獲取，引擎所應(yīng)用的SQL語句針對(duì)內(nèi)存數(shù)據(jù)庫進(jìn)行適配性改造。酬金規(guī)則從傳統(tǒng)數(shù)據(jù)庫同步到內(nèi)存數(shù)據(jù)庫。計(jì)酬規(guī)則引擎完成酬金計(jì)算后，將計(jì)酬結(jié)果入庫到傳統(tǒng)數(shù)據(jù)庫中，供查詢和報(bào)表展現(xiàn)。

圖2 基于Hadoop系統(tǒng)架構(gòu)

渠道費(fèi)用結(jié)算系統(tǒng)采用“Hadoop+內(nèi)存數(shù)據(jù)庫+x86服務(wù)器+Oracle數(shù)據(jù)庫+小型機(jī)”的架構(gòu)模式，其技術(shù)架構(gòu)由基礎(chǔ)設(shè)施層、數(shù)據(jù)存儲(chǔ)層、應(yīng)用層和展示層組成?；A(chǔ)設(shè)施層提供基礎(chǔ)的硬件資源，如CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)傳輸。數(shù)據(jù)存儲(chǔ)層的大數(shù)據(jù)平臺(tái)從BOSS、BI等采集基礎(chǔ)業(yè)務(wù)明細(xì)數(shù)據(jù)，存儲(chǔ)到Hadoop分布式文件系統(tǒng)HDFS，酬金預(yù)處理后的數(shù)據(jù)放入內(nèi)存數(shù)據(jù)庫，酬金計(jì)算結(jié)果最后入庫到Oracle數(shù)據(jù)庫中。在應(yīng)用層，基于MapReduce框架完成數(shù)據(jù)抽取、轉(zhuǎn)換、裝載等酬金預(yù)處理過程，然后采用現(xiàn)有酬金引擎對(duì)酬金預(yù)處理后的數(shù)據(jù)進(jìn)行酬金計(jì)算，生成酬金計(jì)算結(jié)果。系統(tǒng)的技術(shù)架構(gòu)如圖3所示。

圖3 系統(tǒng)技術(shù)架構(gòu)

2 系統(tǒng)實(shí)現(xiàn)及效果

系統(tǒng)實(shí)現(xiàn)的關(guān)鍵部分包括數(shù)據(jù)采集Sqoop實(shí)現(xiàn)、源數(shù)據(jù)和酬金因子數(shù)據(jù)預(yù)處理改造和計(jì)酬引擎適配性改造。

（1）數(shù)據(jù)采集

系統(tǒng)從周邊系統(tǒng)采集的業(yè)務(wù)辦理明細(xì)數(shù)據(jù)要轉(zhuǎn)換Hadoop存儲(chǔ)的數(shù)據(jù)。從周邊系統(tǒng)采集的數(shù)據(jù)是關(guān)系型數(shù)據(jù)庫的結(jié)構(gòu)化數(shù)據(jù)或者文件，這就涉及數(shù)據(jù)遷移和轉(zhuǎn)換問題。Sqoop是一個(gè)用來將Hadoop和關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)相互轉(zhuǎn)移的工具，可以將關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)導(dǎo)入到Hadoop存儲(chǔ)系統(tǒng)中，也可以將Hadoop的數(shù)據(jù)導(dǎo)入到關(guān)系型數(shù)據(jù)庫中。使用Sqoop工具完成數(shù)據(jù)從Oracle/文件采集到Hive，同時(shí)也可以完成將計(jì)酬結(jié)果數(shù)據(jù)從Hive導(dǎo)出到Oracle。

（2）源數(shù)據(jù)和酬金因子數(shù)據(jù)預(yù)處理改造

采集到Hive中的數(shù)據(jù)表，按照分用戶建表并按采集周期分區(qū)，存儲(chǔ)按ORC格式保存，原來處理關(guān)系型數(shù)據(jù)庫的采集預(yù)處理程序改為處理Hive存儲(chǔ)數(shù)據(jù)的程序。參數(shù)配置表設(shè)計(jì)、中間表邏輯和采集快照表需按照Hive模型建立，采集預(yù)處理接口進(jìn)行HiveSQL適配優(yōu)化改造。Hive并不是傳統(tǒng)的數(shù)據(jù)庫，部分傳統(tǒng)SQL語句需要依據(jù)MapReduce工作原理和設(shè)計(jì)思想進(jìn)行開發(fā)。Insert、Update、Delete、Row_number函數(shù)等要按指定分區(qū)操作的方式修改。使用Join的時(shí)候小表排列在前面，放到MapJoin里面。設(shè)置block為128M來控制文件大小，通過合并方式減少import的小文件數(shù)。

（3）計(jì)酬引擎適配性改造

經(jīng)過預(yù)處理的采集數(shù)據(jù)直接保存到內(nèi)存數(shù)據(jù)庫中，酬金規(guī)則數(shù)據(jù)也保存在內(nèi)存數(shù)據(jù)庫中，計(jì)酬規(guī)則引擎直接從內(nèi)存數(shù)據(jù)庫獲取數(shù)據(jù)進(jìn)行酬金結(jié)算，引擎所使用的SQL語句需針對(duì)內(nèi)存數(shù)據(jù)庫進(jìn)行適配性改造。最終計(jì)酬結(jié)果是入庫到傳統(tǒng)數(shù)據(jù)庫中，可以供前臺(tái)查詢和出具統(tǒng)計(jì)報(bào)表。

通過對(duì)渠道費(fèi)用結(jié)算系統(tǒng)進(jìn)行基于Hadoop的架構(gòu)改造，酬金預(yù)處理清洗和轉(zhuǎn)換時(shí)間由7天減少為3天，減少了60%。酬金預(yù)處理與酬金計(jì)算不再共用傳統(tǒng)數(shù)據(jù)庫，酬金預(yù)處理采用HDFS，酬金計(jì)算采用內(nèi)存數(shù)據(jù)庫。預(yù)處理過程中數(shù)據(jù)庫主機(jī)的內(nèi)存與CPU使用率和負(fù)荷降低到合理水平。當(dāng)部分?jǐn)?shù)據(jù)預(yù)處理完成時(shí)，規(guī)則引擎即可以提前對(duì)相應(yīng)的規(guī)則啟動(dòng)多個(gè)酬金計(jì)算并發(fā)進(jìn)程。數(shù)據(jù)預(yù)處理和計(jì)算過程可以并行執(zhí)行，整體計(jì)算過程可以縮短到半天。

表1

酬金預(yù)處理采用Hadoop框架改造后，傳統(tǒng)數(shù)據(jù)庫原來所使用的高端存儲(chǔ)可以大部分釋放出來，改為使用低端存儲(chǔ)，在降低成本的同時(shí)提高擴(kuò)展性。

3 結(jié)語

本文給出了基于Hadoop的渠道費(fèi)用結(jié)算系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)，以此解決大量業(yè)務(wù)數(shù)據(jù)預(yù)處理和計(jì)算在傳統(tǒng)主機(jī)數(shù)據(jù)庫下的處理瓶頸和性能依賴。實(shí)際系統(tǒng)建設(shè)表明，架構(gòu)改造后出酬時(shí)間縮短，出酬效率得到提高，在降低出酬過程中主機(jī)負(fù)荷的同時(shí)，減少了對(duì)小型機(jī)的依賴，擴(kuò)展性和系統(tǒng)成本均優(yōu)于原有的架構(gòu)。