我們都知道，大多數的推薦算法都是單機版的。如果不進行任何處理是不能夠分佈式執行，也就不能充分利用像hadoop這樣的分佈式計算集羣。這嚴重限制了
推薦算法的實際應用。比如協同過濾，像亞馬遜、天貓這些包含大量用戶、大量物品及大量行爲的平臺，用戶-物品矩陣巨大。要實現協同過濾，時間複雜度不說，就是存儲，單機的也沒法
搞定。所以，實現分佈式的推薦算法，充分利用集羣的資源就變得非常的必要。
在我們自己的推薦算法實踐過程中，已經，並且將來會更加頻繁的遇到推薦算法的可擴展性問題。因此，決定對擴展性這塊系統的研究一下。本篇主要是關於採用hadoop來解決擴展性問題。後面會補充“MF篇”等。
首先，講下如何在hadoop上實現基於用戶的協同過濾算法。詳細可以參考文獻[1]。
如何實現一個能在hadoop上執行的協同過濾算法，也就是算法要能拆分成map-reduce形式的計算模塊。具體做法分爲以下三步：
1、數據拆分階段
將用戶分組到不同的文件中。每個文件的每行對應一個用戶的id。
數據拆分要滿足兩個原則：
1）在整個的運行時間上，計算時間的佔比要越大越好。意思就是運行時間的大多數耗在計算上，而不是頻繁的初始化mapper上。
比如，如果我們針對1000個用戶創建1000個mapper，就需要頻繁初始化mapper這樣不如創建40或者50個要好。
2）所有task的執行完成時間相同。
2、Map階段
mapper的setup函數首先會創建用戶-物品評分矩陣，然後讀取user ID文件，文件的行號爲輸入的key，對應的user ID爲value。
然後計算用戶間相似度–>找到用戶的最近鄰–>預測用戶對所有物品的評分。最後按評分排序得到用戶id及其推薦列表作爲中間key/value,將其
作爲reduce階段的輸入。
3、Reduce階段
reducer根據userID排序，並將最終的結果輸出到hdfs。
整個流程如下圖所示：
參考文獻【2】：
Sales–>Rate transform
將銷售數據轉換成推薦系統中的評分數據
兩種轉換方式：
方式1：
Sui爲商店u對物品i的銷售量
方式2：
Sales<–Rate transform
對應 Sales–>Rate transform的兩種方式：
方式1：
方式2：
當推薦（協同過濾）完成後，又需要將評分數據轉換爲實際銷售數據
如下圖：
整個推薦算法在mapreduce上執行的流程：
