概要:mysql
隨着電子商務的高速發展和普及應用,個性化推薦的推薦系統已成爲一個重要研究領域。
個性化推薦算法是推薦系統中最核心的技術,在很大程度上決定了電子商務推薦系統性能的優劣,決定着是否可以推薦用戶真正感興趣的信息,而面對用戶的不斷提高的需求,推薦系統不只須要正確的推薦,還要實時地根據用戶的行爲進行分析並推薦最新的 結果。
實時推薦系統的任務就是爲每一個用戶,不斷地、精準地推送個性化的服務,甚至到達讓用戶體會到推薦系統比他們更瞭解本身的感受。linux
本文主要研究的是基於模型的協同過濾算法—ALS以及實時推薦系統的可行性並詳細講解ALS(交替最小二乘法)的思想
而後在Spark Streaming框架上運用ALS算法進行測試,評估實時推薦中算法的可靠性
最後,在Spark Mllib和Streaming框架上構建了實時推薦引擎,將推薦數據保存在Hbase中,WebApp經過讀取Hbase中的推薦數據來向用戶展現推薦結果web
關於其餘類別的推薦算法就不細說了,網上有不少的資料查看,推薦幾篇文章:
IBM-探索推薦引擎內部的祕密系列算法
以及向亮的《推薦系統實踐》
下載地址sql
下面進入正文數據庫
基於矩陣分解的協同過濾算法–ALS:編程
基於模型的協同過濾推薦就是基於樣本的用戶喜愛信息,訓練一個推薦模型,而後根據實時的用戶喜愛的信息進行預測,計算推薦。數組
對於一個users-products-rating的評分數據集,ALS會創建一個user*product的m*n的矩陣(其中,m爲users的數量,n爲products的數量),以下圖:緩存
這個矩陣的每一行表明一個用戶 (u1,u2,…,u9)、每一列表明一個產品 (v1,v2,…,v9)。用戶隔天產品的打分在 1-9 之間。
可是在這個數據集中,並非每一個用戶都對每一個產品進行過評分,因此這個矩陣每每是稀疏的,用戶i對產品j的評分每每是空的
ALS所作的事情就是將這個稀疏矩陣經過必定的規律填滿,這樣就能夠從矩陣中獲得任意一個user對任意一個product的評分,ALS填充的評分項也稱爲用戶i對產品j的預測得分
因此說,ALS算法的核心就是經過什麼樣子的規律來填滿(預測)這個稀疏矩陣
它是這麼作的:
假設m*n的評分矩陣R,能夠被近似分解成U*(V)T
U爲m*d的用戶特徵向量矩陣
V爲n*d的產品特徵向量矩陣((V)T表明V的轉置)
d爲user/product的特徵值的數量數據結構
關於d這個值的理解,大概能夠是這樣的:
對於每一個產品,能夠從d個角度進行評價,以電影爲例,能夠從主演,導演,特效,劇情4個角度來評價一部電影,那麼d就等於4
能夠認爲,每部電影在這4個角度上都有一個固定的基準評分值
例如《末日崩塌》這部電影是一個產品,它的特徵向量是由d個特徵值組成的
d=4,有4個特徵值,分別是主演,導演,特效,劇情
每一個特徵值的基準評分值分別爲(滿分爲1.0):
主演:0.9
導演:0.7
特效:0.8
劇情:0.6
矩陣V由n個product*d個特徵值組成
對於矩陣U,假設對於任意的用戶A,該用戶對一部電影的綜合評分和電影的特徵值存在必定的線性關係,即電影的綜合評分=(a1*d1+a2*d2+a3*d3+a4*d4)
其中a1-4爲用戶A的特徵值,d1-4爲以前所說的電影的特徵值
那麼對於以前ALS算法的這個假設
m*n的評分矩陣R,能夠被近似分解成U*(V)T
就是成立的,某個用戶對某個產品的評分能夠經過矩陣U某行和矩陣V(轉置)的某列相乘獲得
那麼如今的問題是,如何肯定用戶和產品的特徵值?(以前僅僅是舉例子,實際中這兩個都是未知的變量)
採用的是交替的最小二乘法
在上面的公式中,a表示評分數據集中用戶i對產品j的真實評分,另一部分表示用戶i的特徵向量(轉置)*產品j的特徵向量(這裏能夠獲得預測的i對j的評分)
用真實評分減去預測評分而後求平方,對下一個用戶,下一個產品進行相同的計算,將全部結果累加起來(其中,數據集構成的矩陣是存在大量的空打分,並無實際的評分,解決的方法是就只看對已知打分的項)
可是這裏以前問題仍是存在,就是用戶和產品的特徵向量都是未知的,這個式子存在兩個未知變量
解決的辦法是交替的最小二乘法
首先對於上面的公式,如下面的形式顯示:
爲了防止過分擬合,加上正則化參數
首先用一個小於1的隨機數初始化V
根據公式(4)求U
此時就能夠獲得初始的UV矩陣了,計算上面說過的差平方和
根據計算獲得的U和公式(5),從新計算並覆蓋V,計算差平方和
反覆進行以上兩步的計算,直到差平方和小於一個預設的數,或者迭代次數知足要求則中止
取得最新的UV矩陣
則本來的稀疏矩陣R就能夠用R=U(V)T來表示了
ALS算法的核心就是將稀疏評分矩陣分解爲用戶特徵向量矩陣和產品特徵向量矩陣的乘積
交替使用最小二乘法逐步計算用戶/產品特徵向量,使得差平方和最小
經過用戶/產品特徵向量的矩陣來預測某個用戶對某個產品的評分
算法原理講述完畢,接下來進行算法測試
算法測試:
算法測試分爲兩部分:
1、測試最佳的參數,如:隱性因子個數,正則式等
2、測試在Streaming框架上算法的可用性
測試數據集來自MovieLens
測試一:
將整個數據集上傳至HDFS中
在spark程序中讀取ratings.dat文件,並隨機劃出80%做爲訓練數據集,20%做爲測試數據集
設置隱性因子、正則式參數列表(因爲物理機配置很差,集羣可以支持的最大迭代次數只有7次,在多就會內存溢出,因此這裏直接將迭代次數設置爲7)
對參數列表的全排列分別進行模型訓練,並計算MSE、RMSE
結果以下圖:
比較得出最佳的參數組合,之後的模型訓練參數都使用這個參數組合
測試二:
將本來的數據劃分爲三部分
trainingData-10k
testData-10k
剩下的爲streamData,做爲流數據實時發送
首先將trainingData、testData上傳到HDFS/data目錄下
在spark程序中讀取,並轉化爲RDD[Rating]類型
使用Streaming框架接受流數據,並進行在線模型訓練
每訓練一次就計算一次MSE和RMSE
對比模型的精準性有沒有提升
使用Scala讀取本地的streamData,經過Socket發送到spark程序中
結果以下圖:
隨着數據的不斷增長,模型的精準度在不斷的提升,因此實時的更新推薦模型是可行的
推薦系統整合:
總體流程圖:
首先用程序生成用戶和圖書數據,並隨機模擬用戶行爲數據,保存在Hbase中
在Hbase數據庫中包含了用戶表(4000個用戶),圖書表(5060本圖書)以及評分表(用戶對圖書的百萬條數據)
因爲對我的來講沒法獲得真實的商業性數據,故評分數據都是程序 模擬隨機生成的,包括實時發送的流數據,因此這可能會對整個系統的推薦結果帶來影響
另外,除了WebUI部分,其他的程序都是運行在Linux的Spark集羣上
原始數據經過一個程序不斷地向Hbase的評分表中寫入數據
模擬用戶在網站上的評分行爲
運行截圖:
其中,前300個用戶的行爲偏向於前600本圖書(計算機相關)
實時流數據將經過另一個程序發送Socket數據,模擬用戶當前在網站上的實時評分行爲
在最後使用用戶進行觀察測試時,程序將會只模擬這個用戶的評分行爲以便觀察推薦系統的實時性
首先推薦引擎會讀取Hbase中的評分數據
並使用算法測試時獲得的最佳參數組合來對其進行訓練
獲得初始的模型
使用這個模型對Hbase中全部用戶進行圖書推薦(取 top10)
並將推薦結果保存在Hbase中
以上階段爲系統初始化階段
運行截圖:
在系統初始化完成以後,開啓實時推薦引擎
接收不斷生成的用戶行爲數據,並和Hbase中的原始數據混合,訓練出新的模型,產生推薦結果保存
不斷地進行流數據的讀取、訓練和保存推薦結果,直至系統關閉或者無流數據產生
推薦引擎運行以下圖:
WebUI部分:
WebUI是由ASP.NET開發的一個簡單的B/S應用,經過Thrift和Linux中的Hbase交互 選擇使用一個用戶觀察系統的實時推薦性,此時流數據模擬程序只產生這個用戶的評分行爲 Spark與kafka整合之實時流計算機器學習實戰,源碼深度剖析,實時流處理,機器學習,數據分析視頻教程網盤下載Spark與kafka整合之實時流計算機器學習實戰,源碼深度剖析,實時流處理,機器學習,數據分析視頻教程網盤下載Spark與kafka整合之實時流計算機器學習實戰,源碼深度剖析,實時流處理,機器學習,數據分析視頻教程網盤下載Spark與kafka整合之實時流計算機器學習實戰,源碼深度剖析,實時流處理,機器學習,數據分析視頻教程網盤下載Spark與kafka整合之實時流計算機器學習實戰,源碼深度剖析,實時流處理,機器學習,數據分析視頻教程網盤下載Spark與kafka整合之實時流計算機器學習實戰,源碼深度剖析,實時流處理,機器學習,數據分析視頻教程網盤下載Spark與kafka整合之實時流計算機器學習實戰,源碼深度剖析,實時流處理,機器學習,數據分析視頻教程網盤下載Spark與kafka整合之實時流計算機器學習實戰,源碼深度剖析,實時流處理,機器學習,數據分析視頻教程網盤下載Spark與kafka整合之實時流計算機器學習實戰,源碼深度剖析,實時流處理,機器學習,數據分析視頻教程網盤下載Spark與kafka整合之實時流計算機器學習實戰,源碼深度剖析,實時流處理,機器學習,數據分析視頻教程網盤下載