Spark平臺下電影推薦系統的設計

李光明 房靖力

(陜西科技大學電子信息與人工智能學院 陜西 西安 710021)

0 引 言

隨著計算機網絡的迅速發展，各種大型網站在實時建立和更新[1]。隨著各類網站的建立，產生了大量的數據信息。在當今大數據時代[2]的背景下，人們逐漸從信息匱乏的階段過渡到信息爆炸的階段，在面對如此巨大的信息量時如何從大量信息中快速有效找到對自己有用的信息顯得尤為重要，個性化推薦系統由此產生。

個性化推薦系統的核心是推薦算法模型的建立和算法模型運行平臺的運行速度。近年來，推薦算法在不斷發展，文獻[3]利用深度學習結合基于用戶的協同過濾算法進行個性化推薦；文獻[4]采用自注意力與Metric Learning結合學習用戶的短期愛好進行精準推薦；文獻[5]基于協同注意力機制，對用戶與物品的若干相關評論進行選擇，選出最重要的信息進行推薦。以上幾種推薦算法在實驗中都取得了不錯的推薦效果，但是針對搭建一個運行于Spark分布式集群并對平臺中MLlib的協同過濾算法的優化還有待進一步的研究。

對于同時考慮算法模型以及算法模型運行平臺速度的研究，雖然從單機版的推薦系統產生，到如今的智能化、個性化推薦系統，經歷了許多的技術架構演變，常見的推薦系統有基于Mahout的推薦系統[6]、基于Hadoop[7-8]的個性化推薦系統等。但推薦系統還面臨以下挑戰：(1) 隨著數據量不斷加大以及用戶對推薦效果的要求不斷提升，使用傳統分布式技術架構的推薦系統平臺的迭代計算速度已經遠遠落后[9]并且會出現推薦效果差的情況，因此技術架構需要有較大的改變與提升；(2) 當選擇的數據文本存在著評分矩陣較為稀疏時[10]，對最終的推薦結果準確性也會產生一定的影響。

由于Spark分布式技術近年來已經趨于成熟，目前已廣泛應用于大數據量的處理方面，針對以上問題，本文結合Spark分布式技術對推薦系統進行設計，主要貢獻如下：(1) 使用包括Hadoop、Flume、Kafka、Spark，及Spark生態圈[11]內組件Spark Streaming等進行推薦系統架構設計，并使用JavaEE[12]對系統展示端與數據管理端進行設計實現；(2) 融合基于改進后的余弦相似性的協同過濾[13]及基于用戶喜愛物品的物品協同過濾并加入一個平衡因子ω解決因不同用戶評分方式不同導致的數據不一致性。

1 Spark平臺與系統設計

1.1 Spark平臺架構

Spark平臺包括Spark Core基本處理框架、Spark SQL結構化數據的分析查詢引擎、MLlib機器學習庫、GraphX圖形計算框架，以及Spark Streaming類似于Storm的流處理框架，實現了類似于Hadoop生態圈的另一Spark生態軟件棧。

Spark集群中主要配置一個Master節點和多個Worker節點，通過在Master節點和Worker節點分別啟動運行。如圖1所示，Spark中Driver通過運行編好的Application的main函數來創建Spark的運行環境SparkContext，而SparkContext通過集群資源管理(Cluster Manager)來進行資源申請、調度、監控等。每個Worker Node進程負責創建Spark Executor進程對Spark RDD進行分布式計算[14]。

圖1 Spark運行框架

1.2 系統架構設計

在考慮系統架構設計時，需考慮后期各個模塊的可維護性和可擴展性[14]。本系統包括三個主要的子系統模塊，分別是前端展示系統、后端數據管理系統，以及離線數據推薦與實時數據推薦模塊，具體的系統架構如圖2所示。

圖2 系統總體架構設計圖

圖2中的系統總體架構設計包括展示層、應用層、數據處理層及存儲層四個層次，每層的詳細信息如下：

(1) 展示層：主要包括前端頁面展示系統與后端數據管理系統，前端頁面展示系統采用SSM框架、BootStrap、HTML、Jquery、JSP等技術進行展示界面設計，展示界面分為門戶界面與詳細信息界面，分別為用戶提供熱門Item與TOP-N的Item的具體展示。后端數據管理系統主要采用SSM后端框架、Easy-UI前端框架、JSP等技術進行后端界面設計，后端系統主要對系統用戶數據、推薦結果數據、Item信息數據等進行維護，以保證前端頁面的數據真實性與可靠性。

(2) 應用層：系統核心算法原型為Spark的機器學習庫中的協同過濾算法模型，該算法模型采用Scala語言編寫，本文采用優化后的基于MLlib的系統過濾推薦算法模型。

(3) 數據處理層：該層主要包括離線數據處理及實時數據處理模塊。其中，離線處理模塊在實驗階段主要將MovieLens的離線數據導入HDFS中，由Spark Streaming讀取HDFS中的離線數據再經過MLlib中優化后的協同過濾算法模型迭代計算生成最終推薦結果存入Hive數據倉庫中，再由Spark SQL對Hive中的數據進行TOP-N排序[16]，產生TOP-N推薦結果存入MySQL數據庫中供展示層調用。而實時數據處理模塊主要是對前端頁面進行埋點，本系統的埋點范圍主要包括頁面跳轉信息、用戶在頁面停留時間信息、點擊信息、評分信息等構成用戶隱式動作信息日志并存于Tomcat服務器中，由Flume數據采集軟件采集到服務器中的日志文件上傳到Kafka消息隊列中，接下來由Spark Streaming對Kafka消息隊列中的數據進行數據流處理。同樣通過算法模型將最終結果存入MySQL數據庫中，應用層定時讀取實時結果數據展示在個性化推薦欄中。

(4) 存儲層：該層主要包括的持久層軟件有HDFS、MySQL與Hive數據倉庫工具，為展示層、應用層、數據處理層提供數據支撐。

1.3 系統功能設計

一個完整的推薦系統包括前端頁面展示系統、后端數據管理系統、實時數據流處理模塊、離線數據處理模塊、推薦算法模塊等。本系統應用以上各類子系統、模塊，并基于Spark大數據處理平臺以及平臺機器學習庫的協同過濾算法模型對數據量進行處理，得出推薦結果。

前端子系統與后端數據管理子系統和推薦模塊之間都是相互獨立、解耦合并易擴展。每個子系統都擁有獨立的前后端開發框架與獨立的持久層軟件，系統之間通過數據接口進行連接。

前端展示系統與后端數據管理系統的系統功能模塊圖如圖3和圖4所示。

圖4 后端數據管理子系統功能模塊圖

1.3.1前端展示子系統

前端展示子系統包括用戶注冊以及個人資料編輯，對電影的查看、評價、收藏、搜索，對推薦出的TOP-N電影展示等功能模塊。其中推薦注冊模塊除了填寫用戶個人信息之外，需要用戶選取感興趣的幾個電影主題，系統結合用戶的人口統計學信息及興趣信息解決協同過濾算法的冷啟動問題，可以為新用戶提供基于興趣的幾個熱門電影。同時，在用戶瀏覽電影信息、對電影評分、收藏電影時，通過網頁埋點的方式獲取他們的隱式評分數據及隱式動作數據，可以實時分析用戶的興趣主題電影。

1.3.2后端數據管理子系統

后端數據管理子系統主要用于對各類計算后的推薦數據及電影信息數據、用戶信息數據進行操作。系統共包含普通管理員與超級管理員兩類用戶，超級管理員對普通管理員的信息進行管理維護。普通管理員主要對電影信息及用戶信息進行管理維護，其中電影管理模塊的數據主要來源為離線電影信息數據，即經過推薦算法模型計算后的TOP-N電影信息，前端通過各項電影的推薦權重進行推薦，權重越高，電影排名越靠前，同時管理員可以人工操作近期上映的熱門電影并將推薦權重升高，進而在頁面上顯示TOP-N電影。

2 推薦系統

2.1 推薦系統概述

現如今的推薦系統主要應用于電商、新聞、旅游方面，為用戶提供個性化的物品、新聞、旅游信息，通過推薦系統，在用戶可以得到自己想要的信息同時，也為企業帶來了潛在的客戶與利益。

一般推薦系統的推薦方式包括TOP-N推薦與評分預測等。TOP-N推薦是基于用戶的興趣與隱式行為信息為用戶推薦N個他可能感興趣的物品信息，而評分預測是猜測U對某個物品I可能的打分。

2.2 協同過濾算法

協同過濾(Collaborative Filtering，CF)[17]主要有基于User的協同過濾算法、基于Item的協同過濾算法、基于Model的協同過濾算法。基于User的協同過濾算法主要計算用戶的相似度，當用戶U1和用戶U2對物品A都有較高的評分時，則認為用戶U1與U2具有較高的相似度，所以當U1對物品B評分較高時，便會將物品B推薦給用戶U2。基于物品的協同過濾算法主要計算物品的相似度，該算法認為兩個物品具有相似度是因為兩個物品同時屬于許多個用戶樣本興趣列表中，當多個用戶對物品A感興趣的同時對物品B也具有同樣的興趣度，則認為物品A、B具有很高的相似度。

2.3 隱式行為數據處理

在前端頁面中通過網頁埋點的方式對用戶操作隱式行為進行記錄，通過這些隱式行為信息可以發現用戶對電影的偏好規律進而基于此進行推薦。本文獲取的隱式行為數據包括用戶的收藏信息、頁面跳轉信息、頁面停留時間、電影評分信息等。

在對以上數據處理后形成一個三元組(userId，itemId，preferDegree)，userId：用戶ID，itemId：物品ID(在這里為電影ID)，preferDegree：偏好度。其中偏好度通過用戶的點擊次數、頁面跳轉次數、頁面停留時長、電影評分等進行加權平均。權重系數如表1所示。

表1 隱式行為權重系數

根據表1的隱式行為信息與權重信息可以得到如下的偏好度結果公式：

Pij=μ1pij+μ2pij+μ3pij+μ4pij

(1)

式中：Pij表示用戶i對電影j的四種隱式行為及權重系數的乘積之和，即最終的偏好度；μn表示用戶行為信息的權重系數；pij表示用戶i對電影j操作行為，使用操作單位數乘以權重系數，若無操作，則為0。最終將Pij作為三元組的preferDegree結果，作為最終偏好度。

2.4 基于物品的協同過濾算法流程及改進

基于物品的協同過濾算法(Item CF)主要為用戶推薦與他們之前喜歡物品相似的物品。算法模型與物品屬性無關，而與喜歡物品的用戶行為有關。例如“啤酒紙尿褲”案例，發現美國男人在買紙尿褲的同時也會買一罐啤酒，超市于是將啤酒和紙尿褲放在一起增加銷售量。Item CF即認為喜歡物品A的用戶同時也喜歡具有相似性的物品B。同時，在用戶對Item的評分過程中會對A、B這兩個“看似相似”物品的打分產生一定的偏差，有可能出現同時喜歡A、B物品(這里認定評分大于4為喜歡該電影)的用戶數很多但用戶U對A打高分卻對B打低分的情況。所以需要對Item CF的算法流程做如下改進：

(1) 對數據集進行遍歷，對喜歡每個電影的用戶數進行分類統計，存入新的文件movie_popular中，則movie_popular[j]表示喜歡電影j的用戶數。

(2) 使用movie_popular列表構建電影喜好相似度矩陣，該矩陣將同時喜歡物品jn和物品jm的用戶總數填入相似度矩陣中，計算其物品相似度，如圖5所示。

對于以上矩陣，可以根據喜歡電影的用戶數量得出相似度公式：

(2)

式中:Simjnjm表示電影jn與jm的相似度；N(jn)表示喜歡電影jn的用戶數；N(jm)表示喜歡電影jm的用戶數；分子表示同時喜歡電影jn和電影jm的用戶數。式(2)表示喜歡電影jn的用戶中喜歡jm的用戶比率。

但是對于式(2)，當電影jn屬于熱門電影時，N(jn)與N(jm)的交集會有很大概率增大，使Simjnjm的值趨近于1，所以為了消除熱門因素帶來的影響，為上述公式分母加上電影jn的懲罰權重，如下：

(3)

由式(3)與movie_popular列表可以構建出用戶相似度矩陣。

(3) 在(2)中的電影相似度公式構建中，僅僅針對用戶高評分數據子集進行電影相似度計算，而每個人對電影的打分習慣不同，有人對電影評分3分對他來說就是“高分”，所以要針對數據集中的大量稀疏的評分數據，使用修正的余弦相似度公式計算相似電影：

(4)

(4) 當通過喜歡電影的共同用戶數計算相似度后可能出現某個用戶對相似度很高的A、B電影評分差距出現個體喜好性差異，所以本文采取集成基于共同喜歡的用戶數計算物品相似度和基于所有物品評分計算的余弦相似度兩種方式，并采用一個平衡因子ω來平衡兩種方法的權重，生成電影p和電影q的相似性，如下：

(5)

式中：平衡因子ω∈(0,1)，ω的取值在實驗中具體說明。Sim(p,q)能夠從整體上衡量物品之間的相似度。

2.5 模塊實現

推薦系統包括離線計算模塊和實時計算模塊，本文將對以上兩個模塊部分作主要說明。兩個模塊的數據走向如圖6所示。

圖6 推薦系統數據走向圖

2.5.1離線計算模塊

本文的離線計算模塊使用MovieLens中的評分數據集作為離線處理數據。隨著系統運行，系統中的電影信息數量與用戶數量不斷增加，考慮采用基于Hadoop集群的分布式文件系統(HDFS)來存儲離線數據，保證系統的性能與可擴展性，可以避免單機情況下的系統性能下降與服務器宕機后數據的丟失。

考慮到基于物品的協同過濾算法運算過程中需要大量的迭代計算，選用基于內存計算的Spark平臺來對推薦算法模型進行迭代計算。其運行速度是傳統計算框架Hadoop的十倍以上，并且帶有Spark Streaming、Spark SQL、MLlib等一棧式開發組件，可以更簡便地對離線系統模塊進行搭建。

將離線數據存儲于HDFS中后，需要對數據進行ETL進而在Hive數據倉庫中建表，本文使用Spark SQL與Hive進行集成對離線數據清洗，將清洗的結果分表存放于Hive中供后續算法模型使用。

根據上文創建好的改進的基于物品的協同過濾算法模型，通過RMSE(均方根誤差)以及MAE(平均絕對誤差)[18]兩種評測方式選取最好的推薦算法模型，將計算結果存入MySQL數據庫中，供前后端系統調用。

2.5.2實時流計算模塊

離線處理的數據大多是歷史舊數據，一個好的推薦系統需要具有實時性，在對離線數據進行計算的同時也需要獲取系統中用戶的實時日志數據，進而對其進行計算產生推薦結果。實時流計算模塊需要解決的問題是假設最近在上映某一電影的第四部，則有些用戶突然想觀看這一系列的其他電影來了解整個系列電影的故事線，離線數據計算模塊就無法做到實時地為用戶推薦最近想看的電影，而實時流計算模塊可以根據用戶近期的點擊行為日志數據計算一些電影的相似度，將最相似的電影推薦給用戶，達到實時推薦的效果。

在2.3節的隱式行為數據處理中，系統通過Flume采集實時生成的隱式行為日志文件，結合Kafka消息隊列，最終使用Spark Streaming作為Kafka的消費者對日志數據進行消費，經過數據處理獲得用戶、電影、偏好度三元組，使用這個三元組數據進行實時推薦階段的算法模型構建。

3 實驗與分析

3.1 評價標準

一個推薦系統的好壞要看其準確度、覆蓋率和新穎度[14]的高低，推薦系統的準確度衡量一般通過評分預測或TOP-N進行評判。本文使用評分預測方式對推薦系統準確度予以評判。評分預測的預測準確度方式包括RMSE和MAE，這兩種計算方式通過計算算法中預測的評分與用戶對項目的實際評分之間的偏差值來衡量預測的準確度。

本文實驗使用均方根誤差RMSE作為評價標準，其公式為：

(6)

式中：N代表項目的個數(即電影的數量)；pi表示數據集中實際評分；ri表示算法模型的預測評分。(pi-ri)的值越小，整體RMSE的值越小，表明預測分數與實際分數的偏差越小，即推薦系統的精度越高。

3.2 數據集與實驗環境

3.2.1數據集

本文使用數據集來自GroupLens的ML-20M數據集，該數據集中包括138 491位用戶對30 106個不同種類電影的評分數據約2 000萬條，在算法精度實驗中使用它的精簡數據集ML-100K、ML-1M與ML-10M進行對比實驗，分別包括10萬條評分數據、100萬條評分數據與1 000萬條評分數據。

3.2.2環境配置

本文系統集群環境使用的是實驗中的三臺普通PC機，由一個Master節點和兩個Worker節點組成，分別命名為Spark01、Spark02和Spark03，三臺機器使用的系統環境是Linux Centos 7.0，機器之間使用局域網進行網絡連接，節點上同時搭建了Spark集群、Hadoop環境下的HDFS分布式文件系統、Kafka消息隊列組件與Zookeeper分布式應用協調組件，同時在Spark03上安裝MySQL數據庫與Hive數據倉庫工具，在Spark01上部署了Flume日志采集組件等。具體情況如表2所示。

表2 Spark分布式集群配置表

3.3 結果分析

本文為驗證改進算法的基本表現以及Spark平臺的優勢，進行以下幾種對比實驗：

實驗一測試改進算法的準確性。在實驗過程中使用評分稀疏度分別為5.88%的ML-100K數據集,其中包括6 040個用戶對3 900部電影的1 000 204條評分數據，本次實驗從數據集中選取1 000、2 000、4 000、6 000個用戶，及其評分數據作為實驗數據進行RMSE對比實驗，ω的取值范圍為0<ω<1,在實驗中ω的值每次增加0.2，觀察RMSE的值隨ω與評分數據量的變化，如圖7所示。

圖7 ω對RMSE的影響

結果表明：算法的精度隨著ω的變化而受到影響，ω值過大或者過小都會使最終效果不理想。在本實驗中，ω取值為0.6時，所得的RMSE結果最小，隨著測試數據樣本逐漸增大，RMSE減小緩慢，算法精度趨于穩定。

實驗二使用相同的數據集ML-100K在Hadoop集群與Spark集群中測試算法的運行速度，測試結果如圖8所示。

圖8 Hadoop平臺與Spark平臺運行效率對比

結果表明，Spark平臺的計算速度遠大于Hadoop平臺的計算速度，運行速度提升36%左右，且隨著節點的增加，運行速度呈線性下降趨勢，表明使用Spark平臺構建推薦系統的優越性。

實驗三為驗證本文改進算法的有效性，將本文使用算法與傳統的基于改進后的余弦相似性的協同過濾及基于用戶喜愛物品的物品協同過濾進行對比實驗。本次實驗使用相同數據集、Spark平臺下相同節點進行RMSE值對比實驗，所得實驗結果如表3所示。

表3 對比實驗結果

結果表明：本文提出的改進后的算法模型較基于改進后的余弦相似性的協同過濾和基于用戶喜愛物品的物品協同過濾有較低的RMSE值，即算法精確度有所提升。在評分數據矩陣較為稀疏的數據集中，使用評分值大于4數據計算相似度，縮小推薦范圍，一定程度上緩解數據的稀疏性，再結合余弦相似度計算去除無評分物品的物品相似度，整體算法相對于單個算法提升了推薦效果。

4 結 語

本文實現Spark平臺下電影推薦系統的實時與離線系統的搭建與基于協同過濾的算法改進。使用基于Spark框架的推薦系統的運行速度相比傳統的Hadoop集群模式的推薦系統提升36%左右，為不斷增加數據量的推薦系統的運行效率提供保證。另外，在傳統的基于物品的協同過濾推薦算法的基礎上改為基于物品的協同過濾與電影相似度計算相融合的方式，提升用戶個性推薦的準確率。

本系統以不同用戶對物品的評分習慣作為出發點，盡可能降低個人習慣對推薦結果帶來的影響，結果表明推薦結果有明顯的提升效果。

下一步將針對有可能出現的“情懷”打分，即評價不高卻評分較高的情況，嘗試使用基于深度學習的自然語言處理技術對評價語義進行研究，以提高算法的準確度，優化系統計算模型，達到更好的效果。