一種基于實(shí)時(shí)大數(shù)據(jù)的分布式智能匹配系統(tǒng)

馮興+周繼恩+方亞超

摘 要：傳統(tǒng)的匹配技術(shù)因規(guī)則和參數(shù)固定，匹配性能和效果很不理想。基于實(shí)時(shí)大數(shù)據(jù)和機(jī)器學(xué)習(xí)技術(shù)，提出了一種新的分布式智能匹配系統(tǒng)，該系統(tǒng)根據(jù)實(shí)時(shí)匹配成功率和用戶(hù)反饋進(jìn)行自我優(yōu)化。實(shí)驗(yàn)表明，系統(tǒng)性能可水平擴(kuò)展，匹配正確率顯著提高。

關(guān)鍵詞：智能匹配；實(shí)時(shí)大數(shù)據(jù)；機(jī)器學(xué)習(xí)；分布式協(xié)調(diào)；Spark Streaming

DOIDOI：10.11907/rjdk.171722

中圖分類(lèi)號(hào)：TP303

文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)文章編號(hào)：1672-7800（2017）008-0005-04

0 引言

人們通過(guò)打車(chē)軟件可以匹配到最佳司機(jī)出行，亦可通過(guò)拼單軟件湊團(tuán)優(yōu)惠秒殺；金融機(jī)構(gòu)根據(jù)海量歷史交易構(gòu)造模型，實(shí)時(shí)偵測(cè)詐欺交易；商戶(hù)根據(jù)客戶(hù)群體特征分析消費(fèi)趨勢(shì)，從而進(jìn)行精準(zhǔn)營(yíng)銷(xiāo)。這一切，都離不開(kāi)匹配技術(shù)。

匹配指事物之間有相符合或相配合的關(guān)系，匹配技術(shù)旨在以一定的目標(biāo)、遵循一定的規(guī)則建立事物之間的關(guān)聯(lián)，從而產(chǎn)生“協(xié)同效應(yīng)”[1]。匹配技術(shù)一般遵循如下流程：從不同的事物中按照一定的規(guī)則提煉出特征，然后按照一定的目標(biāo)去組合這些特征，能夠滿(mǎn)足預(yù)期目標(biāo)則表示匹配成功[2]。傳統(tǒng)匹配技術(shù)采用固定的規(guī)則和方法，規(guī)則不會(huì)隨著實(shí)際情況發(fā)生調(diào)整和改變。實(shí)時(shí)匹配成功率較低，未成功的匹配只有等待T+1日的批量流程完成處理，難以應(yīng)對(duì)越來(lái)越多的（T+0）實(shí)時(shí)場(chǎng)景需求。實(shí)時(shí)大數(shù)據(jù)技術(shù)[3]可以將歷史匹配記錄和實(shí)時(shí)信息結(jié)合起來(lái)分析，動(dòng)態(tài)調(diào)整匹配規(guī)則和方法，提升了匹配的實(shí)時(shí)性和成功率，也提高了匹配效果和用戶(hù)體驗(yàn)。

實(shí)時(shí)匹配系統(tǒng)大多基于實(shí)時(shí)處理框架自行開(kāi)發(fā)。滴滴的實(shí)時(shí)打車(chē)平臺(tái)根據(jù)地理位置、歷史評(píng)分撮合乘客、司機(jī)、代駕者，采用迭代反饋算法[4]，算法分批次迭代進(jìn)行，每次的參數(shù)都由系統(tǒng)動(dòng)態(tài)生成。比如，系統(tǒng)在匹配失敗后會(huì)適當(dāng)增加距離，降低評(píng)分要求，通過(guò)調(diào)整參數(shù)提高匹配成功概率。滴滴打車(chē)平臺(tái)基于Lambda架構(gòu)[5]設(shè)計(jì)，將實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)結(jié)合應(yīng)用，提升匹配效果，增強(qiáng)用戶(hù)體驗(yàn)，同時(shí)獲取更多有價(jià)值的數(shù)據(jù)。

微軟的實(shí)時(shí)數(shù)據(jù)質(zhì)量監(jiān)控平臺(tái)是典型的“模型匹配”[6]系統(tǒng)。平臺(tái)后端連接實(shí)時(shí)機(jī)器學(xué)習(xí)算法，通過(guò)分析實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)，不斷完善風(fēng)險(xiǎn)模型；將結(jié)果數(shù)據(jù)與風(fēng)險(xiǎn)模型動(dòng)態(tài)匹配，可監(jiān)控?cái)?shù)據(jù)質(zhì)量并發(fā)出預(yù)警。

實(shí)時(shí)匹配實(shí)現(xiàn)具有兩個(gè)特點(diǎn)：①結(jié)合實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)共同分析；②可動(dòng)態(tài)調(diào)整參數(shù)，優(yōu)化匹配效果。但是，由于匹配技術(shù)多是公司的核心技術(shù)和商業(yè)秘密，現(xiàn)有成果大多閉源，對(duì)匹配技術(shù)的研究和應(yīng)用也各自為攻，因此，業(yè)內(nèi)尚未形成一個(gè)主流成熟的框架。

1 實(shí)時(shí)大數(shù)據(jù)

大數(shù)據(jù)（Big Data）技術(shù)是一種數(shù)據(jù)存儲(chǔ)和分析技術(shù)，具有5V特性[7]。大數(shù)據(jù)技術(shù)能在每日幾百TB的數(shù)據(jù)增長(zhǎng)情況下高效分析數(shù)據(jù)，并從低價(jià)值密度的海量數(shù)據(jù)中挖掘出有利于企業(yè)戰(zhàn)略的信息。

2011年興起的流式計(jì)算[8]，被稱(chēng)為是后Hadoop時(shí)代的實(shí)時(shí)云計(jì)算。大數(shù)據(jù)流式計(jì)算引擎將多種數(shù)據(jù)源的數(shù)據(jù)整合并切割成小塊，進(jìn)而對(duì)數(shù)據(jù)進(jìn)行并行處理，在流數(shù)據(jù)不斷變化過(guò)程中進(jìn)行實(shí)時(shí)分析，捕捉并返回可能對(duì)用戶(hù)有用的信息。流式計(jì)算技術(shù)百花齊放，種類(lèi)繁多，如Yahoo的S4、Twitter的Storm、Facebook的Puma，以及被稱(chēng)為“Hadoop替代者”的Spark和Spark Streaming[9]。其中，S4不支持“至少遞送一次”的規(guī)則[10]，導(dǎo)致其有丟失事件的風(fēng)險(xiǎn)；盡管Storm應(yīng)用較多，但其性能差強(qiáng)人意；相較而言，Spark Streaming采用“微批量”的處理技術(shù)，處理性能較高，應(yīng)用非常廣泛。此外，Spark和圖算法、機(jī)器學(xué)習(xí)算法天然具備兼容性，生態(tài)發(fā)展較好。

Spark是一個(gè)類(lèi)似MapReduce的并行計(jì)算框架，其核心數(shù)據(jù)結(jié)構(gòu)是彈性分布式數(shù)據(jù)集（Resilient Distributed Datasets， RDD），提供比MapReduce更豐富的模型，可在內(nèi)存中對(duì)RDD進(jìn)行多次計(jì)算和迭代，并支持復(fù)雜的圖算法和機(jī)器學(xué)習(xí)算法。

Spark Streaming是一個(gè)建立在Spark之上的實(shí)時(shí)計(jì)算框架，它擴(kuò)展了Spark處理大規(guī)模流式數(shù)據(jù)的能力，復(fù)用Spark接口實(shí)現(xiàn)復(fù)雜的實(shí)時(shí)算法，且與Spark生態(tài)中的其它組件兼容性好。Spark Streaming處理原理如圖1所示，將數(shù)據(jù)流按時(shí)間片劃分為若干段數(shù)據(jù)，每一段數(shù)據(jù)作為一個(gè)RDD，處理引擎對(duì)每個(gè)RDD進(jìn)行Filter、Map、Reduce等算法操作后，將其作為Spark Job提交給Spark引擎進(jìn)行計(jì)算。Spark Streaming支持?jǐn)?shù)百節(jié)點(diǎn)的分布式實(shí)時(shí)計(jì)算，具備計(jì)算的高可用、容錯(cuò)特性。因此，本文采用Spark Streaming作為主要的實(shí)時(shí)計(jì)算技術(shù)。

2 智能匹配系統(tǒng)

2.1 匹配流程

匹配系統(tǒng)流程如下：通過(guò)規(guī)則提取源消息的特征向量，放置于撮合引擎[11]中；撮合引擎以預(yù)先設(shè)定的目標(biāo)匹配特征向量；如果匹配結(jié)果達(dá)到目標(biāo)要求，則判定為匹配成功；否則，匹配失敗，進(jìn)入下一次匹配。

傳統(tǒng)匹配技術(shù)采用固定的特征向量提取方式，在撮合系統(tǒng)中也使用固定的參數(shù)去匹配特征向量[12]。以拼單系統(tǒng)為例，用戶(hù)有一張滿(mǎn)500減200的優(yōu)惠券，但預(yù)期消費(fèi)只有300元，期望通過(guò)實(shí)時(shí)拼單系統(tǒng)找到附近的人一起共享優(yōu)惠券，傳統(tǒng)匹配技術(shù)算法[13]如下：

輸入：特征向量

<優(yōu)惠券金額，預(yù)期消費(fèi)， 經(jīng)度，維度>

輸出：匹配結(jié)果

（1） 提取特征向量。

（2）將特征向量導(dǎo)入撮合引擎。

（3）撮合引擎根據(jù)預(yù)先設(shè)置參數(shù)（如向量權(quán)重，超時(shí)時(shí)間）匹配附近的人。

（4）匹配成功，則返回配對(duì)信息。

（5）匹配失敗且未超時(shí)，則返回步驟（2）繼續(xù)匹配。endprint

（6）匹配失敗且超時(shí)，則返回匹配失敗。

如果參數(shù)配置不合理，將可能導(dǎo)致客戶(hù)等待時(shí)間太長(zhǎng)、匹配失敗、距離太遠(yuǎn)、總體消費(fèi)金額太多等問(wèn)題，從而導(dǎo)致客戶(hù)流失。此外，由于客戶(hù)向系統(tǒng)發(fā)送的數(shù)據(jù)僅是固定的特征向量，客戶(hù)的其它信息（如歷史消費(fèi)次數(shù)、信用等級(jí)、消費(fèi)路線等）并未在匹配算法中占有權(quán)重，可能使不誠(chéng)信用戶(hù)被頻繁推送，從而導(dǎo)致拼單系統(tǒng)無(wú)法精準(zhǔn)推送優(yōu)惠券，用戶(hù)體驗(yàn)效果不佳。

可見(jiàn)，傳統(tǒng)匹配技術(shù)無(wú)法跟上服務(wù)升級(jí)速度[14]，也無(wú)法滿(mǎn)足需求的時(shí)效性和準(zhǔn)確性，本文提出基于實(shí)時(shí)大數(shù)據(jù)的智能匹配系統(tǒng)，能有效解決以上問(wèn)題。

2.2 匹配系統(tǒng)總體設(shè)計(jì)

2.2.1 節(jié)點(diǎn)設(shè)計(jì)

智能匹配系統(tǒng)采用分布式部署結(jié)構(gòu)，有3類(lèi)角色：

（1）中央控制節(jié)點(diǎn)：負(fù)責(zé)存放當(dāng)前的特征提取規(guī)則以及匹配參數(shù)（向量因子權(quán)重、超時(shí)時(shí)間等），實(shí)時(shí)接收采集節(jié)點(diǎn)和撮合節(jié)點(diǎn)反饋，調(diào)用后端機(jī)器學(xué)習(xí)算法調(diào)整模型，并修正規(guī)則和參數(shù)。

（2）采集節(jié)點(diǎn)：負(fù)責(zé)從多個(gè)客戶(hù)端收集用戶(hù)請(qǐng)求信息，從中央控制節(jié)點(diǎn)獲取特征提取規(guī)則，按規(guī)則對(duì)信息進(jìn)行特征提取，并生成統(tǒng)一格式的報(bào)文通過(guò)Kafka發(fā)送給撮合節(jié)點(diǎn)。采集節(jié)點(diǎn)會(huì)收集用戶(hù)的反饋信息，并向中央控制節(jié)點(diǎn)進(jìn)行反饋。

（3）撮合節(jié)點(diǎn)：撮合節(jié)點(diǎn)負(fù)責(zé)接收采集節(jié)點(diǎn)發(fā)過(guò)來(lái)的信息，按照一定規(guī)則，以預(yù)先設(shè)定的目標(biāo)進(jìn)行撮合。撮合節(jié)點(diǎn)和中央控制節(jié)點(diǎn)保持通信，隨時(shí)根據(jù)中央控制節(jié)點(diǎn)參數(shù)調(diào)整撮合行為。撮合節(jié)點(diǎn)根據(jù)匹配成功率、匹配效果向中央控制節(jié)點(diǎn)反饋。

2.2.2 運(yùn)行機(jī)制

用戶(hù)將匹配請(qǐng)求發(fā)送到采集節(jié)點(diǎn)，采集節(jié)點(diǎn)根據(jù)從中央控制節(jié)點(diǎn)獲取的特征提取規(guī)則，對(duì)原始請(qǐng)求進(jìn)行規(guī)則提取和規(guī)范化處理，得到特征向量，并將這些特征向量按不同主題發(fā)送給不同的撮合節(jié)點(diǎn)。撮合節(jié)點(diǎn)根據(jù)從中央控制節(jié)點(diǎn)獲取的匹配參數(shù)（例如向量中不同特征的權(quán)重）及匹配目標(biāo)，將采集節(jié)點(diǎn)傳來(lái)的特征向量流封裝成若干分布式彈性數(shù)據(jù)集（RDD）以及一系列操作[15]，將其提交給Spark Streaming進(jìn)行匹配處理。Spark Streaming分為多個(gè)微批次進(jìn)行處理，每次處理后都會(huì)存在一些匹配失敗的特征向量。撮合節(jié)點(diǎn)將這些向量暫時(shí)緩存在Redis[16]，積累到一定數(shù)量后，根據(jù)機(jī)器學(xué)習(xí)算法結(jié)果調(diào)整參數(shù)，再次封裝為RDD提交給Spark進(jìn)行二次匹配。撮合節(jié)點(diǎn)還會(huì)根據(jù)匹配成功率、匹配效果向中央控制節(jié)點(diǎn)進(jìn)行反饋，以幫助中央控制節(jié)點(diǎn)標(biāo)記參數(shù)樣本[17]，進(jìn)行自我優(yōu)化。系統(tǒng)整體設(shè)計(jì)如圖2所示。

以實(shí)時(shí)拼單系統(tǒng)為例。實(shí)時(shí)拼單系統(tǒng)能夠幫助用戶(hù)湊單消費(fèi)優(yōu)惠券，例如用戶(hù)A發(fā)布了一個(gè)請(qǐng)求：持有一張滿(mǎn)500元減200元優(yōu)惠券，且期望消費(fèi)300元。理想狀態(tài)是系統(tǒng)能幫助A找到一位期望消費(fèi)200元的搭檔B，但實(shí)際情況可能找到的是消費(fèi)230元的用戶(hù)B。這次匹配也是成功的，只是匹配效果有所下降。此外，智能拼單系統(tǒng)能通過(guò)地理位置、歷史評(píng)價(jià)等信息綜合匹配，同時(shí)能根據(jù)用戶(hù)反饋和實(shí)時(shí)匹配成功率進(jìn)行自我優(yōu)化。本方法中，多名用戶(hù)各自提交原始請(qǐng)求到采集節(jié)點(diǎn)，采集節(jié)點(diǎn)根據(jù)特征向量提取規(guī)則提取出特征向量λ=<票券門(mén)檻，期望消費(fèi)，經(jīng)度，緯度，評(píng)價(jià)分>，將票券類(lèi)型哈希后發(fā)送到某個(gè)撮合節(jié)點(diǎn)（哈?？梢员ＷC同一類(lèi)型的票券都落在同一個(gè)撮合節(jié)點(diǎn)上）。采集節(jié)點(diǎn)同時(shí)也會(huì)接收用戶(hù)的反饋信息，并通知給中央控制節(jié)點(diǎn)。撮合節(jié)點(diǎn)從中央控制節(jié)點(diǎn)獲取匹配參數(shù)，例如向量中的5個(gè)因子對(duì)匹配結(jié)果的影響權(quán)重，將特征向量流封裝為RDD，將匹配算法封裝為基于RDD的運(yùn)算，將其提交給Spark Streaming進(jìn)行運(yùn)算。本次運(yùn)算未能匹配成功的向量將被緩存到Redis中進(jìn)行下一次運(yùn)算；同時(shí)撮合節(jié)點(diǎn)將向中央控制節(jié)點(diǎn)反饋匹配結(jié)果。

3 智能匹配系統(tǒng)實(shí)現(xiàn)

3.1 中央控制節(jié)點(diǎn)

中央控制節(jié)點(diǎn)主備2個(gè)，只有一個(gè)節(jié)點(diǎn)處于活躍狀態(tài)，另一個(gè)節(jié)點(diǎn)隨時(shí)處于待命狀態(tài)，主備節(jié)點(diǎn)共享存儲(chǔ)。中央控制節(jié)點(diǎn)用于存放當(dāng)前的特征提取規(guī)則以及匹配參數(shù)（向量因子權(quán)重、超時(shí)時(shí)間等），實(shí)時(shí)接收采集節(jié)點(diǎn)和撮合節(jié)點(diǎn)反饋，調(diào)用后端機(jī)器學(xué)習(xí)算法調(diào)整模型，并修正規(guī)則和參數(shù)。機(jī)器學(xué)習(xí)算法持續(xù)接收反饋，不斷迭代更新模型，直到模型穩(wěn)定。每當(dāng)規(guī)則和參數(shù)發(fā)生變化時(shí)，都會(huì)發(fā)起一次同步請(qǐng)求，將信息同步到采集節(jié)點(diǎn)和撮合節(jié)點(diǎn)。

3.2 采集節(jié)點(diǎn)

采集節(jié)點(diǎn)收集用戶(hù)原始請(qǐng)求，并根據(jù)最新的提取規(guī)則提取出特征向量，將向量規(guī)則化后通過(guò)Kafka發(fā)送給撮合節(jié)點(diǎn)。采集節(jié)點(diǎn)同時(shí)會(huì)收集用戶(hù)的反饋信息，比如匹配結(jié)果是否滿(mǎn)意、等待時(shí)間是否太長(zhǎng)等，同時(shí)向中央控制單元匯報(bào)。

采集節(jié)點(diǎn)可通過(guò)Redis緩存一些用戶(hù)請(qǐng)求，然后集中進(jìn)行處理后發(fā)至Kafka隊(duì)列，以提升系統(tǒng)吞吐量；接收數(shù)據(jù)時(shí)，也可一次接收多個(gè)用戶(hù)請(qǐng)求，再逐一通知給用戶(hù)，如圖3所示。

3.3 撮合節(jié)點(diǎn)

撮合節(jié)點(diǎn)封裝了核心匹配算法。Spark Streaming將撮合節(jié)點(diǎn)接收到的流數(shù)據(jù)劃分成段，每一段對(duì)應(yīng)一個(gè)RDD，撮合算法只需要定義基于這些RDD的運(yùn)算即可。簡(jiǎn)單撮合算法思路是：先對(duì)數(shù)據(jù)集進(jìn)行排序，然后從頭遍歷數(shù)據(jù)集，對(duì)每一個(gè)元素從尾部尋找和它匹配的元素；如果匹配，則移除匹配成功的所有元素，如果不匹配，則該元素進(jìn)入下一次匹配。整個(gè)過(guò)程迭代數(shù)次，直至結(jié)果集穩(wěn)定，偽代碼如下：

sort（dataSet）

while（iteration_times>0）

do

for（ element in dataSet）

find element from the dataset match the destination from the tail

if（match）

remove matched elements

fi

doneendprint

done

由于傳入的向量是多維度的，上述代碼需要修改為：在滿(mǎn)足既定條件情況下，按照其它因子選取最優(yōu)解。例如在拼單系統(tǒng)中，兩名用戶(hù)的湊單金額高于消費(fèi)券的最低消費(fèi)額即為匹配成功，但是兩位用戶(hù)的距離和信用評(píng)價(jià)將影響最優(yōu)匹配結(jié)果，而這些因子的權(quán)重是由中央控制節(jié)點(diǎn)提供的。撮合節(jié)點(diǎn)不斷反饋匹配成功率和匹配效果，以使中央控制單元不斷優(yōu)化參數(shù)，具體實(shí)現(xiàn)如圖4所示。

此外，RDD中應(yīng)包含實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)。算法在處理用戶(hù)的實(shí)時(shí)請(qǐng)求時(shí)，可根據(jù)用戶(hù)的關(guān)鍵域信息（例如用戶(hù)ID、活躍時(shí)間等）從HBase中查詢(xún)到該用戶(hù)的歷史請(qǐng)求明細(xì)，并分析該用戶(hù)的信用、行為、消費(fèi)習(xí)慣、偏好等特征，從而為用戶(hù)選擇更合適的匹配對(duì)象。

撮合節(jié)點(diǎn)對(duì)一個(gè)RDD的匹配計(jì)算不一定讓所有消息都完美匹配，那些沒(méi)有匹配成功的消息將被緩存進(jìn)Redis，加入下一次匹配。

4 實(shí)驗(yàn)分析

4.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)節(jié)點(diǎn)標(biāo)準(zhǔn)配置：主處理器4核心3.2GHz主頻，內(nèi)存16G；實(shí)驗(yàn)載體為本文實(shí)時(shí)拼單系統(tǒng)；以卷積神經(jīng)網(wǎng)絡(luò)（CNN）作為后端機(jī)器學(xué)習(xí)引擎的實(shí)現(xiàn)技術(shù)。

4.2 實(shí)驗(yàn)1：性能測(cè)試

實(shí)驗(yàn)?zāi)康模簻y(cè)試本系統(tǒng)性能和水平擴(kuò)展性。

實(shí)驗(yàn)配置：（初始）4個(gè)采集節(jié)點(diǎn)，2個(gè)撮合節(jié)點(diǎn)，40節(jié)點(diǎn)Spark集群。

實(shí)驗(yàn)過(guò)程：①客戶(hù)端不斷增加模擬用戶(hù)請(qǐng)求，直至性能瓶頸；②橫向擴(kuò)容采集節(jié)點(diǎn)和撮合節(jié)點(diǎn)，觀察實(shí)時(shí)TPS。

實(shí)驗(yàn)數(shù)據(jù)：初始配置（6節(jié)點(diǎn)），匹配成功的TPS峰值為4.2萬(wàn)左右；擴(kuò)容系統(tǒng)至9節(jié)點(diǎn)，TPS峰值為6.5萬(wàn)左右；擴(kuò)充系統(tǒng)至12節(jié)點(diǎn)，TPS峰值為7.9萬(wàn)左右；最終擴(kuò)充到21個(gè)節(jié)點(diǎn)時(shí)，TPS的峰值為12萬(wàn)左右。實(shí)驗(yàn)結(jié)果如圖5所示。

圖5 性能測(cè)試 圖6 動(dòng)態(tài)優(yōu)化

在該過(guò)程中，系統(tǒng)處理延遲基本處于穩(wěn)定狀態(tài)，隨機(jī)用戶(hù)的期望匹配延遲小于1.6s。

實(shí)驗(yàn)結(jié)論：本系統(tǒng)處理性能優(yōu)異。根據(jù)已公布數(shù)據(jù)，本系統(tǒng)相比于滴滴實(shí)時(shí)匹配系統(tǒng)，相同集群規(guī)模的吞吐量提升了41%，處理延遲減少了25%～60%。

實(shí)驗(yàn)分析：本系統(tǒng)采用Spark Streaming微批量處理技術(shù)，相比于滴滴的Smaza，極大提升了處理能力；采用流批數(shù)據(jù)并行處理的設(shè)計(jì)思想，極大減少了處理延遲。

4.3 實(shí)驗(yàn)2：動(dòng)態(tài)優(yōu)化

實(shí)驗(yàn)?zāi)康模鹤C明本系統(tǒng)可根據(jù)實(shí)時(shí)匹配率和用戶(hù)評(píng)價(jià)進(jìn)行反饋式學(xué)習(xí)，不斷優(yōu)化自身參數(shù)，提升匹配效果。

實(shí)驗(yàn)配置：4個(gè)采集節(jié)點(diǎn)，2個(gè)撮合節(jié)點(diǎn)，40節(jié)點(diǎn)的Spark集群，20節(jié)點(diǎn)的CNN深度學(xué)習(xí)網(wǎng)絡(luò)。

實(shí)驗(yàn)過(guò)程：?jiǎn)?dòng)系統(tǒng)，記錄實(shí)時(shí)匹配成功率和TPS，持續(xù)60分鐘。

實(shí)驗(yàn)現(xiàn)象：開(kāi)始時(shí)匹配成功率較低且劇烈震蕩，隨著深度學(xué)習(xí)算法的運(yùn)行，參數(shù)不斷調(diào)整，成功率開(kāi)始顯著提升，60分鐘時(shí)趨于穩(wěn)定，成功率大約在78%左右，實(shí)驗(yàn)結(jié)果如圖6所示。

實(shí)驗(yàn)結(jié)論：本系統(tǒng)能根據(jù)實(shí)時(shí)匹配結(jié)果進(jìn)行自我優(yōu)化，能夠自動(dòng)提升匹配成功率。

實(shí)驗(yàn)分析：本系統(tǒng)能根據(jù)實(shí)時(shí)匹配結(jié)果進(jìn)行反饋式分析，動(dòng)態(tài)調(diào)整匹配參數(shù)，增加匹配成功率；并能結(jié)合用戶(hù)的歷史信息進(jìn)行分析，做到“投其所好”，提供更人性化的匹配結(jié)果。

5 結(jié)語(yǔ)

傳統(tǒng)的匹配技術(shù)因規(guī)則和參數(shù)固定，匹配性能和效果很不理想；基于實(shí)時(shí)大數(shù)據(jù)的匹配技術(shù)是各公司的核心技術(shù)和商業(yè)秘密，現(xiàn)有成果大多閉源，研究和應(yīng)用也各自為攻，尚未形成一個(gè)主流成熟的框架。本文提出了一種基于大數(shù)據(jù)匹配技術(shù)的通用技術(shù)框架。該框架易搭建，采用分布式架構(gòu)，支持水平擴(kuò)展，性能優(yōu)異，相對(duì)于業(yè)界主流系統(tǒng)，吞吐量提升了41%，匹配延遲減少了25%以上；結(jié)合實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)分析，匹配結(jié)果更精確；后端搭配機(jī)器學(xué)習(xí)算法，可主動(dòng)優(yōu)化匹配效果。

參考文獻(xiàn)：

[1] 朱海燕， 蔡銘， 金連甫. 網(wǎng)絡(luò)化制造系統(tǒng)中的服務(wù)智能匹配技術(shù)研究[J]. 計(jì)算機(jī)工程與應(yīng)用， 2004， 40（18）：137-140.

[2] 郭會(huì)， 王麗俠. 基于個(gè)性化需求的拼車(chē)路徑匹配算法研究[J]. 計(jì)算機(jī)技術(shù)與發(fā)展， 2017（1）：57-60.

[3] 邱雪濤， 趙金濤. 基于實(shí)時(shí)大數(shù)據(jù)處理的交易欺詐偵測(cè)的研究[J]. 軟件產(chǎn)業(yè)與工程， 2013（4）：36-40.

[4] 顧軍華， 任超， 譚慶. 基于正反饋機(jī)制的遺傳算法[J]. 計(jì)算機(jī)工程與應(yīng)用， 2007， 43（14）：73-74.

[5] 蘇樹(shù)鵬. 基于Lambda架構(gòu)的移動(dòng)互聯(lián)大數(shù)據(jù)平臺(tái)架構(gòu)的設(shè)計(jì)與應(yīng)用[J]. 企業(yè)科技與發(fā)展， 2016（6）：66-68.

[6] 方幼林， 楊冬青， 唐世渭，等. 數(shù)據(jù)倉(cāng)庫(kù)中數(shù)據(jù)質(zhì)量控制研究[J]. 計(jì)算機(jī)工程與應(yīng)用， 2003， 39（13）：1-4.

[7] 孟小峰， 慈祥. 大數(shù)據(jù)管理：概念、技術(shù)與挑戰(zhàn)[J]. 計(jì)算機(jī)研究與發(fā)展， 2013， 50（1）：146-169.

[8] 孫大為. 大數(shù)據(jù)流式計(jì)算：應(yīng)用特征和技術(shù)挑戰(zhàn)[J]. 大數(shù)據(jù)， 2015， 1（3）：99-105.

[9] 夏俊鸞， 邵賽賽. Spark Streaming：大規(guī)模流式數(shù)據(jù)處理的新貴[J]. 程序員， 2014（2）：44-47.

[10] NEUMEYER L， ROBBINS B， NAIR A， et al. S4：distributed stream computing platform[C].IEEE International Conference on Data Mining Workshops，IEEE Computer Society， 2010：170-177.

[11] 吳媛，李雄德， 陳正軍. 信息供需互助平臺(tái)中智能撮合算法研究與設(shè)計(jì)[J]. 中國(guó)陶瓷， 2009（4）：36-38.

[12] 唐亮貴，李雙慶， 程代杰. 基于多主體的撮合交易模型及算法研究[J]. 計(jì)算機(jī)工程與應(yīng)用， 2003， 39（23）：145-147.

[13] 李世梁.實(shí)時(shí)全額支付系統(tǒng)中基于基本環(huán)的高效多邊撮合算法分析和設(shè)計(jì)[J]. 計(jì)算機(jī)應(yīng)用與軟件， 2016， 33（9）：296-300.

[14] 佚名.大數(shù)據(jù)時(shí)代[J]. 中國(guó)電子科學(xué)研究院學(xué)報(bào)， 2013， 8（1）：27-31.

[15] S GUPTA. Learning real-time processing with spark streaming[EB/OL].http：//www.bokus.com/.

[16] CARLSON J L. Redis in action[J]. Media，johnwiley， 2013（3）：157-159.

[17] 尹寶才， 王文通， 王立春. 深度學(xué)習(xí)研究綜述[J]. 北京工業(yè)大學(xué)學(xué)報(bào)， 2015（1）：48-59.endprint