如何從零構建實時的個性化推薦系統?
作者:Jon Natkins
現在網上到處都有推薦。亞馬遜等主流電子商務網站根據它們的頁面屬性以各種形式向用戶推薦產品。Mint.com之類的財務規劃網站為用戶提供很多建議,比如向用戶推薦他們可能想要辦理的信用卡,可以提供更好利率的銀行。谷歌根據用戶搜索歷史記錄的信息優化搜索結果,找到相關性更高的結果。
這些知名公司使用推薦提供情境化的、有相關性的用戶體驗,以提高轉化率和用戶滿意度。這些建議原來一般由每天晚上、每周或每月生成新推薦的批處理作業計算提供。
然而對于某些類型的推薦,響應時間有必要比批量處理作業所需的時間更短,比如為消費者提供基于地理位置的推薦。比如電影推薦系統,若用戶先前看過動作片,但現在要找一部喜劇片,批量推薦很可能會給出更多動作片,而不是最相關的喜劇片。本文將會介紹如何使用Kiji框架,它是一個用來構建大數據應用和實時推薦系統的開源框架。
Kiji,以實體為中心數據和360度視角
要構建實時推薦系統,首先需要一個能存儲360視角客戶的系統。此外,我們需要具備迅速獲取與指定用戶相關數據的能力,以便在用戶與網站和移動應用交互時做出推薦。 Kiji是一個構建實時應用的模塊化開源框架,它收集,存儲和分析這類數據。
一般情況下,一個360度視圖所需的數據可以被稱為以實體為中心的數據。一個實體可以是任意數量的東西,比如客戶、用戶、帳戶,或者POS系統或移動設備之類更抽象的東西。
一個以實體為中心的存儲系統要能在一行數據中存儲與某個特定實體有關的一切信息。這對傳統的關系型數據庫來說是個挑戰,因為這些信息可能既有狀態型數據(如姓名,電子郵件地址等)又有事件流(如點擊)。傳統的系統需要把這些數據存放在多張表中,處理時再把這些表聯接起來,這使得它很難做到實時處理。為了解決這個問題,Kiji用了Apache HBase,它在四個維度 – 行、列族、列標識和時間戳-存儲數據。借助時間戳維度和HBase存儲多個版本Cell的能力,Kiji能夠存儲有更多狀態的緩慢變化的事件流數據。

開發用在實時中的模型
Kiji為開發模型提供了兩套API,Java和Scala,兩套API都支持批量和實時組件。如此劃分的目的是將模型執行劃分為不同階段。批量階段是訓練階段,是一個典型的學習過程,在該過程中,將使用完整的數據集來訓練模型。該階段的輸出可能是線性分類器的參數,或者聚類算法的群集位置,或在協同過濾系統中相互關聯條目的相似性矩陣。實時階段被稱為評分階段,取得經過訓練的模型,并將它與實體數據相結合產生衍生信息。關鍵是這些衍生數據被當作一等公民,也就是說它可以存回到實體所在的行中,用于推薦,或作為后續計算的輸入。
Java API被稱為KijiMR, 而Scala API構成了KijiExpress工具的核心。 KijiExpress利用Scalding庫提供API來構建復雜的MapReduce工作流,同時避免了大量Java冗余代碼,以及串聯MapReduce作業所必需的任務調度和協作。
個體與總體
之所以要劃分出批量訓練和實時評分兩個階段,是因為Kiji觀察到總體趨勢變化緩慢,而個體趨勢的變化迅速。
比如一個包含上千萬次購買記錄的用戶總體數據集。多一次購買不太可能對總體趨勢的好惡造成重大影響。但對于一個只有10次購買記錄的特定用戶而言,第11次購買將對系統判斷用戶興趣產生巨大影響。鑒于這種主張,應用程序只需在收集到足以影響總體趨勢的數據時再重新訓練它的模型。但對于特定用戶而言,我們可以通過實時響應用戶的行為來改善推薦的相關性。
實時給模型評分
為了做到實時評分,KijiScoring模塊提供了一個惰性計算系統,應用程序可以只為經常與其交互的活躍用戶生成最新推薦。通過惰性計算,Kiji應用程序不必為那些不經常光顧或再沒回來過的用戶生成推薦。這還有些額外的好處,Kiji可以在推薦時考慮像移動設備的位置之類的情境信息。
KijiScoring的主要組件叫Freshener。Freshener實際上是另外兩個Kiji組件的組合:ScoringFunctions和FreshnessPolicies。正如前面提到的,一個模型包括訓練和評分兩個階段。ScoringFunction是一段代碼,描述了如何把經過訓練的模型和單一實體的數據組合起來產生一個分數或建議。FreshnessPolicy定義數據變得陳舊或過時的時間。比如說,普通的FreshnessPolicy會指出超過一個小時后數據就過期了。更復雜的策略可能會在實體經歷過一定次數的事件后將其標記為過期,比如點擊或產品訪問等事件。最后,ScoringFunction和FreshnessPolicy被附著在Kiji表中特定的列上,在必要時被觸發來刷新數據。

一個典型的Kiji應用程序將包括一定數量的KijiScoring服務器,它們是可以向外擴展的無狀態Java進程,并能夠運行使用單一實體的數據作為輸入的ScoringFunction。Kiji應用程序通過KijiScoring服務器過濾客戶端請求,由它決定數據是否是最新的。若有必要,它會在把所有推薦傳回客戶端之前運行ScoringFunction進行刷新,并將重算后的數據寫到HBase中,以備后用。
將模型部署到生產系統中
能夠輕松迭代其底層的預測模型是實時推薦系統的一個重要目標,避免因為要將新的或改進過的模型部署到生產環境而停掉應用程序。Kiji為此提供了Kiji模型庫,它結合了描述模型以及用來訓練模型和給模型評分的代碼如何執行的元數據。KijiScoring服務器需要知道什么樣的列訪問會觸發刷新,要用的FreshnessPolicy,以及將在用戶數據上執行的ScoringFunction,以及所有經過訓練的模型的位置,或給模型評分所必需的外部數據。元數據也存在一個Kiji系統表中,只是另一種最底層的HBase表。此外,模型庫在受管的Maven庫中為已注冊的模型存儲代碼工件。KijiScoring服務器為新登記或未登記模型定期輪詢模型庫,按需加載或卸載代碼。
整合到一起
使用協同過濾是一種非常常用的推薦提供方式。協同過濾算法通常會建立一個大型的相似矩陣,用來存放一個產品跟產品目錄中其它產品的關聯信息。矩陣中的每一行代表一個產品Pi,每一列代表另一種產品Pj。(Pi,Pj)中的值就是兩個產品之間的相似度。


既然我們在評分階段之前已經做了很多繁重的工作,那么評分自然成了一種相當簡單的操作。如果我們想基于被查看的條目展示推薦信息,一個通用的評分函數只是從產品表中查找相關產品,并顯示它們。
將該過程再推進一點并對結果做個性化處理是一個相對簡單的任務。在個性化系統中,評分函數將會取得用戶最近對產品的評級,并使用KeyValueStore API查找與用戶評價過的產品相似的產品。結合評級和存儲在產品表中的產品相似度,應用程序可以預測用戶給相關條目下的評級,并將預測評級最高的產品推薦給用戶。通過限制所用評級和所有已評級的相似產品的數量,系統在用戶與應用程序進行交互時可以很輕松地處理上述操作。

結論
在本文中,我們可以了解到如何用Kiji開發一個可以實時刷新推薦的推薦系統。利用HBase進行低延遲處理,用Avro存儲復雜的數據類型,使用MapReduce和Scalding處理數據,應用程序能夠在實時情境中給用戶提供相關推薦。
轉載請注明來自36大數據(36dsj.com):36大數據 ? 如何從零構建實時的個性化推薦系統?