一直以為在
mahout
的在分布式上做了很多東西，很高深。最近一段時間由於工作中要實現一些分布式演算法，所以硬著頭皮看了一下它的原始碼。當時我匆忙的看過
kmeans
的實現，這次我的工作是在搜尋引擎日誌記錄中找相似
query
。我是按照
query
以及它對應的點選商品來進行相似
query
匹配的，其實就是乙個協同推薦問題。
開始時，我實現了乙個單機版的演算法，每個
query
對整個query
集合進行相似度計算，這相當於乙個笛卡爾積的計算。在獨立
query
較小的情況下，這個計算了還可以接受，但是一旦
query
的量表達，例如
10w級別，單機就無法容忍了。
所以很有必要把這個計算搬到
hadoop
上來做。於是我就分析了一下
mahout taste
部分的原始碼。分享下來。
taste
提交job
的流程：
1. 獲得
job處理所需要的樣本資訊；推薦引擎定義的有幾種檔案格式，有從資料庫讀取，有從檔案系統裡讀取，我覺得從檔案系統裡最方便，可能是我現在使用
hadoop
的緣故吧。不同的資料**會由不同的
datamodel
來進行資料讀取。例如檔案系統的是
filedatamodel
，檔案系統內的檔案格式是
userid itemid value,
中間通過」\t
」或者」,
」進行分割。資料庫系統的讀取也是通過指定
userid itemid value
相對於的資料表字段就可以了。這些熟悉
taste
的人應該都了解。
2. 獲取需要得到相似物件的
userid
佇列，這個佇列應該是每行乙個使用者
id3.
4. 在本地構建乙個推薦引擎
5. 對
map中的每乙個
userid
，通過推薦引擎給其推薦相似物件
看到這個流程後，大家也就明白了，所謂的分布式，其實只是對需要計算相似物件的userid進行了分布運算而已，而計算相似度的本身還是在本地構建推薦引擎，然後計算。
這裡最要注意的問題是，這個userids列表，我們一定不要再map中就直接做計算，因為預設的通過textfileformat中，hadoop按照檔案的大小來劃分map，所以如果在map做計算的話，很有可能所有的userid尋找相似物件的工作都在乙個map或者少量的幾個map中做了（筆者就犯了這個錯誤，結果map就啟動了兩個，計算速度並沒有比單機快多少）。
具體解決辦法由兩種
1.在map端，使用nlinefileformat對userids進行切割，這樣乙個列表就可以劃分到多個map中了；
2.在reduce端，如果我們在map端不做任何工作，僅僅是將userids輸出到reduce中，這時通過對userid的hash，userids這個列表就會被劃分到多個reduce中了，那麼計算的速度自然就提高了。
筆者在對10萬的記錄做笛卡爾積時，1g記憶體，cpu不詳（公司的機器應該也不差）。幾個小時下來也不能結束。將計算搬到hadoop上，通過第二種方案，計算時間被壓縮到了10分鐘以內。
推薦引擎分類介紹
搜尋引擎是當前快速查詢目標資訊的最好途徑。在使用者對自己需求很明確時，用搜尋引擎可以方便地通過關鍵字快速找到自己需要的資訊。但搜尋引擎並不能完全滿足使用者對資訊發現的需求，因為在很多情況下，使用者其實並不明確自己的需要，或者他們的需求很難用簡單的關鍵字來表述，又或者他們需要更加符合他們個人口味和喜好...
mahout的推薦引擎Taste的學習筆記（一）
mahout中的乙個模組taste實現了推薦引擎的功能，到網上查了一下資料，都沒有任何taste原始碼分析，只有自己看一看 了，能記的就記錄下來，以後用到的時候就方便了。推薦引擎的原理是協同過濾 collaborative filtering,簡稱 cf 下邊就用這個縮寫了。1 基於使用者的cf 基...
推薦引擎分為哪幾類，個性化推薦引擎的介紹
在資訊時代的今天，大資料為使用者獲取方方面面的資訊提高了效率，更可以智慧型的幫助使用者從海量內容中快速找到想要閱讀的資訊，或者從海量商品中快速找到想要購買的商品。推薦引擎的發展讓選擇不明確的使用者更加了解她們的需求和喜好。下面以內容產品和電商產品為例，談談推薦引擎在產品中發揮的巨大作用。一 推薦引擎...