我使用Spark構建推薦系統原型。閱讀完一些教程後，我可以從我的數據中培訓MatrixFactorizationModel。Spark - 如何在生產中使用受過訓練的推薦人模型？
但是，由Spark mllib培訓的模型只是Serializable。我如何使用這個模型來爲真實用戶提供建議？我的意思是，如何將模型持久化到某種數據庫中，或者在用戶數據增加後更新它？
例如，Mahout推薦庫培訓的模型可以像Redis一樣存儲到數據庫中，之後我們可以查詢推薦的項目列表。但是我們如何在Spark中做類似的事情呢？任何建議？
首先，您從Mahout引用的「模型」不是模型，而是預先計算的推薦列表。您也可以使用Spark來完成此操作，併爲用戶批量推薦計算，並將其保留在您喜歡的任何位置。這與序列化模型無關。如果你不想做實時更新或評分，你可以在那裏停下來，就像你做Mahout一樣使用Spark進行批量處理。
但我同意在很多情況下，您確實希望將模型運送到其他地方並提供服務。如您所見，Spark中的其他型號爲Serializable，但不是MatrixFactorizationModel。 （是的，即使它被標記爲這樣，它也不會序列化）。同樣，對於稱爲PMML的預測模型有一個標準序列化，但它沒有包含因式矩陣模型的詞彙表。
原因實際上是一樣的。儘管許多預測模型（如支持向量機或邏輯迴歸模型）只是一小組係數，但分解矩陣模型非常龐大，包含兩個可能具有數十億個元素的矩陣。這就是爲什麼我認爲PMML沒有任何合理的編碼。
同樣，在Spark中，這意味着實際的矩陣是不能直接序列化的RDD。您可以將這些RDD保存到存儲中，使用Spark在其他地方重新讀取它們，然後手動重新創建MatrixFactorizationModel。
儘管您不能使用Spark來提供或更新模型。爲此，您真的在編寫一些代碼來執行更新並計算推薦。
我不介意在這裏建議Oryx項目，因爲它的重點在於管理這方面，尤其是對於ALS建議。實際上，Oryx 2項目基於Spark，雖然在alpha中已經包含完整的管道，用於序列化並提供MatrixFactorizationModel的輸出。我不知道它是否符合您的需求，但至少可以成爲一個有趣的參考點。
用Spark創建recs的另一種方法是搜索引擎方法。這基本上是由Solr或Elasticsearch服務的共同推薦人。將分解因子化和共生現象進行比較已經超出了這個問題，所以我只會描述後者。
您將交互（user-id，item-id）引入Mahout的spark-itemsimilarity。這會爲交互數據中看到的每個項目生成一個類似項目的列表。它會默認爲csv，因此可以存儲在任何地方。但它需要被搜索引擎索引。
在任何情況下，當您要抓取recs時，將用戶的歷史記錄用作查詢，您將得到一個有序的物品列表作爲recs。這種方法的
一個好處是，指標可爲儘可能多的用戶動作來計算，只要你想。可以使用用戶採取的任何與您想推薦的操作相關的操作。例如，如果您想推薦購買產品，但也需要記錄產品視圖。如果您將產品視圖視爲與購買相同，那麼您可能會變得更糟糕（我嘗試過）。但是，如果您計算購買指標並且爲產品視圖指定另一個（實際上是交叉一致的）指標，則它們同樣可以預測購買。這會增加用於recs的數據。用戶位置可以完成相同類型的事情，以將位置信息融入購買記錄。
您也可以根據上下文偏置的區域經濟共同體。如果您處於目錄的「電子」部分，則可能需要向電子設備傾斜。針對該項目的「類別」元數據字段向查詢添加電子元件，並在查詢中提升它，並且您有偏見。
由於所有的偏置和指標混合發生在它使得容易調諧到多個上下文，同時保持僅一個通過搜索引擎由多字段的查詢的倫理委員會引擎查詢。我們從Solr或Elasticsearch獲得可伸縮性。
分解或搜索方法的另一個好處是可以使用全新的用戶和新的歷史記錄來創建舊版Mahout推薦程序只能向用戶推薦的信息以及在作業運行時已知的交互。
說明這裏：
您應該運行模式。 predictAll（）也縮小到RDD組（用戶，產品）對像亨利馬烏Hadoop的工作和存儲網絡使用的結果...
可以使用函數.save（sparkContext，outputFolder）將模型保存到您選擇的文件夾。同時給予實時的建議，你只需要使用MatrixFactorizationModel.load（sparkContext，modelFolder）函數將其加載爲MatrixFactorizationModel對象。
到@Sean一個問題歐文：不將MatrixFactorizationObject含有分解矩陣：用戶特徵和項目特徵矩陣，而不是建議/預測評級。
感謝您的優秀和詳細的解釋！我會嘗試Oryx :) – shihpeng