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

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

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