58同城智能推薦系統的演進與實踐(轉)

58同城做爲中國最大的分類信息網站，向用戶提供找房子、找工做、二手車和黃頁等多種生活信息。在這樣的場景下，推薦系統可以幫助用戶發現對本身有價值的信息，提高用戶體驗，本文將介紹58同城智能推薦系統的技術演進和實踐。

58同城智能推薦系統大約誕生於2014年（C++實現），該套系統前後經歷了招聘、房產、二手車、黃頁和二手物品等產品線的推薦業務迭代，但該系統耦合性高，難以適應推薦策略的快速迭代。58同城APP猜你喜歡推薦和推送項目在2016年快速迭代，產出了一套基於微服務架構的推薦系統（Java實現），該系統穩定、高性能且耦合性低，支持推薦策略的快速迭代，大大提升了推薦業務的迭代效率。此後，咱們對舊的推薦系統進行了重構，將全部業務接入至新的推薦系統，最終成功打造了統一的58同城智能推薦系統。下面咱們將對58同城智能推薦系統展開介紹，首先會概覽總體架構，而後從算法、系統和數據三方面作詳細介紹。

總體架構首先看一下58同城推薦系統總體架構，一共分數據層、策略層和應用層三層，基於58平臺產生的各種業務數據和用戶積累的豐富的行爲數據，咱們採用各種策略對數據進行挖掘分析，最終將結果應用於各種推薦場景。

• 數據層：主要包括業務數據和用戶行爲日誌數據。業務數據主要包含用戶數據和帖子數據，用戶數據即58平臺上註冊用戶的基礎數據，這裏包括C端用戶和企業用戶的信息，帖子數據即用戶在58平臺上發佈的帖子的基礎屬性數據。這裏的帖子是指用戶發佈的房源、車源、職位、黃頁等信息，爲方便表達，後文將這些信息統稱爲帖子。用戶行爲日誌數據來源於在前端和後臺的埋點，例如用戶在APP上的篩選、點擊、收藏、打電話、微聊等各種操做日誌。這些數據都存在兩種存儲方式，一種是批量存儲在HDFS上以用做離線分析，一種是實時流向Kafka以用做實時計算。

• 策略層：基於離線和實時數據，首先會開展各種基礎數據計算，例如用戶畫像、帖子畫像和各種數據分析，在這些基礎數據之上即是推薦系統中最重要的兩個環節：召回和排序。召回環節包括多種召回源的計算，例如熱門召回、用戶興趣召回、關聯規則、協同過濾、矩陣分解和DNN等。咱們採用機器學習模型來作推薦排序，前後迭代了LR、FM、GBDT、融合模型以及DNN，基於這些基礎機器學習模型，咱們開展了點擊率、轉化率和停留時長多指標的排序。這一層的數據處理使用了多種計算工具，例如使用MapReduce和Hive作離線計算，使用Kylin作多維數據分析，使用Spark、DMLC作大規模分佈式機器學習模型訓練，使用theano和tensorflow作深度模型訓練。

• 再往上就是應用層，咱們經過對外提供rpc和http接口來實現推薦業務的接入。58同城的推薦應用大可能是向用戶展現一個推薦結果列表，屬於topN推薦模式，這裏介紹下58同城的幾個重要的推薦產品：

• 猜你喜歡：58同城最重要的推薦產品，推薦場景包括APP首頁和不一樣品類的大類頁，目標是讓用戶打開APP或進入大類頁時能夠快速找到他們想要的帖子信息，這主要根據用戶的我的偏好進行推薦。

• 詳情頁相關推薦：用戶進入帖子詳情頁，會向用戶推薦與當前帖子相關的帖子。該場景下用戶意圖較明顯，會採用以當前帖子信息爲主用戶偏好信息爲輔的方式進行推薦。

• 搜索少無結果推薦：用戶會經過品類列表頁上的篩選項或搜索框進入品類列表頁獲取信息，若當前篩選項或搜索條件搜索出的結果較少或者沒有結果，便會觸發推薦邏輯進行信息推薦。此時會結合當前搜索條件的擴展以及用戶偏好信息進行推薦。

• 個性化推送（Push）：在用戶打開APP前，將用戶感興趣的信息推送給他們，促使用戶點擊，提升用戶活躍度。這裏包含推送通知的生成和推送落地頁上帖子列表的生成兩個推薦邏輯。值得一提的是推送是強制性的推薦，會對用戶造成騷擾，所以如何下降用戶騷擾並給用戶推薦真正感興趣的信息尤其重要。

• Feed流推薦：咱們的推薦產品在某些推薦場景下是以Feed流的形式展示的，例如APP消息中心的今日推薦場景、推送落地頁場景。用戶能夠在這些頁面中不斷下拉刷新消費信息，相似時下火熱的各大資訊Feed流推薦。

推薦系統是一個複雜的工程，涉及算法策略、工程架構和效果數據評估三方面的技術，後文將分別從這三方面介紹58同城推薦系統。

算法

推薦涉及了前端頁面到後臺算法策略間的各個流程，咱們將推薦流程抽象成以下圖所示的召回、排序、規則和展現四個主要環節：

• 召回環節即便用各類算法邏輯從海量的帖子中篩選出用戶感興趣的帖子候選集合，通常集合大小是幾十到上百。

• 排序即對候選集合中的帖子進行打分排序，這裏通常會使用機器學習排序模型，排序環節會生成一個排序列表。

• 規則環節即咱們可能對排序列表採起必定的規則策略，最終生成一個包含N條結果的列表。例如在規則環節咱們可能會採起不一樣的去重策略，如文本去重、圖片去重、混合去重等，可能會採起不一樣的列表打散策略，可能會迭代產品經理提出的各類規則邏輯。因爲推薦系統的最終評價是看統計效果，所以各類人爲的規則都會影響最終結果，咱們抽象出規則環節後即可以對任何邏輯作線上ABTest，最終評價相關邏輯是否合理。

• 生成N條推薦結果列表後，不一樣的前端展現方式也會影響最終的推薦效果，例如不一樣的UI設計，採用大圖模式仍是小圖模式，頁面上展現哪些字段都會影響用戶在推薦列表頁上的點擊，所以在推薦產品迭代過程當中不一樣的展現樣式迭代也很重要。

在上述的四個環節中，召回和排序是推薦系統最重要的兩個環節。規則和展現樣式通常變化週期較長，而召回和排序有很大的挖掘空間，會被不斷的迭代，咱們的推薦算法工做也主要是圍繞召回和排序進行。下圖是咱們推薦算法的總體框架，主要包括基礎數據的計算以及上層的召回策略和排序模型的迭代。

基礎數據計算主要包括用戶標籤和帖子標籤的挖掘，這部分工做由用戶畫像、搜索和推薦多個團隊共同完成，最終各團隊共享數據。基於用戶註冊時填寫的基礎屬性信息和用戶行爲日誌，能夠挖掘出用戶人口屬性和興趣偏好信息，如用戶的年齡、性別、學歷、收入等基礎屬性，用戶感興趣的地域商圈、二手房均價、廳室、裝修程度等偏好信息。帖子標籤挖掘包括提取帖子的固定屬性、挖掘衍生屬性以及計算動態屬性。固定屬性直接從帖子數據庫提取便可，如分類、地域、標題、正文、圖片、房源價格、廳室、小區等。咱們還會基於貼子信息是否完備、價格是否合理、圖片質量好壞、發帖人質量等多個維度來計算帖子質量分。基於用戶行爲日誌數據能夠計算帖子的PV、UV、點擊率、轉化率、停留時長等動態屬性。這些數據最終會在召回環節和排序環節使用，例如基於用戶標籤和帖子標籤能夠進行興趣召回，將用戶標籤和帖子標籤做爲特徵迭代機器學習模型。

召回主要負責生成推薦的候選集，咱們採用多種召回源融合的方式來完成該過程。咱們前後迭代了以下各種召回策略：

• 熱門召回。基於曝光和點擊日誌，咱們會計算不一樣粒度的熱門數據。以二手車業務線爲例，從粗粒度到細粒度的數據包括：城市下的熱門商圈、商圈下的熱門車系和品牌、特定車系和品牌下的熱門車源等。每個車源的熱度咱們經過最近一段時間內帖子的PV、UV、CTR等指標來衡量，這裏的CTR會經過貝葉斯和COEC作平滑處理。熱門召回策略會在冷啓動時被大量採用。

• 地域召回。58同城是向用戶提供本地生活服務類信息，用戶的每次訪問都會帶上地域信息，如選擇的城市、定位的地點等。咱們主要結合地域信息和熱門數據作召回，如附近最新或最熱帖子召回、城市熱門帖子召回等。

• 興趣召回。基於帖子基礎屬性字段和帖子標籤信息，咱們構建了一套帖子檢索系統，經過該系統可以以標籤或屬性字段檢索出最新發布的帖子。在用戶畫像中，咱們計算了每一個用戶的興趣標籤，所以基於用戶興趣標籤便能在檢索系統中檢索出一批帖子，這能夠做爲一種召回源。此外，在帖子詳情頁相關推薦場景中，咱們也能夠利用當前帖子的屬性和標籤信息去檢索系統中檢索出相關帖子做爲召回數據源。這兩種檢索召回其實就是咱們常說的基於內容的推薦。

• 關聯規則。這裏並不是直接採用傳統Apriori、FP-growth關聯規則算法，而是參考關聯規則思想，將最近一段時間中每一個用戶點擊全部物品當作一次事務，由此計算兩兩物品之間的支持度，並在支持度中融入時間衰減因子，最終能夠獲得每一個物品的topK個關聯性強的物品。這種召回方式其實相似協同過濾中的item類似度矩陣計算，咱們主要將其應用在詳情頁相關推薦中。

• 協同過濾。咱們使用Spark實現了基於User和基於Item的批量協同過濾計算，因爲數據量大，批量計算會較消耗時間，咱們又實現了基於Item的實時協同過濾算法。一般狀況下咱們會直接將用戶的推薦結果列表做爲一種召回源，而在詳情頁相關推薦場景，咱們還會使用協同過濾計算出的Item類似度矩陣，將帖子最類似的topK個帖子也做爲一種召回源。

• 矩陣分解。咱們引入了SVD算法，將用戶對帖子的點擊、收藏、分享、微聊和電話等行爲操做看做用戶對帖子進行不一樣檔次的評分，從而構建評分矩陣數據集來作推薦。

• DNN召回。Google在YouTube視頻推薦上使用了DNN來作召回，咱們也正在進行相關嘗試，經過DNN來學習用戶向量和帖子向量，並計算用戶最相近的topK個帖子作爲召回源。

上述不一樣的召回算法都產生出了一部分推薦候選數據，咱們須要將不一樣的召回數據融合起來以提升候選集的多樣性和覆蓋率，這裏咱們主要使用兩種召回融合策略：

• 分級融合。設置一個候選集目標數量值，而後按照效果好壞的次序選擇候選物品，直至知足候選集大小。假設召回算法效果好壞的順序是A、B、C、D，則優先從A中取數據，不足候選集目標數量時則從B中取數據，依次類推。咱們的系統支持分級融合策略的配置化，不一樣召回算法的前後順序能夠靈活配置。這裏的效果好壞順序是根據離線評價和線上評價來決定的，例如離線咱們會比較不一樣召回算法的召回率和準確率，線上咱們會比較最終點擊或轉化數據中不一樣召回算法的覆蓋率。

• 調製融合。按照不一樣的比例分別從不一樣召回算法中取數據，而後疊加產生最終總的候選集。咱們的系統也支持調製融合策略的配置化，選擇哪些召回算法、每種召回算法的選擇比例都可以靈活配置。這裏的比例主要根據最終線上點擊或轉化數據中不一樣召回算法的覆蓋率來設置。

召回環節新召回源的添加或者新融合策略的上線，例如開發了一種新召回算法、須要修改調製融合策略中的配比等，咱們都會作線上ABTest，最終經過比較不一樣策略的效果來指導咱們的迭代。值得一提的是，召回環節咱們還會有一些過濾規則，例如過濾低質量帖子、在某些特定場景下對召回算法產生的結果加一些條件限制等。

排序環節咱們主要採用Pointwise方法，爲每一個帖子打分並進行排序，經過使用機器學習模型預估帖子的點擊率、轉化率和停留時長等多指標來作排序。早期咱們主要優化點擊率，目前咱們不只關注點擊率外還會注重轉化率的提升。在58同城的產品場景中，轉化主要指用戶在帖子詳情頁上的微聊、打電話操做。

排序離線流程主要包括樣本生成和選擇、特徵抽取、模型訓練和評價。首先對埋點日誌中的曝光、點擊、轉化和停留時長等數據作抽取解析，如基於曝光序列號關聯各種操做、解析埋點參數（例如日誌中記錄的實時特徵）、解析上下文特徵等，並同時打上label，生成模型樣本。而後對樣本進行過濾，例如過濾惡意用戶樣本、過濾無效曝光樣本等。而後對樣本作特徵抽取，生成帶特徵的樣本，咱們主要從用戶、帖子、發帖人和上下文四個維度作特徵工程。以後，按照必定正負樣本比例作採樣，最終進行模型訓練和評估，離線評估指標主要參考AUC，離線效果有提高後會進行ABTest上線，逐步迭代。咱們前後迭代上線了以下排序策略：

• 規則序。早期未上線機器學習模型時，對候選集中的帖子會直接使用刷新時間、統計CTR或者一些產品規則來作排序。

• 單機器學習模型。咱們最先實踐的是LR模型，它是線性模型，簡單高效、可解釋性好，但對特徵工程要求較高，須要咱們本身作特徵組合來加強模型的非線性表達能力，早期咱們使用LibLinear來訓練模型，後來遷移到了Spark上。以後咱們引入了XGBoost樹模型，它非線性表達能力強、高效穩定，是目前開源社區裏最火熱的模型之一，最初咱們採用單機版本訓練，後期將XGBoost部署在咱們的yarn集羣上，使用分佈式版本進行訓練。同時，咱們應用了FM模型，相比於LR模型它引進了特徵組合，可以解決大規模稀疏數據下的特徵組合問題，咱們主要使用分佈式FM （DiFacto，FM on Yarn）來進行模型訓練。上述這些模型都是批量更新，一般是一天更新一次，爲了快速捕捉用戶行爲的變化，咱們還引入Online Learning模型，主要嘗試應用FTRL方式去更新LR模型，在某些場景下得到了穩定的效果提高。

• 融合模型。相似Facebook、Kaggle的作法，咱們實踐了GBDT+LR和GBDT+FM的模型融合方案。首先利用XGBoost對原始特徵作處理生成高階特徵，而後輸入到LR和FM模型中，目前咱們的點擊率預估模型中效果最佳的是GBDT+LR融合模型，轉化率預估模型中效果最佳的是GBDT+FM融合模型。此外，咱們還會嘗試將某個單指標（如點擊率）下多個模型的預測結果進行融合（如相加或相乘等），也會將多個指標（點擊率、轉化率和停留時長）的模型進行融合（如相乘）以觀察效果。

• 深度模型。深度學習正逐漸被各大公司應用於推薦系統中，咱們也正在進行嘗試。目前，咱們已將FNN（Factorisation machine supported neuralnetwork）模型應用在咱們的推薦排序中，相比單機器學習模型，FNN有較穩定的效果提高，但比融合模型效果要稍差，目前咱們正在進行深度模型的調優，並在嘗試引入Wide&Deep等其餘深度模型。

基於上述基礎機器學習工具，目前咱們主要會迭代點擊率、轉化率和停留時長預估模型，線上會ABTest上線單指標模型、多指標融合模型，以提升推薦效果。

架構

對於推薦系統來講，一套支撐算法策略高效迭代的推薦後臺系統相當重要，咱們基於微服務架構設計了推薦後臺系統，它擴展性好、性能高，系統架構以下圖所示，系統分爲數據層、邏輯層和接入層，數據層提供各種基礎數據的讀取，邏輯層實現召回和排序策略並支持不一樣策略的ABTest，接入層對外提供了通用的訪問接口。

數據層提供推薦邏輯所須要的各種數據，這些數據存儲在WRedis、文件、WTable等多種設備上，咱們將全部數據的讀取都封裝成RPC服務，屏蔽了底層的存儲細節。這裏包括檢索服務、召回源讀取服務、帖子特徵中心和用戶特徵中心：

• 檢索服務。咱們搭建了一套搜索引擎用作召回檢索，支持基於各種搜索條件去檢索數據，例如能夠檢索出價格在200萬至300萬之間的回龍觀兩室的房源、檢索出中關村附近的最新房源。該服務主要應用於這幾類場景：在猜你喜歡推薦場景中基於用戶標籤去檢索帖子、在相關推薦場景中基於當前帖子屬性去檢索相關帖子、冷啓動時基於地域信息召回附近的帖子等。

• 召回源讀取服務。提供各種召回源數據的讀取，這些召回源數據經過離線或實時計算獲得，包括熱門數據、協同過濾數據、關聯規則數據、矩陣分解結果等。該服務設計得較靈活，支持任意召回源的增長。

• 帖子特徵中心。提供帖子全部屬性字段的讀取，在召回、排序和推薦主體邏輯中會使用到這些帖子屬性，通常狀況咱們會在召回環節讀取出全部帖子屬性，而後應用於排序和規則邏輯中。召回獲得的候選集大小通常是幾十到幾百，爲了支持高性能的批量讀取，咱們選擇使用WRedis集羣存儲帖子屬性，並經過多線程併發讀取、緩存、JVM調優等多項技術保證服務性能。目前，該服務天天承接數億級請求，平均每次讀取150條數據，耗時保證在2ms以內。

• 用戶特徵中心。UserProfile數據包括用戶離線/實時興趣標籤、人口屬性等，該數據會在召回環節使用，例如使用用戶興趣標籤去檢索帖子做爲一種召回源，也會在排序環節使用，例如將用戶標籤做爲機器學習排序模型的特徵。

邏輯層實現了詳細的推薦策略，包括推薦主體服務、召回服務、排序服務和ABTest實驗中心。這些服務由不一樣的開發人員維護，保證了推薦策略的高效迭代，例如召回和排序是咱們常常迭代的環節，由不一樣的算法人員來完成，召回服務和排序服務的分離下降了耦合，提升了迭代效率。

• 推薦主體服務。接收推薦請求，解析推薦場景參數，調用用戶特徵中心獲取用戶信息，請求ABTest實驗中心獲取對應場景的ABTest實驗參數，如召回策略號、排序算法號、規則號和展現號。而後將推薦場景參數、ABTest實驗參數等發送至召回服務得到候選集列表，以後再調用排序服務對候選集進行排序，最終對排序列表作相關規則處理，將結果列表封裝返回。

• 召回服務。接收場景參數和召回策略號參數，調用檢索服務和召回源讀取服務讀取各種召回數據，並進行分級融合或調製融合。咱們實現了召回策略的配置化，一個召回號對應一種召回策略，策略採用哪一種融合方式、每種融合方式下包含哪些召回源、不一樣召回源的數量均經過配置來完成。咱們將召回配置進行Web化，算法或產品人員只需在Web頁面上配置便可生效策略。此外，召回層還包括一些過濾規則，例如過濾低質量信息、過濾用戶歷史瀏覽記錄、過濾產品指定的符合某些特定條件的數據等。

• 排序服務。接收場景參數、用戶信息、候選集列表和排序算法號等參數，調用機器學習排序模塊，對候選集列表作排序。咱們設計了一套通用的特徵提取框架，保證機器學習離線模型訓練和線上排序共用相同的特徵提取代碼，並靈活支持不一樣模型之間的特徵共享。在排序服務中上線一種模型成本很低，只須要提供模型文件和特徵配置文件便可，後續咱們將會對排序配置進行Web化，簡化上線流程。目前，咱們的排序服務中運行了基於LR、XGBoost、FM、XGBoost+LR、XGBoost+FM、DNN的幾十個排序模型。

• ABTest實驗中心。咱們設計了一套靈活通用的ABTest實驗平臺（內部稱做「日晷」）來支持推薦系統的策略迭代，它包括流量控制、實時效果數據統計和可視化等功能，支持用戶在Web頁面上配置實驗和流量，並能展現實時效果數據。這套實驗平臺不只能夠應用於推薦系統，還能夠用於任何其它須要作ABTest實驗的業務系統中，它支持多層ABTest實驗，能充分利用每份流量去完成業務迭代。例如咱們的推薦系統ABTest實驗就包含召回、排序、規則和展現四層，不一樣層之間實現了流量的從新打散，保證了不一樣層之間實驗的正交性。當請求到達咱們的推薦系統時，推薦主體服務便請求「日晷」以得到該請求對應的召回號、排序號、規則號和展現號等實驗參數，以後該請求便會被這些實驗參數打上標記，貫穿於後續的推薦流程，決定每層中將走哪部分邏輯，最終這些實驗參數會記錄到後臺和客戶端埋點日誌中，用於最終的實驗效果統計。

接入層直接和客戶端交互，從客戶端接收請求並調用推薦主體服務得到推薦帖子id列表，而後查詢出帖子詳細屬性返回給客戶端作展現。在大部分推薦場景中，接入層由業務方維護，多是PHP或Java實現的http接口；也有少部分場景的接入層是咱們自主維護，咱們採用58自研的MVC框架WF實現了相關http接口。

咱們採用58自研的RPC框架SCF實現了上述微服務架構的推薦系統，採用58自研的監控系統WMonitor實現了推薦系統的立體監控，整個技術棧是Java。咱們採用多線程、異步、緩存、JVM調優、降級、限流等措施保證了推薦系統的穩定和高可用，目前咱們的推薦系統日均處理數億的推薦請求，平均耗時約30毫秒。

數據

這裏的數據主要指推薦埋點數據和推薦效果數據：埋點數據是推薦系統的基石，模型訓練和效果數據統計都基於埋點數據，需保證埋點數據的正確無誤；效果數據是對推薦系統的評價，指引推薦策略的迭代，構建完備的效果數據體系相當重要。

咱們的推薦埋點日誌數據包括曝光日誌、點擊日誌、轉化日誌和頁面停留時長日誌等，這些日誌數據都須要客戶端經過埋點來產生。這裏簡單解釋一下這些操做的含義：客戶端請求一次推薦接口獲得推薦結果列表叫作一次曝光；用戶點擊推薦結果列表上的某條帖子進入帖子詳情頁叫作一次點擊；用戶在帖子詳情頁上進行微聊、打電話、收藏等操做叫作轉化；用戶在帖子詳情頁上的閱讀時間叫作頁面停留時長。這裏的曝光、點擊和轉化是一個漏斗，操做數量是逐漸遞減的趨勢。因爲58同城上用戶對帖子的訪問可能來源於推薦、搜索和運營活動頁等場景，爲了標識出推薦產生的點擊/轉化/停留時長，咱們須要在埋點中加入推薦相關的參數。咱們將埋點參數設計成一個固定格式的字符串，它包含了曝光惟一序列號、推薦位標識、召回號、排序號、規則號、展現號、帖子id列表、帖子id等字段，這些字段將會做用於機器學習模型訓練樣本生成和推薦效果統計中。埋點參數主要分爲列表參數和單貼參數兩類：推薦接口返回一個帖子列表，會對應返回一個列表參數，包含了曝光序列號、推薦位標識、召回號、排序號、規則號、展現號、帖子id列表等字段；返回的帖子列表中，每一個帖子會對應返回一個單貼參數，包含曝光序列號、推薦位標識、召回號、排序號、規則號、展現號、帖子id等字段。客戶端獲得推薦接口返回的埋點參數後，會將列表參數埋入到曝光日誌中，將單貼參數埋入到點擊日誌、轉化日誌和停留時長日誌當中，注意這裏埋點時須要推薦列表頁向帖子詳情頁傳遞單貼參數，通常須要經過修改跳轉協議來實現。最終埋點日誌中有了這些參數後，咱們即可基於曝光惟一序列號將曝光、點擊、轉化、時長數據join起來，產生模型訓練樣本以及漏斗效果數據。值得一提的是，咱們採起透傳的方式在推薦後臺、接入層、客戶端間傳遞埋點參數字符串，全部埋點參數由推薦系統後臺生成，接入層和客戶端均不作任何處理。埋點參數僅由咱們推薦一方負責，這樣可以避免多方改動埋點參數，從而減小埋點錯誤的可能性，因爲是透傳處理，也便於從此埋點參數的擴展。

埋點數據是推薦系統的基石，不能有遺漏或者錯誤，這就要求咱們嚴格把控開發測試流程，尤爲是APP上的埋點，若發版以後發現有錯誤，便要等到下一次發版時解決。客戶端開發和測試同事不清楚埋點參數的含義但熟練掌握測試環境部署及擁有Android和IOS測試機，而推薦後臺同事清楚埋點參數含義但對測試環境較生疏並缺少測試機，所以咱們總結出了測試同事負責環境部署、推薦後臺同事負責檢驗埋點參數的測試流程，詳細流程以下圖所示。此外，58同城上的APP開發比較複雜，不一樣產品線各自開發本身的APP業務模塊，APP平臺方開發主模塊，每次發版前都有一個集成階段，合併全部業務方提交的代碼，產生最終的APP包，集成階段極可能會發生業務方埋點未生效的狀況。所以，咱們的埋點測試包括業務方內部測試和集成測試兩個階段，以保證埋點萬無一失。

咱們的推薦效果數據是一個多維數據集，咱們主要關注推薦位上的點擊、轉化、停留時長等指標。平常工做中咱們須要從不一樣業務線、不一樣客戶端、不一樣推薦位、不一樣推薦算法等多個維度去分析這些指標數據，例如咱們會觀察房產和車在相同推薦位上的數據對比、猜你喜歡場景上不一樣召回或排序算法的數據對比、二手房詳情頁在Android和IPhone上數據對比等。各類數據分析對比能幫助咱們優化推薦策略，甚至能發現某些業務線功能邏輯上的隱藏BUG，例如在咱們推薦項目攻堅階段，咱們經過分析比較二手房詳情頁在Android和IPhone兩端的推薦效果，發現了IPhone上詳情頁瀏覽回退的BUG，最終反饋給業務方並解決了該問題，該BUG的解決使得咱們在二手房詳情頁推薦位上的推薦點擊量提升了數十萬。

咱們從離線和實時兩方面構建推薦效果數據，數據統計流程以下圖所示：

早期，離線效果數據統計是經過 MapReduce + Hive + MySQL 來實現的，咱們首先會編寫MapReduce程序對原始埋點日誌進行抽取生成Hive表，而後會編寫大量的Hive SQL來統計各種指標數據，並將結果數據寫入MySQL數據表，最終作可視化展現和郵件報表。因爲咱們比較的維度和指標多，Hive SQL語句的編寫消耗了咱們很多人力。在數據平臺部門部署了Kylin多維分析系統後，咱們將效果數據統計工做遷移到了Kylin上，咱們只須要設計好Hive源數據表，並設置好維度和度量，Kylin便能根據維度和度量來自動預計算結果數據，這省去了咱們編寫Hive SQL的工做，大大提升了效率。關於如何利用Kylin構建多維數據集能夠參考此文《基於Kylin的推薦系統效果評價系統》。

實時效果數據咱們採用Storm + HBase 來計算，實時效果數據主要用於異常埋點監控、新上線推薦算法效果快速反饋、模型異常監控等，咱們實現了一個包含較少維度的多維數據統計，從此咱們將嘗試引入Druid等實時多維分析系統來完善推薦實時效果數據的建設。

總結

本文介紹了58同城智能推薦系統在算法、工程和數據三方面的技術演進。咱們在最近一年加快了推薦業務的迭代速度，接入了房產、車等業務線在APP、PC、M三端共計近百個推薦位，咱們的推薦點擊佔比指標（推薦位上產生的點擊量在整體點擊量中的佔比）相比一年以前提升了2~3倍，達到了20%~30%，天天可以產生數千萬的推薦點擊量，爲業務線帶來了流量提高。

任何推薦系統的發展必會經歷推薦位擴充和推薦算法深刻優化兩個階段，流量指標能夠經過擴充推薦位來快速提升，當推薦位穩定以後，就須要依賴更加深刻的算法優化來繼續提升指標，而此時的效果提高也會相對緩慢。目前，咱們的流量指標已相對穩定，咱們會更進一層去關注轉化指標，提升用戶進入帖子以後與發帖人進行微聊或電話溝通的可能性，幫助用戶找到真正有用的信息。

做者：詹坤林，58趕集集團TEG架構線智能推薦部負責人、算法架構師，前騰訊高級工程師，從事推薦算法和架構設計工做