孫成

摘要：在人們的生產(chǎn)生活中經(jīng)?？梢姶髷?shù)據(jù)[1]的身影，數(shù)據(jù)量呈現(xiàn)幾何式的增長(zhǎng)，傳統(tǒng)的信息傳遞機(jī)制越顯弊端。現(xiàn)在正是推薦系統(tǒng)大力發(fā)展的上升期，但是也要克服隨之而來(lái)的諸多問(wèn)題，經(jīng)常出現(xiàn)的冷啟動(dòng)[2]、數(shù)據(jù)稀疏性[3]等問(wèn)題被眾多學(xué)者廣泛研究。該文打算采用聚類技術(shù)和協(xié)同過(guò)濾等技術(shù)來(lái)緩解這些問(wèn)題，提升推薦質(zhì)量，從而滿足人們能夠快速地獲取所需信息。然后設(shè)計(jì)出一個(gè)關(guān)于電影的推薦網(wǎng)站，采用現(xiàn)今比較流行的處理大數(shù)據(jù)的Spark[4]技術(shù)以及依托建立在其上層的MLlib機(jī)器學(xué)習(xí)生態(tài)庫(kù)。達(dá)到處理海量數(shù)據(jù)的能力，根據(jù)現(xiàn)有的條件技術(shù)從離線推薦和熱門推薦兩種方式分區(qū)組合推薦來(lái)實(shí)現(xiàn)本系統(tǒng)。

關(guān)鍵詞：大數(shù)據(jù);協(xié)同過(guò)濾;Spark;機(jī)器學(xué)習(xí)

中圖分類號(hào)：TP391 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2020）33-0080-02

開放科學(xué)（資源服務(wù)）標(biāo)識(shí)碼（OSID）：

現(xiàn)在網(wǎng)絡(luò)上提供的信息量過(guò)于龐大，用戶經(jīng)常都會(huì)遇到信息過(guò)載的情形，使其難以做出符合自身需求的選擇。因此，許多科研人員一直在努力試圖探究新的技術(shù)，來(lái)幫助人們快速而又精準(zhǔn)地尋找到他們所感興趣的物品，這就是推薦系統(tǒng)的作用。通常我們?cè)谛枰獙ふ倚畔⒌臅r(shí)候，我們會(huì)借助搜索引擎來(lái)完成，但是它也存在一些不足，用戶需要使用準(zhǔn)確的關(guān)鍵詞來(lái)涵蓋所要檢索的內(nèi)容，其次檢索后返回的結(jié)果也很難讓其非常滿意。對(duì)于不同人使用同樣關(guān)鍵字進(jìn)行搜索，但系統(tǒng)展示的結(jié)果將是一樣的，無(wú)法做到個(gè)性化的推送。而然推薦系統(tǒng)對(duì)用戶來(lái)說(shuō)就不需要嚴(yán)格的條件，它并非一定要讓用戶提供準(zhǔn)確的檢索關(guān)鍵詞就能主動(dòng)地發(fā)掘用戶愛好，從而可以為不同的用戶做出特定的推薦服務(wù)。

1 Spark概述

Apache Spark于2009年由加州大學(xué)伯克利分校的AMP實(shí)驗(yàn)室所開發(fā)的分布式計(jì)算框架，與MapReduce相比它是基于內(nèi)存運(yùn)行的，使得運(yùn)算速率大幅提升。也正是這一優(yōu)點(diǎn)讓Spark很快變?yōu)锳pache社區(qū)知名度很高的項(xiàng)目，而且還得到國(guó)內(nèi)外眾多知名度很高的互聯(lián)網(wǎng)公司所青睞，例如IBM、Twitter、百度、阿里巴巴等。

Spark中有一種彈性分布式數(shù)據(jù)集RDD（ Resilient Distribut-ed Dataset），它是數(shù)據(jù)和運(yùn)算的抽象，可以通過(guò)它實(shí)現(xiàn)Spark將數(shù)據(jù)在內(nèi)存中的緩存操作。Spark還提供了廣播變量和累加器，廣播變量能夠?qū)?shù)據(jù)發(fā)送給每個(gè)節(jié)點(diǎn)，方便數(shù)據(jù)的共享傳輸，累加器能夠?qū)⒐?jié)點(diǎn)中的元算結(jié)果數(shù)據(jù)聚合返回。用戶可以使用外部數(shù)據(jù)來(lái)創(chuàng)建RDD，也可以通過(guò)采用已有的RDD來(lái)創(chuàng)造。RDD有兩類基本操作分別是：轉(zhuǎn)化操作（transformations）和行動(dòng)操作（action），轉(zhuǎn)化操作的RDD只有在遇到行動(dòng)算子才會(huì)去計(jì)算執(zhí)行。

2 基于Spark的電影推薦系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

2.1 系統(tǒng)總體架構(gòu)設(shè)計(jì)

單一的推薦算法都會(huì)存在薄弱點(diǎn)，很難兼顧所有需求，此時(shí)需要同時(shí)考慮將多種算法組合以達(dá)到互補(bǔ)的效果，彌補(bǔ)自身的不足。最后將從離線推薦和熱門推薦兩方面設(shè)計(jì)出關(guān)于電影的推薦系統(tǒng)。

離線推薦方面是使用用戶歷史行為數(shù)據(jù)作為依據(jù)，分析用戶與電影直接的潛在聯(lián)系，它考慮了所有有價(jià)值的信息，全面分析比較。也正因如此，它在實(shí)際的運(yùn)算過(guò)程中會(huì)非常占用系統(tǒng)資源，耗時(shí)較長(zhǎng)。由于離線推薦對(duì)實(shí)時(shí)性要求不高的特點(diǎn)，也使得這種全面考慮的方式能夠得以實(shí)現(xiàn)。可以設(shè)置一個(gè)任務(wù)，按照預(yù)設(shè)的周期內(nèi)運(yùn)行一次離線推薦步驟，以保障數(shù)據(jù)的時(shí)效性和可靠性。

熱門推薦方面，主要是為了考慮新注冊(cè)用戶進(jìn)入系統(tǒng)時(shí)，由于沒有歷史行為信息無(wú)法做出較優(yōu)質(zhì)的推薦，退而求其次地使用熱門推薦來(lái)盡可能滿足新用戶的需求，不至于給用戶非常糟糕的體驗(yàn)感.因?yàn)橥o用戶的第一印象至關(guān)重要的。當(dāng)用戶在電影業(yè)務(wù)系統(tǒng)的操作增多時(shí)，那就可以再對(duì)其做個(gè)性化的推薦。因此可以避免出現(xiàn)剛注冊(cè)的用戶進(jìn)入系統(tǒng)后的冷啟動(dòng)問(wèn)題。

2.2 電影推薦系統(tǒng)的需求分析

2.2.1 功能需求

1）注冊(cè)模塊

新用戶在瀏覽器輸入網(wǎng)址打開賬戶注冊(cè)頁(yè)面，填寫相關(guān)用戶基本信息，再向系統(tǒng)進(jìn)行提交操作。

2）登錄模塊

將用戶的賬號(hào)密碼填寫到登錄網(wǎng)站，提交后系統(tǒng)會(huì)自動(dòng)驗(yàn)證其真實(shí)性，如果正確則進(jìn)入系統(tǒng)主界面，如果失敗則會(huì)提示重新檢查信息后再次提交。

3）電影推薦模塊

本模塊是推薦系統(tǒng)的核心關(guān)鍵所在，它會(huì)根據(jù)各用戶的歷史信息做出非常接近其真實(shí)喜好的電影推送。如果是新用戶，則會(huì)采取把近期內(nèi)的比較熱門的推薦給他。盡可能兼顧所有的用戶，使得推薦效率更高。同時(shí)業(yè)務(wù)系統(tǒng)也可以搜集用戶的行為信息，比如用戶給電影的評(píng)分。通過(guò)多方面的渠道了解用戶的興趣愛好，能夠?yàn)橛脩糇龀龈泳珳?zhǔn)的推薦，使得用戶的推薦列表中的電影一直是他所喜愛的。系統(tǒng)功能模塊如圖1所示。

2.2.2 用戶需求

在網(wǎng)站的登錄界面填寫賬號(hào)與密碼，通過(guò)驗(yàn)證其真實(shí)性后轉(zhuǎn)跳到推薦首頁(yè)，其中一部分展示的電影列表是為當(dāng)前登錄用戶所做的個(gè)性化推薦，另一部分展示的是近期比較熱門的電影，這部分向所有用戶都推薦相同的內(nèi)容。登錄用戶用例圖如圖2所示。

2.2.3 電影推薦流程設(shè)計(jì)

用戶進(jìn)入電影網(wǎng)站后，如果是用老用戶直接輸入賬號(hào)密碼登錄，如果是新用戶則轉(zhuǎn)跳到注冊(cè)頁(yè)面后再重新登錄。推薦系統(tǒng)為用戶展示電影信息，用戶可以選擇某部電影查看詳情，同時(shí)還可以對(duì)此電影采取打分操作。用戶電影推薦流程如圖3所示。

2.3 離線推薦

離線部分打算采用聚類技術(shù)與協(xié)同過(guò)濾等技術(shù)來(lái)實(shí)現(xiàn)，具體為：

1）從數(shù)據(jù)庫(kù)中讀取模型所需要的評(píng)分?jǐn)?shù)據(jù)M，存儲(chǔ)形式為：用戶ID，電影ID，評(píng)分。

2）使用Spark MLlib庫(kù)中已經(jīng)實(shí)現(xiàn)的交替最小二乘法（ALS，Alternating Least Squares）來(lái)訓(xùn)練模型。其原理是，對(duì)評(píng)分矩陣M采取交替的方式進(jìn)行分解。先令電影特征矩陣V為零，將其固定后求用戶特征矩陣U，再固定U求V，一直循環(huán)交替運(yùn)算下去，直到損失函數(shù)f收斂或已到預(yù)先設(shè)定次數(shù)，那么此時(shí)的U，V就是所需的最優(yōu)值。

3）繼續(xù)使用K-means方法對(duì)上一步中求出的電影屬性特征矩陣V做聚類操作，直到聚類中心不再發(fā)生大幅的變化或者達(dá)到指定的運(yùn)算次數(shù)，那么會(huì)停止計(jì)算，能夠讓相似的電影聚在同一簇中。

4）在同一簇中尋找離新目標(biāo)電影距離最近的鄰居，再按照一定的運(yùn)算方式求出目標(biāo)電影的特征值，將之合并到原始的V中。

5）最后將U與更新后的V進(jìn)行相乘運(yùn)算（M=UyT）得出的新矩陣，通過(guò)它能夠?qū)π码娪斑M(jìn)入網(wǎng)站后的推薦，進(jìn)而起到了緩解冷啟動(dòng)的效果。

2.4 熱門推薦

熱門推薦模塊將使用Spark SQL通過(guò)對(duì)歷史數(shù)據(jù)采取統(tǒng)計(jì)的方式發(fā)掘有價(jià)值的信息。從數(shù)據(jù)庫(kù)中獲取用戶的歷史行為數(shù)據(jù)，在最近的一定范圍內(nèi)對(duì)每月的用戶評(píng)價(jià)次數(shù)做出統(tǒng)計(jì)，在各個(gè)月份中適當(dāng)選擇一些評(píng)價(jià)次數(shù)特別高的電影，然后將其按月存到數(shù)據(jù)庫(kù)中。在用戶訪問(wèn)電影網(wǎng)頁(yè)時(shí)，按照各月分別展示出排名靠前的電影。熱門推薦就是面向所有的用戶都推送相同熱門電影，即使是新注冊(cè)的用戶也可以得到很好的推薦，從另一個(gè)角度講也是在完善系統(tǒng)中所存在的冷啟動(dòng)缺陷，增強(qiáng)用戶體驗(yàn)感。

3 實(shí)驗(yàn)解析

本實(shí)驗(yàn)主要對(duì)離線模塊部分進(jìn)行實(shí)驗(yàn)對(duì)比，通過(guò)調(diào)節(jié)數(shù)據(jù)量的大小來(lái)驗(yàn)證本系統(tǒng)的可行性。此處使用的由GroupLens提供的MovieLens免費(fèi)的電影數(shù)據(jù)集，為了方便展開測(cè)試，對(duì)其大小預(yù)先做了劃分，具體分為IOOK、400K、700K、IM和IOM。在Spark和單機(jī)環(huán)境下的實(shí)驗(yàn)結(jié)果如圖4所示。

觀察上圖不難發(fā)現(xiàn)，當(dāng)數(shù)據(jù)量在比較小的情況下，是否采用Spark或單機(jī)對(duì)系統(tǒng)執(zhí)行效率影響較小。反之，如果數(shù)據(jù)量非常巨大，單機(jī)的運(yùn)行效率下降尤為明顯，而基于Spark的系統(tǒng)穩(wěn)定性非常好，那是因?yàn)閱螜C(jī)的系統(tǒng)資源急劇匱乏無(wú)法支持海量數(shù)據(jù)的高強(qiáng)度運(yùn)算，使得系統(tǒng)性能大幅下降。

4 結(jié)束語(yǔ)

從大數(shù)據(jù)的角度設(shè)計(jì)了一個(gè)關(guān)于電影的推薦網(wǎng)站，從主要方面對(duì)其進(jìn)行了分析，借助了現(xiàn)今比較流行的Spark技術(shù)來(lái)面對(duì)海量數(shù)據(jù)的接人。不僅能實(shí)現(xiàn)了老用戶的個(gè)性化推薦，也能兼顧新用戶的要求。最后也通過(guò)實(shí)驗(yàn)的方式驗(yàn)證了采用Spark實(shí)現(xiàn)大規(guī)模數(shù)據(jù)的優(yōu)勢(shì)。

參考文獻(xiàn)：

[1]國(guó)杰，程學(xué)旗.大數(shù)據(jù)研究：未來(lái)科技及經(jīng)濟(jì)社會(huì)發(fā)展的重大戰(zhàn)略領(lǐng)域——大數(shù)據(jù)的研究現(xiàn)狀與科學(xué)思考[J].中國(guó)科學(xué)院院刊，2012，27（6）：647-657.

[2]孫小華.協(xié)同過(guò)濾系統(tǒng)的稀疏性與冷啟動(dòng)問(wèn)題研究[D].杭州：浙江大學(xué)，2005.

[3] Linden G，Smith B，York J.Amazon.com recommendations：item-to-item collaborative filtering[J]. lEEE Internet Comput-ing，2003，7（1）： 76-80.

[4] Zaharia M， Chowdhury M， Franklin M J，et aI.Spark： clustercomputing with working sets[C]. USENIX Conference on HotTopics in Cloud Computing， 2010：1765-1773.

[通聯(lián)編輯：王力]