「從零入門推薦系統(tǒng)」05：推薦系統(tǒng)業(yè)務(wù)流程與架構(gòu)

520jefferson 2021-12-14

展開全文

作者 | gongyouliu

編輯 | auroral-L

全文共7426字，預計閱讀時間30分鐘。

大家好，我是強哥。一個熱愛暴走、讀書、寫作的人！

本章目錄

一、推薦算法的業(yè)務(wù)流程

1. 數(shù)據(jù)收集

2. ETL 與特征工程

3. 推薦模型構(gòu)建

4. 推薦預測

5. 推薦Web服務(wù)

6. 離線評估與在線評估

7. 推薦算法的其他支撐模塊

二、推薦系統(tǒng)的pipeline架構(gòu)

三、推薦系統(tǒng)的工程架構(gòu)設(shè)計原則

總結(jié)

推薦系統(tǒng)是一個偏業(yè)務(wù)的系統(tǒng)，工程實現(xiàn)和架構(gòu)設(shè)計對推薦系統(tǒng)是否能夠產(chǎn)生商業(yè)價值非常關(guān)鍵。好的工程實現(xiàn)和架構(gòu)設(shè)計也方便推薦系統(tǒng)的維護與迭代。在后續(xù)章節(jié)講解推薦算法和推薦系統(tǒng)工程實踐方面的知識之前，我們在本章簡單地介紹一下推薦系統(tǒng)工程與架構(gòu)相關(guān)的基本原理和概念，方便讀者更好地理解后續(xù)章節(jié)的內(nèi)容。

作為推薦算法工程師（或者即將準備入行推薦算法）的我們，在平時工作中可能不會直接參與工程相關(guān)的工作，但是對推薦系統(tǒng)工程與架構(gòu)有一個宏觀和整體的認識可以更好地讓我們?nèi)ピO(shè)計算法、更好地與工程團隊交流。在小公司，算法和工程可能分得不是那么清楚，算法開發(fā)人員也會參與工程的實現(xiàn)，所以了解推薦系統(tǒng)工程架構(gòu)方面的知識是非常必要的。

本章我們從推薦算法的業(yè)務(wù)流程、推薦系統(tǒng)pipeline架構(gòu)、推薦系統(tǒng)的工程架構(gòu)設(shè)計原則等3個方面來講解。首先我們來介紹一下推薦算法的業(yè)務(wù)流程。

一、推薦算法的業(yè)務(wù)流程

推薦算法是機器學習的一個子領(lǐng)域，因此推薦算法的業(yè)務(wù)流程跟一般的機器學習過程是類似的，一般來說，推薦算法業(yè)務(wù)流程可以從數(shù)據(jù)流向的角度來加以說明，具體參考下面圖1。

圖1：推薦系統(tǒng)業(yè)務(wù)流程

上圖中圓型和方形的藍色模塊是數(shù)據(jù)（或者模型），而紅色的模塊是基于數(shù)據(jù)之上的操作（算子），下面分別對上面的各個操作（數(shù)據(jù)收集、特征工程、推薦模型構(gòu)建、推薦預測、推薦服務(wù)、離線評估、在線評估等）進行詳細說明，讓大家對每一個模塊的功能和特色有更好的了解。

1. 數(shù)據(jù)收集

構(gòu)建推薦算法模型需要收集很多數(shù)據(jù)，包括用戶行為數(shù)據(jù)、用戶相關(guān)數(shù)據(jù)、物品相關(guān)數(shù)據(jù)、場景化數(shù)據(jù)（如用戶設(shè)備屬性、用戶當前地點、時間、用戶停留的頁面等）。如果將推薦算法進行推薦的過程類比為廚師做菜，那么這些數(shù)據(jù)是構(gòu)建推薦算法模型的各種食材和配料。巧婦難為無米之炊，要構(gòu)建好的推薦算法，收集到足夠多的有價值的數(shù)據(jù)是非常關(guān)鍵和重要的。第3章《推薦系統(tǒng)的數(shù)據(jù)源與數(shù)據(jù)處理》已經(jīng)對推薦系統(tǒng)相關(guān)的數(shù)據(jù)進行了全面的介紹，這里不再贅述。

2. ETL與特征工程

收集到的原始數(shù)據(jù)一般是非結(jié)構(gòu)化的、雜亂無章的，一般在進行后續(xù)步驟之前還需要進行ETL，ETL的主要目的是從收集到的原始數(shù)據(jù)中提取推薦算法建模需要的關(guān)鍵字段(拿視頻推薦來說，用戶id、時間、播放的節(jié)目、播放時長等都是關(guān)鍵字段)，將數(shù)據(jù)轉(zhuǎn)化為結(jié)構(gòu)化的數(shù)據(jù)存儲到數(shù)據(jù)倉庫中。同時根據(jù)一定的規(guī)則或策略過濾掉臟數(shù)據(jù)，保證數(shù)據(jù)質(zhì)量。

在互聯(lián)網(wǎng)公司中，用戶行為數(shù)據(jù)跟用戶規(guī)模呈正比，所以當用戶規(guī)模很大時數(shù)據(jù)量非常大，一般采用HDFS、Hive、HBase等大數(shù)據(jù)分布式存儲系統(tǒng)來存儲數(shù)據(jù)。用戶相關(guān)數(shù)據(jù)、物品相關(guān)數(shù)據(jù)一般是結(jié)構(gòu)化的數(shù)據(jù)，一般是通過后臺管理模塊將數(shù)據(jù)存儲到MySQL、ProgreSQL等關(guān)系型數(shù)據(jù)庫中（或者快照到Hive表中）。第3章《推薦系統(tǒng)的數(shù)據(jù)源與數(shù)據(jù)處理》第二部分已經(jīng)對ETL進行過介紹，這里不再說明。

做完了ETL的工作，接下來就是特征工程了。推薦系統(tǒng)采用各種機器學習算法來學習用戶偏好，并基于用戶偏好來為用戶推薦物品。這些推薦算法用于訓練的數(shù)據(jù)應(yīng)該是可以被數(shù)學模型所理解和處理的，一般是向量的形式，其中向量的每一個分量/維度就是一個特征，所以特征工程的目的就是將推薦算法需要的原始數(shù)據(jù)通過ETL后再轉(zhuǎn)換為推薦算法可以學習的特征。

當然，不是所有推薦算法都需要特征工程，比如，如果要做排行榜相關(guān)的熱門推薦，只需要對數(shù)據(jù)做統(tǒng)計排序就可以了。最常用的基于物品的協(xié)同過濾和基于用戶的協(xié)同過濾（后面章節(jié)會講）也只用到用戶id，物品id，用戶對物品的評分三個維度，也談不上特征工程（KNN推薦、bayes算法、關(guān)聯(lián)規(guī)則等推薦算法也都不需要特征工程）。像logistic回歸、FM、深度學習等等復雜一些的機器學習算法需要做特征工程，一般基于模型的推薦算法都需要特征工程。

特征工程是一個比較復雜的過程，要做好需要很多技巧、行業(yè)知識、經(jīng)驗等。我們在后面會單獨用一章的篇幅來講解特征工程，或者讀者可以參考我的另外一個系列「推薦系統(tǒng)與特征工程」，這里不贅述。

3. 推薦模型構(gòu)建

推薦算法模塊是整個推薦系統(tǒng)的核心之一，該模塊的核心是根據(jù)具體業(yè)務(wù)及可利用的所有數(shù)據(jù)設(shè)計一套精準、易于工程實現(xiàn)、可以處理大規(guī)模數(shù)據(jù)的(分布式)機器學習算法，進而可以預測用戶的興趣偏好。這里一般涉及到模型訓練、預測兩個核心模塊。下面圖2簡單描述這兩個過程，這也是機器學習的通用流程。好的推薦算法工程實現(xiàn)，希望盡量將這兩個過程解耦合，盡量做到通用，方便用到各種推薦業(yè)務(wù)中。本節(jié)我們不詳細講解具體的推薦算法，留到后續(xù)章節(jié)講解，下面一小節(jié)我們簡單說說推薦模型預測。

圖2：推薦算法建模過程

4. 推薦預測

當我們構(gòu)建好推薦算法模型后，就可以用該模型進行預測了（即為用戶進行個性化推薦）。如果是T+1（每天為用戶進行一次推薦）的推薦模型，可以將推薦模型加載到推薦預測的代碼塊中（用計算機的術(shù)語，一般預測的邏輯是一個函數(shù)或者一個方法），循環(huán)（對所有待推薦的用戶循環(huán)）為用戶計算推薦結(jié)果。

在計算機工程中有所謂的“空間換時間”的說法，對于推薦系統(tǒng)來說，事先計算好每個用戶的推薦結(jié)果，將結(jié)果存儲下來，可以更快的為用戶提供推薦服務(wù)，及時響應(yīng)用戶的請求，提升用戶體驗(對于T+1推薦，這樣做是非常合適的)。由于推薦系統(tǒng)會為每個用戶生成推薦結(jié)果，并且每天都會(基本全量)更新用戶的推薦結(jié)果，一般采用NoSQL數(shù)據(jù)庫來存儲，并且要求數(shù)據(jù)庫可拓展，高可用，支持大規(guī)模并發(fā)讀寫。

針對實時推薦，上面的方法也是可以行的（只不過需要基于用戶的實時行為近實時更新用戶的推薦結(jié)果），不過一般會將推薦預測過程部署成一個Web服務(wù)，對于用戶的每一次請求，通過該服務(wù)來實時為用戶提供推薦結(jié)果，像TorchServe就是提供這種能力的一種實現(xiàn)（T+1的推薦也可以采用這種方式，在為每個用戶循環(huán)推薦的過程中調(diào)用該服務(wù)）。

圖3：TorchServe的服務(wù)流程（圖片來源于PyTorch官網(wǎng)）

推薦預測是推薦系統(tǒng)產(chǎn)生業(yè)務(wù)價值最重要的部分，真實的推薦系統(tǒng)更加復雜，還要進行很多工程和業(yè)務(wù)上的處理。在工業(yè)級推薦系統(tǒng)中，一般會將推薦預測過程拆分為更多子模塊，方便進行更精細的業(yè)務(wù)控制，具體推薦模型在進行推薦過程中的工程實現(xiàn)細節(jié)我們在本章的5.2節(jié)中介紹。

5. 推薦Web服務(wù)

該模塊是推薦系統(tǒng)直接服務(wù)用戶的模塊，該模塊的主要作用是當用戶在UI上使用推薦系統(tǒng)時，觸發(fā)推薦Web接口服務(wù)（比如用戶在抖音上刷，參見下面圖4中的web服務(wù)模塊），為用戶提供個性化推薦，該模塊的穩(wěn)定性、響應(yīng)時長直接影響到用戶體驗。跟上面的推薦存儲模塊類似，Web服務(wù)模塊也需要支持高并發(fā)訪問、水平可拓展、亞秒級(一般200ms之內(nèi))響應(yīng)延遲。我們會在第17章中詳細介紹推薦Web服務(wù)相關(guān)的知識點，這里不再贅述。

圖4：推薦系統(tǒng)中的Web服務(wù)

6. 離線評估與在線評估

推薦評估模塊的主要作用是評估整個推薦系統(tǒng)的質(zhì)量及價值產(chǎn)出。一般來說可以從兩個維度來評估。

l 離線評估

離線評估是在構(gòu)建推薦算法模型過程中的評估（參見圖1），主要是評估訓練好的推薦模型的質(zhì)量（即模型預測的好不好、準不準，常用的評估指標有準確度、召回率等）。模型在上線服務(wù)之前需要評估該模型的準確度，一般是將樣本數(shù)據(jù)劃分為訓練集和測試集，訓練集用于訓練模型，而測試集用來評估模型的預測誤差（一般還會有驗證集，用于調(diào)優(yōu)模型的超參數(shù)）。

l 在線評估

在線評估是在模型上線提供推薦服務(wù)過程中（參見上面的圖1）評估一些真實的用戶體驗指標、轉(zhuǎn)化指標，比如轉(zhuǎn)化率、購買率、點擊率、人均播放時長等。線上評估一般會結(jié)合AB測試做不同模型的對比實驗，先對新模型放一部分量（用戶或者接口訪問），如果效果達到期望再逐步拓展到所有用戶，避免模型線上效果不好嚴重影響用戶體驗和收益性指標等。

推薦系統(tǒng)評估是對推薦系統(tǒng)的推薦質(zhì)量的一種度量，只有滿足一定評估要求的推薦系統(tǒng)才能產(chǎn)生更好的業(yè)務(wù)效果。本節(jié)我們不詳細說明評估的細節(jié)，在本書第14章我們會更細致地介紹推薦系統(tǒng)評估相關(guān)的話題。

7. 推薦算法的其他支撐模塊

推薦系統(tǒng)各個模塊（即上面講到的模塊）要真正發(fā)揮價值，需要部署到服務(wù)器上，并且能夠自動化地運行，這就涉及到任務(wù)的調(diào)度。常用的任務(wù)調(diào)度有Linux的Crontab，針對少量任務(wù)的調(diào)度Crontab還可以勝任，當任務(wù)量多的時候就不那么方便了，Crontab也無法很好解決任務(wù)依賴關(guān)系。這時一般用更友好、更專業(yè)的Azkaban、Airflow等來實現(xiàn)。

推薦系統(tǒng)是一個工程系統(tǒng) ，工程系統(tǒng)不可避免會偶爾出現(xiàn)問題（代碼中隱含的bug或者軟件及硬件的波動等因素都會導致出現(xiàn)問題），這時就需要監(jiān)控模塊，監(jiān)控模塊解決的是當推薦業(yè)務(wù)(依賴的)任務(wù)由于各種原因調(diào)度失敗、運行報錯時可以及時告警、及時發(fā)現(xiàn)錯誤的問題。監(jiān)控系統(tǒng)在業(yè)務(wù)出現(xiàn)問題時會通過郵件或者短信通知運維或者業(yè)務(wù)的維護者，監(jiān)控系統(tǒng)還可以做到更智能化，當出現(xiàn)問題時，可以自行判斷問題的原因并可以在后臺自動拉起服務(wù)重新啟動(這要求你的業(yè)務(wù)是冪等的)。

我們可以對服務(wù)的各種狀態(tài)做監(jiān)控，可以事先根據(jù)業(yè)務(wù)需要定義一些監(jiān)控指標(比如文件大小、狀態(tài)變量的值、日期時間等)，當這些狀態(tài)變量無值或者值超過事先定義的閾值范圍時及時告警。監(jiān)控模塊的主要目的是保證推薦業(yè)務(wù)的穩(wěn)定性，時時刻刻為用戶提供一致的、高質(zhì)量的個性化推薦服務(wù)。監(jiān)控模塊的開發(fā)和設(shè)計一般需要運維人員來配合實施。

本節(jié)我們只是簡單梳理了調(diào)度與監(jiān)控相關(guān)的概念，讓讀者有一個基本的了解，我們會在本書的第18章詳盡介紹推薦系統(tǒng)調(diào)度與監(jiān)控相關(guān)的話題。

二、推薦系統(tǒng)的pipeline架構(gòu)

上面一節(jié)我們從推薦算法業(yè)務(wù)流程的角度來簡單介紹了推薦算法實施過程中涉及到的各個模塊及其作用。這一節(jié)我們聚焦在推薦預測這一塊，講清楚推薦預測的一些處理方法和思路。工業(yè)級推薦系統(tǒng)為了更好地響應(yīng)業(yè)務(wù)需求，為了將系統(tǒng)解耦合，需要對推薦預測進行更細致的拆分，一般將推薦預測過程按照pipeline的模式拆分為召回、排序、業(yè)務(wù)調(diào)控3個子階段（見下面圖5）。

圖5：推薦系統(tǒng)的pipeline架構(gòu)

召回就是將用戶可能會感興趣的物品通過召回算法從全量物品庫中取出來，一般會采用多個算法來召回，比如熱門召回、協(xié)同過濾召回、標簽召回、地域召回等。排序階段將召回階段的物品列表根據(jù)用戶可能的點擊概率大小排序(即所謂的CTR預估，也可以是預測用戶的停留時長，具體用什么指標作為目標需要根據(jù)業(yè)務(wù)來定)。在實際業(yè)務(wù)中，在排序后還會增加一層調(diào)控邏輯，根據(jù)業(yè)務(wù)規(guī)則及運營策略對排序后的列表進一步增補微調(diào)，滿足特定的運營需求。我們會在本書的第三篇（6~9章）和第四篇（10~12章）分別講解各種召回、排序策略，這里不贅述。

為了讓大家更好地理解上面每個步驟的作用，這里拿相親來舉例說明召回、排序和業(yè)務(wù)調(diào)控的過程。對于單身的人，每年過年回家不可避免地被家長、親戚們問起談對象的事情，他們也會非常熱心的幫我們介紹對象。假如你有3個親戚朋友幫你介紹對象，每個人幫你物色了3個后續(xù)人（他們基于對你的了解，幫你物色的是他們認為和你比較合適的人），親戚朋友幫你物色對象的過程就叫做召回，他們基于自己對你的了解及他們的人脈圈去選擇合適的人，整個召回過程一共召回了9個候選人（越多人幫你介紹，你最終找到滿意對象的概率也越大，在真實的推薦系統(tǒng)中也是會采用很多召回策略的）。由于你的時間有限，你不希望與這9個人每個人都見面，那么你的做法可能是基于這9個人的條件（長相、身材、學歷、性格、家庭背景等）和自己的擇偶標準，從這9個人中最終選擇3個準備去見面更詳細地了解，當你與他們見過面有了更深入的了解之后，這3個人在你心里的匹配度你基本就知道了，那么這個過程就是排序。這時你的父母可能會給你一些建議，在你心里排在第2的人，你父母可能會覺得更合適，你可能會聽父母的建議（畢竟父母閱歷更多，有時看人會更準），最后會與父母覺得最合適的那個人深入接觸。父母對你提建議并且影響你決策的過程就是業(yè)務(wù)調(diào)控。

有了上面這個例子，我相信你一定對什么是召回、排序、業(yè)務(wù)調(diào)控有了更深入的了解了，也知道了各個階段的價值是什么。在真實業(yè)務(wù)場景中，整個推薦預測過程還需要做更多事情，比如進行不同算法的AB測試、過濾掉用戶操作過的物品、對推薦結(jié)果進行信息填補（推薦結(jié)果在存儲時一般只存物品的id，但展示在前端時需要有標題、海報圖等metadata信息，所以需要填補這些在前端展示必要的信息）等。下面圖6是推薦預測過程中的涉及到的操作時序關(guān)系圖。

圖6：推薦系統(tǒng)的pipeline架構(gòu)的時序關(guān)系圖

下面對上圖中每個操作進行簡單說明。首先當用戶請求推薦服務(wù)時，我們獲得了用戶的id，這時如果推薦系統(tǒng)有AB測試的話，需要先獲得用戶的AB測試分組信息（AB測試中不同的組會用不同的召回、排序算法，AB測試的目的就是評估各個算法的效果），然后基于基于用戶的分組去獲得該用戶的召回結(jié)果（即圖中的recall_1、recall_2、... 、recall_n等），召回之后我們會過濾掉用戶操作過的物品然后進行排序（即圖中ranking），之后是一些業(yè)務(wù)規(guī)則（比如新聞資訊APP中會對某些新聞置頂?shù)龋?，然后是填補物品需要展示的metadata數(shù)據(jù)，最終將推薦結(jié)果在前端展現(xiàn)給用戶。

這里順便說一下，召回、排序都可以獨立部署成一個Web服務(wù)（微服務(wù)），推薦預測過程可以通過RPC或者HTTP協(xié)議獲取召回、排序結(jié)果，這樣做的目的是解耦各個排序、召回算法，方便每個算法獨立迭代，這么做是有一定的工程設(shè)計哲學考慮的，下面我們來介紹一下推薦系統(tǒng)的工程架構(gòu)設(shè)計原則。

三、推薦系統(tǒng)的工程架構(gòu)設(shè)計原則

作者在早期構(gòu)建推薦系統(tǒng)時由于經(jīng)驗不足，而業(yè)務(wù)又比較多，當時的策略是每個算法工程師負責幾個推薦業(yè)務(wù)(一個推薦業(yè)務(wù)對應(yīng)一個推薦產(chǎn)品形態(tài))，由于每個人只對自己的業(yè)務(wù)負責，所以開發(fā)基本是獨立的，每個人只關(guān)注自己的算法實現(xiàn)，雖然用到的算法很多都是一樣的，但前期在開發(fā)過程中沒有將通用的模塊抽象出來，每個開發(fā)人員從ETL、模型訓練、推薦預測、推薦結(jié)果存儲、推薦web服務(wù)都是獨立的，并且每個人在實現(xiàn)過程中整合了自己的一些優(yōu)化邏輯，一竿子插到底（即所謂的煙囪式架構(gòu)），導致資源(計算資源、存儲資源、人力資源)利用率不高，開發(fā)效率低下，代碼也極難復用。下面圖7就是這兩種設(shè)計方案的對比。

圖7：煙囪式架構(gòu)與模塊化架構(gòu)

為了支撐更多類型的推薦業(yè)務(wù)，減少系統(tǒng)的耦合，便于發(fā)現(xiàn)和追蹤問題，節(jié)省人力成本，方便算法快速上線和迭代，需要設(shè)計比較好的推薦系統(tǒng)架構(gòu)，而好的推薦系統(tǒng)架構(gòu)應(yīng)該具備4大原則：

通用性、模塊化、組件化、可拓展性。下面分別對這4大原則做簡要說明，闡述清楚它們的目標和意義。

l 通用性

所謂通用，就是該架構(gòu)具備包容的能力，業(yè)務(wù)上的任何推薦產(chǎn)品都可以用這一套架構(gòu)來涵蓋和實現(xiàn)。對于多條相似的產(chǎn)品線，也可以采用同樣的一套架構(gòu)來滿足。

l 模塊化

模塊化的目的在于將一個業(yè)務(wù)按照其功能做拆分，分成相互獨立的模塊，便于每個模塊只包含與其功能相關(guān)的實現(xiàn)邏輯，模塊之間通過一致性的協(xié)議調(diào)用(如HTTP、Thrift等)。將一個大的系統(tǒng)模塊化之后，每個模塊都可以被高度復用。模塊化的目的是為了復用，模塊化后，各個模塊可以方便重復使用到不同推薦業(yè)務(wù)邏輯、甚至不同的產(chǎn)品線中。

l 組件化

組件化就是基于方便維護的目的，將一個大的軟件系統(tǒng)拆分成多個獨立的組件，主要目的就是減少耦合。一個獨立的組件可以是一個軟件包、web服務(wù)、web資源或者是封裝了一些函數(shù)的模塊。這樣，獨立出來的組件可以單獨維護和升級而不會影響到其他的組件。組件化的目的是為了解耦，把系統(tǒng)拆分成多個組件，確定各個組件邊界和責任，便于獨立升級和維護，組件可插拔，通過組件的拼接和增減提供更完整的服務(wù)能力。

組件化和模塊化比較類似，目標分別是為了更好的解耦和重用，就像搭積木一樣構(gòu)建復雜系統(tǒng)。一個組件可以進一步分為多個模塊，組件化是從業(yè)務(wù)功能的角度進行的劃分，是更宏觀的視角，而模塊化是從軟件實現(xiàn)層面進行的劃分，是偏微觀的視角。

l 可拓展性

系統(tǒng)具備支撐大數(shù)據(jù)量，高并發(fā)的能力，并且容易在該系統(tǒng)中增添新的模塊，提供更豐富的能力，讓業(yè)務(wù)更加完備自治。

下面來舉例說明上面原則的應(yīng)用。首先我們可以將利用輸入數(shù)據(jù)通過“操作”得到輸出的的過程抽象為“算子”（參考下面圖8），按照這個抽象，ETL、機器學習訓練模型、召回、排序、業(yè)務(wù)調(diào)控等功能都是算子。其中輸入輸出可以是數(shù)據(jù)或者模型。

圖8：算法或者操作的算子抽象

本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間，所有內(nèi)容均由用戶發(fā)布，不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導購買等信息，謹防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請點擊一鍵舉報。

电竞比分网-中国电竞赛事及体育赛事平台

「從零入門推薦系統(tǒng)」05：推薦系統(tǒng)業(yè)務(wù)流程與架構(gòu)