百分點推薦引擎研究從需求到架構(gòu)

百分點推薦引擎研究從需求到架構(gòu)

導讀：百分點推薦引擎為電子商務和資訊網(wǎng)站提供SaaS模式的個性化推薦服務，提高網(wǎng)站的整站轉(zhuǎn)化率和用戶黏度。本文將從電子商務網(wǎng)站的實際需求出發(fā)，介紹百分點推薦引擎架構(gòu)設計和搭建。需求當下，個性化時代的潮流勢不可擋，業(yè)界普遍意識到了推薦是網(wǎng)站的一項基本服務。但是，人們對推薦該如何來做，也就是推薦技術(shù)本身，還不甚了解。我們經(jīng)常會遇到這樣的疑問：“購買過該商品的用戶還購買過哪些商品這種推薦，不是一個SQL語句就搞定了嗎?”其實不然，推薦技術(shù)遠遠不是這么簡單。廣義上講，推薦技術(shù)屬于數(shù)據(jù)挖掘和機器學習范疇，這也意味著好的推薦服務依賴于科學的推薦算法和大量的學習數(shù)據(jù)。對于電子商務和資訊網(wǎng)站來講，想在推薦技術(shù)領(lǐng)域精耕細作，研發(fā)高端的推薦算法并應用到海量數(shù)據(jù)上是非常困難的。正是在這樣的背景下，百分點推薦引擎應運而生。在百分點推薦引擎產(chǎn)品的開發(fā)過程中，我們與麥包包、紅孩子、走秀網(wǎng)、耀點100等知名電子商務網(wǎng)站，以及天極網(wǎng)、億邦動力等知名媒體資訊類網(wǎng)站的技術(shù)部門進行了深入探討，從他們那里得到了很多幫助與啟發(fā)。在與這些行業(yè)先鋒的交流中我們發(fā)現(xiàn)，有一些需求是行業(yè)共有的，比如推薦的實時性、高可用性。另外一些需求是行業(yè)性的，比如嬰幼兒用品的單品重復購買率比較高，但相同的包包的重復購買率就不算高。對于一位正在育兒的母親，我們可以給她重復推薦符合她們偏好的、相同的奶粉和尿片，但對于一位時尚的女孩，我們向她重復推薦相同的包包可能就不合適了。經(jīng)過廣泛的市場需求和交流，我們要求百分點推薦引擎能夠從方方面面支持客戶的市場營銷策略，概括的講主要包括：l科學高效的推薦算法，并且根據(jù)網(wǎng)站特點選擇最佳的推薦算法和推薦策略;l根據(jù)用戶的全網(wǎng)行為分析他們的潛在偏好，幫助網(wǎng)站實現(xiàn)站內(nèi)站外精準營銷;l根據(jù)全網(wǎng)的商品和資訊信息分析各種內(nèi)容之間的相關(guān)度，幫助網(wǎng)站優(yōu)化站外流量導入工作。百分點推薦引擎面對的是全網(wǎng)的商品資訊信息以及用戶行為，如何科學有效的利用這些數(shù)據(jù)為電子商務和資訊網(wǎng)站提供豐富的推薦服務，滿足其推廣營銷目標，成為了我們最大的技術(shù)挑戰(zhàn)。為此我們對百分點推薦引擎提出了以下技術(shù)要求：l支持各種推薦算法和科學衡量指標。研究人員們已經(jīng)提出了數(shù)百種推薦算法以及相應的標準數(shù)據(jù)集和推薦效果衡量指標，百分點推薦引擎必須足夠靈活以便能夠支持這些算法。而且我們要明確每種算法在各個數(shù)據(jù)集上的性能指標，以便為具體需求選擇合適的推薦算法。l大數(shù)據(jù)處理。面對全網(wǎng)資源和用戶行為，如何安全可靠的存儲和分析這些數(shù)據(jù)是非常關(guān)鍵的。我們的最低要求是每天能夠處理1億級別的數(shù)據(jù)輸入和推薦請求，并且保證數(shù)據(jù)絕對安全。顯然，分布式和云服務是我們唯一的選擇。l高可用性和實時性。作為一個WebService提供商，提供穩(wěn)定可靠低延時的服務是基本要求，我們從用戶體驗角度出發(fā)，要求每個推薦請求都能在2ms內(nèi)處理完成。l可擴展性。這是所有計算機系統(tǒng)的普遍需求，我們要求百分點推薦引擎可以很方便的添加各種新的推薦邏輯，提供新的推薦服務。并且當整個系統(tǒng)需要升級擴容的時候，人力和硬件成本是線性可控的。l便于管理。運維是WebService的重頭戲，我們要求百分點推薦引擎中的各個部件(或邏輯單元)都是獨立可拆卸可替換的，每個部件都要有完善的容災備份恢復機制，這樣整個系統(tǒng)的管理工作逐步細分，有利于分工協(xié)作。架構(gòu)設計根據(jù)上節(jié)提出的需求，我們將百分點推薦引擎設計為一組云服務的有機組合，如上圖，百分點推薦引擎可以分為存儲層，業(yè)務層，算法層和管理層四大功能組件。每個組件內(nèi)部又可以細分為更小的單元，或者服務模塊，提供基本的存儲或運算服務。單元與單元之間盡量解耦和，僅通過API協(xié)議進行協(xié)作，這樣一個單元的升級變動帶來的影響是可控的。每個單元都要做到可靠可用。下面，我們?nèi)娼榻B百分點推薦引擎四大功能組件。存儲層存儲層提供基本的數(shù)據(jù)存取服務，并做好備份和災難恢復工作，以保證數(shù)據(jù)的安全可靠。根據(jù)不同的應用需求，存儲層細分為Redis集群，Membase集群，MySQL集群和Hadoop/HDFS四類。lRedis集群。百分點推薦引擎采用了Redis作為緩存，用于存儲熱門數(shù)據(jù)，包括資源(商品或者咨詢)ID，名稱，鏈接，圖片，分類，品牌等。這些信息數(shù)量不算非常多，但是使用頻率非常高，基本上我們的每次推薦都要用到數(shù)十甚至數(shù)百個商品信息。之所以選用Redis，我們看重的是它的速度，持久化和以及主從機制。目前，我們使用Redis的方式是一個Master帶若干個Slaves以便實現(xiàn)讀寫分離，Master只負責寫，Slaves只負責讀，其中兩個Slave有序列化機制，并且必定有兩個Slave在不同的機器上以消除單點故障隱患。lMembase集群。Membase在百分點推薦引擎中扮演了主存的角色，主要用于支持百分點推薦引擎的計算。目前，百分點推薦引擎包含了大大小小十多個在線和離線計算模塊，這些模塊計算過程中需要用到很多數(shù)據(jù)，并產(chǎn)生以及大量的中間結(jié)果，包括用戶在各個網(wǎng)站的行為歷史，資源之間的關(guān)系等等。這些數(shù)據(jù)的特點是不需要Schema，數(shù)量多，但絕大多的使用頻率很低。之所以選用Membase，主要原因是因為它可以很方便的進行橫向擴展以及有豐富的ClientAPI支持。lMySQL集群。在百分點推薦引擎的最初階段，我們賦予MySQL的主要任務是存儲所有客戶的原始數(shù)據(jù)(包括用戶行為，推薦請求及推薦結(jié)果等)以作備份之用，并在后期統(tǒng)計推薦效果。但很快我們就發(fā)現(xiàn)MySQL數(shù)據(jù)庫變得極其龐大，以至于每周都需要對其進行壓縮備份和切割，運維工作量太大?，F(xiàn)在，我們已經(jīng)將數(shù)據(jù)備份和后期統(tǒng)計工作轉(zhuǎn)移到了Hadoop/HDFS平臺，只在MySQL中存儲最終的統(tǒng)計數(shù)據(jù)以及其他客戶配置信息等小規(guī)模的數(shù)據(jù)。由于MySQL的任務量不重，我們僅對其做了雙機熱備以避免單機崩潰造成無法繼續(xù)服務。lHadoop/HDFS。正如前面所說，目前我們使用Hadoop/HDFS來存儲客戶的原始數(shù)據(jù)，并在其上做一些統(tǒng)計處理。另外，我們也在計劃將一些離線算法和數(shù)據(jù)轉(zhuǎn)移到Hadoop平臺上以便發(fā)揮Hadoop的潛力。Hadoop的NameNode存在單點故障隱患，為此我們?yōu)榻⒘艘粋€備份的NameNode，并在主服務器出現(xiàn)問題時將服務切換至備份服務器上。算法層這是百分點推薦引擎最核心也是最具挑戰(zhàn)性的部分，我們將這一層設計為一系列抽象算法的集合。我們深入研究了學術(shù)界在基于用戶行為的推薦算法，基于內(nèi)容的推薦算法和關(guān)聯(lián)規(guī)則等多方面的理論知識，在此之上自主研發(fā)了十多種適用于大數(shù)據(jù)處理的在線和離線推薦算法。目前，我們的在線算法包括協(xié)同過濾(UserBased/ItemBasedCF)，基于內(nèi)容的推薦(ContentBased)，熱擴散(HeatDiffusion)，用戶行為模式分析(BehaviorPatternAnalysis)等等。離線算法包括KNN聚類，基于FPTree的關(guān)聯(lián)規(guī)則挖掘，基于上下文統(tǒng)計的關(guān)聯(lián)規(guī)則挖掘，序列模式算法，文檔建模算法等等。算法層并不關(guān)心具體的業(yè)務邏輯，而只負責數(shù)據(jù)處理和結(jié)果返回。以熱擴散算法為例，一方面它接受(用戶，資源，偏好指數(shù))的三元組作為計算輸入，實時計算用戶與用戶/資源之間的關(guān)系;另外，我們也可以向它請求某個用戶對哪些資源最感興趣，或者某個資源與哪些資源最相關(guān)。將業(yè)務邏輯和推薦算法本身剝離這樣的設計方式使得推薦算法具有了最大的通用性，也保證了前端的推薦功能模塊可以根據(jù)邏輯需求綜合多個算法。以百分點推薦引擎的“基于瀏覽歷史的個性化推薦”為例，它就使用到了熱擴散和基于內(nèi)容的推薦兩種算法。得益于存儲和算法的分離，算法層并不需要考慮數(shù)據(jù)的備份容災等問題。這樣，如果某個算法模塊由于服務器故障出現(xiàn)異常，我們可以很快在另外的服務器上啟動同一個它的一個備份來替換它，而不涉及任何數(shù)據(jù)遷移問題，最大限度滿足了可用性。業(yè)務層這是百分點推薦引擎中直接面對客戶的部分，也就是我們的HTTPWebService，它主要負責兩件事：收集客戶提交的數(shù)據(jù)，并將其轉(zhuǎn)換為各個推薦算法需要的輸入數(shù)據(jù)，交由推薦算法計算;根據(jù)客戶提交的推薦請求，向一個或幾個推薦算法請求數(shù)據(jù)，并轉(zhuǎn)換為客戶需要的數(shù)據(jù)格式?？梢钥闯?，業(yè)務層起到了連接具體需求與推薦算法，真實世界與計算機世界之間的作用。以“購買過該商品的用戶還購買過哪些商品”為例，我們來簡介這個推薦功能模塊是如何溝通客戶需求和推薦算法。目前我們主要采用熱擴散算法來實現(xiàn)這個推薦功能模塊。首先，客戶提交購買數(shù)據(jù)時，百分點推薦引擎會根據(jù)一定的業(yè)務邏輯將這個事件處理為算法可以接受的三元組。例如用戶U購買了商品K，我們可能會向算法發(fā)送一個輸入數(shù)據(jù)(U，K，1.0)。其次，當客戶請求買過K的用戶還買過哪些商品時，我們一方面以K作為參數(shù)向算法請求與K最相近的資源;另一方面如果客戶提交了用戶ID，我們還會向算法請求該用戶可能感興趣的商品;最后我們將兩個結(jié)果加權(quán)整合，挑選其中權(quán)重最大同時滿足客戶額外需求(例如過濾用戶的購買歷史，按照商品類別/價格過濾等)的幾個商品作為最終推薦結(jié)果?？梢?，業(yè)務層完全將推薦算法作為黑盒子來使用，這樣業(yè)務層就可以集中注意力滿足客戶多種多樣的需求。另外，同算法層一樣，業(yè)務層也無須關(guān)心數(shù)據(jù)的存儲備份和容災。管理層在百分點推薦引擎中，管理層負責內(nèi)部DNS，配置管理，服務部署，服務監(jiān)控和自動應急處理。l內(nèi)部DNS是實現(xiàn)高可用性的重要環(huán)節(jié)。百分點推薦引擎的各個組件都是通過內(nèi)部域名訪問其他服務的，所有服務器的主次DNS也都設置成了內(nèi)部DNS。這樣，當有關(guān)鍵的服務器，例如Hadoop的NameNode，出現(xiàn)故障時，我們可以通過修改域名對應的IP保證服務不間斷。l配置管理。這個模塊的主要功能是實現(xiàn)配置的自動化更新和通知。我們曾經(jīng)考慮過用Zookeeper來實現(xiàn)這一功能，但后來覺得Zookeeper太過重型，于是自己根據(jù)自己的需求開發(fā)了一個配置管理服務。百分點推薦引擎的內(nèi)部服務可以將自己注冊在配置管理的某個項目下，在改配置項變動時，配置管理模塊會通知該服務以便其獲得最新的配置信息。l服務監(jiān)控。這個模塊主要用于監(jiān)控服務器的健康狀況，各個進程是否能夠正常提供服務，并在出現(xiàn)異常情況時執(zhí)行短信報警和觸發(fā)自動應急處理。我們的方法包括：n通過top，ps，free等一些基本工具來查看系統(tǒng)負載以及各個進程是否存活，CPU，Memroy等資源占用情況。利用redis-cli，memstats等特定工具來查看Redis，Membase的運行狀況。n對于自主開發(fā)的程序，我們都要求提供一個可供測試的調(diào)用，這個調(diào)用可以走完主要的服務流程，并返回執(zhí)行流程中是否出現(xiàn)異常，例如配置項設置錯誤，執(zhí)行流程超時等等。n我們會對各個服務輸出的LOG進行分析，找出異常狀況。例如短期內(nèi)出現(xiàn)大量EXCEPTION或者ERROR，請求處理時間超長，大量推薦請求得不到結(jié)果等等。監(jiān)控模塊一旦檢測到異常情況，會立即短信通知我們的運維人員，并通知自動應急處理模塊嘗試修復異常。l自動應急處理。我們在自動應急模塊中實現(xiàn)了修改DNS配置，啟動/停止業(yè)務層服務程序和推薦算法的功能。舉個例子，當MySQL主服務器宕機時，自動應急模塊會收到來自監(jiān)控模塊的通知，而后它會嘗試修改將主從DNS中的MySQL服務器域名修改為MySQL從服務器的IP;又或者如果自動應急模塊收到監(jiān)控模塊的通知說業(yè)務層某個服務進程在連續(xù)的1分鐘內(nèi)一直占用了100%的CPU，應急模塊會將它kill掉并重新啟動，因