寫在前面：各位准畢業生你們好，論文已經發出來供你們參考查閱，有問題，ok，我有時間會解答，上來就讓我分享代碼的是什么意思？畢業不僅是畢業設計的考核，也希望你們對的起大學四年的時光。“你好我有些問題想請教。”什么問題？“請你分享一下你的代碼”。這就很無語好吧，這是問題嗎？論文都擺在這，推薦系統懂得都懂，你們對着教程手敲的功夫都不想付出么？從去年開始我也回答了很多人的問題。真正動手去做了的，有清晰的問題，哪里哪里。這個項目確實是有幾個坑點，當初踩坑也耗費了不少的時間。問問題的我一般都會解答；實在不明白上來要代碼的是什么意思哈？免開尊口。我願意幫助那些有動手能力的畢業生克服項目上的困難。我也不想理會那些伸手黨；沒有任何理由幫你們這些人。
本人於2021年6月畢業，當時的課題是推薦系統的算法探究與系統實現。故參考各方面資料完成了畢業設計與論文的編寫。至今也有很多人問我具體系統實現的細節。我把論文貼出來供大家參考借鑒。
終稿論文總查重率5.7%
首先說一下系統的特點：部署在 Windows上!Windows上!Windows上!
沒有用到虛擬機，沒有用到雲服務器。
目 錄
摘要. ii
Abstract ii
第一章 緒論. 1
1.1 課題研究的背景和意義. 1
1.1.1 課題研究背景. 1
1.1.2課題研究意義. 1
1.2國內外研究現狀. 2
1.2.1國外研究現狀. 2
1.2.2國內研究現狀. 3
第二章 大數據平台推薦系統的相關理論以及技術和框架. 4
2.1 JavaEE技術. 4
2.1.1 Spring框架. 4
2.1.2 MVC架構. 4
2.1.3 Maven 5
2.1.4 Restful 5
2.2 AngularJS框架. 5
2.3數據庫. 5
2.3.1 Redis數據庫. 5
2.3.2 MongoDB數據庫. 5
2.4埋點日志的采集. 6
2.4.1 Flume 6
2.4.2 Kafka 6
2.4.3 Zookeeper 6
2.5 Spark相關技術棧. 6
2.5.1 Scala 7
2.5.2 SparkSQL 7
2.5.3 SparkMLlib 7
2.5.4 SparkStreaming 8
2.6商品推薦主要用到的算法. 8
2.6.1 離線統計推薦算法. 8
2.6.2 協同過濾算法. 8
2.6.3 協同過濾LFM隱語義模型. 8
2.6.4 實時推薦算法. 9
2.7 推薦系統的常見召回路徑. 9
2.8 本次推薦系統部署環境. 10
第三章 系統分析與整體結構. 11
3.1可行性分析. 11
3.1.1技術可行性. 11
3.1.2經濟可行性. 11
3.1.3時間可行性. 11
3.2系統用戶需求分析. 11
3.3系統性能需求分析. 13
3.4系統的整體結構. 13
3.5系統的數據源. 15
第四章 系統方案的具體設計. 16
4.1系統功能設計原則. 16
4.1.1微服務. 16
4.1.2系統的可靠性. 16
4.1.3系統的維護性. 16
4.2系統總體架構設計. 16
4.2.1 前端模塊的設計. 16
4.2.2 后端業務模塊的設計. 17
4.2.3 后端推薦模塊的設計. 17
4.3數據庫設計. 17
4.3.1業務數據庫：MongoDB 17
4.3.2緩存數據庫：Redis 20
4.3.3系統數據流向. 20
4.4離線統計模塊設計. 21
4.4.1統計推薦之歷史熱門. 21
4.4.2統計推薦之近期熱門. 21
4.4.3統計推薦之均值推薦. 21
4.5離線個性化推薦模塊設計. 22
4.5.1基於模型的協同過濾算法設計. 22
4.5.2模型評估和參數選取. 23
4.5.3生成商品推薦列表. 24
4.5.4基於物品的協同過濾以及物品間的相似度. 25
4.5.5基於物品標簽的推薦. 25
4.6實時推薦算法設計. 25
4.6.1實時推薦算法. 25
4.6.2實時推薦算法設計. 26
第五章 環境部署和系統實現. 27
5.1環境部署. 27
5.1.1基礎環境. 27
5.1.2 MongoDB環境安裝與配置. 27
5.1.3 Redis環境安裝與配置. 27
5.1.4 Zookeeper環境安裝配置. 28
5.1.6 Kafka安裝與配置. 28
5.1.7 Flume安裝與配置. 28
5.1.8 Scala環境配置. 28
5.1.9 Jdk環境配置. 29
5.1.10 Maven環境配置. 29
5.1.11Spark環境安裝配置. 29
5.2成果實現展示. 29
5.2.1登錄展示效果. 29
5.2.2用戶注冊頁面展示. 30
5.2.3離線統計推薦實現. 30
5.2.4離線協同過濾基於模型的個性化推薦實現. 31
5.2.5基於物品的協同過濾推薦實現. 32
5.2.6實時推薦實現以及打分操作的流程. 32
5.2.7基於物品標簽的推薦. 35
5.2.8 商品的模糊搜索. 36
第六章 總結. 37
6.1畢業設計總結. 37
6.2推薦系統的亮點. 37
6.2.1使用高效率的Spring框架. 37
6.2.2推薦的多樣性. 37
6.2.3 基於大數據環境下的系統環境的配置. 37
6.3推薦系統實現中遇到的問題及解決方法總結. 38
6.3.1命名規范. 38
6.3.2 Windows與Linux命令不兼容問題. 38
6.3.3 Kafka 異常退出. 38
6.4推薦系統的不足之處. 38
6.4.1更准確的推薦算法. 38
6.4.2更高效的實時計算框架. 39
6.4.3 單機模式下的風險. 39
6.4.4用戶畫像（Profile）. 39
參考文獻. 40
謝 辭. 42
第一章 緒論
1.1 課題研究的背景和意義
1.1.1 課題研究背景
隨着科技的快速發展，當下電子商務在全國盛行，各大電商憑借自己獨特的營銷方式爭先搶占市場，隨之帶來的便是指數級別增長的數據量，在最短時間內找到用戶想要的商品就能深受使用者青睞。在我們平時的網上購物中；琳琅滿目的商品使我們往往淹沒在商品的數據中，但是其實我們可以發現：在我們瀏覽商品過后，在下方推薦的都是相同的類似商品。這就是推薦系統為我們帶來的便利之處，推薦系統的運用使我們不會被商品數據的洪流淹沒。根據阿里巴巴2020年12月31日的2021財年第三季度財報。數據顯示，該季度阿里巴巴營收達2210.8億元，高於市場預期的2141.58億元，與去年同期的1614.56億元相比增長37%，據悉其中國零售市場移動月活躍用戶數已達9.02億，年度活躍消費者達7.79億，單季凈增長2200萬。由此可見，國內的電商發展已經為社會帶來了巨大的經濟效益，也更加方便了人們的日常生活。不僅電商巨頭在推薦系統上煞費苦工，各類App都開始接入推薦的模塊，例如抖音App會根據用戶的喜好推薦觀看列表；網易雲音樂根據用戶的喜好生成個性化的推薦音樂列表等等。越來越多的專家和學者也對推薦系統進行了研究，國內外也出現許多優秀論文可供我們參考學習。
1.1.2課題研究意義
在如今的大數據時代，信息呈指數增長，人們很容易迷失在數據洪流中，面對大數據的沖擊，我們希望能有一個推薦准確率更高的系統完成對無關商品的過濾，將我們真正感興趣的商品留下來，為我們帶來更好的購物體驗。本課題實現商品推薦系統，使用Spark框架實現離線推薦、在線推薦、針對每位用戶完成個性化推薦，讓大家的用戶體檢更更加豐富，不局限於大眾的喜好。本課題結合大數據相關組件工具Zookeeper、Flume-ng、Kafka等，JavaEE企業級框架Spring，Tomcat部署系統服務，將整個系統部署在線上，可為小型電商公司作為商品推薦的雛形，也可供后來研究者更直觀清晰的學習。研究出來電商推薦系統准確度較高的推薦算法，能為電商企業和消費者提升粘合度，達到商品的“精准營銷”的目的，不僅能給電商平台提升市場競爭力，而且給用戶提升網上購物的消費體驗，實現電商交易的“雙贏”。
1.2國內外研究現狀
推薦系統的概念最先起源於國外，最早被運用於新聞推薦。亞馬遜發現了推薦系統在電商領域的巨大潛力，最先把推薦技術運用在電商系統中。
NetFlix提出了經典的推薦架構。在20世紀末，21世紀初期國內的電商才隨着互聯網的普及進入國內開始發展。直到現在，國內外的各大電商的推薦系統逐漸完善，電商推薦算法也推逐漸陳出新。給人們網上購物帶來極佳的的用戶體驗。
1.2.1國外研究現狀
推薦系統的鼻是祖1994年在國被設計出來的新聞推薦系統。亞馬遜率先發現了推薦算法在電商的優勢，並率先將推薦系統引入到電商中。為推薦系統的發展開辟出一條道路，對之后后的電商發展產生了很大的影響。
在國外，推薦系統依舊在亞馬遜沿用至今，隨着技術的不斷成熟以及用戶體驗的要求不斷提升。解決冷啟動問題[1]，運用機器學習訓練推薦模型[2]已經逐漸普及。
在2006年Netflix國外舉辦懸賞尋求可以將推薦准確度提高10個百分點的優秀學者。在此之后，高准確度算法推薦系統就開始出現。但仍然不能達到推薦完全正確；所以提高推薦的准確度就是衡量一個推薦算法是否有效的最好切入點。
也是推薦系統發展路上一直要攻克的難題。
2013年3月27日，Netflix的工程師在官方博客發文，推出了經典推薦系統架構——NetFlix推薦架構[3]。整個技術架構分為三層：ONLINE在線層、NEARLINE進線層、OFFLINE離線層。三層相互獨立，互相配合共同完成推薦系統的運行。在線層直接對接用戶與系統的交互，用戶在交互的過程中會伴隨着許多操作，例如評分、瀏覽等。這些作為前端的日志打點序列分發到離線層的Hadoop和近線層的流失處理平台（類似於SparkStreaming）。離線層一般以天或小時為粒度進行計算；數據存放於HDFS使用Pig、Hive等對數據進行過濾、提取。將最終的數據進行分發完成離線計算和模型訓練。模型可以傳到在線層供用戶實時計算，也可以在離線層提前預計算出用戶的推薦列表。還可以將矩陣分解得到用戶向量和物品向量。近線層是在線層和離線層之間的橋梁，近線層的計算可能會用到離線數據，也可與在線層的數據相接。這一層的計算結果往往存到一些高速緩存，以備調用。在線層一般會存在一個算法服務調度，這個服務會從高速緩存中獲取數據，使用在線層計算將結果快速計算出來。在線層不可以使用復雜的算法，不能讀取大量數據，因為要確保數據的快速響應。
Embedding技術[4]也在近期盛行起來，運用Embedding技術可以做出人人推薦、人物推薦、物物推薦等從中找到猜你喜歡的商品，可能認識的用戶等，在這個方面應用都有很好的效果反饋。
1.2.2國內研究現狀
在中國國內，雖然推薦系統起步不及國外早，但是近幾年的發展大家也有目共睹。2003年是我國公認的電商元年，從那時起，各大電商巨頭就將推薦算法逐漸引入到他們的線上電子商務中。隨着國內互聯網技術的發展與成熟，推薦系統現在已經能很好的帶給我們使用體驗。現國內研究推薦系統的研究者有大部分都集中在基於協同過濾算法[6]方向，建立基於模型的協同過濾體系[7][2]；通過用LFM建立模型使得推薦更加高效，提平等，李啟旭，郁雪，王巧等作者都發表了相關文獻來推動國內推薦系統的建設。也有作者利用FPFM組推薦框架[8]進行統推薦的研究；由於實時性是推薦系統繞不開的話題，國內也有部分作者對推薦系統的實時性有獨特見解。
2006年，國內書籍電商巨頭當當網首次將推薦系統運用，收到廣大用戶的好評；兩年之后，淘寶團隊也研發出自己的電商推薦模塊加以運用——“i淘寶”
這是淘寶電商推薦系統的雛形；到了2011年，百度也加入推薦技術行列，着重於搜索技術的個性化推薦。並提出了“一人一世界”的口號。
近幾年，用戶畫像逐漸成為推薦系統最火爆的應用。用戶畫像也能更精確的為每個用戶添加標簽，給用戶精准定位。目的就是為了把握每個用戶的興趣喜好，推廣合適的業務給用戶。
第二章 大數據平台推薦系統的相關理論以及技術和框架
2.1 JavaEE技術
在當下互聯網B/S模式的興起，Spring開源框架成為各大互聯網哪個公司搭建項目的首選。在web端的開發語言中，根據調查結果（圖2.1）Java無疑是近10年來開發者的首選。由於其跨平台性、高效的計算性能，以及全球眾多開發者在類庫和框架方面的開源貢獻，Java語言是本次課題項目實現業務系統綜合業務的首選，此次選擇的是基於Java語言的Spring框架。
2.1.1 Spring框架
在Spring框架是為了簡化JavaWeb開發而創建的；傳統的企業級應用開發，龐大的EJB使開飯維護工作量異常大；除了寫代碼邏輯，更重要的是配置組件之間的關系。然而為了解決這一難題。Spring框架誕生，Spring是一個容器框架，幫助開發者注冊加載各種組件，實現較EJB輕量級開發。
2.1.2 MVC架構
系統利用當下主流的MVC結構模式結構進行開發，M、V、C分別代表業后端編碼的三大構成M（模型）層大體可以分為兩類：承載數據的實體類業務處理的處理類。和、V（視圖）層是用戶直面系統的一層，也是用戶和系統交互的一層、C（控制）層把用戶和系統的交互操作轉換成請求發給相應的模型，根據模型的處理結果向用戶返回響應，MVC是如今J2EE應用極其廣泛的層次架構。
2.1.3 Maven
Maven是Apache基金會開源的依賴控制組件，是現大型web項目采用的jar包依賴以及模塊控制的結構，用小段描述信息管理項目的構建，便於開發人員直觀的查看項目結構和依賴。
2.1.4 Restful
Restful是基於HTTP的一種網絡應用程序的設計風格,是一種開發規范，用來寫接口時規范命名，使用restful風格開發接口可以使接口名稱長度變短，更加簡單清爽簡介，也便於開發人員直觀閱讀，看到接口的名稱就可以判斷該接口的功能。適用於移動互聯網廠商作為業務接口的場景，通過發起方式的不同請求完成對數據的增、刪、查、改等操作，極大的提升開發效率。
2.2 AngularJS框架
前端框架采用AngularJS，谷歌開源。AngularJS可以實現數據的雙向綁定。雙向綁定的操作通過檢查臟數據完成，但是臟檢查機制不是定時進行，而是在數據發生變化時也就是dom元素或者xhr事件的變化會引起底層的digest函數，這個函數會從底層逐步遍，檢查所有的watcher是否變化，如果數據變化，那么就會執行指令完成數據變化。從而實現雙向綁定。
2.3數據庫
電商推薦系統的構建選擇非關系型數據庫；因為在大數據環境下，數據的量級大且有一個特征：關系不一定完整；關系型數據庫並不適合大數據環境下的數據存數；所以利用非關系型數據庫非常符合本次場景，是大數據環境下業務的需要。
2.3.1 Redis數據庫
Redis是一種非結構化數據庫，是一種作用在內存上的緩存數據庫，Redis的讀、寫性能極高，可作為緩存、消息隊列、分布式鎖等場景應用。這次畢業設計基於大數據平台 商推薦系統就是借助Redis存儲和傳輸實時數據用於實時推薦模塊。可以按滿足數據的快速讀取。
2.3.2 MongoDB數據庫
MongoDB也是一種基於內存的數據庫，在存儲文檔信息發揮出色，多用於博客等存儲大量信息系統，底層用C++語言實現。是采用C++語言編寫的文檔型非結構化數據庫。基於大數據的電商推薦系統利用MongoDB存儲JSON數據格式，占用資源小，且支持單機、集群的使用。對大量的文字數據有較好的支持。
2.4埋點日志的采集
基於大數據環境中的電商數據，日志是反應用戶操作最直觀的途徑。所以需要采集日志並且用消息隊列中間件進行數據傳輸；大數據環境下有成熟的日志捕獲組件Flume和消息隊列Kafka組件。
2.4.1 Flume
Flume在大數據環境下多被用於日志的采集，由Source、Channel、Sink組成；通過管道的形式實現一對一，一對多，多對多端的數據傳輸；Flume具有可拓展性，且拓展性很強，可以單個Flume單獨使用，也可以多個Flume組合使用，采集不同源頭或者發送到不同物理位置、不同邏輯位置的文件中保存日志。支持多端多環境下配置捕捉傳輸日志數據。是專門負責日志數據收集的強大利器。本次畢業設計采用Flume將WebServer的數據采集到本地磁盤進行保存。以備Redis數據可進行快速的讀取。
2.4.2 Kafka
Kafka消息隊列可以作為緩存，為系統的傳輸可靠性提供保障，避免端與端的消息傳因各種原因出現遺漏或者丟失。Kafka能與Flumg組合使用，Flume進行數據收集，kafka在下游消費Flume采集到的數據進而將數據廣播到KafkaStreaming進行實時計算。
2.4.3 Zookeeper
還有一個特殊的框架——Zookeeper，這是基於大數據環境下為分布式應用提供調度的服務，也是Kafka服務的啟動依賴；
2.5 Spark相關技術棧
Spark在網絡上被稱為大數據技術棧的長子；確實，在大數據環境下，Spark的地位是舉足輕重的，Spark是通用的數據處理引擎；適用於多種離線、在線場
景大型數據集的交互式查詢Spark於2009年開始在加利福尼亞大學伯克利分校的AMPLab項目中生活。更具體地說，它是由於需要證明Meso的概念而誕生的，這也是在AMPLab中創建的；2014年被加州大學開源捐贈給Apache基金會，隨后其火熱程度就如它的名字一樣以星星之火迅速燎原不到一年就成為Apache的頂級項目Spark技術棧包括可用於可以實現高吞吐量的，具備容錯機制的實時流數據處理的SparkStreaming、處理結構化數據的SparkSql、機器學習實現庫SparkMLib等。Spark結構圖如圖2.2所示。
2.5.1 Scala
Scala是以利於Jvm的一種面向對象加面向函數（可以進行函數式編程）的語言，是編寫Spark框架的的語言。Scala的優點是面向對象，支持函數式編程，能帶來更高層的並發模型。
2.5.2 SparkSQL
SparkSQL專注於處理結構化數據，可以作為Sql在數據庫中獲取數據。還有兩個用於交互式計算的DataFrame和DataSet。
2.5.3 SparkMLlib
基於協同過濾的推薦需要借助機器學習來完成，用Spark的機器學習實現庫組件SparkMLib可以幫助我們更好的結合機器學習內容完成協同過濾算法的實現。
2.5.4 SparkStreaming
SparkStreaming是流式計算框架；它被用於大數據的流式處理實時計算。推薦系統的實時需求的實現就要用到SparkString處理消息隊列Kafka中的數據，進行數據的快速處理和計算。
2.6商品推薦主要用到的算法
基於大數據環境下的電商推薦系統核心算法就是推薦功能，也是本課題項目的關鍵所在，本項目包含統計分析推薦、機器學習智能推薦，離線推薦和實時推薦，下面將對相關算法做簡要說明。
2.6.1 離線統計推薦算法
離線統計推薦是非個性化推薦，也就是說，對於任何不同的用戶，這部分推薦的內容應該是一樣的；所以離線統計推薦就是每隔一段時間，把信息指標通過自己的任務運行計算，將推薦列表計算出推薦給每個人。
2.6.2 協同過濾算法
協同過濾算法是比較著名的商推薦算法，國內外研究者頗為喜愛，它誕生較早，通過對使用者歷史動作的數據挖掘進而分析用戶的偏好，基於不同的偏好對適用人群進行區分。可以從多個角度進行協同過濾推薦：基於用戶、基於商品、基於隱語義模型。
2.6.3 協同過濾LFM隱語義模型
LFM（later factor model）是一種基於模型的矩陣分解的召回算法，輸入UI點展矩陣，輸出是P和Q兩個矩陣。本項目中是將評分矩陣拆解為用戶特征矩陣和商品評分矩陣。
建模公式如式2.3所示：
2.6.4 實時推薦算法
實時推薦滿足的是更快地更新要求，准確性的標准可以略微降低。但是實時算法不能太過復雜，每次讀取的數據也不能大量。因為在實時算法面前短的時延才是標准。
2.7 推薦系統的常見召回路徑
推薦系統面對的主要問題就是如何從海量數據中挑選出用戶的興趣愛好且還要滿足低時延性能要求（例如NetFlix的指標是250ms返回，今日頭條指標是200ms返回結果）。當今推薦系統往往存在三個步驟：召回，排序，調整[4]。
召回環節實現兩個功能：一是巨量的數據降低，從億級別到萬級別；二是選取與用戶相關的感興趣的條目。方式一般有：協同過濾、內容相似等。
排序環節一般利用機器學習算法：邏輯回歸或者二分類算法等得到的結果降序排序就會得出用戶的喜好列表，此時的數據量降為千或百。完成了精細的個性化功能。
調整環節對排序后的加過進行優化，去除推薦重復，將購買過的商品進行去除等，熱門補足等。
推薦中的常見的召回路徑有以下幾類：
I2I、U2I、U2I2I、U2U2I、U2tag2I，I代表物品Item，2諧音為to，相當於圖中的邊，U代表用戶，如圖2.4所示。
1.I2I：從一個物品到達另外一個物品，例如今日頭條會在一篇文章的最后列出預制相似的另一篇文章。可基於內容相似。協同過濾、關聯規則挖掘等實現。
2.U2I：來源於用戶的直接行為，例如播放，購買，收藏等。
3.U2I2I：可以看做U2I+I2I的方法結合。根據用戶的喜好找到喜愛的商品，在找到與這個商品相似的另一個物品。這個新找到的物品推薦給用戶。
4.U2U2I：看做U2U+U2I的方法結合，U2U可以通過行為找到，也可以根據標簽找到。把第二個用戶的喜愛物品推薦給第一個用戶。中間的橋梁通過U2U實現。
5.U2tag2I：這個是把U2I2I更泛化的一種召回路徑，tag表示的就是用戶喜好的商品的標簽，通過標簽的相似度查找標簽相似的物品，將結果推薦給用戶。
2.8 本次推薦系統部署環境
在大數據環境中，Linux是具有先天優勢的；開源，擁有眾多的發行版，是廣大程序員的首選；但是隨着大數據技術棧的發展，時至今日，Apache各大主流框架組件已經支持Windows環境；例如Kafka，Zookeeper等；以kafka為例，可以發現，后續大數據組件版本的根目錄結構中多出了/Windows，其文件目錄中的執行腳本也從.sh換成了在Win環境中的執行腳本.bat文件。所以，本次項大
數據環境決定嘗試部署在Windows環境下，同時這也是現階段對該類的現階段研究的一個變化。
第三章 系統分析與整體結構
本畢業設計實現的推薦系統要明確電商中推薦算法的運用以及推薦系統的完整開發與上線部署，對用戶的需求進行分析，需求合理可執行，方可對系統進行開發。
3.1可行性分析
電商推薦系統的可行性分析是衡量系統能否順利實現指標，有以下幾點：技術可行性、時間可行性、經濟可行性。
3.1.1技術可行性
該系統在當前環境下技術可實現，推薦系統采用B/S架構，B/S架構又稱瀏覽器/服務器架構，他的優點是容易維護，只需要瀏覽器就可以發起請求操作。不需要繁雜的安裝系統等，適合本次推薦系統的開發選型。前后端分離技術，部署上線並不困難，即使未來有需求改為C/S結構，那也只需要構建C端的界面代碼及配置項，無需較大改動。將推薦系統開發完畢可以利用Tomcat將打包的war文件部署到服務器實現網絡訪問。
3.1.2經濟可行性
該系統采用的框架皆為開源框架，全部免費。在項目框架上選用約為“0”成本，項目上線的運維成本也比較低，通過Zookeeper搭建管理集群，構建分布式或者偽分布式結構，推薦系系統主節點宕機服務異常停止的情況下節點可以由follower繼續接替工作，留出足夠的時間給開發者排查，解決問題，在此期間不會影響系統的正常工作。所以運維成本也可以降低。
3.1.3時間可行性
畢業設計推薦系統系統從查閱資料到選型、構建、開發、完成，由於基本需求比較明確，使用框架開源，社區維護者很多，碰到的開發問題可以較快時間解決，老師指導耐心全面，參考資料豐富，可以在規定時間內完成開發並加以測試、修改及完善。
3.2系統用戶需求分析
接下來介紹本系統的各部分需求。
（1）注冊功能：登錄注冊功能的實現；新用戶在首頁都需要注冊用戶方可成為新用戶，新用戶首次登錄需要注冊用戶名，注冊后方可登錄系統。在注冊時還要判斷該用戶名有無被搶先注冊，如果被提前注冊，那么要提示用戶這個用戶名已經被注冊；使用其他用戶名重新注冊。
（2）忘記密碼：對於已注冊過的用戶再次登錄時，如果忘記自己的登錄密碼，可以根據自己的密保方式找回自己的密碼。
（3）用戶登錄：注冊過的用戶將正確的用戶名和密碼輸入后可以順利登錄系統。看到自己的推薦頁面。
（4）用戶退出：在用戶瀏覽尚品后要可以做到安全退出，防止其他非法人員盜用信息。
（5）推薦頁面的展示：系統要把每個用戶的推薦列表在頁面上進行展示
通過程序運算將推薦列表進行可視化展示。
（6）埋點數據采集：系統前端要能捕捉到用戶打分的行為傳到后端，后端要將埋點日志進行捕捉並本地保存。
（7）埋點日志的監聽：系統要能時刻動態監聽到日志文件的變化，用以第一時間捕捉日志文件。
（8）埋點日志的處理：系統后端將前端穿過來的日志進行格式處理，識別日志文件中的用信息。並將其中有用的數據截取出來，傳到相應的推薦模塊計算推薦結果或者推薦列表。
（9）統計推薦：推薦系統要能准確推薦出后台統計出的物品評分歷史，准確找到評分最多的物品列表。
（10）基於物品標簽的推薦：推薦系統要能根據物品的標簽內容，推薦出標簽相似度最高的其它物品。
（11）實時推薦：推薦系統要將用戶的實時打分數據進行處理，系統要快速處理給出響應並更新推薦列表，實時的反饋給用戶。
（12）基於模型的協同過濾推薦：系統要實現基於模型的協同過濾，實現個性化推薦。
（13）商品模糊查詢：對商城內的已有商品進行模糊查詢，快速找到相關商品。
整個推薦系統的用例圖如圖3.1所示。
3.3系統性能需求分析
（1）數據存儲部分：業務數據庫要滿足頻繁的增刪查改的需求，而且數據多為非結構化數據，緩存數據庫需要滿足高效，實時計算的要求。
（2）響應速度：API請求的普遍時間是小於1s；打開或跳轉Web頁面時間加載所有數據，JS圖片等相關完整內容共不能超過8s。
（3）並發量：系統要同時支持多用戶同時在線，滿足並發處理多用戶的推薦需求。
3.4系統的整體結構
綜合以上系統結構用戶需求以及性能需求，畢業設計推薦系統整體結構設計如圖3.2所示，離線推薦模塊包括四個詳細的離線推薦：分別為離線統計推薦服務、基於隱語義模型的協同過濾、基於物品的協同過濾、基於物品標簽的相似度推薦；實時推薦模塊的結構在圖的右側由Flume、Kafka、SparkStreaming相接組成。
這些模塊的推薦結果與業務數據庫MongoDB相連接；前端可視化通過Spring后台的處理從MongoDB拿到結果后展示給用戶。用戶的操作通過前端再傳到后台，通過日志采集服務進行監控日志文件，傳輸到Kafka消息隊列進行日志數據處理，再通過SparkStreaming實時推薦服務結合業務數據庫的結果把數據傳輸到Redis緩存數據庫，供實時推薦列表的快速刷新。
推薦系統Spring后台流程控制MVC結構如圖3.3所示，前端點擊綁定的函數觸發rest請求對服務器發起訪問，請求包括注冊、登錄、評分等等。任何一個請求都有唯一的標識，Controller接到數據會轉換成Model實體類，與數據庫進行交互，計算的結果仍會返回到Controller，最后向View層發送結果數據，進行數據的解析與前端顯示。
3.5系統的數據源
推薦系統的基礎數據源於學者在GitHub上開源數據集亞馬遜商品集[5]。共分為兩個部分：物品信息和用戶評分信息。
結構如表3.4所示：
表3.4 物品信息表結構
| 物品ID |
物品名稱 |
物品種類向量 |
物品圖片URL |
物品標簽 |
| 160597 |
白鹿原 |
832,519,1 |
https://images-cn- |
小說|文學藝術|圖書音像 |
| 66003 |
諾基亞N1280 |
1128,640,304 |
https://imag s-cn- |
手機|手機通訊|手機 |
| … |
… |
… |
… |
… |
商品信息共487條。
評分信息結構如表3.5所示：
表3.5 評分信息表結構
| 物品ID |
用戶ID |
分數 |
時間戳 |
| 160597 |
452794 |
4.0 |
1264089600 |
| 66003 |
452754 |
1.0 |
1351267200 |
| 160597 |
452796 |
5.0 |
1381766400 |
表中被一行為兩兩對應的評分，每個物品由對應用戶在某一時間點打出的分數。例如：表格中第一行意思是452794用戶為id為160597的商品在1264089600的時刻打上了4.0的評分。這兩個表的數據是構建系統時的初始數據；整個系統運行的數據遠不止這些，在后文數據庫設計會詳細說明。
第四章 系統方案的具體設計
4.1系統功能設計原則
4.1.1微服務
系統采用微服務架構，利用Maven自動控制jar包依賴，各部分相互獨立，松耦合。每個推薦模塊相互獨立，就模塊而言互不干涉。
4.1.2系統的可靠性
微服務設計理念有強調，系統中加用日志和監控能使系統變得更加健壯。還有要考慮到消息在傳輸過程的准確性，避免網絡擁塞，消息緩存隊列是必要的也是必須的。系統的各組件，都已經比較成熟，開源社區為系統的可靠持續運行提供強大的后盾支持。
4.1.3系統的維護性
本系統目前部署在單節點偽分布式下，遇到問題可以根據日志快速定位並回滾。當前只存在單機部署，維護方便快捷。
4.2系統總體架構設計
4.2.1 前端模塊的設計
前端展示運用AngularJS編寫，完成對數據可視化視圖的構建，利用webpack打包並將前端項目一同放入后端項目文件，將請求與操作進行綁定，定義路由，請求方法等，規定渲染流程。
前端模塊具體包括：
1.home：推薦系統首頁，將推薦線結果進行展示。
2.login：登錄模塊的頁面，進行用戶登錄的表單構建。
3.register：用戶注冊頁面，完成注冊模塊的構建。
4.tags：定義tags標簽，這個標簽要js實現商品的標簽
5.star：定義打分，需要實現鼠標滑動打分的效果以及綁定打分的數據與操做
6.mdetail:商品詳細信息頁，定義商品的可視化結構，要包括標簽、評分、詳細信息等信息。
4.2.2 后端業務模塊的設計
主要采用Java寫明Pojo實體類，controller控制層，service業務層；接收前端傳來的數據，根據對應的請求進行restful操作匹配作出對應的處理。
后端的請求處理主要包括：
1./rest/user/login：用戶登錄請求
2./rest/user/register：用戶注冊請求
3./rest/user/forget：用戶忘記密碼請求
4./rest/product/most：獲取基於模型的推薦列表
5./rest/product/reating：獲取商品的評分
6./rest/itemcf/{pid}：獲取根據物品協同過濾的推薦列表
7./rest/content/{pid}：獲取基於標簽的推薦列表
8./rest/detials：商品詳情頁請求
9./rest/search：商品模糊查詢請求
4.2.3 后端推薦模塊的設計
主要采用Scala開發編寫Spark程序，根據推薦方式方法的不同，分成多個對應模塊，離線推薦、實時推薦；離線推薦包括基於統計的離線推薦，基於隱語義模型的協同過濾離線推薦、各個模塊相互獨立，松耦合。
推薦模塊具體包括：
1.統計推薦模塊
2.基於隱語義模型的協同過濾推薦模塊
3.基於物品的協同過濾推薦模塊
4.基於物品標簽的推薦模塊
5.實時推薦模塊
6.近期熱門推薦
4.3數據庫設計
4.3.1業務數據庫：MongoDB
主業務數據存放在非關系型數據庫MongoDB。
具體數據表如4.1—4.10所示：
1.Rating表結構如表4.1所示
表4.1 Rating表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| pid |
Int |
物品id |
| score timestamp |
Double Int |
評分 打分時間 |
2.Product表結構如表4.2所示
表4.2 Product表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| pname |
String |
物品名稱 |
| imageUri categoraies tags |
String String String |
圖片保存鏈接 分類 商品標簽 |
3.User表結構如表4.3所示
表4.3 User表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| username |
String |
用戶名 |
| password |
String |
登錄密碼 |
| |
String |
密保郵箱 |
| timestamp |
Int |
注冊時間 |
4.AvgRating表結構如表4.4所示
表4.4 AvgRating表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| avgrateing |
Double |
物品平均得分 |
5.BaseOnContentProArr表結構如表4.5所示
表4.5 BaseOnContentProArr表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| list |
Seq[Recommendation] |
基於內容的推薦列表 |
6.ItemCFProArr表結構如表4.6所示
表4.6 ItemCFProArr表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| list |
Seq[Object] |
基於物品協同過濾的推薦列表 |
7.ProductList表結構如表4.7所示
表4.7 ProductList表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| list |
Seq[Seq[Object]] |
商品的推薦列表 |
8.RateXProduct表結構如表4.8所示
表4.8 RateXProduct表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| num |
Int |
商品被評價總數 |
9.UserList表結構如表4.9所示
表4.9 UserList表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| list |
Seq[Object] |
用戶推薦列表 |
10.StreamRecs表結構如表4.10所示
表4.10 StreamRecs表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| list |
Seq[Object] |
實時推薦列表 |
4.3.2緩存數據庫：Redis
緩存數據庫的存在為實時推薦獲取商品列表提供了快速支持，Redis中保存了已經注冊的用戶推薦列表；格式如下：
2) "userId:1985105"
…
8) "userId:4867"
4.3.3系統數據流向
數據流向圖如圖4.11所示：
4.4離線統計模塊設計
商品離線推薦的設計是要綜合電商用戶的所有打分歷史數據，通過運行離線推薦算法，運行過后結果是固定不變的，每運行一次便會更新一次結果；結果的變化只取決於捕捉到所有使用者的評分以及將這些評分重新計算的執行時間。
離線推薦用數據庫商品的直接屬性進行計算，例如商品標簽，商品名稱，商品評分等，計算結果作為前端可視化數據的支撐。
如果按照分類划分，僅使用SQL進行的統計推薦和利用機器算法的協同過濾推薦都屬於離線推薦。
4.4.1統計推薦之歷史熱門
根據數據庫中已經存在的所有商品評分信息，使用sql統計出被評分最多的商品。這個統計僅僅是做出熱度比較高的商品，不對評分的高低做判斷。實現sql語句如4.12所示：
統計歷史熱門商品僅需要根據商品ID聚合匯總再降序排列即可，將SQL代碼注入到SparkSession.sql()函數中實現。
4.4.2統計推薦之近期熱門
在上一步的基礎上，增加時間條件進行評分篩選。實現sql語句如4.13所示：
4.4.3統計推薦之均值推薦
在數據庫中找到每個商品獲得的所有評分，求平均值，根據平均值構建推薦信息。實現sql語句如4.14所示：
統計商品的平均分僅需要根據商品ID聚合，使用系統函數（圖中的AVG函數）計算商品ID對應的平均法再降序排序，將SQL代碼注入到SparkSession.sql()函數中實現
4.5離線個性化推薦模塊設計
4.5.1基於模型的協同過濾算法設計
前邊有說到，離線統計是把所用有用戶的評分結果進行計算法處理，每個人都會看到看到相同的推薦列表。然而，個性化離線推薦就要體現出用戶和用戶之間的不同。每個人的看到的離線列表都是根據自己的評分喜好計算而出，不同用戶的喜好不同，對商品的評分不同，那么他所看到的列表熱度結果也就不同。協同過濾不可以直接用商品直接屬性，需要利用統計離線推薦結果生成矩陣。我們要用ALS訓練LFM（隱語義模型[9][7]）。
ALS算法交替最小二乘法的原理為矩陣分解技術，矩陣分解就是把一個矩陣分解成兩個或者多個矩陣的乘積，意義層面的解釋就是通過隱含特征（latent factor）將用戶的興趣與item聯系起來。主要思想如圖4.15所示。
目標函數公式如式4.16所示：
優化目標函數公式如式4.17所示：
在原始的評分矩陣中，不可能保證每個用戶對每個物品都有過評價評分。用戶和物品之間還是沒有聯系的，得到的矩陣是稀疏的缺少特征的。矩陣分解的優點可以將高維的矩陣映射成兩個低維矩陣的乘積，能解決數據的稀疏問題，自定義隱特征數量，預測的精度高，高於基於統計的協同過濾和基於內容的推薦。矩陣分解也有一定的缺點，第一個缺點。在隱語義模型中，你無法解釋這些個隱因子的具體含義；就不能將隱空間的維度與現實中的概念一一對應。第二個缺點就是模型訓練比較費時，模型的訓練需要迭代式進行，數據量大的術后天粒度的話只能是按天粒度進行訓練。
使用ALS算法可進行顯式模型訓練與隱式模型訓練，進行訓練模型時需要傳入四個參數。若進行顯式訓練，則使用ALS.train(ratings, rank, iterations=5, lambda_=0.01)；如果要進行隱式訓練，則參數為ALS.trainImplict(ratings, rank, iterations=5, lambda_=0.01)。上式中，參數ratings指訓練模型數據源，rank指的是當進行矩陣分解時，將原矩陣分解成X(m*rank)矩陣和Y(rank*n)矩陣，Iterations指ALS算法的迭代次數，lambda為正則化項系數，默認為0.01。
4.5.2模型評估和參數選取
ALS訓練隱語義模型的過程中公式中的三個參數僅僅憑借經驗或者查閱資料固定填寫。雖然可能出較好的結果，但是這樣的參數集並不一定是針對我們研究的問題的最優解。所以有必要采取模型優化的步驟對模型進行優化。可以計算方根誤差來評判模型的優劣。公式如式4.18所示：
通過RMSE計算[8]，可以反復調整參數的取值范圍，最后保留值最小的一組參數作為模型的參數最優解。
程序代碼實現如圖4.19所示：
圖4.19 RMSE優化參數代碼
4.5.3生成商品推薦列表
只有計算出來模型才能通過模型構建商品列表進行推薦。構建推薦列表的主要思路步驟如下：
1.得到用戶和商品的二元組（用戶ID，商品ID），完成這個操作只需將用戶表中的Id和商品表的Id做笛卡爾積。
2.用ALS訓練出來的模型給二元組預計算評分。
3.將最終的記過排序后保存到數據庫。
最終結果形式如圖4.20所示：
矩陣R表示用戶對物品的興趣度，矩陣P表示用戶對物品的偏好度，Q表示物品屬於哪個類別的概率如圖4.21所示。隱語義模型及時通過將矩陣R分解成P和Q的乘積，通過P矩陣物品類別將用戶User與物品Item聯系起來。
4.5.4基於物品的協同過濾以及物品間的相似度
協同過濾推薦針對的對象不同可以分成兩種：基於用戶的協同過濾和基於物品的協同過濾；由於此時用戶群體非常少，基於用戶的協同過濾[7][8]不夠明顯，所以暫且不討論基於用戶的協同過濾，下里面來講述基於物品的協同過濾[9][10][11]。
基於物品的協同過濾[12][13]判斷兩個商品相關性的大小，一般用余弦相似度作為依據。不需要對物品進行標簽采集分詞，只需要收集用戶的行為（例如點擊、收藏、購買、評價等）便可以進行基於物品的協同過濾推薦。可以通過前邊的余弦相似度進行評判，也可以用同現相似度[14]來反應物品間的相似程度。計算公式如式4.22所示：
4.5.5基於物品標簽的推薦
基於物品標簽的推薦[15][16]需要利用物品的初始標簽，對標簽進行分類從而進行同類推薦，這個部分會把商品中屬於同一類的物品進行篩選展示。實現思路為在Spark單例中實例化分詞器，定義HashTF工具把文字信息處理成向量信息，運用TF_IDF進行特征矩陣的獲取。
4.6實時推薦算法設計
在電商推薦系統中，實時的更新推薦列表能給用戶帶來更好的體驗，假如物品推薦的列表只有到了系統設定的時間（例如凌晨）實時推薦[17]與離線推薦應最大的不同之處在於實時計算推薦推薦列表應該動態更新，能計算出用戶近期的喜好並推薦商品，需要實時技術的支持而不是在后台周期性的運行算法模塊。
4.6.1實時推薦算法
推薦系統的使用群體對商品的喜愛與否是會隨時間逐漸變化的。我們假設小明喜歡喝牛奶，比如小明在某個時間點對“A牌牛奶”做出了很高的行為舉動（例如購買、收藏、分享、好評、長時間瀏覽等），那么我們就可以猜測，小明有可能很喜歡其他品牌的“牛奶”、“奶制品”等；而如果小紅在某天給“L牌辣條”做了負面行為（例如寫差評、從購物車刪除，取消收藏、退貨等），那么我們就可以推斷：“L牌辣條”不是小紅這段時間心儀的商品，更甚至與“辣條”相似的同類物品如“辣片”、“麻辣”等都不會被小紅納入采購的行列。所以針對於實時推薦，每當用戶對某個產品進行了評分，后台要根據這次的行為動作捕捉具體的的喜好或者忌口，從而更新推薦列表，使結果能喜好最大程度匹配。
4.6.2實時推薦算法設計
實時推薦[18]推薦優先級的基本思路：用戶短時間內的喜好保持一致相似。
初步計算備選商品的推薦優先級公式4.23的如下：
公式的意義如下：基礎評分項*評分（權重系數）從而調整推薦力度+，除以sim_sum做平均，結果就是推薦優先級得基礎分數；后邊的偏移量一個是鼓勵項，一個是懲罰項；鼓勵項：最近的評分都是高分，看了買了還給了高分，說明最近的行為很能代表自己的喜好；如果最近將某個商品拉黑刪除等，說明用戶不喜歡這個商品。這個商品的類別就不能代表用戶的喜好。
第五章 環境部署和系統實現
5.1環境部署
以下環境作為本次畢業設計系統部署的開發環境參考：
5.1.1基礎環境
操作系統如圖5.1所示：
5.1.2 MongoDB環境安裝與配置
1.安裝MongoDB：到MongoDB官網下載社區免費版MongoDB msi安裝程序，
將下載到本地的msi安裝程序運行，按照個人需求安裝在目錄,以下簡稱為：%MONGODB_PATH%。
2.創建數據與日志文件夾：在%MONGODB_PATH%中找到data文件夾在內部創建db和logs文件夾以存放數據和日志信息。
3.配置環境變量：在系統環境變量中加入%MONGODB_PATH%
4.啟動mongodb服務：輸入指令mongod --dbpath %MONGODB_PATH%\data\db;
5.檢查服務：瀏覽器輸入http://localhost:27017如果提示連接成功，那就表示MongoDB環境已經配置完成。
5.1.3 Redis環境安裝與配置
1.安裝Redis：到Redis官方github倉庫下載現階段穩定版本的msi。將下載的msi文件安裝運行，按照個人習慣安裝在指定目錄，以下簡稱%REDIS_PATH%。
2.將%REDIS_PATH%添加到系統的環境變量中。
3.啟動Redsi臨時服務：輸入指令redis-server.exe redis.windows.conf
4.創建Redis連接：輸入指令redis-cli。進入redis說明redis環境已經配置完成
5.1.4 Zookeeper環境安裝配置
1.解壓Zookeeper壓縮包：到官網下載Zookeeper安裝包，根據個人習慣解壓文件到指定路徑，以下簡稱%ZK_PATH%，將%ZK_PATH%添加到系統環境變量中
2.復制%ZK_PATH%\conf\zoo_sample.cfg文件，重命名為zoo.cfg；修改文件內容，將dataDir和dataLogData的路徑修改為自定義路徑。
3.運行zkServer.cmd可執行腳本，運行zkCli.cmd腳本。提示連接到2181端口和出現“Welcome to Zookeeper！”字樣便證明環境配置成功。
5.1.6 Kafka安裝與配置
1.官網下載Kafka安裝包，並根據自己的習慣解壓到自定義路徑，以下簡稱%KAFKA_PATH%，將%KAFKA_PATH%加入到系統環境變量中。
2.進入%KAFKA_PATH%\conf目錄編輯文件server.properties，將log.dir修改為自定義路徑，建議為%KAFKA_PATH%\kafka-logs；編輯zookeeper.connect=localhost:2181
3.創建topic測試kafka安裝成功：在%KAFKA_PATH%下運行指令
.\bin\windows\kafka-topics.bat --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic tast；
4.運行指令查看主題
.\bin\windows\kafka-topics.bat --list --zookeeper localhost:2181；
如果顯示列表中存在一個tast主題說明kafka環境配置成功。
5.1.7 Flume安裝與配置
Flume安裝包下載：到Apache官網下載Flume安裝包，根據自己的習慣解壓到指定路徑%FLUME_PATH%，將%FLUME_PATH%添加到系統環境變量中。
5.1.8 Scala環境配置
Scala安裝包下載：官網下載Scala安裝包;根據自己習慣將安裝包安裝在指定路徑，以下簡稱%SCALA_PATH%，注意此路徑中不能包含空格。將%SCALA_PATH%添加到系統變量中。安裝完畢在cmd命令行輸入scala顯示版本信息即為正確配置環境。
5.1.9 Jdk環境配置
官網選擇合適的JDK版本，建議選擇穩定且普及率高德JDK8；根據個人習慣將壓縮包解壓至指定路徑，以下簡稱%JAVA_HOME%；將%JAVA_HOME%添加到系統環境變量中。輸入命令java -version有版本信息輸出說明環境配置成功。
5.1.10 Maven環境配置
Maven官網下載安裝包，根據個人習慣，將安裝包安裝到指定目錄，以下簡稱%MVN_HOME%，將%MVN_HOME%添加到系統環境變量。cmd輸入指令 mvn -v查看Maven版本號，有版本號正確輸出便說明環境正確安裝成功。
5.1.11Spark環境安裝配置
下載Spark安裝包，根據個人習慣將安裝包解壓安裝在指定目錄，以下簡稱為%SPARK_HOME%，將%SPARK_HOME%添加在系統的環境變量在cmd中輸入spark-shell,顯示有正確版本號輸出，那就說明環境正確安裝。（Spark環境是依賴於JDK8以上版本+Scala環境，安裝配置Spark環境時確保JDK與Scala環境已經正確安裝）hadoop報錯提示在單機環境下運行時可以忽略。也可以自行安裝Hadoop環境搭建高可用集群。
5.2成果實現展示
前端模塊構建的主要是識別用戶的身份信息，將推薦列表做數據可視化展示，包含用戶注冊、用戶登錄、瀏覽商品頁面、商品模糊查詢、用戶打分、以滿足基本的要求。
5.2.1登錄展示效果
登錄界面如圖5.2所示
5.2.2用戶注冊頁面展示
用戶注冊界面如圖5.3所示，若注冊時改用戶名被搶先注冊，那么系統會提示注冊失敗，請更換用戶名注冊。
5.2.3離線統計推薦實現
離線統計推薦在系統中的具體實現是熱門推薦模塊和評分最多推薦模塊如圖5.4所示,熱門推薦列表是基於商品的評分高低，求所有用戶對物品的平均分得出來的推薦列表，具體實現過程為把評分數據定義成一個新的樣例類（僅關注評分表中的分數，與物品id）通過Spark以DataFrame的形式進行讀取，使用Spark.SQL統計出在歷史時間內的評價均分最高的物品，將統計后的數據保存在MongoDB中的RateXProduct表中，保存的序列就是商品平均分由高到低的序列，這也就是前端頁面展示出的熱門推薦列表的內容。評分最多推薦模塊的實現是基於評分的次數，而不是評分的高低，步驟與前邊類似，將評分數據以Spark的DataFrame形式讀取，使用SparkSQL統計商品的評分次數，降序排序，得到的列表即為評分最多的列表。需要注意的是：評分最多代表的是用戶給他的評分此時多。並不能說明用戶給他的評分數值高。這點需要讀者認真區別。
5.2.4離線協同過濾基於模型的個性化推薦實現
基於模型的協同過濾需要用到用戶的歷史數據進行計算，用戶打分的行為數據，定義新的樣例類，將數據加載到定義的RDD中，提取所有用戶的商品打分數據，將數據轉換成mllib規定的規范格式進行隱語義模型的訓練，規范中要具體三個參數：隱特征個數、迭代次數、正則化系數。RDD調用cartesian函數得到笛卡爾積；此時就擁有了一個稀疏的評分預測矩陣；接下來對矩陣進行分解，將稀疏額矩陣變為稠密矩陣。將數據集切分，運用Mllib中ALS.train訓練模型，getRMSE得到最優模型參數。得到了模型就可以將矩陣最優分解，再做笛卡爾積；就能得到商品兩兩的相似度；此時還要過濾掉自乘的結果，因為自乘的結果相似度為1。計算出物品的相似度矩陣。挑選出相似度最高的物品。組成基於模型的協同過濾推薦列表如圖5.5所示。
5.2.5基於物品的協同過濾推薦實現
基於物品的協同過濾用到了第二章介紹的U2I2I召回路徑：分為兩步：U2I和I2I；U2I根據用戶找到喜愛的物品；I2I根據物品找到相似物品；I2I這個步驟通過同現相似度完成，使用商品之間的同現相似度計算出推薦商品，具體實現步驟為：加載數據到spark，按照pid做group by對評分進行統計，新加一列sum存放評分個數。此時數據應為pid|num；再將評分按照uid兩兩匹配，統計商品被同一個用戶打過分數的次數，此時的結果中油兩個pid；將這兩個pid做group by；統計出uid的個數；那么就算出了對兩個商品同時評分的個數。將這個序列倒序輸出，就得到了基於物品U2I2I的協同過推薦列表如圖5.6所示。
5.2.6實時推薦實現以及打分操作的流程
當我們對一個商品進行打分操作時，評分的數據會在控制台看到，並且以埋點日志的方式存到本地文件；Flume檢測到本地文件變化，就會將日志預處理傳送給Kafka消息隊列，KafKa消息隊列將數據傳到SparkStreaming；通過計算運行將處理后的結果保存到Redis中。操作過程步驟如圖5.7-5.10所示。
以上就是一個完整的物品打分數據流；此時實時推薦結果已經更新。圖5.11與5.12展示了用戶對商品進行評分后實時推薦的變化。
5.2.7基於物品標簽的推薦
打開《這就是你給我的愛》物品詳情頁；可以找到下面對於這本書的標簽：書、少兒圖書、教育類、勵志、雞湯、好看、內容不錯。基於物品標簽的推薦的實現是通過Mlib中的Tokenizer將物品的標簽通過“|”分詞，實例化一個HashingTF工具增加一列向量表示這個物品的標簽，訓練idf統計向量出現的頻次，把這些特征轉換成和和模型協同過濾推薦一樣的RDD，兩兩配對商品計算余弦相似度，過濾掉自己本身，得出的變標簽相似列表。
我們繼續查看它基於標簽的的推薦列表，打開第一本書：《30年后你拿什么養活自己》如圖5.13所示，查看標簽如圖5.14所示，發現相似度很高，標簽有 書、勵志、雞湯、好看 這四個是和《這就是你給我的愛》重合如圖5.15,5.16所示。所以可以得出結論。按照物品標簽推薦也是非常准確的。
5.2.8 商品的模糊搜索
在商品首頁的導航欄中，還新增了商品信息模糊搜索查詢，輸入查詢的物品名字，即可模糊搜索到數據庫中含有該名稱的物品；並直接跳轉到詳細頁面展示，如下圖如圖5.17所示。
搜索“白”，可以找到伊麗莎白化妝品，清除白噪聲耳機；白岩松的書。這部分的具體實現直接是在Spring的控制層寫了sql語句，由於不涉及到對數據評分的變化，所以沒有歸納到推薦模塊中，直接從Spring返回模糊查詢結果。
第六章 總結
6.1畢業設計總結
在完成這次畢業設計的過程中，經歷了研究開題、文獻查找閱讀、撰寫開題報告、中期檢查、文獻綜述的編寫等眾多步驟。經歷了很多，也學到了很多。通過查閱大量的相關資料文獻，總結前人的論文研究加上自己的思考與創新，最終完成了基於大數據平台的商品推薦系統設計與實現。在整個完成期間也碰到許多難題。老師和同學們都耐心的指導我幫我解決問題。自己的理解差錯也能被及時糾正。下面簡述我在本次畢業設計過程中的亮點與遇到的一些問題。
6.2推薦系統的亮點
6.2.1使用高效率的Spring框架
系統使用Spring構建整體框架使開發成本變低，后續可以轉為SpringBoot更輕量級的架構，能降低項目的成本投入以及維護成本，並提高系統運行效率。
6.2.2推薦的多樣性
系統中共多個推薦模塊：實時推薦滿足了系統推薦的實時性、統計推薦了反映了商品庫中信息的總覽，將所有用戶的地對商品的評價進行總覽、基於商品協同過濾實現了個性化推薦，讓每個用戶都要自己獨特的推薦列表、基於每個模塊都采用不同的推薦算法進行實現，使我們能從更多角度查看推薦的結果。
6.2.3 基於大數據環境下的系統環境的配置
當下大數據環境大部分都是部署在虛擬機或者雲服務器的Linux發行版的操作系統上。在Windows上配置環境的先例少之又少，原因有二：一是Apache基金會下的大部分組件先天就不支持Windows操作系統；二是在Linux上更加利於項目的配置與運行和發布。但是本次畢業設計主要為了研究推薦算法的實現以及相關業務，用戶基數少，再加上想隨着版本的迭代，大數據組件已經支持在Windows操作環境系統中安裝配置。雖然相比較而言在Windows上配置環境比Linux更加繁瑣，但是對於國內更習慣Windows的用戶來說這是一種新的探索，方便他人借鑒和參考。
6.3推薦系統實現中遇到的問題及解決方法總結
6.3.1命名規范
在本次系統代碼編寫過程中，有些類屬性代碼不規范，導致后續排查錯誤耗費時間較久，所以在編寫任何代碼時都要嚴格按照規范進行開發，避免后續維護或者二次開發碰到因代不規范而導致的問題，這類問題一般較難發現，並非邏輯錯誤，排查非常耗時。我們應養成規范編碼的好習慣！
6.3.2 Windows與Linux命令不兼容問題
本次系統創新的部署在Windows環境下，雖然大部分組件都支持在Windows環境下運行，但是windows和Linux存在本質區別；命令的啟動方式以及參數的位置都需要注意，尤其是Flume-ng啟動時，不僅要調整參數位置，更重要的是啟動命令中包含“-tail”指令，這個指令是在Linux的內置shell指令，在Windows中並不能被識別，這是就要在Windows本地函數文件中添加一個可執行文件，使操作系統可以識別到這個命令並且正常運行。
6.3.3 Kafka 異常退出
在Windows下啟動kafka產生的offset文件在關閉kafka后並不會自動刪除，如果想重啟kafka，系統不會把上次的本地文件自動刪除。需要手動刪除，否則會啟動異常。
6.4推薦系統的不足之處
在本次畢業設計中，也有許多不足的地方。例如樣本的數據不夠特別全，並不是一個完整的成熟的電商商品數據庫，等待筆者自己提升技術能力后加以完善等。
6.4.1更准確的推薦算法
迄今為止沒有任何一個推薦算法能滿足用戶全體的興趣愛好，也就是說推薦系統存在就必然會存在的問題：提升推薦准確度。推薦算法不可能做到符合每個人的興趣，這正如一句話所說：“一千個人眼中就會有一千個哈姆雷特”[20]。每個人都有各自的看法和觀點。做到完全符合每位用戶的喜好，這是推薦系統發展的最終極目標。是推動推薦系統發展的動力源頭。
6.4.2更高效的實時計算框架
Flink框架摒棄了批處理的思想，可以達到比spark更高的實時要求。由於我現在能力有限，畢業設計采取現學習資源比較成熟的spark。
6.4.3 單機模式下的風險
我們知道在當數據量級變大時，必要的數據冗余是保證節點在遇到宕機等突發情況下恢復正常的保證。只存在一個單一節點在部署上線后，再服務器掛掉后容易發生數據的丟失。所以正式部署上線后，數據的復制是很有必要的需要將數據定時同步到其他多個節點。確保在某個機器宕機后數據不丟失。
6.4.4用戶畫像（Profile）
當下的主流電商系統都在構建用戶畫像，通過數據建立描繪用戶的標簽。逐漸把用戶畫像運用在推薦系統中，只要用戶畫像畫的夠准，那么推薦的准度就會更高。所以接下來的研究趨勢可以適當加入用戶畫像的構建[21]，從而更加提升推薦系統的綜合准確度。
供網友參考借鑒。
論文主要是理論知識的沉淀，系統實現則是對動手能力的考驗！
希望這篇文章可以幫助到需要的畢業生。如果還有疑問或者不懂得可以聯系作者，工作之余會幫助你們解決系統問題。
（2.3）
------------恢復內容開始------------
寫在前面：各位准畢業生你們好，論文已經發出來供你們參考查閱，有問題，ok，我有時間會解答，上來就讓我分享代碼的是什么意思？畢業不僅是畢業設計的考核，也希望你們對的起大學四年的時光。“你好我有些問題想請教。”什么問題？“請你分享一下你的代碼”。這就很無語好吧，這是問題嗎？論文都擺在這，推薦系統懂得都懂，你們對着教程手敲的功夫都不想付出么？從去年開始我也回答了很多人的問題。真正動手去做了的，有清晰的問題，哪里哪里。這個項目確實是有幾個坑點，當初踩坑也耗費了不少的時間。問問題的我一般都會解答；實在不明白上來要代碼的是什么意思哈？免開尊口。我願意幫助那些有動手能力的畢業生克服項目上的困難。我也不想理會那些伸手黨；沒有任何理由幫你們這些人。
本人於2021年6月畢業，當時的課題是推薦系統的算法探究與系統實現。故參考各方面資料完成了畢業設計與論文的編寫。至今也有很多人問我具體系統實現的細節。我把論文貼出來供大家參考借鑒。
終稿論文總查重率5.7%
首先說一下系統的特點：部署在 Windows上!Windows上!Windows上!
沒有用到虛擬機，沒有用到雲服務器。
目 錄
摘要. ii
Abstract ii
第一章 緒論. 1
1.1 課題研究的背景和意義. 1
1.1.1 課題研究背景. 1
1.1.2課題研究意義. 1
1.2國內外研究現狀. 2
1.2.1國外研究現狀. 2
1.2.2國內研究現狀. 3
第二章 大數據平台推薦系統的相關理論以及技術和框架. 4
2.1 JavaEE技術. 4
2.1.1 Spring框架. 4
2.1.2 MVC架構. 4
2.1.3 Maven 5
2.1.4 Restful 5
2.2 AngularJS框架. 5
2.3數據庫. 5
2.3.1 Redis數據庫. 5
2.3.2 MongoDB數據庫. 5
2.4埋點日志的采集. 6
2.4.1 Flume 6
2.4.2 Kafka 6
2.4.3 Zookeeper 6
2.5 Spark相關技術棧. 6
2.5.1 Scala 7
2.5.2 SparkSQL 7
2.5.3 SparkMLlib 7
2.5.4 SparkStreaming 8
2.6商品推薦主要用到的算法. 8
2.6.1 離線統計推薦算法. 8
2.6.2 協同過濾算法. 8
2.6.3 協同過濾LFM隱語義模型. 8
2.6.4 實時推薦算法. 9
2.7 推薦系統的常見召回路徑. 9
2.8 本次推薦系統部署環境. 10
第三章 系統分析與整體結構. 11
3.1可行性分析. 11
3.1.1技術可行性. 11
3.1.2經濟可行性. 11
3.1.3時間可行性. 11
3.2系統用戶需求分析. 11
3.3系統性能需求分析. 13
3.4系統的整體結構. 13
3.5系統的數據源. 15
第四章 系統方案的具體設計. 16
4.1系統功能設計原則. 16
4.1.1微服務. 16
4.1.2系統的可靠性. 16
4.1.3系統的維護性. 16
4.2系統總體架構設計. 16
4.2.1 前端模塊的設計. 16
4.2.2 后端業務模塊的設計. 17
4.2.3 后端推薦模塊的設計. 17
4.3數據庫設計. 17
4.3.1業務數據庫：MongoDB 17
4.3.2緩存數據庫：Redis 20
4.3.3系統數據流向. 20
4.4離線統計模塊設計. 21
4.4.1統計推薦之歷史熱門. 21
4.4.2統計推薦之近期熱門. 21
4.4.3統計推薦之均值推薦. 21
4.5離線個性化推薦模塊設計. 22
4.5.1基於模型的協同過濾算法設計. 22
4.5.2模型評估和參數選取. 23
4.5.3生成商品推薦列表. 24
4.5.4基於物品的協同過濾以及物品間的相似度. 25
4.5.5基於物品標簽的推薦. 25
4.6實時推薦算法設計. 25
4.6.1實時推薦算法. 25
4.6.2實時推薦算法設計. 26
第五章 環境部署和系統實現. 27
5.1環境部署. 27
5.1.1基礎環境. 27
5.1.2 MongoDB環境安裝與配置. 27
5.1.3 Redis環境安裝與配置. 27
5.1.4 Zookeeper環境安裝配置. 28
5.1.6 Kafka安裝與配置. 28
5.1.7 Flume安裝與配置. 28
5.1.8 Scala環境配置. 28
5.1.9 Jdk環境配置. 29
5.1.10 Maven環境配置. 29
5.1.11Spark環境安裝配置. 29
5.2成果實現展示. 29
5.2.1登錄展示效果. 29
5.2.2用戶注冊頁面展示. 30
5.2.3離線統計推薦實現. 30
5.2.4離線協同過濾基於模型的個性化推薦實現. 31
5.2.5基於物品的協同過濾推薦實現. 32
5.2.6實時推薦實現以及打分操作的流程. 32
5.2.7基於物品標簽的推薦. 35
5.2.8 商品的模糊搜索. 36
第六章 總結. 37
6.1畢業設計總結. 37
6.2推薦系統的亮點. 37
6.2.1使用高效率的Spring框架. 37
6.2.2推薦的多樣性. 37
6.2.3 基於大數據環境下的系統環境的配置. 37
6.3推薦系統實現中遇到的問題及解決方法總結. 38
6.3.1命名規范. 38
6.3.2 Windows與Linux命令不兼容問題. 38
6.3.3 Kafka 異常退出. 38
6.4推薦系統的不足之處. 38
6.4.1更准確的推薦算法. 38
6.4.2更高效的實時計算框架. 39
6.4.3 單機模式下的風險. 39
6.4.4用戶畫像（Profile）. 39
參考文獻. 40
謝 辭. 42
第一章 緒論
1.1 課題研究的背景和意義
1.1.1 課題研究背景
隨着科技的快速發展，當下電子商務在全國盛行，各大電商憑借自己獨特的營銷方式爭先搶占市場，隨之帶來的便是指數級別增長的數據量，在最短時間內找到用戶想要的商品就能深受使用者青睞。在我們平時的網上購物中；琳琅滿目的商品使我們往往淹沒在商品的數據中，但是其實我們可以發現：在我們瀏覽商品過后，在下方推薦的都是相同的類似商品。這就是推薦系統為我們帶來的便利之處，推薦系統的運用使我們不會被商品數據的洪流淹沒。根據阿里巴巴2020年12月31日的2021財年第三季度財報。數據顯示，該季度阿里巴巴營收達2210.8億元，高於市場預期的2141.58億元，與去年同期的1614.56億元相比增長37%，據悉其中國零售市場移動月活躍用戶數已達9.02億，年度活躍消費者達7.79億，單季凈增長2200萬。由此可見，國內的電商發展已經為社會帶來了巨大的經濟效益，也更加方便了人們的日常生活。不僅電商巨頭在推薦系統上煞費苦工，各類App都開始接入推薦的模塊，例如抖音App會根據用戶的喜好推薦觀看列表；網易雲音樂根據用戶的喜好生成個性化的推薦音樂列表等等。越來越多的專家和學者也對推薦系統進行了研究，國內外也出現許多優秀論文可供我們參考學習。
1.1.2課題研究意義
在如今的大數據時代，信息呈指數增長，人們很容易迷失在數據洪流中，面對大數據的沖擊，我們希望能有一個推薦准確率更高的系統完成對無關商品的過濾，將我們真正感興趣的商品留下來，為我們帶來更好的購物體驗。本課題實現商品推薦系統，使用Spark框架實現離線推薦、在線推薦、針對每位用戶完成個性化推薦，讓大家的用戶體檢更更加豐富，不局限於大眾的喜好。本課題結合大數據相關組件工具Zookeeper、Flume-ng、Kafka等，JavaEE企業級框架Spring，Tomcat部署系統服務，將整個系統部署在線上，可為小型電商公司作為商品推薦的雛形，也可供后來研究者更直觀清晰的學習。研究出來電商推薦系統准確度較高的推薦算法，能為電商企業和消費者提升粘合度，達到商品的“精准營銷”的目的，不僅能給電商平台提升市場競爭力，而且給用戶提升網上購物的消費體驗，實現電商交易的“雙贏”。
1.2國內外研究現狀
推薦系統的概念最先起源於國外，最早被運用於新聞推薦。亞馬遜發現了推薦系統在電商領域的巨大潛力，最先把推薦技術運用在電商系統中。
NetFlix提出了經典的推薦架構。在20世紀末，21世紀初期國內的電商才隨着互聯網的普及進入國內開始發展。直到現在，國內外的各大電商的推薦系統逐漸完善，電商推薦算法也推逐漸陳出新。給人們網上購物帶來極佳的的用戶體驗。
1.2.1國外研究現狀
推薦系統的鼻是祖1994年在國被設計出來的新聞推薦系統。亞馬遜率先發現了推薦算法在電商的優勢，並率先將推薦系統引入到電商中。為推薦系統的發展開辟出一條道路，對之后后的電商發展產生了很大的影響。
在國外，推薦系統依舊在亞馬遜沿用至今，隨着技術的不斷成熟以及用戶體驗的要求不斷提升。解決冷啟動問題[1]，運用機器學習訓練推薦模型[2]已經逐漸普及。
在2006年Netflix國外舉辦懸賞尋求可以將推薦准確度提高10個百分點的優秀學者。在此之后，高准確度算法推薦系統就開始出現。但仍然不能達到推薦完全正確；所以提高推薦的准確度就是衡量一個推薦算法是否有效的最好切入點。
也是推薦系統發展路上一直要攻克的難題。
2013年3月27日，Netflix的工程師在官方博客發文，推出了經典推薦系統架構——NetFlix推薦架構[3]。整個技術架構分為三層：ONLINE在線層、NEARLINE進線層、OFFLINE離線層。三層相互獨立，互相配合共同完成推薦系統的運行。在線層直接對接用戶與系統的交互，用戶在交互的過程中會伴隨着許多操作，例如評分、瀏覽等。這些作為前端的日志打點序列分發到離線層的Hadoop和近線層的流失處理平台（類似於SparkStreaming）。離線層一般以天或小時為粒度進行計算；數據存放於HDFS使用Pig、Hive等對數據進行過濾、提取。將最終的數據進行分發完成離線計算和模型訓練。模型可以傳到在線層供用戶實時計算，也可以在離線層提前預計算出用戶的推薦列表。還可以將矩陣分解得到用戶向量和物品向量。近線層是在線層和離線層之間的橋梁，近線層的計算可能會用到離線數據，也可與在線層的數據相接。這一層的計算結果往往存到一些高速緩存，以備調用。在線層一般會存在一個算法服務調度，這個服務會從高速緩存中獲取數據，使用在線層計算將結果快速計算出來。在線層不可以使用復雜的算法，不能讀取大量數據，因為要確保數據的快速響應。
Embedding技術[4]也在近期盛行起來，運用Embedding技術可以做出人人推薦、人物推薦、物物推薦等從中找到猜你喜歡的商品，可能認識的用戶等，在這個方面應用都有很好的效果反饋。
1.2.2國內研究現狀
在中國國內，雖然推薦系統起步不及國外早，但是近幾年的發展大家也有目共睹。2003年是我國公認的電商元年，從那時起，各大電商巨頭就將推薦算法逐漸引入到他們的線上電子商務中。隨着國內互聯網技術的發展與成熟，推薦系統現在已經能很好的帶給我們使用體驗。現國內研究推薦系統的研究者有大部分都集中在基於協同過濾算法[6]方向，建立基於模型的協同過濾體系[7][2]；通過用LFM建立模型使得推薦更加高效，提平等，李啟旭，郁雪，王巧等作者都發表了相關文獻來推動國內推薦系統的建設。也有作者利用FPFM組推薦框架[8]進行統推薦的研究；由於實時性是推薦系統繞不開的話題，國內也有部分作者對推薦系統的實時性有獨特見解。
2006年，國內書籍電商巨頭當當網首次將推薦系統運用，收到廣大用戶的好評；兩年之后，淘寶團隊也研發出自己的電商推薦模塊加以運用——“i淘寶”
這是淘寶電商推薦系統的雛形；到了2011年，百度也加入推薦技術行列，着重於搜索技術的個性化推薦。並提出了“一人一世界”的口號。
近幾年，用戶畫像逐漸成為推薦系統最火爆的應用。用戶畫像也能更精確的為每個用戶添加標簽，給用戶精准定位。目的就是為了把握每個用戶的興趣喜好，推廣合適的業務給用戶。
第二章 大數據平台推薦系統的相關理論以及技術和框架
2.1 JavaEE技術
在當下互聯網B/S模式的興起，Spring開源框架成為各大互聯網哪個公司搭建項目的首選。在web端的開發語言中，根據調查結果（圖2.1）Java無疑是近10年來開發者的首選。由於其跨平台性、高效的計算性能，以及全球眾多開發者在類庫和框架方面的開源貢獻，Java語言是本次課題項目實現業務系統綜合業務的首選，此次選擇的是基於Java語言的Spring框架。
2.1.1 Spring框架
在Spring框架是為了簡化JavaWeb開發而創建的；傳統的企業級應用開發，龐大的EJB使開飯維護工作量異常大；除了寫代碼邏輯，更重要的是配置組件之間的關系。然而為了解決這一難題。Spring框架誕生，Spring是一個容器框架，幫助開發者注冊加載各種組件，實現較EJB輕量級開發。
2.1.2 MVC架構
系統利用當下主流的MVC結構模式結構進行開發，M、V、C分別代表業后端編碼的三大構成M（模型）層大體可以分為兩類：承載數據的實體類業務處理的處理類。和、V（視圖）層是用戶直面系統的一層，也是用戶和系統交互的一層、C（控制）層把用戶和系統的交互操作轉換成請求發給相應的模型，根據模型的處理結果向用戶返回響應，MVC是如今J2EE應用極其廣泛的層次架構。
2.1.3 Maven
Maven是Apache基金會開源的依賴控制組件，是現大型web項目采用的jar包依賴以及模塊控制的結構，用小段描述信息管理項目的構建，便於開發人員直觀的查看項目結構和依賴。
2.1.4 Restful
Restful是基於HTTP的一種網絡應用程序的設計風格,是一種開發規范，用來寫接口時規范命名，使用restful風格開發接口可以使接口名稱長度變短，更加簡單清爽簡介，也便於開發人員直觀閱讀，看到接口的名稱就可以判斷該接口的功能。適用於移動互聯網廠商作為業務接口的場景，通過發起方式的不同請求完成對數據的增、刪、查、改等操作，極大的提升開發效率。
2.2 AngularJS框架
前端框架采用AngularJS，谷歌開源。AngularJS可以實現數據的雙向綁定。雙向綁定的操作通過檢查臟數據完成，但是臟檢查機制不是定時進行，而是在數據發生變化時也就是dom元素或者xhr事件的變化會引起底層的digest函數，這個函數會從底層逐步遍，檢查所有的watcher是否變化，如果數據變化，那么就會執行指令完成數據變化。從而實現雙向綁定。
2.3數據庫
電商推薦系統的構建選擇非關系型數據庫；因為在大數據環境下，數據的量級大且有一個特征：關系不一定完整；關系型數據庫並不適合大數據環境下的數據存數；所以利用非關系型數據庫非常符合本次場景，是大數據環境下業務的需要。
2.3.1 Redis數據庫
Redis是一種非結構化數據庫，是一種作用在內存上的緩存數據庫，Redis的讀、寫性能極高，可作為緩存、消息隊列、分布式鎖等場景應用。這次畢業設計基於大數據平台 商推薦系統就是借助Redis存儲和傳輸實時數據用於實時推薦模塊。可以按滿足數據的快速讀取。
2.3.2 MongoDB數據庫
MongoDB也是一種基於內存的數據庫，在存儲文檔信息發揮出色，多用於博客等存儲大量信息系統，底層用C++語言實現。是采用C++語言編寫的文檔型非結構化數據庫。基於大數據的電商推薦系統利用MongoDB存儲JSON數據格式，占用資源小，且支持單機、集群的使用。對大量的文字數據有較好的支持。
2.4埋點日志的采集
基於大數據環境中的電商數據，日志是反應用戶操作最直觀的途徑。所以需要采集日志並且用消息隊列中間件進行數據傳輸；大數據環境下有成熟的日志捕獲組件Flume和消息隊列Kafka組件。
2.4.1 Flume
Flume在大數據環境下多被用於日志的采集，由Source、Channel、Sink組成；通過管道的形式實現一對一，一對多，多對多端的數據傳輸；Flume具有可拓展性，且拓展性很強，可以單個Flume單獨使用，也可以多個Flume組合使用，采集不同源頭或者發送到不同物理位置、不同邏輯位置的文件中保存日志。支持多端多環境下配置捕捉傳輸日志數據。是專門負責日志數據收集的強大利器。本次畢業設計采用Flume將WebServer的數據采集到本地磁盤進行保存。以備Redis數據可進行快速的讀取。
2.4.2 Kafka
Kafka消息隊列可以作為緩存，為系統的傳輸可靠性提供保障，避免端與端的消息傳因各種原因出現遺漏或者丟失。Kafka能與Flumg組合使用，Flume進行數據收集，kafka在下游消費Flume采集到的數據進而將數據廣播到KafkaStreaming進行實時計算。
2.4.3 Zookeeper
還有一個特殊的框架——Zookeeper，這是基於大數據環境下為分布式應用提供調度的服務，也是Kafka服務的啟動依賴；
2.5 Spark相關技術棧
Spark在網絡上被稱為大數據技術棧的長子；確實，在大數據環境下，Spark的地位是舉足輕重的，Spark是通用的數據處理引擎；適用於多種離線、在線場
景大型數據集的交互式查詢Spark於2009年開始在加利福尼亞大學伯克利分校的AMPLab項目中生活。更具體地說，它是由於需要證明Meso的概念而誕生的，這也是在AMPLab中創建的；2014年被加州大學開源捐贈給Apache基金會，隨后其火熱程度就如它的名字一樣以星星之火迅速燎原不到一年就成為Apache的頂級項目Spark技術棧包括可用於可以實現高吞吐量的，具備容錯機制的實時流數據處理的SparkStreaming、處理結構化數據的SparkSql、機器學習實現庫SparkMLib等。Spark結構圖如圖2.2所示。
2.5.1 Scala
Scala是以利於Jvm的一種面向對象加面向函數（可以進行函數式編程）的語言，是編寫Spark框架的的語言。Scala的優點是面向對象，支持函數式編程，能帶來更高層的並發模型。
2.5.2 SparkSQL
SparkSQL專注於處理結構化數據，可以作為Sql在數據庫中獲取數據。還有兩個用於交互式計算的DataFrame和DataSet。
2.5.3 SparkMLlib
基於協同過濾的推薦需要借助機器學習來完成，用Spark的機器學習實現庫組件SparkMLib可以幫助我們更好的結合機器學習內容完成協同過濾算法的實現。
2.5.4 SparkStreaming
SparkStreaming是流式計算框架；它被用於大數據的流式處理實時計算。推薦系統的實時需求的實現就要用到SparkString處理消息隊列Kafka中的數據，進行數據的快速處理和計算。
2.6商品推薦主要用到的算法
基於大數據環境下的電商推薦系統核心算法就是推薦功能，也是本課題項目的關鍵所在，本項目包含統計分析推薦、機器學習智能推薦，離線推薦和實時推薦，下面將對相關算法做簡要說明。
2.6.1 離線統計推薦算法
離線統計推薦是非個性化推薦，也就是說，對於任何不同的用戶，這部分推薦的內容應該是一樣的；所以離線統計推薦就是每隔一段時間，把信息指標通過自己的任務運行計算，將推薦列表計算出推薦給每個人。
2.6.2 協同過濾算法
協同過濾算法是比較著名的商推薦算法，國內外研究者頗為喜愛，它誕生較早，通過對使用者歷史動作的數據挖掘進而分析用戶的偏好，基於不同的偏好對適用人群進行區分。可以從多個角度進行協同過濾推薦：基於用戶、基於商品、基於隱語義模型。
2.6.3 協同過濾LFM隱語義模型
LFM（later factor model）是一種基於模型的矩陣分解的召回算法，輸入UI點展矩陣，輸出是P和Q兩個矩陣。本項目中是將評分矩陣拆解為用戶特征矩陣和商品評分矩陣。
建模公式如式2.3所示：
2.6.4 實時推薦算法
實時推薦滿足的是更快地更新要求，准確性的標准可以略微降低。但是實時算法不能太過復雜，每次讀取的數據也不能大量。因為在實時算法面前短的時延才是標准。
2.7 推薦系統的常見召回路徑
推薦系統面對的主要問題就是如何從海量數據中挑選出用戶的興趣愛好且還要滿足低時延性能要求（例如NetFlix的指標是250ms返回，今日頭條指標是200ms返回結果）。當今推薦系統往往存在三個步驟：召回，排序，調整[4]。
召回環節實現兩個功能：一是巨量的數據降低，從億級別到萬級別；二是選取與用戶相關的感興趣的條目。方式一般有：協同過濾、內容相似等。
排序環節一般利用機器學習算法：邏輯回歸或者二分類算法等得到的結果降序排序就會得出用戶的喜好列表，此時的數據量降為千或百。完成了精細的個性化功能。
調整環節對排序后的加過進行優化，去除推薦重復，將購買過的商品進行去除等，熱門補足等。
推薦中的常見的召回路徑有以下幾類：
I2I、U2I、U2I2I、U2U2I、U2tag2I，I代表物品Item，2諧音為to，相當於圖中的邊，U代表用戶，如圖2.4所示。
1.I2I：從一個物品到達另外一個物品，例如今日頭條會在一篇文章的最后列出預制相似的另一篇文章。可基於內容相似。協同過濾、關聯規則挖掘等實現。
2.U2I：來源於用戶的直接行為，例如播放，購買，收藏等。
3.U2I2I：可以看做U2I+I2I的方法結合。根據用戶的喜好找到喜愛的商品，在找到與這個商品相似的另一個物品。這個新找到的物品推薦給用戶。
4.U2U2I：看做U2U+U2I的方法結合，U2U可以通過行為找到，也可以根據標簽找到。把第二個用戶的喜愛物品推薦給第一個用戶。中間的橋梁通過U2U實現。
5.U2tag2I：這個是把U2I2I更泛化的一種召回路徑，tag表示的就是用戶喜好的商品的標簽，通過標簽的相似度查找標簽相似的物品，將結果推薦給用戶。
2.8 本次推薦系統部署環境
在大數據環境中，Linux是具有先天優勢的；開源，擁有眾多的發行版，是廣大程序員的首選；但是隨着大數據技術棧的發展，時至今日，Apache各大主流框架組件已經支持Windows環境；例如Kafka，Zookeeper等；以kafka為例，可以發現，后續大數據組件版本的根目錄結構中多出了/Windows，其文件目錄中的執行腳本也從.sh換成了在Win環境中的執行腳本.bat文件。所以，本次項大
數據環境決定嘗試部署在Windows環境下，同時這也是現階段對該類的現階段研究的一個變化。
第三章 系統分析與整體結構
本畢業設計實現的推薦系統要明確電商中推薦算法的運用以及推薦系統的完整開發與上線部署，對用戶的需求進行分析，需求合理可執行，方可對系統進行開發。
3.1可行性分析
電商推薦系統的可行性分析是衡量系統能否順利實現指標，有以下幾點：技術可行性、時間可行性、經濟可行性。
3.1.1技術可行性
該系統在當前環境下技術可實現，推薦系統采用B/S架構，B/S架構又稱瀏覽器/服務器架構，他的優點是容易維護，只需要瀏覽器就可以發起請求操作。不需要繁雜的安裝系統等，適合本次推薦系統的開發選型。前后端分離技術，部署上線並不困難，即使未來有需求改為C/S結構，那也只需要構建C端的界面代碼及配置項，無需較大改動。將推薦系統開發完畢可以利用Tomcat將打包的war文件部署到服務器實現網絡訪問。
3.1.2經濟可行性
該系統采用的框架皆為開源框架，全部免費。在項目框架上選用約為“0”成本，項目上線的運維成本也比較低，通過Zookeeper搭建管理集群，構建分布式或者偽分布式結構，推薦系系統主節點宕機服務異常停止的情況下節點可以由follower繼續接替工作，留出足夠的時間給開發者排查，解決問題，在此期間不會影響系統的正常工作。所以運維成本也可以降低。
3.1.3時間可行性
畢業設計推薦系統系統從查閱資料到選型、構建、開發、完成，由於基本需求比較明確，使用框架開源，社區維護者很多，碰到的開發問題可以較快時間解決，老師指導耐心全面，參考資料豐富，可以在規定時間內完成開發並加以測試、修改及完善。
3.2系統用戶需求分析
接下來介紹本系統的各部分需求。
（1）注冊功能：登錄注冊功能的實現；新用戶在首頁都需要注冊用戶方可成為新用戶，新用戶首次登錄需要注冊用戶名，注冊后方可登錄系統。在注冊時還要判斷該用戶名有無被搶先注冊，如果被提前注冊，那么要提示用戶這個用戶名已經被注冊；使用其他用戶名重新注冊。
（2）忘記密碼：對於已注冊過的用戶再次登錄時，如果忘記自己的登錄密碼，可以根據自己的密保方式找回自己的密碼。
（3）用戶登錄：注冊過的用戶將正確的用戶名和密碼輸入后可以順利登錄系統。看到自己的推薦頁面。
（4）用戶退出：在用戶瀏覽尚品后要可以做到安全退出，防止其他非法人員盜用信息。
（5）推薦頁面的展示：系統要把每個用戶的推薦列表在頁面上進行展示
通過程序運算將推薦列表進行可視化展示。
（6）埋點數據采集：系統前端要能捕捉到用戶打分的行為傳到后端，后端要將埋點日志進行捕捉並本地保存。
（7）埋點日志的監聽：系統要能時刻動態監聽到日志文件的變化，用以第一時間捕捉日志文件。
（8）埋點日志的處理：系統后端將前端穿過來的日志進行格式處理，識別日志文件中的用信息。並將其中有用的數據截取出來，傳到相應的推薦模塊計算推薦結果或者推薦列表。
（9）統計推薦：推薦系統要能准確推薦出后台統計出的物品評分歷史，准確找到評分最多的物品列表。
（10）基於物品標簽的推薦：推薦系統要能根據物品的標簽內容，推薦出標簽相似度最高的其它物品。
（11）實時推薦：推薦系統要將用戶的實時打分數據進行處理，系統要快速處理給出響應並更新推薦列表，實時的反饋給用戶。
（12）基於模型的協同過濾推薦：系統要實現基於模型的協同過濾，實現個性化推薦。
（13）商品模糊查詢：對商城內的已有商品進行模糊查詢，快速找到相關商品。
整個推薦系統的用例圖如圖3.1所示。
3.3系統性能需求分析
（1）數據存儲部分：業務數據庫要滿足頻繁的增刪查改的需求，而且數據多為非結構化數據，緩存數據庫需要滿足高效，實時計算的要求。
（2）響應速度：API請求的普遍時間是小於1s；打開或跳轉Web頁面時間加載所有數據，JS圖片等相關完整內容共不能超過8s。
（3）並發量：系統要同時支持多用戶同時在線，滿足並發處理多用戶的推薦需求。
3.4系統的整體結構
綜合以上系統結構用戶需求以及性能需求，畢業設計推薦系統整體結構設計如圖3.2所示，離線推薦模塊包括四個詳細的離線推薦：分別為離線統計推薦服務、基於隱語義模型的協同過濾、基於物品的協同過濾、基於物品標簽的相似度推薦；實時推薦模塊的結構在圖的右側由Flume、Kafka、SparkStreaming相接組成。
這些模塊的推薦結果與業務數據庫MongoDB相連接；前端可視化通過Spring后台的處理從MongoDB拿到結果后展示給用戶。用戶的操作通過前端再傳到后台，通過日志采集服務進行監控日志文件，傳輸到Kafka消息隊列進行日志數據處理，再通過SparkStreaming實時推薦服務結合業務數據庫的結果把數據傳輸到Redis緩存數據庫，供實時推薦列表的快速刷新。
推薦系統Spring后台流程控制MVC結構如圖3.3所示，前端點擊綁定的函數觸發rest請求對服務器發起訪問，請求包括注冊、登錄、評分等等。任何一個請求都有唯一的標識，Controller接到數據會轉換成Model實體類，與數據庫進行交互，計算的結果仍會返回到Controller，最后向View層發送結果數據，進行數據的解析與前端顯示。
3.5系統的數據源
推薦系統的基礎數據源於學者在GitHub上開源數據集亞馬遜商品集[5]。共分為兩個部分：物品信息和用戶評分信息。
結構如表3.4所示：
表3.4 物品信息表結構
| 物品ID |
物品名稱 |
物品種類向量 |
物品圖片URL |
物品標簽 |
| 160597 |
白鹿原 |
832,519,1 |
https://images-cn- |
小說|文學藝術|圖書音像 |
| 66003 |
諾基亞N1280 |
1128,640,304 |
https://imag s-cn- |
手機|手機通訊|手機 |
| … |
… |
… |
… |
… |
商品信息共487條。
評分信息結構如表3.5所示：
表3.5 評分信息表結構
| 物品ID |
用戶ID |
分數 |
時間戳 |
| 160597 |
452794 |
4.0 |
1264089600 |
| 66003 |
452754 |
1.0 |
1351267200 |
| 160597 |
452796 |
5.0 |
1381766400 |
表中被一行為兩兩對應的評分，每個物品由對應用戶在某一時間點打出的分數。例如：表格中第一行意思是452794用戶為id為160597的商品在1264089600的時刻打上了4.0的評分。這兩個表的數據是構建系統時的初始數據；整個系統運行的數據遠不止這些，在后文數據庫設計會詳細說明。
第四章 系統方案的具體設計
4.1系統功能設計原則
4.1.1微服務
系統采用微服務架構，利用Maven自動控制jar包依賴，各部分相互獨立，松耦合。每個推薦模塊相互獨立，就模塊而言互不干涉。
4.1.2系統的可靠性
微服務設計理念有強調，系統中加用日志和監控能使系統變得更加健壯。還有要考慮到消息在傳輸過程的准確性，避免網絡擁塞，消息緩存隊列是必要的也是必須的。系統的各組件，都已經比較成熟，開源社區為系統的可靠持續運行提供強大的后盾支持。
4.1.3系統的維護性
本系統目前部署在單節點偽分布式下，遇到問題可以根據日志快速定位並回滾。當前只存在單機部署，維護方便快捷。
4.2系統總體架構設計
4.2.1 前端模塊的設計
前端展示運用AngularJS編寫，完成對數據可視化視圖的構建，利用webpack打包並將前端項目一同放入后端項目文件，將請求與操作進行綁定，定義路由，請求方法等，規定渲染流程。
前端模塊具體包括：
1.home：推薦系統首頁，將推薦線結果進行展示。
2.login：登錄模塊的頁面，進行用戶登錄的表單構建。
3.register：用戶注冊頁面，完成注冊模塊的構建。
4.tags：定義tags標簽，這個標簽要js實現商品的標簽
5.star：定義打分，需要實現鼠標滑動打分的效果以及綁定打分的數據與操做
6.mdetail:商品詳細信息頁，定義商品的可視化結構，要包括標簽、評分、詳細信息等信息。
4.2.2 后端業務模塊的設計
主要采用Java寫明Pojo實體類，controller控制層，service業務層；接收前端傳來的數據，根據對應的請求進行restful操作匹配作出對應的處理。
后端的請求處理主要包括：
1./rest/user/login：用戶登錄請求
2./rest/user/register：用戶注冊請求
3./rest/user/forget：用戶忘記密碼請求
4./rest/product/most：獲取基於模型的推薦列表
5./rest/product/reating：獲取商品的評分
6./rest/itemcf/{pid}：獲取根據物品協同過濾的推薦列表
7./rest/content/{pid}：獲取基於標簽的推薦列表
8./rest/detials：商品詳情頁請求
9./rest/search：商品模糊查詢請求
4.2.3 后端推薦模塊的設計
主要采用Scala開發編寫Spark程序，根據推薦方式方法的不同，分成多個對應模塊，離線推薦、實時推薦；離線推薦包括基於統計的離線推薦，基於隱語義模型的協同過濾離線推薦、各個模塊相互獨立，松耦合。
推薦模塊具體包括：
1.統計推薦模塊
2.基於隱語義模型的協同過濾推薦模塊
3.基於物品的協同過濾推薦模塊
4.基於物品標簽的推薦模塊
5.實時推薦模塊
6.近期熱門推薦
4.3數據庫設計
4.3.1業務數據庫：MongoDB
主業務數據存放在非關系型數據庫MongoDB。
具體數據表如4.1—4.10所示：
1.Rating表結構如表4.1所示
表4.1 Rating表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| pid |
Int |
物品id |
| score timestamp |
Double Int |
評分 打分時間 |
2.Product表結構如表4.2所示
表4.2 Product表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| pname |
String |
物品名稱 |
| imageUri categoraies tags |
String String String |
圖片保存鏈接 分類 商品標簽 |
3.User表結構如表4.3所示
表4.3 User表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| username |
String |
用戶名 |
| password |
String |
登錄密碼 |
| |
String |
密保郵箱 |
| timestamp |
Int |
注冊時間 |
4.AvgRating表結構如表4.4所示
表4.4 AvgRating表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| avgrateing |
Double |
物品平均得分 |
5.BaseOnContentProArr表結構如表4.5所示
表4.5 BaseOnContentProArr表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| list |
Seq[Recommendation] |
基於內容的推薦列表 |
6.ItemCFProArr表結構如表4.6所示
表4.6 ItemCFProArr表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| list |
Seq[Object] |
基於物品協同過濾的推薦列表 |
7.ProductList表結構如表4.7所示
表4.7 ProductList表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| list |
Seq[Seq[Object]] |
商品的推薦列表 |
8.RateXProduct表結構如表4.8所示
表4.8 RateXProduct表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| num |
Int |
商品被評價總數 |
9.UserList表結構如表4.9所示
表4.9 UserList表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| list |
Seq[Object] |
用戶推薦列表 |
10.StreamRecs表結構如表4.10所示
表4.10 StreamRecs表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| list |
Seq[Object] |
實時推薦列表 |
4.3.2緩存數據庫：Redis
緩存數據庫的存在為實時推薦獲取商品列表提供了快速支持，Redis中保存了已經注冊的用戶推薦列表；格式如下：
2) "userId:1985105"
…
8) "userId:4867"
4.3.3系統數據流向
數據流向圖如圖4.11所示：
4.4離線統計模塊設計
商品離線推薦的設計是要綜合電商用戶的所有打分歷史數據，通過運行離線推薦算法，運行過后結果是固定不變的，每運行一次便會更新一次結果；結果的變化只取決於捕捉到所有使用者的評分以及將這些評分重新計算的執行時間。
離線推薦用數據庫商品的直接屬性進行計算，例如商品標簽，商品名稱，商品評分等，計算結果作為前端可視化數據的支撐。
如果按照分類划分，僅使用SQL進行的統計推薦和利用機器算法的協同過濾推薦都屬於離線推薦。
4.4.1統計推薦之歷史熱門
根據數據庫中已經存在的所有商品評分信息，使用sql統計出被評分最多的商品。這個統計僅僅是做出熱度比較高的商品，不對評分的高低做判斷。實現sql語句如4.12所示：
統計歷史熱門商品僅需要根據商品ID聚合匯總再降序排列即可，將SQL代碼注入到SparkSession.sql()函數中實現。
4.4.2統計推薦之近期熱門
在上一步的基礎上，增加時間條件進行評分篩選。實現sql語句如4.13所示：
4.4.3統計推薦之均值推薦
在數據庫中找到每個商品獲得的所有評分，求平均值，根據平均值構建推薦信息。實現sql語句如4.14所示：
統計商品的平均分僅需要根據商品ID聚合，使用系統函數（圖中的AVG函數）計算商品ID對應的平均法再降序排序，將SQL代碼注入到SparkSession.sql()函數中實現
4.5離線個性化推薦模塊設計
4.5.1基於模型的協同過濾算法設計
前邊有說到，離線統計是把所用有用戶的評分結果進行計算法處理，每個人都會看到看到相同的推薦列表。然而，個性化離線推薦就要體現出用戶和用戶之間的不同。每個人的看到的離線列表都是根據自己的評分喜好計算而出，不同用戶的喜好不同，對商品的評分不同，那么他所看到的列表熱度結果也就不同。協同過濾不可以直接用商品直接屬性，需要利用統計離線推薦結果生成矩陣。我們要用ALS訓練LFM（隱語義模型[9][7]）。
ALS算法交替最小二乘法的原理為矩陣分解技術，矩陣分解就是把一個矩陣分解成兩個或者多個矩陣的乘積，意義層面的解釋就是通過隱含特征（latent factor）將用戶的興趣與item聯系起來。主要思想如圖4.15所示。
目標函數公式如式4.16所示：
優化目標函數公式如式4.17所示：
在原始的評分矩陣中，不可能保證每個用戶對每個物品都有過評價評分。用戶和物品之間還是沒有聯系的，得到的矩陣是稀疏的缺少特征的。矩陣分解的優點可以將高維的矩陣映射成兩個低維矩陣的乘積，能解決數據的稀疏問題，自定義隱特征數量，預測的精度高，高於基於統計的協同過濾和基於內容的推薦。矩陣分解也有一定的缺點，第一個缺點。在隱語義模型中，你無法解釋這些個隱因子的具體含義；就不能將隱空間的維度與現實中的概念一一對應。第二個缺點就是模型訓練比較費時，模型的訓練需要迭代式進行，數據量大的術后天粒度的話只能是按天粒度進行訓練。
使用ALS算法可進行顯式模型訓練與隱式模型訓練，進行訓練模型時需要傳入四個參數。若進行顯式訓練，則使用ALS.train(ratings, rank, iterations=5, lambda_=0.01)；如果要進行隱式訓練，則參數為ALS.trainImplict(ratings, rank, iterations=5, lambda_=0.01)。上式中，參數ratings指訓練模型數據源，rank指的是當進行矩陣分解時，將原矩陣分解成X(m*rank)矩陣和Y(rank*n)矩陣，Iterations指ALS算法的迭代次數，lambda為正則化項系數，默認為0.01。
4.5.2模型評估和參數選取
ALS訓練隱語義模型的過程中公式中的三個參數僅僅憑借經驗或者查閱資料固定填寫。雖然可能出較好的結果，但是這樣的參數集並不一定是針對我們研究的問題的最優解。所以有必要采取模型優化的步驟對模型進行優化。可以計算方根誤差來評判模型的優劣。公式如式4.18所示：
通過RMSE計算[8]，可以反復調整參數的取值范圍，最后保留值最小的一組參數作為模型的參數最優解。
程序代碼實現如圖4.19所示：
圖4.19 RMSE優化參數代碼
4.5.3生成商品推薦列表
只有計算出來模型才能通過模型構建商品列表進行推薦。構建推薦列表的主要思路步驟如下：
1.得到用戶和商品的二元組（用戶ID，商品ID），完成這個操作只需將用戶表中的Id和商品表的Id做笛卡爾積。
2.用ALS訓練出來的模型給二元組預計算評分。
3.將最終的記過排序后保存到數據庫。
最終結果形式如圖4.20所示：
矩陣R表示用戶對物品的興趣度，矩陣P表示用戶對物品的偏好度，Q表示物品屬於哪個類別的概率如圖4.21所示。隱語義模型及時通過將矩陣R分解成P和Q的乘積，通過P矩陣物品類別將用戶User與物品Item聯系起來。
4.5.4基於物品的協同過濾以及物品間的相似度
協同過濾推薦針對的對象不同可以分成兩種：基於用戶的協同過濾和基於物品的協同過濾；由於此時用戶群體非常少，基於用戶的協同過濾[7][8]不夠明顯，所以暫且不討論基於用戶的協同過濾，下里面來講述基於物品的協同過濾[9][10][11]。
基於物品的協同過濾[12][13]判斷兩個商品相關性的大小，一般用余弦相似度作為依據。不需要對物品進行標簽采集分詞，只需要收集用戶的行為（例如點擊、收藏、購買、評價等）便可以進行基於物品的協同過濾推薦。可以通過前邊的余弦相似度進行評判，也可以用同現相似度[14]來反應物品間的相似程度。計算公式如式4.22所示：
4.5.5基於物品標簽的推薦
基於物品標簽的推薦[15][16]需要利用物品的初始標簽，對標簽進行分類從而進行同類推薦，這個部分會把商品中屬於同一類的物品進行篩選展示。實現思路為在Spark單例中實例化分詞器，定義HashTF工具把文字信息處理成向量信息，運用TF_IDF進行特征矩陣的獲取。
4.6實時推薦算法設計
在電商推薦系統中，實時的更新推薦列表能給用戶帶來更好的體驗，假如物品推薦的列表只有到了系統設定的時間（例如凌晨）實時推薦[17]與離線推薦應最大的不同之處在於實時計算推薦推薦列表應該動態更新，能計算出用戶近期的喜好並推薦商品，需要實時技術的支持而不是在后台周期性的運行算法模塊。
4.6.1實時推薦算法
推薦系統的使用群體對商品的喜愛與否是會隨時間逐漸變化的。我們假設小明喜歡喝牛奶，比如小明在某個時間點對“A牌牛奶”做出了很高的行為舉動（例如購買、收藏、分享、好評、長時間瀏覽等），那么我們就可以猜測，小明有可能很喜歡其他品牌的“牛奶”、“奶制品”等；而如果小紅在某天給“L牌辣條”做了負面行為（例如寫差評、從購物車刪除，取消收藏、退貨等），那么我們就可以推斷：“L牌辣條”不是小紅這段時間心儀的商品，更甚至與“辣條”相似的同類物品如“辣片”、“麻辣”等都不會被小紅納入采購的行列。所以針對於實時推薦，每當用戶對某個產品進行了評分，后台要根據這次的行為動作捕捉具體的的喜好或者忌口，從而更新推薦列表，使結果能喜好最大程度匹配。
4.6.2實時推薦算法設計
實時推薦[18]推薦優先級的基本思路：用戶短時間內的喜好保持一致相似。
初步計算備選商品的推薦優先級公式4.23的如下：
公式的意義如下：基礎評分項*評分（權重系數）從而調整推薦力度+，除以sim_sum做平均，結果就是推薦優先級得基礎分數；后邊的偏移量一個是鼓勵項，一個是懲罰項；鼓勵項：最近的評分都是高分，看了買了還給了高分，說明最近的行為很能代表自己的喜好；如果最近將某個商品拉黑刪除等，說明用戶不喜歡這個商品。這個商品的類別就不能代表用戶的喜好。
第五章 環境部署和系統實現
5.1環境部署
以下環境作為本次畢業設計系統部署的開發環境參考：
5.1.1基礎環境
操作系統如圖5.1所示：
5.1.2 MongoDB環境安裝與配置
1.安裝MongoDB：到MongoDB官網下載社區免費版MongoDB msi安裝程序，
將下載到本地的msi安裝程序運行，按照個人需求安裝在目錄,以下簡稱為：%MONGODB_PATH%。
2.創建數據與日志文件夾：在%MONGODB_PATH%中找到data文件夾在內部創建db和logs文件夾以存放數據和日志信息。
3.配置環境變量：在系統環境變量中加入%MONGODB_PATH%
4.啟動mongodb服務：輸入指令mongod --dbpath %MONGODB_PATH%\data\db;
5.檢查服務：瀏覽器輸入http://localhost:27017如果提示連接成功，那就表示MongoDB環境已經配置完成。
5.1.3 Redis環境安裝與配置
1.安裝Redis：到Redis官方github倉庫下載現階段穩定版本的msi。將下載的msi文件安裝運行，按照個人習慣安裝在指定目錄，以下簡稱%REDIS_PATH%。
2.將%REDIS_PATH%添加到系統的環境變量中。
3.啟動Redsi臨時服務：輸入指令redis-server.exe redis.windows.conf
4.創建Redis連接：輸入指令redis-cli。進入redis說明redis環境已經配置完成
5.1.4 Zookeeper環境安裝配置
1.解壓Zookeeper壓縮包：到官網下載Zookeeper安裝包，根據個人習慣解壓文件到指定路徑，以下簡稱%ZK_PATH%，將%ZK_PATH%添加到系統環境變量中
2.復制%ZK_PATH%\conf\zoo_sample.cfg文件，重命名為zoo.cfg；修改文件內容，將dataDir和dataLogData的路徑修改為自定義路徑。
3.運行zkServer.cmd可執行腳本，運行zkCli.cmd腳本。提示連接到2181端口和出現“Welcome to Zookeeper！”字樣便證明環境配置成功。
5.1.6 Kafka安裝與配置
1.官網下載Kafka安裝包，並根據自己的習慣解壓到自定義路徑，以下簡稱%KAFKA_PATH%，將%KAFKA_PATH%加入到系統環境變量中。
2.進入%KAFKA_PATH%\conf目錄編輯文件server.properties，將log.dir修改為自定義路徑，建議為%KAFKA_PATH%\kafka-logs；編輯zookeeper.connect=localhost:2181
3.創建topic測試kafka安裝成功：在%KAFKA_PATH%下運行指令
.\bin\windows\kafka-topics.bat --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic tast；
4.運行指令查看主題
.\bin\windows\kafka-topics.bat --list --zookeeper localhost:2181；
如果顯示列表中存在一個tast主題說明kafka環境配置成功。
5.1.7 Flume安裝與配置
Flume安裝包下載：到Apache官網下載Flume安裝包，根據自己的習慣解壓到指定路徑%FLUME_PATH%，將%FLUME_PATH%添加到系統環境變量中。
5.1.8 Scala環境配置
Scala安裝包下載：官網下載Scala安裝包;根據自己習慣將安裝包安裝在指定路徑，以下簡稱%SCALA_PATH%，注意此路徑中不能包含空格。將%SCALA_PATH%添加到系統變量中。安裝完畢在cmd命令行輸入scala顯示版本信息即為正確配置環境。
5.1.9 Jdk環境配置
官網選擇合適的JDK版本，建議選擇穩定且普及率高德JDK8；根據個人習慣將壓縮包解壓至指定路徑，以下簡稱%JAVA_HOME%；將%JAVA_HOME%添加到系統環境變量中。輸入命令java -version有版本信息輸出說明環境配置成功。
5.1.10 Maven環境配置
Maven官網下載安裝包，根據個人習慣，將安裝包安裝到指定目錄，以下簡稱%MVN_HOME%，將%MVN_HOME%添加到系統環境變量。cmd輸入指令 mvn -v查看Maven版本號，有版本號正確輸出便說明環境正確安裝成功。
5.1.11Spark環境安裝配置
下載Spark安裝包，根據個人習慣將安裝包解壓安裝在指定目錄，以下簡稱為%SPARK_HOME%，將%SPARK_HOME%添加在系統的環境變量在cmd中輸入spark-shell,顯示有正確版本號輸出，那就說明環境正確安裝。（Spark環境是依賴於JDK8以上版本+Scala環境，安裝配置Spark環境時確保JDK與Scala環境已經正確安裝）hadoop報錯提示在單機環境下運行時可以忽略。也可以自行安裝Hadoop環境搭建高可用集群。
5.2成果實現展示
前端模塊構建的主要是識別用戶的身份信息，將推薦列表做數據可視化展示，包含用戶注冊、用戶登錄、瀏覽商品頁面、商品模糊查詢、用戶打分、以滿足基本的要求。
5.2.1登錄展示效果
登錄界面如圖5.2所示
5.2.2用戶注冊頁面展示
用戶注冊界面如圖5.3所示，若注冊時改用戶名被搶先注冊，那么系統會提示注冊失敗，請更換用戶名注冊。
5.2.3離線統計推薦實現
離線統計推薦在系統中的具體實現是熱門推薦模塊和評分最多推薦模塊如圖5.4所示,熱門推薦列表是基於商品的評分高低，求所有用戶對物品的平均分得出來的推薦列表，具體實現過程為把評分數據定義成一個新的樣例類（僅關注評分表中的分數，與物品id）通過Spark以DataFrame的形式進行讀取，使用Spark.SQL統計出在歷史時間內的評價均分最高的物品，將統計后的數據保存在MongoDB中的RateXProduct表中，保存的序列就是商品平均分由高到低的序列，這也就是前端頁面展示出的熱門推薦列表的內容。評分最多推薦模塊的實現是基於評分的次數，而不是評分的高低，步驟與前邊類似，將評分數據以Spark的DataFrame形式讀取，使用SparkSQL統計商品的評分次數，降序排序，得到的列表即為評分最多的列表。需要注意的是：評分最多代表的是用戶給他的評分此時多。並不能說明用戶給他的評分數值高。這點需要讀者認真區別。
5.2.4離線協同過濾基於模型的個性化推薦實現
基於模型的協同過濾需要用到用戶的歷史數據進行計算，用戶打分的行為數據，定義新的樣例類，將數據加載到定義的RDD中，提取所有用戶的商品打分數據，將數據轉換成mllib規定的規范格式進行隱語義模型的訓練，規范中要具體三個參數：隱特征個數、迭代次數、正則化系數。RDD調用cartesian函數得到笛卡爾積；此時就擁有了一個稀疏的評分預測矩陣；接下來對矩陣進行分解，將稀疏額矩陣變為稠密矩陣。將數據集切分，運用Mllib中ALS.train訓練模型，getRMSE得到最優模型參數。得到了模型就可以將矩陣最優分解，再做笛卡爾積；就能得到商品兩兩的相似度；此時還要過濾掉自乘的結果，因為自乘的結果相似度為1。計算出物品的相似度矩陣。挑選出相似度最高的物品。組成基於模型的協同過濾推薦列表如圖5.5所示。
5.2.5基於物品的協同過濾推薦實現
基於物品的協同過濾用到了第二章介紹的U2I2I召回路徑：分為兩步：U2I和I2I；U2I根據用戶找到喜愛的物品；I2I根據物品找到相似物品；I2I這個步驟通過同現相似度完成，使用商品之間的同現相似度計算出推薦商品，具體實現步驟為：加載數據到spark，按照pid做group by對評分進行統計，新加一列sum存放評分個數。此時數據應為pid|num；再將評分按照uid兩兩匹配，統計商品被同一個用戶打過分數的次數，此時的結果中油兩個pid；將這兩個pid做group by；統計出uid的個數；那么就算出了對兩個商品同時評分的個數。將這個序列倒序輸出，就得到了基於物品U2I2I的協同過推薦列表如圖5.6所示。
5.2.6實時推薦實現以及打分操作的流程
當我們對一個商品進行打分操作時，評分的數據會在控制台看到，並且以埋點日志的方式存到本地文件；Flume檢測到本地文件變化，就會將日志預處理傳送給Kafka消息隊列，KafKa消息隊列將數據傳到SparkStreaming；通過計算運行將處理后的結果保存到Redis中。操作過程步驟如圖5.7-5.10所示。
以上就是一個完整的物品打分數據流；此時實時推薦結果已經更新。圖5.11與5.12展示了用戶對商品進行評分后實時推薦的變化。
5.2.7基於物品標簽的推薦
打開《這就是你給我的愛》物品詳情頁；可以找到下面對於這本書的標簽：書、少兒圖書、教育類、勵志、雞湯、好看、內容不錯。基於物品標簽的推薦的實現是通過Mlib中的Tokenizer將物品的標簽通過“|”分詞，實例化一個HashingTF工具增加一列向量表示這個物品的標簽，訓練idf統計向量出現的頻次，把這些特征轉換成和和模型協同過濾推薦一樣的RDD，兩兩配對商品計算余弦相似度，過濾掉自己本身，得出的變標簽相似列表。
我們繼續查看它基於標簽的的推薦列表，打開第一本書：《30年后你拿什么養活自己》如圖5.13所示，查看標簽如圖5.14所示，發現相似度很高，標簽有 書、勵志、雞湯、好看 這四個是和《這就是你給我的愛》重合如圖5.15,5.16所示。所以可以得出結論。按照物品標簽推薦也是非常准確的。
5.2.8 商品的模糊搜索
在商品首頁的導航欄中，還新增了商品信息模糊搜索查詢，輸入查詢的物品名字，即可模糊搜索到數據庫中含有該名稱的物品；並直接跳轉到詳細頁面展示，如下圖如圖5.17所示。
搜索“白”，可以找到伊麗莎白化妝品，清除白噪聲耳機；白岩松的書。這部分的具體實現直接是在Spring的控制層寫了sql語句，由於不涉及到對數據評分的變化，所以沒有歸納到推薦模塊中，直接從Spring返回模糊查詢結果。
第六章 總結
6.1畢業設計總結
在完成這次畢業設計的過程中，經歷了研究開題、文獻查找閱讀、撰寫開題報告、中期檢查、文獻綜述的編寫等眾多步驟。經歷了很多，也學到了很多。通過查閱大量的相關資料文獻，總結前人的論文研究加上自己的思考與創新，最終完成了基於大數據平台的商品推薦系統設計與實現。在整個完成期間也碰到許多難題。老師和同學們都耐心的指導我幫我解決問題。自己的理解差錯也能被及時糾正。下面簡述我在本次畢業設計過程中的亮點與遇到的一些問題。
6.2推薦系統的亮點
6.2.1使用高效率的Spring框架
系統使用Spring構建整體框架使開發成本變低，后續可以轉為SpringBoot更輕量級的架構，能降低項目的成本投入以及維護成本，並提高系統運行效率。
6.2.2推薦的多樣性
系統中共多個推薦模塊：實時推薦滿足了系統推薦的實時性、統計推薦了反映了商品庫中信息的總覽，將所有用戶的地對商品的評價進行總覽、基於商品協同過濾實現了個性化推薦，讓每個用戶都要自己獨特的推薦列表、基於每個模塊都采用不同的推薦算法進行實現，使我們能從更多角度查看推薦的結果。
6.2.3 基於大數據環境下的系統環境的配置
當下大數據環境大部分都是部署在虛擬機或者雲服務器的Linux發行版的操作系統上。在Windows上配置環境的先例少之又少，原因有二：一是Apache基金會下的大部分組件先天就不支持Windows操作系統；二是在Linux上更加利於項目的配置與運行和發布。但是本次畢業設計主要為了研究推薦算法的實現以及相關業務，用戶基數少，再加上想隨着版本的迭代，大數據組件已經支持在Windows操作環境系統中安裝配置。雖然相比較而言在Windows上配置環境比Linux更加繁瑣，但是對於國內更習慣Windows的用戶來說這是一種新的探索，方便他人借鑒和參考。
6.3推薦系統實現中遇到的問題及解決方法總結
6.3.1命名規范
在本次系統代碼編寫過程中，有些類屬性代碼不規范，導致后續排查錯誤耗費時間較久，所以在編寫任何代碼時都要嚴格按照規范進行開發，避免后續維護或者二次開發碰到因代不規范而導致的問題，這類問題一般較難發現，並非邏輯錯誤，排查非常耗時。我們應養成規范編碼的好習慣！
6.3.2 Windows與Linux命令不兼容問題
本次系統創新的部署在Windows環境下，雖然大部分組件都支持在Windows環境下運行，但是windows和Linux存在本質區別；命令的啟動方式以及參數的位置都需要注意，尤其是Flume-ng啟動時，不僅要調整參數位置，更重要的是啟動命令中包含“-tail”指令，這個指令是在Linux的內置shell指令，在Windows中並不能被識別，這是就要在Windows本地函數文件中添加一個可執行文件，使操作系統可以識別到這個命令並且正常運行。
6.3.3 Kafka 異常退出
在Windows下啟動kafka產生的offset文件在關閉kafka后並不會自動刪除，如果想重啟kafka，系統不會把上次的本地文件自動刪除。需要手動刪除，否則會啟動異常。
6.4推薦系統的不足之處
在本次畢業設計中，也有許多不足的地方。例如樣本的數據不夠特別全，並不是一個完整的成熟的電商商品數據庫，等待筆者自己提升技術能力后加以完善等。
6.4.1更准確的推薦算法
迄今為止沒有任何一個推薦算法能滿足用戶全體的興趣愛好，也就是說推薦系統存在就必然會存在的問題：提升推薦准確度。推薦算法不可能做到符合每個人的興趣，這正如一句話所說：“一千個人眼中就會有一千個哈姆雷特”[20]。每個人都有各自的看法和觀點。做到完全符合每位用戶的喜好，這是推薦系統發展的最終極目標。是推動推薦系統發展的動力源頭。
6.4.2更高效的實時計算框架
Flink框架摒棄了批處理的思想，可以達到比spark更高的實時要求。由於我現在能力有限，畢業設計采取現學習資源比較成熟的spark。
6.4.3 單機模式下的風險
我們知道在當數據量級變大時，必要的數據冗余是保證節點在遇到宕機等突發情況下恢復正常的保證。只存在一個單一節點在部署上線后，再服務器掛掉后容易發生數據的丟失。所以正式部署上線后，數據的復制是很有必要的需要將數據定時同步到其他多個節點。確保在某個機器宕機后數據不丟失。
6.4.4用戶畫像（Profile）
當下的主流電商系統都在構建用戶畫像，通過數據建立描繪用戶的標簽。逐漸把用戶畫像運用在推薦系統中，只要用戶畫像畫的夠准，那么推薦的准度就會更高。所以接下來的研究趨勢可以適當加入用戶畫像的構建[21]，從而更加提升推薦系統的綜合准確度。
供網友參考借鑒。
論文主要是理論知識的沉淀，系統實現則是對動手能力的考驗！
希望這篇文章可以幫助到需要的畢業生。如果還有疑問或者不懂得可以聯系作者，工作之余會幫助你們解決系統問題。
（2.3）
------------恢復內容結束------------
------------恢復內容開始------------
寫在前面：各位准畢業生你們好，論文已經發出來供你們參考查閱，有問題，ok，我有時間會解答，上來就讓我分享代碼的是什么意思？畢業不僅是畢業設計的考核，也希望你們對的起大學四年的時光。“你好我有些問題想請教。”什么問題？“請你分享一下你的代碼”。這就很無語好吧，這是問題嗎？論文都擺在這，推薦系統懂得都懂，你們對着教程手敲的功夫都不想付出么？從去年開始我也回答了很多人的問題。真正動手去做了的，有清晰的問題，哪里哪里。這個項目確實是有幾個坑點，當初踩坑也耗費了不少的時間。問問題的我一般都會解答；實在不明白上來要代碼的是什么意思哈？免開尊口。我願意幫助那些有動手能力的畢業生克服項目上的困難。我也不想理會那些伸手黨；沒有任何理由幫你們這些人。
本人於2021年6月畢業，當時的課題是推薦系統的算法探究與系統實現。故參考各方面資料完成了畢業設計與論文的編寫。至今也有很多人問我具體系統實現的細節。我把論文貼出來供大家參考借鑒。
終稿論文總查重率5.7%
首先說一下系統的特點：部署在 Windows上!Windows上!Windows上!
沒有用到虛擬機，沒有用到雲服務器。
目 錄
摘要. ii
Abstract ii
第一章 緒論. 1
1.1 課題研究的背景和意義. 1
1.1.1 課題研究背景. 1
1.1.2課題研究意義. 1
1.2國內外研究現狀. 2
1.2.1國外研究現狀. 2
1.2.2國內研究現狀. 3
第二章 大數據平台推薦系統的相關理論以及技術和框架. 4
2.1 JavaEE技術. 4
2.1.1 Spring框架. 4
2.1.2 MVC架構. 4
2.1.3 Maven 5
2.1.4 Restful 5
2.2 AngularJS框架. 5
2.3數據庫. 5
2.3.1 Redis數據庫. 5
2.3.2 MongoDB數據庫. 5
2.4埋點日志的采集. 6
2.4.1 Flume 6
2.4.2 Kafka 6
2.4.3 Zookeeper 6
2.5 Spark相關技術棧. 6
2.5.1 Scala 7
2.5.2 SparkSQL 7
2.5.3 SparkMLlib 7
2.5.4 SparkStreaming 8
2.6商品推薦主要用到的算法. 8
2.6.1 離線統計推薦算法. 8
2.6.2 協同過濾算法. 8
2.6.3 協同過濾LFM隱語義模型. 8
2.6.4 實時推薦算法. 9
2.7 推薦系統的常見召回路徑. 9
2.8 本次推薦系統部署環境. 10
第三章 系統分析與整體結構. 11
3.1可行性分析. 11
3.1.1技術可行性. 11
3.1.2經濟可行性. 11
3.1.3時間可行性. 11
3.2系統用戶需求分析. 11
3.3系統性能需求分析. 13
3.4系統的整體結構. 13
3.5系統的數據源. 15
第四章 系統方案的具體設計. 16
4.1系統功能設計原則. 16
4.1.1微服務. 16
4.1.2系統的可靠性. 16
4.1.3系統的維護性. 16
4.2系統總體架構設計. 16
4.2.1 前端模塊的設計. 16
4.2.2 后端業務模塊的設計. 17
4.2.3 后端推薦模塊的設計. 17
4.3數據庫設計. 17
4.3.1業務數據庫：MongoDB 17
4.3.2緩存數據庫：Redis 20
4.3.3系統數據流向. 20
4.4離線統計模塊設計. 21
4.4.1統計推薦之歷史熱門. 21
4.4.2統計推薦之近期熱門. 21
4.4.3統計推薦之均值推薦. 21
4.5離線個性化推薦模塊設計. 22
4.5.1基於模型的協同過濾算法設計. 22
4.5.2模型評估和參數選取. 23
4.5.3生成商品推薦列表. 24
4.5.4基於物品的協同過濾以及物品間的相似度. 25
4.5.5基於物品標簽的推薦. 25
4.6實時推薦算法設計. 25
4.6.1實時推薦算法. 25
4.6.2實時推薦算法設計. 26
第五章 環境部署和系統實現. 27
5.1環境部署. 27
5.1.1基礎環境. 27
5.1.2 MongoDB環境安裝與配置. 27
5.1.3 Redis環境安裝與配置. 27
5.1.4 Zookeeper環境安裝配置. 28
5.1.6 Kafka安裝與配置. 28
5.1.7 Flume安裝與配置. 28
5.1.8 Scala環境配置. 28
5.1.9 Jdk環境配置. 29
5.1.10 Maven環境配置. 29
5.1.11Spark環境安裝配置. 29
5.2成果實現展示. 29
5.2.1登錄展示效果. 29
5.2.2用戶注冊頁面展示. 30
5.2.3離線統計推薦實現. 30
5.2.4離線協同過濾基於模型的個性化推薦實現. 31
5.2.5基於物品的協同過濾推薦實現. 32
5.2.6實時推薦實現以及打分操作的流程. 32
5.2.7基於物品標簽的推薦. 35
5.2.8 商品的模糊搜索. 36
第六章 總結. 37
6.1畢業設計總結. 37
6.2推薦系統的亮點. 37
6.2.1使用高效率的Spring框架. 37
6.2.2推薦的多樣性. 37
6.2.3 基於大數據環境下的系統環境的配置. 37
6.3推薦系統實現中遇到的問題及解決方法總結. 38
6.3.1命名規范. 38
6.3.2 Windows與Linux命令不兼容問題. 38
6.3.3 Kafka 異常退出. 38
6.4推薦系統的不足之處. 38
6.4.1更准確的推薦算法. 38
6.4.2更高效的實時計算框架. 39
6.4.3 單機模式下的風險. 39
6.4.4用戶畫像（Profile）. 39
參考文獻. 40
謝 辭. 42
第一章 緒論
1.1 課題研究的背景和意義
1.1.1 課題研究背景
隨着科技的快速發展，當下電子商務在全國盛行，各大電商憑借自己獨特的營銷方式爭先搶占市場，隨之帶來的便是指數級別增長的數據量，在最短時間內找到用戶想要的商品就能深受使用者青睞。在我們平時的網上購物中；琳琅滿目的商品使我們往往淹沒在商品的數據中，但是其實我們可以發現：在我們瀏覽商品過后，在下方推薦的都是相同的類似商品。這就是推薦系統為我們帶來的便利之處，推薦系統的運用使我們不會被商品數據的洪流淹沒。根據阿里巴巴2020年12月31日的2021財年第三季度財報。數據顯示，該季度阿里巴巴營收達2210.8億元，高於市場預期的2141.58億元，與去年同期的1614.56億元相比增長37%，據悉其中國零售市場移動月活躍用戶數已達9.02億，年度活躍消費者達7.79億，單季凈增長2200萬。由此可見，國內的電商發展已經為社會帶來了巨大的經濟效益，也更加方便了人們的日常生活。不僅電商巨頭在推薦系統上煞費苦工，各類App都開始接入推薦的模塊，例如抖音App會根據用戶的喜好推薦觀看列表；網易雲音樂根據用戶的喜好生成個性化的推薦音樂列表等等。越來越多的專家和學者也對推薦系統進行了研究，國內外也出現許多優秀論文可供我們參考學習。
1.1.2課題研究意義
在如今的大數據時代，信息呈指數增長，人們很容易迷失在數據洪流中，面對大數據的沖擊，我們希望能有一個推薦准確率更高的系統完成對無關商品的過濾，將我們真正感興趣的商品留下來，為我們帶來更好的購物體驗。本課題實現商品推薦系統，使用Spark框架實現離線推薦、在線推薦、針對每位用戶完成個性化推薦，讓大家的用戶體檢更更加豐富，不局限於大眾的喜好。本課題結合大數據相關組件工具Zookeeper、Flume-ng、Kafka等，JavaEE企業級框架Spring，Tomcat部署系統服務，將整個系統部署在線上，可為小型電商公司作為商品推薦的雛形，也可供后來研究者更直觀清晰的學習。研究出來電商推薦系統准確度較高的推薦算法，能為電商企業和消費者提升粘合度，達到商品的“精准營銷”的目的，不僅能給電商平台提升市場競爭力，而且給用戶提升網上購物的消費體驗，實現電商交易的“雙贏”。
1.2國內外研究現狀
推薦系統的概念最先起源於國外，最早被運用於新聞推薦。亞馬遜發現了推薦系統在電商領域的巨大潛力，最先把推薦技術運用在電商系統中。
NetFlix提出了經典的推薦架構。在20世紀末，21世紀初期國內的電商才隨着互聯網的普及進入國內開始發展。直到現在，國內外的各大電商的推薦系統逐漸完善，電商推薦算法也推逐漸陳出新。給人們網上購物帶來極佳的的用戶體驗。
1.2.1國外研究現狀
推薦系統的鼻是祖1994年在國被設計出來的新聞推薦系統。亞馬遜率先發現了推薦算法在電商的優勢，並率先將推薦系統引入到電商中。為推薦系統的發展開辟出一條道路，對之后后的電商發展產生了很大的影響。
在國外，推薦系統依舊在亞馬遜沿用至今，隨着技術的不斷成熟以及用戶體驗的要求不斷提升。解決冷啟動問題[1]，運用機器學習訓練推薦模型[2]已經逐漸普及。
在2006年Netflix國外舉辦懸賞尋求可以將推薦准確度提高10個百分點的優秀學者。在此之后，高准確度算法推薦系統就開始出現。但仍然不能達到推薦完全正確；所以提高推薦的准確度就是衡量一個推薦算法是否有效的最好切入點。
也是推薦系統發展路上一直要攻克的難題。
2013年3月27日，Netflix的工程師在官方博客發文，推出了經典推薦系統架構——NetFlix推薦架構[3]。整個技術架構分為三層：ONLINE在線層、NEARLINE進線層、OFFLINE離線層。三層相互獨立，互相配合共同完成推薦系統的運行。在線層直接對接用戶與系統的交互，用戶在交互的過程中會伴隨着許多操作，例如評分、瀏覽等。這些作為前端的日志打點序列分發到離線層的Hadoop和近線層的流失處理平台（類似於SparkStreaming）。離線層一般以天或小時為粒度進行計算；數據存放於HDFS使用Pig、Hive等對數據進行過濾、提取。將最終的數據進行分發完成離線計算和模型訓練。模型可以傳到在線層供用戶實時計算，也可以在離線層提前預計算出用戶的推薦列表。還可以將矩陣分解得到用戶向量和物品向量。近線層是在線層和離線層之間的橋梁，近線層的計算可能會用到離線數據，也可與在線層的數據相接。這一層的計算結果往往存到一些高速緩存，以備調用。在線層一般會存在一個算法服務調度，這個服務會從高速緩存中獲取數據，使用在線層計算將結果快速計算出來。在線層不可以使用復雜的算法，不能讀取大量數據，因為要確保數據的快速響應。
Embedding技術[4]也在近期盛行起來，運用Embedding技術可以做出人人推薦、人物推薦、物物推薦等從中找到猜你喜歡的商品，可能認識的用戶等，在這個方面應用都有很好的效果反饋。
1.2.2國內研究現狀
在中國國內，雖然推薦系統起步不及國外早，但是近幾年的發展大家也有目共睹。2003年是我國公認的電商元年，從那時起，各大電商巨頭就將推薦算法逐漸引入到他們的線上電子商務中。隨着國內互聯網技術的發展與成熟，推薦系統現在已經能很好的帶給我們使用體驗。現國內研究推薦系統的研究者有大部分都集中在基於協同過濾算法[6]方向，建立基於模型的協同過濾體系[7][2]；通過用LFM建立模型使得推薦更加高效，提平等，李啟旭，郁雪，王巧等作者都發表了相關文獻來推動國內推薦系統的建設。也有作者利用FPFM組推薦框架[8]進行統推薦的研究；由於實時性是推薦系統繞不開的話題，國內也有部分作者對推薦系統的實時性有獨特見解。
2006年，國內書籍電商巨頭當當網首次將推薦系統運用，收到廣大用戶的好評；兩年之后，淘寶團隊也研發出自己的電商推薦模塊加以運用——“i淘寶”
這是淘寶電商推薦系統的雛形；到了2011年，百度也加入推薦技術行列，着重於搜索技術的個性化推薦。並提出了“一人一世界”的口號。
近幾年，用戶畫像逐漸成為推薦系統最火爆的應用。用戶畫像也能更精確的為每個用戶添加標簽，給用戶精准定位。目的就是為了把握每個用戶的興趣喜好，推廣合適的業務給用戶。
第二章 大數據平台推薦系統的相關理論以及技術和框架
2.1 JavaEE技術
在當下互聯網B/S模式的興起，Spring開源框架成為各大互聯網哪個公司搭建項目的首選。在web端的開發語言中，根據調查結果（圖2.1）Java無疑是近10年來開發者的首選。由於其跨平台性、高效的計算性能，以及全球眾多開發者在類庫和框架方面的開源貢獻，Java語言是本次課題項目實現業務系統綜合業務的首選，此次選擇的是基於Java語言的Spring框架。
2.1.1 Spring框架
在Spring框架是為了簡化JavaWeb開發而創建的；傳統的企業級應用開發，龐大的EJB使開飯維護工作量異常大；除了寫代碼邏輯，更重要的是配置組件之間的關系。然而為了解決這一難題。Spring框架誕生，Spring是一個容器框架，幫助開發者注冊加載各種組件，實現較EJB輕量級開發。
2.1.2 MVC架構
系統利用當下主流的MVC結構模式結構進行開發，M、V、C分別代表業后端編碼的三大構成M（模型）層大體可以分為兩類：承載數據的實體類業務處理的處理類。和、V（視圖）層是用戶直面系統的一層，也是用戶和系統交互的一層、C（控制）層把用戶和系統的交互操作轉換成請求發給相應的模型，根據模型的處理結果向用戶返回響應，MVC是如今J2EE應用極其廣泛的層次架構。
2.1.3 Maven
Maven是Apache基金會開源的依賴控制組件，是現大型web項目采用的jar包依賴以及模塊控制的結構，用小段描述信息管理項目的構建，便於開發人員直觀的查看項目結構和依賴。
2.1.4 Restful
Restful是基於HTTP的一種網絡應用程序的設計風格,是一種開發規范，用來寫接口時規范命名，使用restful風格開發接口可以使接口名稱長度變短，更加簡單清爽簡介，也便於開發人員直觀閱讀，看到接口的名稱就可以判斷該接口的功能。適用於移動互聯網廠商作為業務接口的場景，通過發起方式的不同請求完成對數據的增、刪、查、改等操作，極大的提升開發效率。
2.2 AngularJS框架
前端框架采用AngularJS，谷歌開源。AngularJS可以實現數據的雙向綁定。雙向綁定的操作通過檢查臟數據完成，但是臟檢查機制不是定時進行，而是在數據發生變化時也就是dom元素或者xhr事件的變化會引起底層的digest函數，這個函數會從底層逐步遍，檢查所有的watcher是否變化，如果數據變化，那么就會執行指令完成數據變化。從而實現雙向綁定。
2.3數據庫
電商推薦系統的構建選擇非關系型數據庫；因為在大數據環境下，數據的量級大且有一個特征：關系不一定完整；關系型數據庫並不適合大數據環境下的數據存數；所以利用非關系型數據庫非常符合本次場景，是大數據環境下業務的需要。
2.3.1 Redis數據庫
Redis是一種非結構化數據庫，是一種作用在內存上的緩存數據庫，Redis的讀、寫性能極高，可作為緩存、消息隊列、分布式鎖等場景應用。這次畢業設計基於大數據平台 商推薦系統就是借助Redis存儲和傳輸實時數據用於實時推薦模塊。可以按滿足數據的快速讀取。
2.3.2 MongoDB數據庫
MongoDB也是一種基於內存的數據庫，在存儲文檔信息發揮出色，多用於博客等存儲大量信息系統，底層用C++語言實現。是采用C++語言編寫的文檔型非結構化數據庫。基於大數據的電商推薦系統利用MongoDB存儲JSON數據格式，占用資源小，且支持單機、集群的使用。對大量的文字數據有較好的支持。
2.4埋點日志的采集
基於大數據環境中的電商數據，日志是反應用戶操作最直觀的途徑。所以需要采集日志並且用消息隊列中間件進行數據傳輸；大數據環境下有成熟的日志捕獲組件Flume和消息隊列Kafka組件。
2.4.1 Flume
Flume在大數據環境下多被用於日志的采集，由Source、Channel、Sink組成；通過管道的形式實現一對一，一對多，多對多端的數據傳輸；Flume具有可拓展性，且拓展性很強，可以單個Flume單獨使用，也可以多個Flume組合使用，采集不同源頭或者發送到不同物理位置、不同邏輯位置的文件中保存日志。支持多端多環境下配置捕捉傳輸日志數據。是專門負責日志數據收集的強大利器。本次畢業設計采用Flume將WebServer的數據采集到本地磁盤進行保存。以備Redis數據可進行快速的讀取。
2.4.2 Kafka
Kafka消息隊列可以作為緩存，為系統的傳輸可靠性提供保障，避免端與端的消息傳因各種原因出現遺漏或者丟失。Kafka能與Flumg組合使用，Flume進行數據收集，kafka在下游消費Flume采集到的數據進而將數據廣播到KafkaStreaming進行實時計算。
2.4.3 Zookeeper
還有一個特殊的框架——Zookeeper，這是基於大數據環境下為分布式應用提供調度的服務，也是Kafka服務的啟動依賴；
2.5 Spark相關技術棧
Spark在網絡上被稱為大數據技術棧的長子；確實，在大數據環境下，Spark的地位是舉足輕重的，Spark是通用的數據處理引擎；適用於多種離線、在線場
景大型數據集的交互式查詢Spark於2009年開始在加利福尼亞大學伯克利分校的AMPLab項目中生活。更具體地說，它是由於需要證明Meso的概念而誕生的，這也是在AMPLab中創建的；2014年被加州大學開源捐贈給Apache基金會，隨后其火熱程度就如它的名字一樣以星星之火迅速燎原不到一年就成為Apache的頂級項目Spark技術棧包括可用於可以實現高吞吐量的，具備容錯機制的實時流數據處理的SparkStreaming、處理結構化數據的SparkSql、機器學習實現庫SparkMLib等。Spark結構圖如圖2.2所示。
2.5.1 Scala
Scala是以利於Jvm的一種面向對象加面向函數（可以進行函數式編程）的語言，是編寫Spark框架的的語言。Scala的優點是面向對象，支持函數式編程，能帶來更高層的並發模型。
2.5.2 SparkSQL
SparkSQL專注於處理結構化數據，可以作為Sql在數據庫中獲取數據。還有兩個用於交互式計算的DataFrame和DataSet。
2.5.3 SparkMLlib
基於協同過濾的推薦需要借助機器學習來完成，用Spark的機器學習實現庫組件SparkMLib可以幫助我們更好的結合機器學習內容完成協同過濾算法的實現。
2.5.4 SparkStreaming
SparkStreaming是流式計算框架；它被用於大數據的流式處理實時計算。推薦系統的實時需求的實現就要用到SparkString處理消息隊列Kafka中的數據，進行數據的快速處理和計算。
2.6商品推薦主要用到的算法
基於大數據環境下的電商推薦系統核心算法就是推薦功能，也是本課題項目的關鍵所在，本項目包含統計分析推薦、機器學習智能推薦，離線推薦和實時推薦，下面將對相關算法做簡要說明。
2.6.1 離線統計推薦算法
離線統計推薦是非個性化推薦，也就是說，對於任何不同的用戶，這部分推薦的內容應該是一樣的；所以離線統計推薦就是每隔一段時間，把信息指標通過自己的任務運行計算，將推薦列表計算出推薦給每個人。
2.6.2 協同過濾算法
協同過濾算法是比較著名的商推薦算法，國內外研究者頗為喜愛，它誕生較早，通過對使用者歷史動作的數據挖掘進而分析用戶的偏好，基於不同的偏好對適用人群進行區分。可以從多個角度進行協同過濾推薦：基於用戶、基於商品、基於隱語義模型。
2.6.3 協同過濾LFM隱語義模型
LFM（later factor model）是一種基於模型的矩陣分解的召回算法，輸入UI點展矩陣，輸出是P和Q兩個矩陣。本項目中是將評分矩陣拆解為用戶特征矩陣和商品評分矩陣。
建模公式如式2.3所示：
2.6.4 實時推薦算法
實時推薦滿足的是更快地更新要求，准確性的標准可以略微降低。但是實時算法不能太過復雜，每次讀取的數據也不能大量。因為在實時算法面前短的時延才是標准。
2.7 推薦系統的常見召回路徑
推薦系統面對的主要問題就是如何從海量數據中挑選出用戶的興趣愛好且還要滿足低時延性能要求（例如NetFlix的指標是250ms返回，今日頭條指標是200ms返回結果）。當今推薦系統往往存在三個步驟：召回，排序，調整[4]。
召回環節實現兩個功能：一是巨量的數據降低，從億級別到萬級別；二是選取與用戶相關的感興趣的條目。方式一般有：協同過濾、內容相似等。
排序環節一般利用機器學習算法：邏輯回歸或者二分類算法等得到的結果降序排序就會得出用戶的喜好列表，此時的數據量降為千或百。完成了精細的個性化功能。
調整環節對排序后的加過進行優化，去除推薦重復，將購買過的商品進行去除等，熱門補足等。
推薦中的常見的召回路徑有以下幾類：
I2I、U2I、U2I2I、U2U2I、U2tag2I，I代表物品Item，2諧音為to，相當於圖中的邊，U代表用戶，如圖2.4所示。
1.I2I：從一個物品到達另外一個物品，例如今日頭條會在一篇文章的最后列出預制相似的另一篇文章。可基於內容相似。協同過濾、關聯規則挖掘等實現。
2.U2I：來源於用戶的直接行為，例如播放，購買，收藏等。
3.U2I2I：可以看做U2I+I2I的方法結合。根據用戶的喜好找到喜愛的商品，在找到與這個商品相似的另一個物品。這個新找到的物品推薦給用戶。
4.U2U2I：看做U2U+U2I的方法結合，U2U可以通過行為找到，也可以根據標簽找到。把第二個用戶的喜愛物品推薦給第一個用戶。中間的橋梁通過U2U實現。
5.U2tag2I：這個是把U2I2I更泛化的一種召回路徑，tag表示的就是用戶喜好的商品的標簽，通過標簽的相似度查找標簽相似的物品，將結果推薦給用戶。
2.8 本次推薦系統部署環境
在大數據環境中，Linux是具有先天優勢的；開源，擁有眾多的發行版，是廣大程序員的首選；但是隨着大數據技術棧的發展，時至今日，Apache各大主流框架組件已經支持Windows環境；例如Kafka，Zookeeper等；以kafka為例，可以發現，后續大數據組件版本的根目錄結構中多出了/Windows，其文件目錄中的執行腳本也從.sh換成了在Win環境中的執行腳本.bat文件。所以，本次項大
數據環境決定嘗試部署在Windows環境下，同時這也是現階段對該類的現階段研究的一個變化。
第三章 系統分析與整體結構
本畢業設計實現的推薦系統要明確電商中推薦算法的運用以及推薦系統的完整開發與上線部署，對用戶的需求進行分析，需求合理可執行，方可對系統進行開發。
3.1可行性分析
電商推薦系統的可行性分析是衡量系統能否順利實現指標，有以下幾點：技術可行性、時間可行性、經濟可行性。
3.1.1技術可行性
該系統在當前環境下技術可實現，推薦系統采用B/S架構，B/S架構又稱瀏覽器/服務器架構，他的優點是容易維護，只需要瀏覽器就可以發起請求操作。不需要繁雜的安裝系統等，適合本次推薦系統的開發選型。前后端分離技術，部署上線並不困難，即使未來有需求改為C/S結構，那也只需要構建C端的界面代碼及配置項，無需較大改動。將推薦系統開發完畢可以利用Tomcat將打包的war文件部署到服務器實現網絡訪問。
3.1.2經濟可行性
該系統采用的框架皆為開源框架，全部免費。在項目框架上選用約為“0”成本，項目上線的運維成本也比較低，通過Zookeeper搭建管理集群，構建分布式或者偽分布式結構，推薦系系統主節點宕機服務異常停止的情況下節點可以由follower繼續接替工作，留出足夠的時間給開發者排查，解決問題，在此期間不會影響系統的正常工作。所以運維成本也可以降低。
3.1.3時間可行性
畢業設計推薦系統系統從查閱資料到選型、構建、開發、完成，由於基本需求比較明確，使用框架開源，社區維護者很多，碰到的開發問題可以較快時間解決，老師指導耐心全面，參考資料豐富，可以在規定時間內完成開發並加以測試、修改及完善。
3.2系統用戶需求分析
接下來介紹本系統的各部分需求。
（1）注冊功能：登錄注冊功能的實現；新用戶在首頁都需要注冊用戶方可成為新用戶，新用戶首次登錄需要注冊用戶名，注冊后方可登錄系統。在注冊時還要判斷該用戶名有無被搶先注冊，如果被提前注冊，那么要提示用戶這個用戶名已經被注冊；使用其他用戶名重新注冊。
（2）忘記密碼：對於已注冊過的用戶再次登錄時，如果忘記自己的登錄密碼，可以根據自己的密保方式找回自己的密碼。
（3）用戶登錄：注冊過的用戶將正確的用戶名和密碼輸入后可以順利登錄系統。看到自己的推薦頁面。
（4）用戶退出：在用戶瀏覽尚品后要可以做到安全退出，防止其他非法人員盜用信息。
（5）推薦頁面的展示：系統要把每個用戶的推薦列表在頁面上進行展示
通過程序運算將推薦列表進行可視化展示。
（6）埋點數據采集：系統前端要能捕捉到用戶打分的行為傳到后端，后端要將埋點日志進行捕捉並本地保存。
（7）埋點日志的監聽：系統要能時刻動態監聽到日志文件的變化，用以第一時間捕捉日志文件。
（8）埋點日志的處理：系統后端將前端穿過來的日志進行格式處理，識別日志文件中的用信息。並將其中有用的數據截取出來，傳到相應的推薦模塊計算推薦結果或者推薦列表。
（9）統計推薦：推薦系統要能准確推薦出后台統計出的物品評分歷史，准確找到評分最多的物品列表。
（10）基於物品標簽的推薦：推薦系統要能根據物品的標簽內容，推薦出標簽相似度最高的其它物品。
（11）實時推薦：推薦系統要將用戶的實時打分數據進行處理，系統要快速處理給出響應並更新推薦列表，實時的反饋給用戶。
（12）基於模型的協同過濾推薦：系統要實現基於模型的協同過濾，實現個性化推薦。
（13）商品模糊查詢：對商城內的已有商品進行模糊查詢，快速找到相關商品。
整個推薦系統的用例圖如圖3.1所示。
3.3系統性能需求分析
（1）數據存儲部分：業務數據庫要滿足頻繁的增刪查改的需求，而且數據多為非結構化數據，緩存數據庫需要滿足高效，實時計算的要求。
（2）響應速度：API請求的普遍時間是小於1s；打開或跳轉Web頁面時間加載所有數據，JS圖片等相關完整內容共不能超過8s。
（3）並發量：系統要同時支持多用戶同時在線，滿足並發處理多用戶的推薦需求。
3.4系統的整體結構
綜合以上系統結構用戶需求以及性能需求，畢業設計推薦系統整體結構設計如圖3.2所示，離線推薦模塊包括四個詳細的離線推薦：分別為離線統計推薦服務、基於隱語義模型的協同過濾、基於物品的協同過濾、基於物品標簽的相似度推薦；實時推薦模塊的結構在圖的右側由Flume、Kafka、SparkStreaming相接組成。
這些模塊的推薦結果與業務數據庫MongoDB相連接；前端可視化通過Spring后台的處理從MongoDB拿到結果后展示給用戶。用戶的操作通過前端再傳到后台，通過日志采集服務進行監控日志文件，傳輸到Kafka消息隊列進行日志數據處理，再通過SparkStreaming實時推薦服務結合業務數據庫的結果把數據傳輸到Redis緩存數據庫，供實時推薦列表的快速刷新。
推薦系統Spring后台流程控制MVC結構如圖3.3所示，前端點擊綁定的函數觸發rest請求對服務器發起訪問，請求包括注冊、登錄、評分等等。任何一個請求都有唯一的標識，Controller接到數據會轉換成Model實體類，與數據庫進行交互，計算的結果仍會返回到Controller，最后向View層發送結果數據，進行數據的解析與前端顯示。
3.5系統的數據源
推薦系統的基礎數據源於學者在GitHub上開源數據集亞馬遜商品集[5]。共分為兩個部分：物品信息和用戶評分信息。
結構如表3.4所示：
表3.4 物品信息表結構
| 物品ID |
物品名稱 |
物品種類向量 |
物品圖片URL |
物品標簽 |
| 160597 |
白鹿原 |
832,519,1 |
https://images-cn- |
小說|文學藝術|圖書音像 |
| 66003 |
諾基亞N1280 |
1128,640,304 |
https://imag s-cn- |
手機|手機通訊|手機 |
| … |
… |
… |
… |
… |
商品信息共487條。
評分信息結構如表3.5所示：
表3.5 評分信息表結構
| 物品ID |
用戶ID |
分數 |
時間戳 |
| 160597 |
452794 |
4.0 |
1264089600 |
| 66003 |
452754 |
1.0 |
1351267200 |
| 160597 |
452796 |
5.0 |
1381766400 |
表中被一行為兩兩對應的評分，每個物品由對應用戶在某一時間點打出的分數。例如：表格中第一行意思是452794用戶為id為160597的商品在1264089600的時刻打上了4.0的評分。這兩個表的數據是構建系統時的初始數據；整個系統運行的數據遠不止這些，在后文數據庫設計會詳細說明。
第四章 系統方案的具體設計
4.1系統功能設計原則
4.1.1微服務
系統采用微服務架構，利用Maven自動控制jar包依賴，各部分相互獨立，松耦合。每個推薦模塊相互獨立，就模塊而言互不干涉。
4.1.2系統的可靠性
微服務設計理念有強調，系統中加用日志和監控能使系統變得更加健壯。還有要考慮到消息在傳輸過程的准確性，避免網絡擁塞，消息緩存隊列是必要的也是必須的。系統的各組件，都已經比較成熟，開源社區為系統的可靠持續運行提供強大的后盾支持。
4.1.3系統的維護性
本系統目前部署在單節點偽分布式下，遇到問題可以根據日志快速定位並回滾。當前只存在單機部署，維護方便快捷。
4.2系統總體架構設計
4.2.1 前端模塊的設計
前端展示運用AngularJS編寫，完成對數據可視化視圖的構建，利用webpack打包並將前端項目一同放入后端項目文件，將請求與操作進行綁定，定義路由，請求方法等，規定渲染流程。
前端模塊具體包括：
1.home：推薦系統首頁，將推薦線結果進行展示。
2.login：登錄模塊的頁面，進行用戶登錄的表單構建。
3.register：用戶注冊頁面，完成注冊模塊的構建。
4.tags：定義tags標簽，這個標簽要js實現商品的標簽
5.star：定義打分，需要實現鼠標滑動打分的效果以及綁定打分的數據與操做
6.mdetail:商品詳細信息頁，定義商品的可視化結構，要包括標簽、評分、詳細信息等信息。
4.2.2 后端業務模塊的設計
主要采用Java寫明Pojo實體類，controller控制層，service業務層；接收前端傳來的數據，根據對應的請求進行restful操作匹配作出對應的處理。
后端的請求處理主要包括：
1./rest/user/login：用戶登錄請求
2./rest/user/register：用戶注冊請求
3./rest/user/forget：用戶忘記密碼請求
4./rest/product/most：獲取基於模型的推薦列表
5./rest/product/reating：獲取商品的評分
6./rest/itemcf/{pid}：獲取根據物品協同過濾的推薦列表
7./rest/content/{pid}：獲取基於標簽的推薦列表
8./rest/detials：商品詳情頁請求
9./rest/search：商品模糊查詢請求
4.2.3 后端推薦模塊的設計
主要采用Scala開發編寫Spark程序，根據推薦方式方法的不同，分成多個對應模塊，離線推薦、實時推薦；離線推薦包括基於統計的離線推薦，基於隱語義模型的協同過濾離線推薦、各個模塊相互獨立，松耦合。
推薦模塊具體包括：
1.統計推薦模塊
2.基於隱語義模型的協同過濾推薦模塊
3.基於物品的協同過濾推薦模塊
4.基於物品標簽的推薦模塊
5.實時推薦模塊
6.近期熱門推薦
4.3數據庫設計
4.3.1業務數據庫：MongoDB
主業務數據存放在非關系型數據庫MongoDB。
具體數據表如4.1—4.10所示：
1.Rating表結構如表4.1所示
表4.1 Rating表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| pid |
Int |
物品id |
| score timestamp |
Double Int |
評分 打分時間 |
2.Product表結構如表4.2所示
表4.2 Product表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| pname |
String |
物品名稱 |
| imageUri categoraies tags |
String String String |
圖片保存鏈接 分類 商品標簽 |
3.User表結構如表4.3所示
表4.3 User表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| username |
String |
用戶名 |
| password |
String |
登錄密碼 |
| |
String |
密保郵箱 |
| timestamp |
Int |
注冊時間 |
4.AvgRating表結構如表4.4所示
表4.4 AvgRating表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| avgrateing |
Double |
物品平均得分 |
5.BaseOnContentProArr表結構如表4.5所示
表4.5 BaseOnContentProArr表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| list |
Seq[Recommendation] |
基於內容的推薦列表 |
6.ItemCFProArr表結構如表4.6所示
表4.6 ItemCFProArr表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| list |
Seq[Object] |
基於物品協同過濾的推薦列表 |
7.ProductList表結構如表4.7所示
表4.7 ProductList表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| list |
Seq[Seq[Object]] |
商品的推薦列表 |
8.RateXProduct表結構如表4.8所示
表4.8 RateXProduct表結構
| 字段名稱 |
類型 |
字段含義 |
| pid |
Int |
物品id |
| num |
Int |
商品被評價總數 |
9.UserList表結構如表4.9所示
表4.9 UserList表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| list |
Seq[Object] |
用戶推薦列表 |
10.StreamRecs表結構如表4.10所示
表4.10 StreamRecs表結構
| 字段名稱 |
類型 |
字段含義 |
| uid |
Int |
用戶id |
| list |
Seq[Object] |
實時推薦列表 |
4.3.2緩存數據庫：Redis
緩存數據庫的存在為實時推薦獲取商品列表提供了快速支持，Redis中保存了已經注冊的用戶推薦列表；格式如下：
2) "userId:1985105"
…
8) "userId:4867"
4.3.3系統數據流向
數據流向圖如圖4.11所示：
4.4離線統計模塊設計
商品離線推薦的設計是要綜合電商用戶的所有打分歷史數據，通過運行離線推薦算法，運行過后結果是固定不變的，每運行一次便會更新一次結果；結果的變化只取決於捕捉到所有使用者的評分以及將這些評分重新計算的執行時間。
離線推薦用數據庫商品的直接屬性進行計算，例如商品標簽，商品名稱，商品評分等，計算結果作為前端可視化數據的支撐。
如果按照分類划分，僅使用SQL進行的統計推薦和利用機器算法的協同過濾推薦都屬於離線推薦。
4.4.1統計推薦之歷史熱門
根據數據庫中已經存在的所有商品評分信息，使用sql統計出被評分最多的商品。這個統計僅僅是做出熱度比較高的商品，不對評分的高低做判斷。實現sql語句如4.12所示：
統計歷史熱門商品僅需要根據商品ID聚合匯總再降序排列即可，將SQL代碼注入到SparkSession.sql()函數中實現。
4.4.2統計推薦之近期熱門
在上一步的基礎上，增加時間條件進行評分篩選。實現sql語句如4.13所示：
4.4.3統計推薦之均值推薦
在數據庫中找到每個商品獲得的所有評分，求平均值，根據平均值構建推薦信息。實現sql語句如4.14所示：
統計商品的平均分僅需要根據商品ID聚合，使用系統函數（圖中的AVG函數）計算商品ID對應的平均法再降序排序，將SQL代碼注入到SparkSession.sql()函數中實現
4.5離線個性化推薦模塊設計
4.5.1基於模型的協同過濾算法設計
前邊有說到，離線統計是把所用有用戶的評分結果進行計算法處理，每個人都會看到看到相同的推薦列表。然而，個性化離線推薦就要體現出用戶和用戶之間的不同。每個人的看到的離線列表都是根據自己的評分喜好計算而出，不同用戶的喜好不同，對商品的評分不同，那么他所看到的列表熱度結果也就不同。協同過濾不可以直接用商品直接屬性，需要利用統計離線推薦結果生成矩陣。我們要用ALS訓練LFM（隱語義模型[9][7]）。
ALS算法交替最小二乘法的原理為矩陣分解技術，矩陣分解就是把一個矩陣分解成兩個或者多個矩陣的乘積，意義層面的解釋就是通過隱含特征（latent factor）將用戶的興趣與item聯系起來。主要思想如圖4.15所示。
目標函數公式如式4.16所示：
優化目標函數公式如式4.17所示：
在原始的評分矩陣中，不可能保證每個用戶對每個物品都有過評價評分。用戶和物品之間還是沒有聯系的，得到的矩陣是稀疏的缺少特征的。矩陣分解的優點可以將高維的矩陣映射成兩個低維矩陣的乘積，能解決數據的稀疏問題，自定義隱特征數量，預測的精度高，高於基於統計的協同過濾和基於內容的推薦。矩陣分解也有一定的缺點，第一個缺點。在隱語義模型中，你無法解釋這些個隱因子的具體含義；就不能將隱空間的維度與現實中的概念一一對應。第二個缺點就是模型訓練比較費時，模型的訓練需要迭代式進行，數據量大的術后天粒度的話只能是按天粒度進行訓練。
使用ALS算法可進行顯式模型訓練與隱式模型訓練，進行訓練模型時需要傳入四個參數。若進行顯式訓練，則使用ALS.train(ratings, rank, iterations=5, lambda_=0.01)；如果要進行隱式訓練，則參數為ALS.trainImplict(ratings, rank, iterations=5, lambda_=0.01)。上式中，參數ratings指訓練模型數據源，rank指的是當進行矩陣分解時，將原矩陣分解成X(m*rank)矩陣和Y(rank*n)矩陣，Iterations指ALS算法的迭代次數，lambda為正則化項系數，默認為0.01。
4.5.2模型評估和參數選取
ALS訓練隱語義模型的過程中公式中的三個參數僅僅憑借經驗或者查閱資料固定填寫。雖然可能出較好的結果，但是這樣的參數集並不一定是針對我們研究的問題的最優解。所以有必要采取模型優化的步驟對模型進行優化。可以計算方根誤差來評判模型的優劣。公式如式4.18所示：
通過RMSE計算[8]，可以反復調整參數的取值范圍，最后保留值最小的一組參數作為模型的參數最優解。
程序代碼實現如圖4.19所示：
圖4.19 RMSE優化參數代碼
4.5.3生成商品推薦列表
只有計算出來模型才能通過模型構建商品列表進行推薦。構建推薦列表的主要思路步驟如下：
1.得到用戶和商品的二元組（用戶ID，商品ID），完成這個操作只需將用戶表中的Id和商品表的Id做笛卡爾積。
2.用ALS訓練出來的模型給二元組預計算評分。
3.將最終的記過排序后保存到數據庫。
最終結果形式如圖4.20所示：
矩陣R表示用戶對物品的興趣度，矩陣P表示用戶對物品的偏好度，Q表示物品屬於哪個類別的概率如圖4.21所示。隱語義模型及時通過將矩陣R分解成P和Q的乘積，通過P矩陣物品類別將用戶User與物品Item聯系起來。
4.5.4基於物品的協同過濾以及物品間的相似度
協同過濾推薦針對的對象不同可以分成兩種：基於用戶的協同過濾和基於物品的協同過濾；由於此時用戶群體非常少，基於用戶的協同過濾[7][8]不夠明顯，所以暫且不討論基於用戶的協同過濾，下里面來講述基於物品的協同過濾[9][10][11]。
基於物品的協同過濾[12][13]判斷兩個商品相關性的大小，一般用余弦相似度作為依據。不需要對物品進行標簽采集分詞，只需要收集用戶的行為（例如點擊、收藏、購買、評價等）便可以進行基於物品的協同過濾推薦。可以通過前邊的余弦相似度進行評判，也可以用同現相似度[14]來反應物品間的相似程度。計算公式如式4.22所示：
4.5.5基於物品標簽的推薦
基於物品標簽的推薦[15][16]需要利用物品的初始標簽，對標簽進行分類從而進行同類推薦，這個部分會把商品中屬於同一類的物品進行篩選展示。實現思路為在Spark單例中實例化分詞器，定義HashTF工具把文字信息處理成向量信息，運用TF_IDF進行特征矩陣的獲取。
4.6實時推薦算法設計
在電商推薦系統中，實時的更新推薦列表能給用戶帶來更好的體驗，假如物品推薦的列表只有到了系統設定的時間（例如凌晨）實時推薦[17]與離線推薦應最大的不同之處在於實時計算推薦推薦列表應該動態更新，能計算出用戶近期的喜好並推薦商品，需要實時技術的支持而不是在后台周期性的運行算法模塊。
4.6.1實時推薦算法
推薦系統的使用群體對商品的喜愛與否是會隨時間逐漸變化的。我們假設小明喜歡喝牛奶，比如小明在某個時間點對“A牌牛奶”做出了很高的行為舉動（例如購買、收藏、分享、好評、長時間瀏覽等），那么我們就可以猜測，小明有可能很喜歡其他品牌的“牛奶”、“奶制品”等；而如果小紅在某天給“L牌辣條”做了負面行為（例如寫差評、從購物車刪除，取消收藏、退貨等），那么我們就可以推斷：“L牌辣條”不是小紅這段時間心儀的商品，更甚至與“辣條”相似的同類物品如“辣片”、“麻辣”等都不會被小紅納入采購的行列。所以針對於實時推薦，每當用戶對某個產品進行了評分，后台要根據這次的行為動作捕捉具體的的喜好或者忌口，從而更新推薦列表，使結果能喜好最大程度匹配。
4.6.2實時推薦算法設計
實時推薦[18]推薦優先級的基本思路：用戶短時間內的喜好保持一致相似。
初步計算備選商品的推薦優先級公式4.23的如下：
公式的意義如下：基礎評分項*評分（權重系數）從而調整推薦力度+，除以sim_sum做平均，結果就是推薦優先級得基礎分數；后邊的偏移量一個是鼓勵項，一個是懲罰項；鼓勵項：最近的評分都是高分，看了買了還給了高分，說明最近的行為很能代表自己的喜好；如果最近將某個商品拉黑刪除等，說明用戶不喜歡這個商品。這個商品的類別就不能代表用戶的喜好。
第五章 環境部署和系統實現
5.1環境部署
以下環境作為本次畢業設計系統部署的開發環境參考：
5.1.1基礎環境
操作系統如圖5.1所示：
5.1.2 MongoDB環境安裝與配置
1.安裝MongoDB：到MongoDB官網下載社區免費版MongoDB msi安裝程序，
將下載到本地的msi安裝程序運行，按照個人需求安裝在目錄,以下簡稱為：%MONGODB_PATH%。
2.創建數據與日志文件夾：在%MONGODB_PATH%中找到data文件夾在內部創建db和logs文件夾以存放數據和日志信息。
3.配置環境變量：在系統環境變量中加入%MONGODB_PATH%
4.啟動mongodb服務：輸入指令mongod --dbpath %MONGODB_PATH%\data\db;
5.檢查服務：瀏覽器輸入http://localhost:27017如果提示連接成功，那就表示MongoDB環境已經配置完成。
5.1.3 Redis環境安裝與配置
1.安裝Redis：到Redis官方github倉庫下載現階段穩定版本的msi。將下載的msi文件安裝運行，按照個人習慣安裝在指定目錄，以下簡稱%REDIS_PATH%。
2.將%REDIS_PATH%添加到系統的環境變量中。
3.啟動Redsi臨時服務：輸入指令redis-server.exe redis.windows.conf
4.創建Redis連接：輸入指令redis-cli。進入redis說明redis環境已經配置完成
5.1.4 Zookeeper環境安裝配置
1.解壓Zookeeper壓縮包：到官網下載Zookeeper安裝包，根據個人習慣解壓文件到指定路徑，以下簡稱%ZK_PATH%，將%ZK_PATH%添加到系統環境變量中
2.復制%ZK_PATH%\conf\zoo_sample.cfg文件，重命名為zoo.cfg；修改文件內容，將dataDir和dataLogData的路徑修改為自定義路徑。
3.運行zkServer.cmd可執行腳本，運行zkCli.cmd腳本。提示連接到2181端口和出現“Welcome to Zookeeper！”字樣便證明環境配置成功。
5.1.6 Kafka安裝與配置
1.官網下載Kafka安裝包，並根據自己的習慣解壓到自定義路徑，以下簡稱%KAFKA_PATH%，將%KAFKA_PATH%加入到系統環境變量中。
2.進入%KAFKA_PATH%\conf目錄編輯文件server.properties，將log.dir修改為自定義路徑，建議為%KAFKA_PATH%\kafka-logs；編輯zookeeper.connect=localhost:2181
3.創建topic測試kafka安裝成功：在%KAFKA_PATH%下運行指令
.\bin\windows\kafka-topics.bat --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic tast；
4.運行指令查看主題
.\bin\windows\kafka-topics.bat --list --zookeeper localhost:2181；
如果顯示列表中存在一個tast主題說明kafka環境配置成功。
5.1.7 Flume安裝與配置
Flume安裝包下載：到Apache官網下載Flume安裝包，根據自己的習慣解壓到指定路徑%FLUME_PATH%，將%FLUME_PATH%添加到系統環境變量中。
5.1.8 Scala環境配置
Scala安裝包下載：官網下載Scala安裝包;根據自己習慣將安裝包安裝在指定路徑，以下簡稱%SCALA_PATH%，注意此路徑中不能包含空格。將%SCALA_PATH%添加到系統變量中。安裝完畢在cmd命令行輸入scala顯示版本信息即為正確配置環境。
5.1.9 Jdk環境配置
官網選擇合適的JDK版本，建議選擇穩定且普及率高德JDK8；根據個人習慣將壓縮包解壓至指定路徑，以下簡稱%JAVA_HOME%；將%JAVA_HOME%添加到系統環境變量中。輸入命令java -version有版本信息輸出說明環境配置成功。
5.1.10 Maven環境配置
Maven官網下載安裝包，根據個人習慣，將安裝包安裝到指定目錄，以下簡稱%MVN_HOME%，將%MVN_HOME%添加到系統環境變量。cmd輸入指令 mvn -v查看Maven版本號，有版本號正確輸出便說明環境正確安裝成功。
5.1.11Spark環境安裝配置
下載Spark安裝包，根據個人習慣將安裝包解壓安裝在指定目錄，以下簡稱為%SPARK_HOME%，將%SPARK_HOME%添加在系統的環境變量在cmd中輸入spark-shell,顯示有正確版本號輸出，那就說明環境正確安裝。（Spark環境是依賴於JDK8以上版本+Scala環境，安裝配置Spark環境時確保JDK與Scala環境已經正確安裝）hadoop報錯提示在單機環境下運行時可以忽略。也可以自行安裝Hadoop環境搭建高可用集群。
5.2成果實現展示
前端模塊構建的主要是識別用戶的身份信息，將推薦列表做數據可視化展示，包含用戶注冊、用戶登錄、瀏覽商品頁面、商品模糊查詢、用戶打分、以滿足基本的要求。
5.2.1登錄展示效果
登錄界面如圖5.2所示
5.2.2用戶注冊頁面展示
用戶注冊界面如圖5.3所示，若注冊時改用戶名被搶先注冊，那么系統會提示注冊失敗，請更換用戶名注冊。
5.2.3離線統計推薦實現
離線統計推薦在系統中的具體實現是熱門推薦模塊和評分最多推薦模塊如圖5.4所示,熱門推薦列表是基於商品的評分高低，求所有用戶對物品的平均分得出來的推薦列表，具體實現過程為把評分數據定義成一個新的樣例類（僅關注評分表中的分數，與物品id）通過Spark以DataFrame的形式進行讀取，使用Spark.SQL統計出在歷史時間內的評價均分最高的物品，將統計后的數據保存在MongoDB中的RateXProduct表中，保存的序列就是商品平均分由高到低的序列，這也就是前端頁面展示出的熱門推薦列表的內容。評分最多推薦模塊的實現是基於評分的次數，而不是評分的高低，步驟與前邊類似，將評分數據以Spark的DataFrame形式讀取，使用SparkSQL統計商品的評分次數，降序排序，得到的列表即為評分最多的列表。需要注意的是：評分最多代表的是用戶給他的評分此時多。並不能說明用戶給他的評分數值高。這點需要讀者認真區別。
5.2.4離線協同過濾基於模型的個性化推薦實現
基於模型的協同過濾需要用到用戶的歷史數據進行計算，用戶打分的行為數據，定義新的樣例類，將數據加載到定義的RDD中，提取所有用戶的商品打分數據，將數據轉換成mllib規定的規范格式進行隱語義模型的訓練，規范中要具體三個參數：隱特征個數、迭代次數、正則化系數。RDD調用cartesian函數得到笛卡爾積；此時就擁有了一個稀疏的評分預測矩陣；接下來對矩陣進行分解，將稀疏額矩陣變為稠密矩陣。將數據集切分，運用Mllib中ALS.train訓練模型，getRMSE得到最優模型參數。得到了模型就可以將矩陣最優分解，再做笛卡爾積；就能得到商品兩兩的相似度；此時還要過濾掉自乘的結果，因為自乘的結果相似度為1。計算出物品的相似度矩陣。挑選出相似度最高的物品。組成基於模型的協同過濾推薦列表如圖5.5所示。
5.2.5基於物品的協同過濾推薦實現
基於物品的協同過濾用到了第二章介紹的U2I2I召回路徑：分為兩步：U2I和I2I；U2I根據用戶找到喜愛的物品；I2I根據物品找到相似物品；I2I這個步驟通過同現相似度完成，使用商品之間的同現相似度計算出推薦商品，具體實現步驟為：加載數據到spark，按照pid做group by對評分進行統計，新加一列sum存放評分個數。此時數據應為pid|num；再將評分按照uid兩兩匹配，統計商品被同一個用戶打過分數的次數，此時的結果中油兩個pid；將這兩個pid做group by；統計出uid的個數；那么就算出了對兩個商品同時評分的個數。將這個序列倒序輸出，就得到了基於物品U2I2I的協同過推薦列表如圖5.6所示。
5.2.6實時推薦實現以及打分操作的流程
當我們對一個商品進行打分操作時，評分的數據會在控制台看到，並且以埋點日志的方式存到本地文件；Flume檢測到本地文件變化，就會將日志預處理傳送給Kafka消息隊列，KafKa消息隊列將數據傳到SparkStreaming；通過計算運行將處理后的結果保存到Redis中。操作過程步驟如圖5.7-5.10所示。
以上就是一個完整的物品打分數據流；此時實時推薦結果已經更新。圖5.11與5.12展示了用戶對商品進行評分后實時推薦的變化。
5.2.7基於物品標簽的推薦
打開《這就是你給我的愛》物品詳情頁；可以找到下面對於這本書的標簽：書、少兒圖書、教育類、勵志、雞湯、好看、內容不錯。基於物品標簽的推薦的實現是通過Mlib中的Tokenizer將物品的標簽通過“|”分詞，實例化一個HashingTF工具增加一列向量表示這個物品的標簽，訓練idf統計向量出現的頻次，把這些特征轉換成和和模型協同過濾推薦一樣的RDD，兩兩配對商品計算余弦相似度，過濾掉自己本身，得出的變標簽相似列表。
我們繼續查看它基於標簽的的推薦列表，打開第一本書：《30年后你拿什么養活自己》如圖5.13所示，查看標簽如圖5.14所示，發現相似度很高，標簽有 書、勵志、雞湯、好看 這四個是和《這就是你給我的愛》重合如圖5.15,5.16所示。所以可以得出結論。按照物品標簽推薦也是非常准確的。
5.2.8 商品的模糊搜索
在商品首頁的導航欄中，還新增了商品信息模糊搜索查詢，輸入查詢的物品名字，即可模糊搜索到數據庫中含有該名稱的物品；並直接跳轉到詳細頁面展示，如下圖如圖5.17所示。
搜索“白”，可以找到伊麗莎白化妝品，清除白噪聲耳機；白岩松的書。這部分的具體實現直接是在Spring的控制層寫了sql語句，由於不涉及到對數據評分的變化，所以沒有歸納到推薦模塊中，直接從Spring返回模糊查詢結果。
第六章 總結
6.1畢業設計總結
在完成這次畢業設計的過程中，經歷了研究開題、文獻查找閱讀、撰寫開題報告、中期檢查、文獻綜述的編寫等眾多步驟。經歷了很多，也學到了很多。通過查閱大量的相關資料文獻，總結前人的論文研究加上自己的思考與創新，最終完成了基於大數據平台的商品推薦系統設計與實現。在整個完成期間也碰到許多難題。老師和同學們都耐心的指導我幫我解決問題。自己的理解差錯也能被及時糾正。下面簡述我在本次畢業設計過程中的亮點與遇到的一些問題。
6.2推薦系統的亮點
6.2.1使用高效率的Spring框架
系統使用Spring構建整體框架使開發成本變低，后續可以轉為SpringBoot更輕量級的架構，能降低項目的成本投入以及維護成本，並提高系統運行效率。
6.2.2推薦的多樣性
系統中共多個推薦模塊：實時推薦滿足了系統推薦的實時性、統計推薦了反映了商品庫中信息的總覽，將所有用戶的地對商品的評價進行總覽、基於商品協同過濾實現了個性化推薦，讓每個用戶都要自己獨特的推薦列表、基於每個模塊都采用不同的推薦算法進行實現，使我們能從更多角度查看推薦的結果。
6.2.3 基於大數據環境下的系統環境的配置
當下大數據環境大部分都是部署在虛擬機或者雲服務器的Linux發行版的操作系統上。在Windows上配置環境的先例少之又少，原因有二：一是Apache基金會下的大部分組件先天就不支持Windows操作系統；二是在Linux上更加利於項目的配置與運行和發布。但是本次畢業設計主要為了研究推薦算法的實現以及相關業務，用戶基數少，再加上想隨着版本的迭代，大數據組件已經支持在Windows操作環境系統中安裝配置。雖然相比較而言在Windows上配置環境比Linux更加繁瑣，但是對於國內更習慣Windows的用戶來說這是一種新的探索，方便他人借鑒和參考。
6.3推薦系統實現中遇到的問題及解決方法總結
6.3.1命名規范
在本次系統代碼編寫過程中，有些類屬性代碼不規范，導致后續排查錯誤耗費時間較久，所以在編寫任何代碼時都要嚴格按照規范進行開發，避免后續維護或者二次開發碰到因代不規范而導致的問題，這類問題一般較難發現，並非邏輯錯誤，排查非常耗時。我們應養成規范編碼的好習慣！
6.3.2 Windows與Linux命令不兼容問題
本次系統創新的部署在Windows環境下，雖然大部分組件都支持在Windows環境下運行，但是windows和Linux存在本質區別；命令的啟動方式以及參數的位置都需要注意，尤其是Flume-ng啟動時，不僅要調整參數位置，更重要的是啟動命令中包含“-tail”指令，這個指令是在Linux的內置shell指令，在Windows中並不能被識別，這是就要在Windows本地函數文件中添加一個可執行文件，使操作系統可以識別到這個命令並且正常運行。
6.3.3 Kafka 異常退出
在Windows下啟動kafka產生的offset文件在關閉kafka后並不會自動刪除，如果想重啟kafka，系統不會把上次的本地文件自動刪除。需要手動刪除，否則會啟動異常。
6.4推薦系統的不足之處
在本次畢業設計中，也有許多不足的地方。例如樣本的數據不夠特別全，並不是一個完整的成熟的電商商品數據庫，等待筆者自己提升技術能力后加以完善等。
6.4.1更准確的推薦算法
迄今為止沒有任何一個推薦算法能滿足用戶全體的興趣愛好，也就是說推薦系統存在就必然會存在的問題：提升推薦准確度。推薦算法不可能做到符合每個人的興趣，這正如一句話所說：“一千個人眼中就會有一千個哈姆雷特”[20]。每個人都有各自的看法和觀點。做到完全符合每位用戶的喜好，這是推薦系統發展的最終極目標。是推動推薦系統發展的動力源頭。
6.4.2更高效的實時計算框架
Flink框架摒棄了批處理的思想，可以達到比spark更高的實時要求。由於我現在能力有限，畢業設計采取現學習資源比較成熟的spark。
6.4.3 單機模式下的風險
我們知道在當數據量級變大時，必要的數據冗余是保證節點在遇到宕機等突發情況下恢復正常的保證。只存在一個單一節點在部署上線后，再服務器掛掉后容易發生數據的丟失。所以正式部署上線后，數據的復制是很有必要的需要將數據定時同步到其他多個節點。確保在某個機器宕機后數據不丟失。
6.4.4用戶畫像（Profile）
當下的主流電商系統都在構建用戶畫像，通過數據建立描繪用戶的標簽。逐漸把用戶畫像運用在推薦系統中，只要用戶畫像畫的夠准，那么推薦的准度就會更高。所以接下來的研究趨勢可以適當加入用戶畫像的構建[21]，從而更加提升推薦系統的綜合准確度。
供網友參考借鑒。
論文主要是理論知識的沉淀，系統實現則是對動手能力的考驗！
希望這篇文章可以幫助到需要的畢業生。如果還有疑問或者不懂得可以聯系作者，工作之余會幫助你們解決系統問題。
（2.3）
------------恢復內容結束------------