百分點個性化推薦引擎的學習

一、百分點的主要特點

1、用戶全網興趣偏好平臺

滿足針對用戶全網興趣偏好進行精準分析，打通用戶在多個網站的興趣偏好。

個人點評：全網數據指的是所有目前與其合作的網站的的數據，從目前合作的規模看，目前與百分點合作的大型網站沒有幾個，其他的都是些冷門的網站。對于一些大型網站，處于商業信息的保密，基本上不會將此部分數據與其他網站共享。

</blockquote>

2、互聯網用戶的興趣圖譜

瀏覽和收藏代表用戶的偏好，購買行為則最貼近用戶的真實需求，通常在互聯網上完成購買行為越多的用戶，他的興趣展示越充分。

3、海量消費偏好挖掘能力

在群體智慧與復雜網絡領域的多年耕耘讓百分點科技擁有海量消費偏好挖掘能力，確保每次送達的精準性和時效性。

個人點評：以上信息均為百分點公司商業介紹資料，具體算法是什么，具體效果有多少不得而知。

</blockquote>

二、N年前的百分點

以下資料來自百分點2010年公開下載的文檔。

百分點推薦引擎提供了三項基于客戶的個性化推薦和四項常規推薦。

三項個性化推薦包括：

1. 基于顧客購物車的推薦
2. 基于顧客瀏覽歷史的推薦
3. 基于顧客購買歷史的推薦
</ol>

四項常規推薦包括：

1. 瀏覽過本商品的顧客還瀏覽過什么
2. 購買過本商品的顧客還購買了什么
3. 瀏覽過本商品的顧客最終購買了什么
4. 經常與本商品一起購買的商品是什么
</ol>

個人點評：三項個性化推薦為數據來源，對于普通的網站來說基本上都能實現。四項常規推薦中第一、第二點在先前的文章中已經介紹過了。推薦系統之Also Buy和Also View的實現。第三種情況為決策性推薦，和第四種組合推薦在技術是實現上也沒有難度。

</blockquote>

三、百分點的前端實現

有兩種方法可以幫助您在購物頁面上嵌入百分點推薦引擎的推薦欄：

1、基于JavaScript 的實現方式，需要在多個頁面中 嵌入百分點的JavaScript 代碼：

①通過“產品展示頁面”上傳商品信息和發送推薦請求；

②通過“購買確認頁面”上傳商品購買記錄。

2. 直接調用webservice 接口，詳情請參見API 文檔 購物網站需要上傳商品信息（比如商品 ID，商品名稱，商品價格，商品鏈接等信息） 到百分點服務器。

個人評價：百分點在做跨瀏覽器、跨站時采用了Flash Cooike技術，這點可以學習，具體Flash Cookie的介紹如下:
用戶數據跟蹤之Flash Cookies

</blockquote>

四、百分點的系統架構

1、百分點需要實現的需求

• 科學高效的推薦算法，并且根據網站特點選擇最佳的推薦算法和推薦策略；
• 根據用戶的全網行為分析他們的潛在偏好，幫助網站實現站內站外精準營銷；
• 根據全網的商品和資訊信息分析各種內容之間的相關度，幫助網站優化站外流量導入工作。
</ul>

2、百分點需要解決的技術要求

• 支持各種推薦算法和科學衡量指標。研究人員們已經提出了數百種推薦算法以及相應的標準數據集和推薦效果衡量指標，百分點推薦引擎必須足夠靈活以便能夠支持這些算法。明確每種算法在各個數據集上的性能指標，以便為具體需求選擇合適的推薦算法。
• 大數據處理。面對全網資源和用戶行為，如何安全可靠的存儲和分析這些數據是非常關鍵的。最低要求是每天能夠處理1億級別的數據輸入和推薦請求，并且保證數據絕對安全。分布式和云服務是唯一的選擇。
• 高可用性和實時性。作為一個Web Service提供商，提供穩定可靠低延時的服務是基本要求，從用戶體驗角度出發，要求每個推薦請求都能在2ms內處理完成。
• 可擴展性。這是所有計算機系統的普遍需求，我們要求百分點推薦引擎可以很方便的添加各種新的推薦邏輯，提供新的推薦服務。并且當整個系統需要升級擴容的時候，人力和硬件成本是線性可控的。
• 便于管理。運維是Web Service的重頭戲，我們要求百分點推薦引擎中的各個部件（或邏輯單元）都是獨立可拆卸可替換的，每個部件都要有完善的容災備份恢復機制，這樣整個系統的管理工作逐步細分，有利于分工協作。
</ul>

3、百分點架構圖



百分點推薦引擎可以分為存儲層，業務層，算法層和管理層四大功能組件。每個組件內部又可以細分為更小的單元，或者服務模塊，提供基本的存儲或運算服 務。單元與單元之間盡量解耦和，僅通過API協議進行協作，這樣一個單元的升級變動帶來的影響是可控的。每個單元都要做到可靠可用。

存儲層

存儲層提供基本的數據存取服務，并做好備份和災難恢復工作，以保證數據的安全可靠。根據不同的應用需求，存儲層細分為Redis集群，Membase集群，MySQL集群和Hadoop/HDFS四類。

• Redis集群。百分點推薦引擎采用了Redis作為緩存，用于存儲熱門數據，包括資源（商品或者咨詢）ID，名稱，鏈接，圖片，分類，品牌等。 這些信息數量不算非常多，但是使用頻率非常高，基本上我們的每次推薦都要用到數十甚至數百個商品信息。之所以選用Redis，我們看重的是它的速度，持久 化和以及主從機制。目前，我們使用Redis的方式是一個Master帶若干個Slaves以便實現讀寫分離，Master只負責寫，Slaves只負責 讀，其中兩個Slave有序列化機制，并且必定有兩個Slave在不同的機器上以消除單點故障隱患。
• Membase集群。Membase在百分點推薦引擎中扮演了主存的角色，主要用于支持百分點推薦引擎的計算。目前，百分點推薦引擎包含了大大小 小十多個在線和離線計算模塊，這些模塊計算過程中需要用到很多數據，并產生以及大量的中間結果，包括用戶在各個網站的行為歷史，資源之間的關系等等。這些 數據的特點是不需要Schema，數量多，但絕大多的使用頻率很低。之所以選用Membase，主要原因是因為它可以很方便的進行橫向擴展以及有豐富的 Client API支持。
• MySQL集群。在百分點推薦引擎的最初階段，我們賦予MySQL的主要任務是存儲所有客戶的原始數據（包括用戶行為，推薦請求及推薦結果等）以 作備份之用，并在后期統計推薦效果。但很快我們就發現MySQL數據庫變得極其龐大，以至于每周都需要對其進行壓縮備份和切割，運維工作量太大。現在，我 們已經將數據備份和后期統計工作轉移到了Hadoop/HDFS平臺，只在MySQL中存儲最終的統計數據以及其他客戶配置信息等小規模的數據。由于 MySQL的任務量不重，我們僅對其做了雙機熱備以避免單機崩潰造成無法繼續服務。
• Hadoop/HDFS。正如前面所說，目前我們使用Hadoop/HDFS來存儲客戶的原始數據，并在其上做一些統計處理。另外，百分點也在計 劃將一些離線算法和數據轉移到Hadoop平臺上以便發揮Hadoop的潛力。Hadoop的NameNode存在單點故障隱患，為此建立了一個備份的 NameNode，并在主服務器出現問題時將服務切換至備份服務器上。
</ul>

算法層

這是百分點推薦引擎最核心也是最具挑戰性的部分，百分數將這一層設計為一系列抽象算法的集合。通過深入研究了學術界在基于用戶行為的推薦算法，基于 內容的推薦算法和關聯規則等多方面的理論知識，在此之上自主研發了十多種適用于大數據處理的在線和離線推薦算法。目前，在線算法包括協同過濾 （UserBased/ItemBased CF），基于內容的推薦（Content Based），熱擴散（Heat Diffusion），用戶行為模式分析（Behavior PatterAnalysis）等等。離線算法包括KNN聚類，基于FP Tree的關聯規則挖掘，基于上下文統計的關聯規則挖掘，序列模式算法，文檔建模算法等等。

算法層并不關心具體的業務邏輯，而只負責數據處理和結果返回。以熱擴散算法為例，一方面它接受（用戶，資源，偏好指數）的三元組作為計算輸入，實時計算用戶與用戶/資源之間的關系；另外，也可以向它請求某個用戶對哪些資源最感興趣，或者某個資源與哪些資源最相關。

將業務邏輯和推薦算法本身剝離這樣的設計方式使得推薦算法具有了最大的通用性，也保證了前端的推薦功能模塊可以根據邏輯需求綜合多個算法。以百分點推薦引擎的“基于瀏覽歷史的個性化推薦”為例，它就使用到了熱擴散和基于內容的推薦兩種算法。

得益于存儲和算法的分離，算法層并不需要考慮數據的備份容災等問題。這樣，如果某個算法模塊由于服務器故障出現異常，可以很快在另外的服務器上啟動同一個它的一個備份來替換它，而不涉及任何數據遷移問題，最大限度滿足了可用性。

業務層

這是百分點推薦引擎中直接面對客戶的部分，也就是HTTP Web Service，它主要負責兩件事：收集客戶提交的數據，并將其轉換為各個推薦算法需要的輸入數據，交由推薦算法計算；根據客戶提交的推薦請求，向一個或 幾個推薦算法請求數據，并轉換為客戶需要的數據格式。可以看出，業務層起到了連接具體需求與推薦算法，真實世界與計算機世界之間的作用。

以“購買過該商品的用戶還購買過哪些商品”為例來簡介這個推薦功能模塊是如何溝通客戶需求和推薦算法。目前主要采用熱擴散算法來實現這個推薦功能模 塊。首先，客戶提交購買數據時，百分點推薦引擎會根據一定的業務邏輯將這個事件處理為算法可以接受的三元組。例如用戶U購買了商品K，我們可能會向算法發 送一個輸入數據(U, K, 1.0)。其次，當客戶請求買過K的用戶還買過哪些商品時，我們一方面以K作為參數向算法請求與K最相近的資源；另一方面如果客戶提交了用戶ID，我們還 會向算法請求該用戶可能感興趣的商品；最后我們將兩個結果加權整合，挑選其中權重最大同時滿足客戶額外需求（例如過濾用戶的購買歷史，按照商品類別/價格 過濾等）的幾個商品作為最終推薦結果。

可見，業務層完全將推薦算法作為黑盒子來使用，這樣業務層就可以集中注意力滿足客戶多種多樣的需求。另外，同算法層一樣，業務層也無須關心數據的存儲備份和容災。

管理層

在百分點推薦引擎中，管理層負責內部DNS，配置管理，服務部署，服務監控和自動應急處理。

• 內部DNS是實現高可用性的重要環節。百分點推薦引擎的各個組件都是通過內部域名訪問其他服務的，所有服務器的主次DNS也都設置成了內部DNS。這樣，當有關鍵的服務器，例如Hadoop的NameNode，出現故障時，我們可以通過修改域名對應的IP保證服務不間斷。
• 配置管理。這個模塊的主要功能是實現配置的自動化更新和通知。曾經考慮過用Zookeeper來實現這一功能，但后來覺得Zookeeper太過 重型，于是自己根據自己的需求開發了一個配置管理服務。百分點推薦引擎的內部服務可以將自己注冊在配置管理的某個項目下，在改配置項變動時，配置管理模塊 會通知該服務以便其獲得最新的配置信息。
• 服務監控。這個模塊主要用于監控服務器的健康狀況，各個進程是否能夠正常提供服務，并在出現異常情況時執行短信報警和觸發自動應急處理。我們的方法包括：

  • 通過top，ps，free等一些基本工具來查看系統負載以及各個進程是否存活，CPU，Memroy等資源占用情況。利用redis-cli，memstats等特定工具來查看Redis，Membase的運行狀況。
  • 對于自主開發的程序，我們都要求提供一個可供測試的調用，這個調用可以走完主要的服務流程，并返回執行流程中是否出現異常，例如配置項設置錯誤，執行流程超時等等。
  • 我們會對各個服務輸出的LOG進行分析，找出異常狀況。例如短期內出現大量EXCEPTION或者ERROR，請求處理時間超長，大量推薦請求得不到結果等等。
  • 監控模塊一旦檢測到異常情況，會立即短信通知我們的運維人員，并通知自動應急處理模塊嘗試修復異常。
  • 自動應急處理。我們在自動應急模塊中實現了修改DNS配置，啟動/停止業務層服務程序和推薦算法的功能。舉個例子，當MySQL主服務器宕機時， 自動應急模塊會收到來自監控模塊的通知，而后它會嘗試修改將主從DNS中的MySQL服務器域名修改為MySQL從服務器的IP；又或者如果自動應急模塊 收到監控模塊的通知說業務層某個服務進程在連續的1分鐘內一直占用了100%的CPU，應急模塊會將它kill掉并重新啟動，因為很可能是該進程出現異常 了。
  </ul> </li> </ul>

  參考文章：http://www.infoq.com/cn/articles/baifendian-recommendation-engine

  </div> 來自：http://www.biaodianfu.com/baifendian.html