建站
咨詢
售后
建站咨詢
新聞中心
[[150470]]
王傳鵬 新浪微博推薦及廣告技術總監(jiān)
| 王傳鵬，WOT峰會特邀嘉賓，曾為第七屆WOT移動互聯(lián)網(wǎng)開發(fā)者大會的特約講師，也是本屆“互聯(lián)網(wǎng)+”時代大數(shù)據(jù)技術峰會的聯(lián)合出品人之一。2006年從北航畢業(yè)，然后加入霍尼韋爾北京研中心做工程，之后同合伙人一起創(chuàng)辦云存儲網(wǎng)絡硬盤（99盤）。在公司被收購后，加入當當網(wǎng)負責推薦和廣告工作。于2011年加入新浪微博商業(yè)產(chǎn)品部，負責推薦和廣告，直至現(xiàn)在。 |
引言
微博（Weibo）是一種通過關注機制分享簡短實時信息的廣播式社交網(wǎng)絡平臺。微博用戶通過關注來訂閱內容，在這種場景下，推薦系統(tǒng)可以很好地和訂閱分發(fā)體系進行融合，相互促進。微博兩個核心基礎點：一是用戶關系構建，二是內容傳播，微博推薦一直致力于優(yōu)化這兩點，促進微博發(fā)展。如圖1所示：
圖1 微博推薦的使命
在微博推薦發(fā)展的過程中遇到體系方向的變化、業(yè)務的不斷更迭、目標的重新樹立，其產(chǎn)品思路、架構以及算法也隨之進行變遷。本文主要闡述在這個過程中推薦架構的演進，從產(chǎn)品目標、算法需求以及技術發(fā)展等維度為讀者呈現(xiàn)一個完整的發(fā)展脈絡，同時也希望通過這個機會跟大家一起探討業(yè)務與技術的相互關系。
為了便于理解微博推薦架構演進，在介紹之前需要陳述一下微博推薦在流程上的構成，其實這個和微博本身沒有關系，理論上業(yè)內推薦所存在的流程基本都是相同的。如圖2所示，推薦是為了解決用戶與item之間的關系，將用戶感興趣的item推薦給他／她。那么，一個item被推薦出來會經(jīng)過候選、排序、策略、展示、反饋到評估再改變候選等等形成一個完整的回路。
圖2推薦的鏈路
在上述整體流程的基礎上，微博推薦架構經(jīng)歷了如圖3所示的三個階段：
圖3 微博推薦架構的三個階段
通常架構的產(chǎn)生都會來自于團隊和業(yè)務環(huán)境，源于環(huán)境因素而致力于解決環(huán)境中的問題，架構形成會帶著較為強烈的特點，在其實施中會產(chǎn)生交給針對性的效果。本文將從環(huán)境因素、架構組成與特點以及實施效果這三個方面進行闡述微博推薦的三個階段。
1 獨立式的1.0
1.1 環(huán)境
影響架構形成的環(huán)境因素可以分為內部環(huán)境因素以及外部環(huán)境因素。內部因素主要是團隊及其成員相關內容，而外部因素主要來自于外部門、整個公司或者整個行業(yè)領域。
微博推薦1.0的這段時間是從2011年7月份到2013年2月份左右，其主要的目標就是實現(xiàn)當前的業(yè)務需求。對于獨立式的解釋：每一個業(yè)務項目都是一套完整架構流程，架構之間相對獨立，甚至包括技術棧。之所以稱之為獨立式其內部因素有幾點：
1) 當時團隊是一個新團隊，成員也相對較新，相互的合作不多，缺乏推薦領域整體性經(jīng)驗。
2) 團隊成員對于推薦架構都有自己的一些或多或少的理解，但是對于在當前場景下的微博推薦架構，共識并沒有形成。
當然起決定性因素的還是外部環(huán)境，是因為內部原因還是比較好協(xié)調和進化的。當時的外部環(huán)境因素包括：
1) 項目需求很多，在當時一個5人團隊并行開發(fā)的項目平均在3-5個左右，當然最重要的因素是當時的微博產(chǎn)品正處于高速發(fā)展期，很多地方都需要微博推薦的支撐。同時，項目周期也很短，排期倉促，很難有時間進行細致的整理和抽象。典型產(chǎn)品包括：微吧、微群、微刊、微話題、用戶以及內容排序等等。
2) 團隊是一個支撐性的，絕大部分需求來自于外部團隊，各個外部團隊不同的產(chǎn)品方向也導致疲于應付需求。
3) 當時業(yè)內的推薦架構也有不同的發(fā)展方向，大家都在嘗試摸索一些符合自身發(fā)展的架構思路。
由于上述的那些原因，通常我們面對一個接一個的項目時，都會根據(jù)自己的理解使用熟悉的技術棧來搭建流程，這樣形成了一個又一個的獨立架構。
1.2 架構組成與特點
上節(jié)中提到了獨立架構形成的原因，大家可能覺得架構組成沒有必要去描述了，這是不對的，事實上后來的分層以及平臺架構的基礎恰恰都來源于這個階段，沒有這個階段團隊不斷踩坑總結就沒有因地制宜產(chǎn)生的后續(xù)進化。因此，我們需要為大家剖析一下推薦1.0的架構組成與特點。
1) 技術目標
參考圖2所示，以業(yè)務實現(xiàn)為主要目標的微博推薦1.0，沒有建立起完整的反饋以及評估體系，同時排序也是被策略取代，那么講主要的重點體現(xiàn)到了候選、策略以及展現(xiàn)上。上述推薦流程被轉化為：候選?策略?展現(xiàn)簡單形態(tài)。
2) 架構組成
如圖4所示，我們試圖將每個項目的架構能夠在圖中表達出來，在真正的實施過程中，每一個項目負責人會選擇使用apache＋mod_python作為服務架構同時，使用redis作為存儲選型。在一些特定的項目中，引入了復雜運算從而誕生了c/c++的服務框架woo；同時，對于數(shù)據(jù)的存儲要求特型化的項目中又自己研發(fā)了一系列的db，比如早期存儲靜態(tài)數(shù)據(jù)的mapdb，存儲key-list的keylistdb等等。當然，在部署中會比下圖更加隨意一些，一個項目幾臺服務器部署好微博服務提供http請求，然后再找?guī)讉€服務器安裝redis作為數(shù)據(jù)支撐，來源數(shù)據(jù)和業(yè)務方定好規(guī)則使用rsync傳輸就OK了，大部分策略在python中實現(xiàn)。
圖中可以看到主要的技術棧：
- web服務：apache＋mod_python，后來發(fā)展成為社區(qū)更為完善的mod_wsgi。使用python作為WEB開發(fā)語言主要是因為平時處理數(shù)據(jù)使用的都是python，同時上手快，學習曲線平緩。
- 運算服務：c/c++，形成woo內部服務框架
- db：redis／mapdb／keylistdb等等，分為兩種存儲方法：redis以及自研型
- 數(shù)據(jù)來源：rsync文件傳輸，firehose作為微博相關內容來源［微博內部使用的一種數(shù)據(jù)隊列］
圖4 微博推薦1.0架構簡圖
3) 架構特點
將架構特點劃分為優(yōu)點和缺點進行描述。那么優(yōu)點是：
- 簡單，易于實現(xiàn)，不需要額外的基礎支撐
- 利于業(yè)務的功能快速實現(xiàn)
- 利于多業(yè)務并行開展，相互不影響
而不足是：
- 推薦流程不完整，缺乏反饋、評估等等重要內容，對于數(shù)據(jù)方面也極度缺乏統(tǒng)一處理方法
- 沒有提供給算法相關的支撐，很難將推薦做的深入
- 幾乎無法進行專業(yè)運維
- QA的測試僅僅能到功能層面，模塊級別的測試幾乎不可能，因為太過于分散
- 很難進行團隊協(xié)作，不利于項目的分解
1.3 成果
盡管存在諸多的缺點，但是在其發(fā)展的過程中，也給后面的架構優(yōu)化奠定了基礎，其成果如下：
1) 在微博高速發(fā)展的過程中，滿足了微博對于推薦的業(yè)務支撐要求，在這段時期里面共完成二十多個獨立項目。
2) 誕生了woo的基礎框架，后面的內部高效運算框架來源于此
3) 誕生了mapdb的靜態(tài)存儲，成為后期微博推薦靜態(tài)存儲的雛形
4) web應用層的不斷需求的總結，組建形成推薦通用應用框架
#p#
2 分層式的2.0
上一節(jié)介紹完獨立的1.0，按照架構發(fā)展的道路，我們到了分叉路口，一邊是流行的LAMP架構，另一邊是符合廣告、搜索的CELL架構。LAMP架構數(shù)據(jù)策略分離，腳本語言作為業(yè)務開發(fā)主要語言，項目快速開發(fā)和迭代的首選。CELL結構強調本地流程處理，數(shù)據(jù)與業(yè)務耦合性強，自研的服務以及數(shù)據(jù)庫較多出現(xiàn)，適用于高性能效果型產(chǎn)品。最終我們選擇兼容兩者，傾向于業(yè)務的架構體系。為何如此呢？讓我們再來看看當時的環(huán)境。
2.1 環(huán)境
微博推薦2.0的時間段是2013年3月份到2014年年底，這段時間內部環(huán)境因素是：
1) 當前團隊成員合作已經(jīng)很長時間，彼此相互熟悉，同時對于技術選型有了一定的共識。
2) 團隊產(chǎn)品進行了聚焦，針對內容／用戶／垂直類三類推薦進行了整理，同時對于場景分別進行了重點劃分：feed流內、正文頁以及PC首頁右側。這種聚焦有利于進行架構統(tǒng)一，同時也為技術爭取了時間。
而外部因素是：
1) 公司對于推薦有了比較明確的定位，提高關系達成以及內容傳播效率，同時為推薦型廣告打好技術探索、場景介入以及用戶體驗的基礎。
2) 推薦領域里，各個公司都紛紛有了對于架構的產(chǎn)出，對于微博推薦有了很好的指導意義。
2.2 架構組成與特點
團隊在執(zhí)行核心業(yè)務實現(xiàn)的時候，不斷演進工具以及框架，構建2.0的目標呼之欲出。
1) 技術目標
與1.0不同，僅僅實現(xiàn)業(yè)務需求已經(jīng)不是2.0的技術目標了，針對完整的推薦流程，我們需要解決：
首先要實現(xiàn)完整的推薦流程，架構覆蓋候選、排序、策略、展示、反饋和評估。
以數(shù)據(jù)為先，提煉出數(shù)據(jù)架構。實現(xiàn)數(shù)據(jù)對比，效果以數(shù)據(jù)為準；實現(xiàn)數(shù)據(jù)通道，體現(xiàn)反饋；實現(xiàn)數(shù)據(jù)落地，承接業(yè)務需求。
提供算法方便介入的方式。
既能保證業(yè)務的快速迭代和開發(fā)，又能支持高效運算。
2) 架構組成
微博推薦2.0的架構如圖5所示，它不再是一個個獨立的系統(tǒng)，也不是會讓開發(fā)人員使用不同的技術解決相似的問題。這個架構圖主要包括幾個部分的內容：
應用層：主要承擔推薦策略以及展現(xiàn)方面的工作，其特點在于充分發(fā)揮腳本語言的特點響應迭代需求。大部分的推薦內容經(jīng)過排序之后已經(jīng)可以展示了，但是由于前端產(chǎn)品策略的設定需要融合、刪選以及重排操作，需要這一層來完成，在技術層面屬于IO密集型的。在技術選型上，早期在原有apache＋mod_python基礎上進行了框架開發(fā)產(chǎn)生了common_recom_frame。該框架面向的是二次開發(fā)者，基于此框架可以很好的實現(xiàn)推薦業(yè)務流程。該框架的核心思想是提煉出project、work以及data的三層interface，project針對每一個推薦項目，work針對每個推薦項目中不同推薦方法，而data則是管理下游數(shù)據(jù)的訪問方法。同時，設定了兩個規(guī)范：一個是統(tǒng)一了推薦接口，無論是用戶、內容還是垂直業(yè)務；另一個是屏蔽了不同協(xié)議數(shù)據(jù)庫訪問方法，極大提高了開發(fā)效率。common_recom_frame框架的誕生基本上解決了產(chǎn)品的各種推薦策略需求，走在了產(chǎn)品的前面。
圖5 微博推薦2.0架構示意圖
計算層：主要承擔推薦的排序計算，主要消耗CPU，在這一層給算法提供介入方法，支持算法的模型迭代。在這一層的技術選型上，我們繼承了原有的WOO協(xié)議框架，一種基于c/c++開發(fā)的內部高效通訊框架。當然也做了不少擴展，依然借用了上面提到的common_recom_frame的思想，在WOO框架基礎上實現(xiàn)了對于project／work/data的管理，提供給二次開發(fā)者更為高效的開發(fā)工具。在團隊的開源項目中包含這個工具：https://github.com/wbrecom/lab_common_so
數(shù)據(jù)層：主要承擔推薦的數(shù)據(jù)流以及存儲工作。數(shù)據(jù)層的工作主要是解決數(shù)據(jù)的IN/OUT/STORE問題。其中IN數(shù)據(jù)如何進入系統(tǒng)，OUT表示數(shù)據(jù)如何訪問，STORE表示數(shù)據(jù)如何存。當在進行數(shù)據(jù)層規(guī)劃的時候，又分析了微博推薦的數(shù)據(jù)特點，可以將其分為兩類：靜態(tài)和動態(tài)。靜態(tài)數(shù)據(jù)的定義為： 更新需要全量同時頻次較低的大規(guī)模數(shù)據(jù)；動態(tài)數(shù)據(jù)的定義為：動態(tài)更新同時頻次較高的增量數(shù)據(jù)。這樣在IN/OUT/SOTRE的大方向下，同時區(qū)分對待靜態(tài)和動態(tài)數(shù)據(jù)，產(chǎn)生了RIN／R9-interface、redis/lushan、tmproxy／gout代理的工具或者框架。在這里展開講一下，RIN支持數(shù)據(jù)動態(tài)數(shù)據(jù)的接入，通過web服務的方式接收數(shù)據(jù)，后端使用ckestrel進行隊列管理，輔以多服務集群的消費框架，使用者只需要進行自己業(yè)務的開發(fā)即可快速上線消費動態(tài)數(shù)據(jù)。R9-interface處理靜態(tài)數(shù)據(jù)的接入，推薦的大量靜態(tài)數(shù)據(jù)來源于Hadoop集群的運算，r9-interface框架勇來解決靜態(tài)運算［MR、HIVE SQL以及SPARK 運算］的通知、管理以及數(shù)據(jù)載入。針對推薦數(shù)據(jù)的存儲，動態(tài)數(shù)據(jù)大量使用了redis集群，靜態(tài)數(shù)據(jù)則使用了lushan集群。對于lushan這個工具在團隊開源項目中也包含了：https://github.com/wbrecom/lushan。tmproxy／gout用來解決數(shù)據(jù)的OUT問題，gout是一個代理中間件，用來處理推薦中對于數(shù)據(jù)的動靜結合訪問的需求，減少業(yè)務對于后端數(shù)據(jù)變化帶來的影響。
基礎服務：推薦系統(tǒng)的基礎服務主要包括監(jiān)控、報警以及評測系統(tǒng)，數(shù)據(jù)監(jiān)控系統(tǒng)分為性能以及效果監(jiān)控兩類，評測系統(tǒng)主要用來進行下線評估，在上線之前對效果有一定預期以及減少無效上線。圖6展示了基礎服務的UI。
圖6 基礎服務系統(tǒng)的UI
3) 特點
優(yōu)點是：
- 支撐完整的推薦流程，對于數(shù)據(jù)方面擁有統(tǒng)一的處理方法
- 在兼顧業(yè)務功能快速實現(xiàn)的同時保證了效果技術的不斷深化
- 給算法提供了很好的支持
- 提出以數(shù)據(jù)為先的思想，可以全面對比效果，推薦效果不斷得以提升
- 封層體系易于部署以及QA介入進行測試
而不足是：
- 和推薦核心有一定的距離，并沒有完全為推薦量身定做
- 將推薦的策略算法完全交給了開發(fā)者，不利于推薦通用型
- 對于算法的訓練并沒有涉及，僅僅是一個線上投放系統(tǒng)，不足以構成完整的推薦體系
2.3 成果
微博推薦2.0的誕生產(chǎn)生很好的收益，其成果如下：
1) 微博推薦的核心業(yè)務均在該體系下完成：正文頁推薦、趨勢用戶推薦、趨勢內容推薦、各個場景下的用戶推薦、粉絲經(jīng)濟的粉條、賬號推薦等等產(chǎn)品
2) 誕生了lab_common_so的基礎框架，并進行了開源
3) 誕生了靜態(tài)存儲集群解決方案lushan，并進行了開源
4) RUF框架的誕生極大提升了業(yè)務生產(chǎn)效率，同時也為openresty社區(qū)做出一定貢獻
#p#
3 平臺式的3.0
上節(jié)中描述2.0的時候提到了一個重要不足是“和推薦核心有一定的距離，并沒有完全為推薦量身定做”，我們希望能夠在推薦3.0中解決它，這個不足會帶來什么問題，以及為何在已經(jīng)滿足業(yè)務需求的同時推薦的架構再次往前發(fā)展呢？那么接下來為各位展現(xiàn)微博推薦平臺式的3.0設計，我們還是先看看所處的環(huán)境。
3.1 環(huán)境
微博推薦3.0的時間段是2014年底至今，當前的內部環(huán)境因素是：
1) 推薦產(chǎn)品不在擴張，對效果更為看重，將工作重點從業(yè)務開發(fā)和迭代轉化為以效果為目標的技術迭代。
2) 新項目或者迭代推薦業(yè)務的時候發(fā)現(xiàn)重復的事情很多，而架構沒有解決，工作存在冗余。
而外部因素是：
1) 公司也從業(yè)務擴展轉變?yōu)樾蕿橄?，提升用戶體驗以及內容質量上來。
2) 微博推薦在推薦技術環(huán)節(jié)距離領域內有一定距離，當下有條件進行追趕。
3.2架構組成與特點
當前的環(huán)境也能體現(xiàn)出3.0的技術目標：
1) 技術目標
與2.0不同，全覆蓋推薦流程已經(jīng)不是3.0的目標，其目標是：
抽象出推薦流程中對于候選／排序／訓練／反饋的通用方法來
推薦是一個算法數(shù)據(jù)問題，應該以一個算法的角度構建推薦系統(tǒng)，因此需要更為貼近算法策略
2) 架構組成
如圖7所示，是微博推薦3.0的架構，也是當前實行的架構體系，大家其實可以發(fā)現(xiàn)，這是基于2.0 發(fā)展起來的，既然還保留了大量2.0中使用的分層體系以及工具框架。在這里重點描述幾個差異：
兩個標準：一個是針對應用層，作為整體框架輸出，應用層設定all in one 接口標準，其標準包含了輸入以及輸出參數(shù)；另外一個是針對動態(tài)輸入rin，由于離線計算我們可以確定結構，因此一個輸入層工具r9-interface不需要設定規(guī)范，但是rin是需要進行標準設定，從屬性／交互數(shù)據(jù)／日志等等層面進行劃分。
計算層增加對于候選的標準生成方法：Artemis內容候選模塊，item-cands用戶候選模塊、……，在項目開發(fā)中只需要選擇這些候選生成方法即可。
增加了策略平臺EROS，解決算法模型的問題。EROS主要的幾個功能是：1）訓練模型 2）特征選取 3）上線對比測試。
數(shù)據(jù)層中的r9-interface以及rin增加對于候選的生成方法，在線以及離線使用推薦通用策略生成結果。
圖7 微博推薦3.0的架構示意圖
3) 特點
主要描述其優(yōu)勢：
繼承了原有2.0的特點，保留了其優(yōu)勢
對于推薦理解更為深入，結合更為緊密
解決了推薦候選／排序／訓練的算法最重要問題
3.3 成果
微博推薦3.0的誕生，其成果如下：
1) 微博推薦的核心業(yè)務會逐步遷移到該體系下，以算法數(shù)據(jù)作為驅動，提升效果
2) 誕生了EROS的訓練流程，提出了訓練的標準方法
3) 針對推薦設定了標準的輸入輸出方法
4) 針對候選，產(chǎn)生了具有抽象意義的推薦方法集合
4 總結
上文中對微博推薦架構演進做了較為詳實的介紹，在這個演進的過程團隊以及個人收益很大，技術與業(yè)務的關系在架構中得到了很好的體現(xiàn)。有幾點可以跟大家分享的是：
1) 技術來源于業(yè)務同時提升業(yè)務發(fā)展，業(yè)務發(fā)展又反過來推動技術的前進，他們是一個相互影響相互促進的關系。和業(yè)務共同發(fā)展的技術才是有生命力的。
2) 技術架構的選型建議是尋找當前最短路徑，然后進行不斷優(yōu)化迭代，一口氣吃撐是不現(xiàn)實的，也是不合理的。
3) 推廣某個框架和工具最好的方式不是行政命令也不是請客吃飯，而是的大家都是參與者，如同開源項目，每個人都是它的主人，這樣人人維護，人人使用。
4) 團隊崇尚簡單可依靠，它說起來容易做起來難，不過有一個好方法就是懂得自己不應該做什么，而不是應該做什么。
5) 說到推薦這個特殊領域上來，設定目標，跟蹤目標很重要，把數(shù)據(jù)和目標擺出來，產(chǎn)品、架構以及算法都會想辦法去解決的。
最后，跟大家推薦一下微博推薦的官方博客：http://www.wbrecom.com/ 歡迎大家提出建議和建議。感謝大家對于微博推薦以及微博的關心和愛護，謝謝！
文章標題：新浪微博王傳鵬：微博推薦架構的演進
當前URL：http://m.5511xx.com/article/cdoioie.html
