百分點推薦引擎——從需求到架構

轉載自:http://www.infoq.com/cn/articles/baifendian-recommendation-engine 

百分點推薦引擎是國內領先的推薦技術平臺,專注於爲電子商務和資訊網站提供SaaS模式的個性化推薦服務,提高網站的整站轉化率和用戶黏度。本文將從電子商務網站的實際需求出發,介紹百分點推薦引擎架構設計和搭建。

 
當下,個性化時代的潮流勢不可擋,業界普遍意識到了推薦是網站的一項基本服務。但是,人們對推薦該如何來做,也就是推薦技術本身,還不甚瞭解。我們經常會遇到這樣的疑問:“購買過該商品的用戶還購買過哪些商品這種推薦,不是一個SQL語句就搞定了嗎?”其實不然,推薦技術遠遠不是這麼簡單。廣義上講,推薦技術屬於數據挖掘和機器學習範疇,這也意味着好的推薦服務依賴於科學的推薦算法和大量的學習數據。對於電子商務和資訊網站來講,想在推薦技術領域精耕細作,研發高端的推薦算法並應用到海量數據上是非常困難的。正是在這樣的背景下,百分點推薦引擎應運而生。在百分點推薦引擎產品的開發過程中,我們與麥包包、紅孩子、走秀網、耀點100等知名電子商務網站,以及天極網、億邦動力等知名媒體資訊類網站的技術部門進行了深入探討,從他們那裏得到了很多幫助與啓發。在與這些行業先鋒的交流中我們發現,有一些需求是行業共有的,比如推薦的實時性、高可用性。另外一些需求是行業性的,比如嬰幼兒用品的單品重複購買率比較高,但相同的包包的重複購買率就不算高。對於一位正在育兒的母親,我們可以給她重複推薦符合她們偏好的、相同的奶粉和尿片,但對於一位時尚的女孩,我們向她重複推薦相同的包包可能就不合適了。
 
經過廣泛的市場需求和交流,我們要求百分點推薦引擎能夠從方方面面支持客戶的市場營銷策略,概括的講主要包括:
 
科學高效的推薦算法,並且根據網站特點選擇最佳的推薦算法和推薦策略;
根據用戶的全網行爲分析他們的潛在偏好,幫助網站實現站內站外精準營銷;
根據全網的商品和資訊信息分析各種內容之間的相關度,幫助網站優化站外流量導入工作。
百分點推薦引擎面對的是全網的商品資訊信息以及用戶行爲,如何科學有效的利用這些數據爲電子商務和資訊網站提供豐富的推薦服務,滿足其推廣營銷目標,成爲了我們最大的技術挑戰。爲此我們對百分點推薦引擎提出了以下技術要求:
 
支持各種推薦算法和科學衡量指標。研究人員們已經提出了數百種推薦算法以及相應的標準數據集和推薦效果衡量指標,百分點推薦引擎必須足夠靈活以便能夠支持這些算法。而且我們要明確每種算法在各個數據集上的性能指標,以便爲具體需求選擇合適的推薦算法。
大數據處理。面對全網資源和用戶行爲,如何安全可靠的存儲和分析這些數據是非常關鍵的。我們的最低要求是每天能夠處理1億級別的數據輸入和推薦請求,並且保證數據絕對安全。顯然,分佈式和雲服務是我們唯一的選擇。
高可用性和實時性。作爲一個Web Service提供商,提供穩定可靠低延時的服務是基本要求,我們從用戶體驗角度出發,要求每個推薦請求都能在2ms內處理完成。
可擴展性。這是所有計算機系統的普遍需求,我們要求百分點推薦引擎可以很方便的添加各種新的推薦邏輯,提供新的推薦服務。並且當整個系統需要升級擴容的時候,人力和硬件成本是線性可控的。
便於管理。運維是Web Service的重頭戲,我們要求百分點推薦引擎中的各個部件(或邏輯單元)都是獨立可拆卸可替換的,每個部件都要有完善的容災備份恢復機制,這樣整個系統的管理工作逐步細分,有利於分工協作。
架構設計
 
根據上節提出的需求,我們將百分點推薦引擎設計爲一組雲服務的有機組合,如上圖,百分點推薦引擎可以分爲存儲層,業務層,算法層和管理層四大功能組件。每個組件內部又可以細分爲更小的單元,或者服務模塊,提供基本的存儲或運算服務。單元與單元之間儘量解耦和,僅通過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,並在主服務器出現問題時將服務切換至備份服務器上。
算法層
 
這是百分點推薦引擎最核心也是最具挑戰性的部分,我們將這一層設計爲一系列抽象算法的集合。我們深入研究了學術界在基於用戶行爲的推薦算法,基於內容的推薦算法和關聯規則等多方面的理論知識,在此之上自主研發了十多種適用於大數據處理的在線和離線推薦算法。目前,我們的在線算法包括協同過濾(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掉並重新啓動,因爲很可能是該進程出現異常了。
小結
本文較爲細緻的介紹了百分點推薦引擎的總體架構和功能劃分,不難看出,在整個架構設計中,我們一直堅持模塊化,低耦合,消除單點等原則,力求將百分點推薦引擎打造成擴展性和可靠性極佳的推薦技術平臺。經過近兩年的多個大中型電子商務合作網站的實踐檢驗,這套架構完全滿足了我們一開始提出的各項需求,而且在可見的未來內,它也足以勝任百分點推薦引擎的戰略規劃。這套架構在穩定性和靈活性等多方面體現了出了百分點推薦引擎團隊在推薦技術和服務上積極的努力耕耘和領先的技術。
 
關於作者
百分點科技推薦引擎研發部由40餘名技術精英組成,絕大多數具有國內外知名院校碩士及以上學位,擁有豐富的國內外互聯網企業的研發經驗,是國內領先的推薦引擎架構設計研發團隊。該團隊在推薦引擎算法,大數據平臺和推薦技術應用等領域所做出的一系列創新成果,已成功服務於國內多家著名電子商務企業,顯著提升了電商企業的運營績效,也奠定了百分點科技在推薦引擎技術領域的領先地位。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章