打造工業級推薦系統（三）：推薦系統的工程實現與架構優化

• gongyouliu

閱讀數：4148 2019 年 4 月 26 日

導讀：個性化推薦系統，簡單來說就是根據每個人的偏好推薦他喜歡的物品。互聯網發展到現在，推薦系統已經無處不在，在各行各業都得到普遍都應用。亞馬遜號稱 40% 的收入是來自個性化推薦系統的，淘寶的個性化推薦系統也帶來非常大的收益，新聞媒體的個性化推薦系統典型的是今日頭條，直播平臺給用戶推薦喜歡的主播，金融網站給用戶推薦需要的理財產品，社交網絡給用戶推薦大 V 或者其他朋友……越來越多的公司將推薦系統作為產品的標配。

大家接觸推薦系統的概率會越來越大。作為程序員，了解推薦系統也越來越必要，甚至可以主動選擇“推薦系統算法工程師”的相關職位。那大家一定會關心推薦算法工程師需要哪些知識儲備，以及作為一個推薦算法工程師，未來的發展道路怎樣？

本文是作者計劃的一系列文章中的一篇。作者在上篇文章《推薦系統介紹》中簡單對推薦系統做了一個較全面的介紹，相信大家對推薦系統有了初步的了解。本篇文章作者會結合多年推薦系統開發的實踐經驗粗略介紹推薦系統的工程實現，簡要說明要將推薦系統很好地落地到產品中需要考慮哪些問題及相應的思路、策略和建議，其中有大量關于設計哲學的思考，希望對從事推薦算法工作或準備入行推薦系統的讀者有所幫助。為了描述方便，本文主要基于視頻推薦來講解，作者這幾年也一直在從事視頻推薦系統開發的工作，其他行業的推薦系統工程實現思路類似。本篇文章主要從整體上來介紹推薦系統工程實現，以后發布的系列文章會逐步介紹工程實現的各個細節實現原理與策略。

推薦系統與大數據

推薦系統是幫助人們解決信息獲取問題的有效工具，對互聯網產品而也用戶數和信息總量通常都是巨大的，每天收集到的用戶在產品上的交互行為也是海量的，這些大量的數據收集處理就涉及到大數據相關技術，所以推薦系統與大數據有天然的聯系，要落地推薦系統往往需要企業具備一套完善的大數據分析平臺。

推薦系統與大數據平臺的依賴關系如下圖。大數據平臺包含數據中心和計算中心兩大抽象，數據中心為推薦系統提供數據存儲，包括訓練推薦模型需要的數據，依賴的其他數據，以及推薦結果，而計算中心提供算力支持，支撐數據預處理、模型訓練、模型推斷 (即基于學習到的模型，為每個用戶推薦) 等。

推薦系統在整個大數據平臺的定位

大數據與人工智能具有千絲萬縷的關系，互聯網公司一般會構建自己的大數據與人工智能團隊，構建大數據基礎平臺，基于大數據平臺構建上層業務，包括商業智能 (BI), 推薦系統及其他人工智能業務，下圖是典型的基于開源技術的視頻互聯網公司大數據與人工智能業務及相關的底層大數據支撐技術。

大數據支撐下的人工智能技術體系 (DS: 數據源，DC: 大數據中心，BIZ: 上層業務)

在產品中整合推薦系統是一個系統工程，怎么讓推薦系統在產品中產生價值，真正幫助到用戶，提升用戶體驗的同時為平臺方提供更大的收益是一件有挑戰的事情，整個推薦系統的業務流可以用下圖來說明，它是一個不斷迭代優化的過程，是一個閉環系統。

有了上面這些介紹，相信讀者對大數據與推薦系統的關系有了一個比較清楚的了解，下面會著重講解推薦系統工程實現相關的知識。

推薦系統業務流及核心模塊

先介紹一下構建一套完善的推薦系統涉及到的主要業務流程及核心模塊，具體流程如下圖，下面分別介紹各個模塊：

數據收集模塊

構建推薦模型需要收集很多數據，包括用戶行為數據，用戶相關數據及推薦“標的物”相關數據。如果將推薦系統比喻為廚師做菜，那么這些數據是構建推薦算法模型的原材料。巧婦難為無米之炊, 要構建好的推薦算法收集到足夠多的有價值的數據是非常關鍵和重要的。

ETL 模塊

收集到的原始數據一般是非結構化的，ETL 模塊的主要目的是從收集到的原始數據中提取關鍵字段 (拿視頻行業來說，用戶 id，時間，播放的節目，播放時長，播放路徑等都是關鍵字段)，將數據轉化為結構化的數據存儲到數據倉庫中。同時根據一定的規則或策略過濾掉臟數據，保證數據質量的高標準。在互聯網公司中，用戶行為數據跟用戶規模呈正比，所以當用戶規模很大時數據量非常大，一般采用 HDFS、Hive、HBase 等大數據分布式存儲系統來存儲數據。

用戶相關數據及推薦“標的物”相關數據一般是結構化的數據，一般是通過后臺管理模塊將數據存儲到 MySQL、ProgreSQL 等關系型數據庫中。

特征工程模塊

推薦系統采用各種機器學習算法來學習用戶偏好，并基于用戶偏好來為用戶推薦“標的物”, 而這些推薦算法用于訓練的數據是可以“被數學所描述”的，一般是向量的形式，其中向量的每一個分量 / 維度就是一個特征，所以特征工程的目的就是將推薦算法需要的，以及上述 ETL 后的數據轉換為推薦算法可以學習的特征。

當然，不是所有推薦算法都需要特征工程，比如，如果要做排行榜相關的熱門推薦，只需要對數據做統計排序處理就可以了。最常用的基于物品的推薦和基于用戶的推薦也只用到用戶 id，標的物 id，用戶對標的物的評分三個維度，也談不上特征工程。像 logistic 回歸等復雜一些的機器學習算法需要做特征工程，一般基于模型的推薦算法都需要特征工程。

特征工程是一個比較復雜的過程，要做好需要很多技巧、智慧、行業知識、經驗等，在這篇文章中作者不作詳細介紹。

推薦算法模塊

推薦算法模塊是整個推薦系統的核心之一，該模塊的核心是根據具體業務及可利用的所有數據設計一套精準、易于工程實現、可以處理大規模數據的 (分布式) 機器學習算法，進而可以預測用戶的興趣偏好。這里一般涉及到模型訓練、預測兩個核心操作。下面用一個圖簡單描述這兩個過程，這也是機器學習的通用流程。

好的推薦工程實現，希望盡量將這兩個過程解耦合，做到通用，方便用到各種推薦業務中，后面在推薦系統架構設計一節中會詳細講解具體的設計思路和哲學。

推薦結果存儲模塊

作者在最開始做推薦系統時由于沒有經驗，開始將推薦結果存儲在 Mysql 中，當時遇到最大的問題是每天更新用戶的推薦時，需要先找到用戶存儲的位置，再做替換，操作復雜，并且當用戶規模大時，高并發讀寫，大數據量存儲，Mysql 也扛不住，現在最好的方式是采用 CouchBase，Redis 等可以橫向擴容的數據庫，可以完全避開 MySQL 的缺點。

在計算機工程中有“空間換時間”的說法，對于推薦系統來說，就是先計算好每個用戶的推薦，將推薦結果存儲下來，通過預先將推薦結果存下來，可以更快的為用戶提供推薦服務, 提升用戶體驗。由于推薦系統會為每個用戶生成推薦結果, 并且每天都會 (基本全量) 更新用戶的推薦結果，一般采用 NoSql 數據庫來存儲，并且要求數據庫可拓展，高可用，支持大規模并發讀寫。

推薦結果一般不是直接在模型推斷階段直接寫入推薦存儲數據庫，較好的方式是通過一個數據管道 (如 kafka) 來解耦，讓整個系統更加模塊化，易于維護拓展。

Web 服務模塊

該模塊是推薦系統直接服務用戶的模塊，該模塊的主要作用是當用戶在 UI 上觸達推薦系統時，觸發推薦接口，為用戶提供個性化推薦，該模塊的穩定性、響應時長直接影響到用戶體驗。跟上面的推薦存儲模塊類似，Web 服務模塊也需要支持高并發訪問、水平可拓展、亞秒級 (一般 200ms 之內) 響應延遲。

下圖是作者公司相似影片推薦算法的一個簡化版業務流向圖，供大家與上面的模塊對照參考：

相似影片業務流

推薦系統支撐模塊

推薦系統想要很好的穩定的發揮價值，需要一些支撐業務來輔助，這些支撐業務雖然不是推薦系統的核心模塊，但卻是推薦業務穩定運行必不可少的部分，主要包括如下 4 大支撐模塊，下面分別簡述各個模塊的作用和價值。

推薦系統核心支撐模塊

評估模塊

推薦評估模塊的主要作用是評估整個推薦系統的質量及價值產出。一般來說可以從兩個維度來評估。

• 離線評估：主要是評估訓練好的推薦模型的“質量”，模型在上線服務之前需要評估該模型的準確度，一般是將訓練數據分為訓練集和測試集，訓練集用于訓練模型，而測試集用來評估模型的預測誤差。

• 在線評估：模型上線提供推薦服務過程中來評估一些真實的轉化指標，比如轉化率、購買率、點擊率、播放時長等。線上評估一般會結合 AB 測試，先放一部分量，如果效果達到期望再逐步拓展到所有用戶，避免模型線上效果不好嚴重影響用戶體驗和收益指標等。

調度模塊

一個推薦業務要產生價值，所有依賴的任務都要正常運行。推薦業務可以抽象為有向無環圖 (第六節推薦系統架構設計會講到將推薦業務抽象為有向無環圖)，因此需要按照該有向圖的依賴關系依次執行每個任務，這些任務的依賴關系就需要借助合適的調度系統 (比如 Azkaban) 來實現，早期我們采用 Crontab 來調度，當任務量多的時候就不那么方便了，Crontab 也無法很好解決任務依賴關系。

監控模塊

監控模塊解決的是當推薦業務 (依賴的) 任務由于各種原因調度失敗時可以及時告警，通過郵件或者短信通知運維或者業務的維護者，及時發現問題，或者可以在后臺自動拉起服務。同時可以對服務的各種其他狀態做監控，比如文件大小、狀態變量的值、日期時間等與業務正常執行相關的狀態變量，不正常時及時發現問題。

審查模塊

審查模塊是對推薦系統結果數據格式的正確性、有效性進行檢查，避免錯誤產生，一般的處理策略是根據業務定義一些審查用例 (類似測試用例)，在推薦任務執行前或者執行階段對運算過程做 check，發現問題及時告警。舉兩個例子，如果你的 DAU 是 100w，每天大約要為這么多用戶生成個性化推薦結果，但是由于一些開發錯誤，只計算了 20w 用戶的個性化推薦，從監控是無法發現問題的，如果增加推薦的用戶數量跟 DAU 的比例控制在 1 附近這個審查項，就可以避免出現問題；在推薦結果插入數據庫過程中，開發人員升級了新的算法，不小心將數據格式寫錯 (如 Json 格式不合法)，如果不加審查，會導致最終插入的數據格式錯誤，導致接口返回錯誤或者掛掉，對用戶體驗有極大負面影響。

推薦系統范式

推薦系統的目的是為用戶推薦可能喜歡的標的物, 這個過程涉及到用戶、標的物兩個重要要素，我們可以根據這兩個要素的不同組合產生不同的推薦形態，即所謂的不同“范式 (paradigm)”(數學專業的同學不難理解范式，如果不好理解可以將范式看成具備某種相似性質的對象的集合)，根據我自己構建推薦系統的經驗可以將推薦系統總結為如下 5 種范式，這 5 中范式可以應用到產品的各種推薦場景中，后面會拿視頻 APP 舉例說明具體的應用場景。

• 范式 1：完全個性化范式：為每個用戶提供個性化的內容，每個用戶推薦結果都不同；

常見的猜你喜歡就是這類推薦，可以用于進入首頁的綜合類猜你喜歡推薦，進入各個頻道 (如電影) 頁的猜你喜歡推薦。下圖是電視貓首頁興趣推薦，就是為每個用戶提供不一樣的個性化推薦；

• 范式 2：群組個性化范式：首先將用戶分組 (根據用戶的興趣，將興趣相似的歸為一組)，每組用戶提供一個個性化的推薦列表，同一組的用戶推薦列表一樣，不同組的用戶推薦列表不一樣；

這里舉一個在作者公司利用范式 2 做推薦的例子，我們在頻道頁三級列表中，會根據用戶的興趣對列表做個性化重排序，讓與用戶更匹配的節目放到前面，提升節目轉化，但是在實現時，為了節省存儲空間，先對用戶聚類，同一類用戶興趣相似，對這一類用戶，列表的排序是一樣的，但是不同類的用戶的列表是完全不一樣的。見下圖的戰爭風云 tab，右邊展示的節目集合總量不變，只是在不同組的用戶看到的排序不一樣，排序是根據與用戶的興趣匹配度高低來降序排列的。

• 范式 3：非個性化范式：為所有用戶提供完全一樣的推薦；

比如各類排行榜業務，既可以作為首頁上的一個獨立的推薦模塊，方便用戶發現新熱內容，也可以作為猜你喜歡推薦新用戶冷啟動的默認推薦，下圖是搜索模塊當用戶未輸入搜索關鍵詞時給出的熱門內容，也是采用該范式的例子；

• 范式 4：標的物關聯標的物范式：為每個標的物關聯一組標的物，作為用戶在訪問標的物詳情頁時的推薦，每個用戶都是相同的標的物；

當用戶瀏覽一個電影時，可以通過關聯相似的電影, 為用戶提供更多的選擇空間 (下圖就是電視貓電影詳情頁關聯的相似影片)；還可以當用戶播放一個節目退出時，推薦用戶可能還喜歡的其他節目；針對短視頻，可以將相似節目做成連播推薦列表，用戶播放當前節目直接連播相似節目，提升節目分發和用戶體驗；

• 范式 5：笛卡爾積范式：每個用戶跟每個標的物的組合產生的推薦都不相同，不同用戶在同一個視頻的詳情頁看到的推薦結果都不一樣；

該范式跟 4 類似，只不過不同用戶在同一個節目得到的關聯節目不一樣，會結合用戶的興趣，給出更匹配用戶興趣的關聯節目；

由于每個用戶跟每個標的物的組合推薦結果都不一樣, 往往用戶數和標的物的數量都是巨大的, 沒有足夠的資源事先將所有的組合的推薦結果先計算存儲下來，一般是在用戶觸發推薦時實時計算推薦結果呈現給用戶，計算過程也要盡量簡單，在亞秒級就可以算完，比如利用用戶的播放歷史，過濾掉用戶已經看過的關聯節目；

下面給一個簡單的圖示來說明這 5 種范式，讓讀者有一個直觀形象的理解。

推薦算法的 5 種范式

總之，推薦系統不是孤立存在的對象，它一定是要整合到具體的業務中，在合適的產品交互流程中觸達用戶，通過用戶觸發推薦行為。所以，推薦系統要應用到產品中需要嵌入到用戶使用產品的各個流程 (頁面) 中。當用戶訪問首頁時，可以通過綜合推薦（范式 1）來給用戶提供個性化推薦內容，當用戶訪問詳情頁，可以通過相似影片（范式 4）提供相似標的物推薦，當用戶進入搜索頁尚未輸入搜索內容時，可以通過熱門推薦給用戶推送新熱節目 (范式 3)。這樣處處都有推薦，才會使產品顯得更加智能。所有這些產品形態基本都可以用上面介紹的 5 種范式來概括。

推薦系統架構設計

作者在早期構建推薦系統時由于經驗不足，而業務又比較多，當時的策略是每個算法工程師負責幾個推薦業務 (一個推薦業務對應一個推薦產品形態)，由于每個人只對自己的業務負責，所以開發基本是獨立的，每個人只關注自己的算法實現，雖然用到的算法是一樣的，但前期在開發過程中沒有將通用的模塊抽象出來，每個開發人員從 ETL、算法訓練、預測到插入數據庫都是獨立的，并且每個人在實現過程中整合了自己的一些優化邏輯，一竿子插到底，導致資源 (計算資源，存儲資源，人力資源) 利用率不高，開發效率低下。經過幾年的摸索，作者在團隊內部構建了一套通用的算法組件 Doraemon 框架 (就像機器貓的小口袋，有很多工具供大家方便構建推薦業務)，盡量做到資源的節省，大大提升了開發效率。開發過程的蛻變，可以用下面的圖示簡單說明，從中讀者也可以對 Doraemon 架構落地前后的推薦業務開發變化有個大致的了解。

Doraemon 框架前后開發方式對比

作者構建 Doraemon 框架的初衷是希望構建推薦業務就像搭積木一樣 (見下圖)，可以快速構建一套算法體系，快速上線業務。算法或者處理邏輯就像一塊一塊的積木，而算法依賴的數據 (及數據結構) 就是不同積木之間是否可以銜接的“接口”。

本著上面樸素的思想，下面作者詳細說說構建這套體系的思路和策略。

為了支撐更多類型的推薦業務，減少系統的耦合，便于發現和追蹤問題，節省人力成本，方便算法快速上線和迭代，需要設計比較好的推薦系統架構，而好的推薦系統架構應該具備 6 大原則：通用性，模塊化，組件化，一致性，可拓展性，抽象性。下面分別對上述 6 大原則做簡要說明，闡述清楚它們的目標和意義。

通用性：所謂通用，就是該架構具備包容的能力，業務上的任何推薦產品都可以用這一套架構來涵蓋和實現。

模塊化：模塊化的目的在于將一個業務按照其功能做拆分，分成相互獨立的模塊，以便于每個模塊只包含與其功能相關的內容，模塊之間通過一致性的協議調用。將一個大的系統模塊化之后，每個模塊都可以被高度復用。模塊化的目的是為了重用，模塊化后可以方便重復使用和插撥到不同平臺，不同推薦業務邏輯中。

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

組件化和模塊化比較類似，目標分別是為了更好的解耦和重用，就像搭積木一樣構建復雜系統。

一致性：指模塊的數據輸入輸出采用統一的數據交互協議，做到整個系統一致。

可拓展性：系統具備支撐大數據量，大并發的能力，并且容易在該系統中增添新的模塊，提供更豐富的能力，讓業務更加完備自治。

抽象性：將相似的操作和流程抽象為統一的操作，主要目的是簡化系統設計，讓系統更加簡潔通用。針對推薦系統采用數學上的概念抽象如下：

操作 / 算法抽象：我們先對數據處理或者算法做一個抽象，將利用輸入數據通過“操作”得到輸出的的過程抽象為“算子”，按照這個抽象,ETL、機器學習訓練模型、機器學習推斷都是算子。其中輸入輸出可以是數據或者模型。

算法或者操作的算子抽象

業務抽象：任何一個推薦業務可以抽象為由數據 / 模型為節點，算子為邊的“有向無環圖”。下圖是深度學習的算法處理流程，整個算法實現就是一個有向無環圖。

下圖是我們做的一個利用深度學習做電影猜你喜歡的推薦業務流程，整個流程是由各個算子通過依賴關系鏈接起來的，就像一個有向無環圖。

推薦業務的有向無環圖抽象

根據 Doraemon 系統的設計哲學及上面描述的推薦系統的核心模塊，結合業內，一般將推薦系統分為召回 (將用戶可能會喜歡的標的物取出來) 和排序 (將取出的標的物按照用戶喜好程度降序排列，最喜歡的排在前面) 兩個過程，推薦系統可以根據如下方式進行設計。

基礎組件：業務枚舉類型、常量、路徑處理、配置文件解析等。

數據讀入組件：包括從 HDFS、數據倉庫、HBase、Mysql 等相關數據庫讀取數據的操作，將這些操作封裝成通用操作，方便所有業務線統一調用；

數據流出組件：類似數據讀入組件，將推薦結果插入最終存儲 (如 Redis，CouchBase 等) 的操作封裝成算子，我們一般是將推薦結果流入 Kafka，利用 Kafka 作為數據管道，最終再從 Kafka 將數據插入推薦存儲服務器；

算法組件：這個是整個推薦系統的核心。在工程實現過程中，我們將推薦系統中涉及到的算子抽象為 3 個接口， AlgParameters(算子依賴的參數集合)、 Algorithm/AlgorithmEx (具體的算法實現，如果算法依賴模型，采用 AlgorithmEx，比如利用模型做推斷)、Model(算法訓練后的模型，包括模型的導入、導出等接口)。所有的算子實現實現上面 3 個接口的抽象方法。下圖給出了這 3 個接口包含的具體方法以及 Spark mllib 中的矩陣分解基于該抽象的實現。

在我們的業務實踐中，發現上述抽象很合理，基本推薦業務涉及到的所有算子 (ETL、模型訓練、模型推薦、排序框架、數據過濾，具體業務邏輯等) 都可以采用該方式很好的抽象。

評估組件：主要是包括算法訓練過程的離線評估等；

其他支撐組件：比如 AB 測試等，都可以整合到 Doraemon 框架中；

這里要特別說一下數據 (模型)，數據作為算子的輸入輸出，一定要定義嚴格的范式 (具備固定的數據結構，比如矩陣分解訓練依賴的數據有三列，一列用戶 id，一列物品 id，一列用戶對物品的評分)，Spark 的 DataFrame 可以很好的支撐各種數據類型。數據格式定義好后，在算子讀入或者輸出時，可以對類型做校驗，可以很好的避免很多由于業務開發疏忽導致的問題。這有點類似強類型編程語言，在編譯過程 (類似算子) 可以檢查出類型錯誤。

我們將上面的 6 類組件封裝成一個 Doraemon 的 lib 庫，供具體的推薦業務使用。

基于大數據的數據中心和計算中心的抽象, 我們將所有推薦業務中涉及到的數據和算子分別放入數據倉庫和算子倉庫, 開發推薦業務時根據推薦算法的業務流程從這兩個倉庫中拿出對應的“積木”來組裝業務, 參考下圖。

基于 Doraemon 框架的算法組件化開發方式

基于上面的設計原則，推薦業務可以抽象為“數據流”和“算子流”兩個流的相互交織，利用 Doraemon 框架構建一個完善的推薦業務流程如下圖。

基于 Doraemon 框架開發的推薦業務，數據流與算子流相互交織，非常清晰

另外，如果公司做產品線的拓展，比如今日頭條拓展新產品抖音、西瓜視頻、火山小視頻等，可以基于上面所提到的“推薦算法的范式”實現很多推薦業務 (比如猜你喜歡、相似影片、熱門推薦等)，將這些業務封裝到一個 DoraemonBiz.jar 的 jar 包，這樣這些能力可以直接平移到新的產品線，賦能新業務。這種操作就是二次封裝，具有極大的威力，下面給一個形象的圖示來說明這種二次賦能的邏輯，讓大家更好理解這種思想。

通過二次封裝，構建推薦業務單元，賦能到新產品矩陣

從上面的介紹，相信大家已經感受到了 Doraemon 框架的威力了，有了這套框架，我們可以高效的開發算法了，如果有新的技術突破，我們可以將這些新算法實現并封裝到 Doraemon 框架中，不斷拓展 Doraemon 的能力，讓 Doraemon 成長為具備更多技能 (算子) 的巨人！

推薦系統工程實現的設計哲學

要為推薦系統設計一套好用高效的工程框架并不容易，往往需要踩過很多坑，通過多年經驗的積累才能深刻領悟。前面在“推薦系統架構設計”一節已經說了很多構建 Doraemon 框架的設計原則，本節試圖從整個推薦業務工程實現的角度給出一些可供參考的設計哲學, 以便大家可以更好的將推薦系統落地到業務中。

什么是好的推薦系統工程實現？

個人認為好的工程實現需要滿足如下幾個原則：

• 別人很容易理解你的邏輯；

• 按照業務流 / 數據流來組織代碼結構；

• 便于 debug；

• 保證數據存儲、代碼模塊、業務邏輯的一致性；

設計好的推薦系統工程架構的原則？

• 盡量將邏輯拆解為獨立的小單元；

• 代碼單元的輸入輸出定義清晰；

• 設置合適的交互出入口；

• 確定通用一致的數據交互格式；

• 數據存儲、業務功能點、代碼單元保持一一對應；

怎么設計好的推薦系統工程架構？

• 確定思考問題的主線：數據流 or 業務流；

• 畫出業務流或者數據流的架構圖；

• 確定核心功能模塊；

• 根據核心功能模塊組織代碼目錄結構，數據存儲結構；

• 定義清晰明確的數據格式；

下圖是作者團隊開發的深度學習猜你喜歡推薦系統 (基于 Tensorflow 開發) 的業務流程圖, 對應的代碼組織結構和對應的數據在本地文件系統中的存儲結構，基本按照上述設計原則來做，看起來很清晰，方便理解和問題排查。

業務流，數據存儲，代碼工程結構保持對應

近實時個性化推薦

推薦系統在實際業務實現時一般是 T+1 推薦 (每天更新一次推薦，今天利用昨天之前的數據計算用戶的推薦結果)，隨著移動互聯網的深入發展，特別是今日頭條和快手等新聞，短視頻 APP 的流行，越來越多的公司將 T+1 和實時策略相結合 (比如采用流行的 lambda 架構，下圖是一個采用 lambda 架構的推薦架構圖，供參考) 將推薦系統做到了近實時推薦, 根據用戶的興趣變化實時為用戶提供個性化推薦。像新聞、短視頻這類滿足用戶碎片化時間需求的產品，做到實時個性化可以極大提升用戶體驗，這樣可以更好地滿足用戶需求，提升用戶在產品的停留時間。這里我們只是簡單的介紹了一下實時個性化推薦，我在后續的系列文章中會詳細講解實時推薦系統。

推薦系統的 lambda 架構

推薦系統業務落地需要關注的問題

推薦系統要想很好的落地產生價值，除了算法實現、核心模塊和支撐模塊構建外, 還有很多方面需要考慮，下面簡單描述一下其他需要考慮的點, 這些點都是非常重要的, 深入理解這些問題，對真正發揮出推薦系統的價值有非常大的幫助。

二八定律：你的產品可能包含很多推薦模塊，但是在投入精力迭代優化過程中，需要將核心精力放到用戶觸點多的產品 (位置好，更容易曝光給用戶的推薦產品) 上，因為這些產品形態占整個推薦價值產出的絕大部分。這個道理看起來誰都懂，但在實際工作中一直堅守這個原則，還是很難的；

牛逼的算法與工程可實現性易用性之間的平衡：剛從事推薦算法開發的工程師會覺得算法的價值是巨大的，一個牛逼的算法可以讓產品一飛沖天。殊不知很多在頂級會議上發表的絕大多數“高大上”的算法遇到工業級海量數據大規模的分布式計算難以在工程上落地。好的推薦算法一定要是易于工程實現，跟公司當前的技術架構、人員能力、可用資源是匹配的；

推薦系統冷啟動：冷啟動是推薦系統非常重要的一塊，特別是對新產品，這塊設計策略好不好直接影響用戶體驗, 冷啟動有很多實現方案，作者以后會單獨介紹冷啟動的實現策略；

推薦系統的解釋：給用戶提供一個推薦理由有時會達到事半功倍的效果，能夠提升用戶體驗，促進用戶的點擊購買。推薦理由又是很難做的，主要是因為現在很多推薦算法 (特別是深度學習算法) 可解釋性不強，給你做出了推薦可能很精準，但是整個系統無法給你解釋為什么給你推薦。拿推薦系統給你推薦了電影 A 來說明，我們可以從其他的途徑來做解釋， 比如“因為你喜歡 B”(電影 B 跟 A 有一定的相似性)，“今天是國慶節，為你推薦 A”，“今天是雨天，為你推薦 A”，“跟你興趣相似的人都喜歡 A”等等，只要可以挖掘出用戶的行為，場景 (時間，空間，上下文等)，跟推薦的電影的某種聯系，這種聯系都可以作為推薦解釋的理由，不必拘泥于一定要從推薦算法原理中尋找解釋；

推薦系統 UI 設計和交互邏輯：好的產品 UI 和交互邏輯有時比好的算法更管用，推薦算法工程師一定要有這種意識，平時在做推薦系統時，也要往這方面多思考，當前的 UI 及交互是否合理，是否還有更好的方式，多參考或者咨詢一下設計師的思路想法，多體驗一下競品，往往你會有新的收獲。我不是這方面的專家，這里只給大家舉一個電視貓產品的例子 (見下圖)， 好的 UI 交互可以極大提升用戶體驗和點擊。

好的 UI 和交互的價值甚至比好的算法大很多

推薦系統的價值度量：讓推薦系統發揮價值，首先要度量出推薦系統的價值，我們需要將推薦系統的價值量化出來，只有量化出推薦系統的價值，推薦工程師的價值才能夠被公司認可，老板才愿意在推薦系統上投入資源。這里我簡單說一下推薦系統的價值產出方式 (拿視頻推薦舉例說明)。

（1）推薦系統可以提升用戶體驗和留存，讓用戶更快更便捷找到想看的電影，減少找片時間：可以統計出推薦產生的播放量，總播放時長，人均播放時長，這些數值指標跟大盤的平均指標對比，可以體現推薦系統的優勢，推薦系統的這些指標在大盤的占比也可以衡量推薦系統所占的分量；

（2）推薦系統可以創造收益：通過精準推薦會員節目，用戶通過推薦的會員節目購買會員可以產生會員收益；在推薦的節目上做貼片廣告，用戶播放推薦的節目讓廣告曝光，可以產生廣告收益；這兩塊收益需要量化出來，體現出推薦系統支撐商業變現的能力；

推薦系統的技術選型

根據第二節推薦系統與大數據的描述，推薦業務落地依賴大數據技術， 推薦系統的中間過程和結果的存儲需要依賴數據庫，推薦系統接口實現需要依賴 web 服務器。這些方面需要的軟件和技術在前面基本都有簡單介紹，也都有開源的軟件供選擇，對創業公司來說，沒有資源和人力去自研相關技術，選擇合適的開源技術是最好最有效的方案。

本節詳細描述一下推薦系統算法開發所依賴的機器學習軟件選型, 方便大家在工程實踐中參考選擇。

由于推薦系統落地強依賴于大數據相關技術，而最流行的開源大數據技術基于 Hadoop 生態系統，所以推薦算法技術選型要圍繞大數據生態系統來發展，可以無縫的將大數據和人工智能結合起來。

基于大數據生態系統有很多機器學習軟件可以用來開發推薦系統，比如 Apache 旗下的工具 SparkMLlib、Flink-ML、Mahout、Storm、SystemML。以及可以運行在 Hadoop 生態系統上的 DeepLearning4J(Java 深度學習軟件)，TonY（TensorflowonYARN，LinkedIn 開源的），CaffeOnSpark(雅虎開源的)，BigDL(基于 Spark 上的深度學習，Intel 開源的) 等。

隨著人工智能第三次浪潮的到來，以 Tensorflow，Pytorch，MXNet 等為代表的深度學習工具得到工業界的大量采用,Tensorflow 上有關于推薦系統、排序框架的模塊和源代碼，可供學習參考，通過簡單修改可以直接用于推薦業務中。

另外像 xgboost,scikit-learn，H2O，gensim 等框架也是非常流行實用的框架，可以用于實際工程項目中。

國內也有很多開源的機器學習框架，騰訊開源的 Angel(基于參數服務器的分布式機器學習平臺，可以直接運行在 yarn 上)，百度開源的 PaddlePaddle(深度學框架)，阿里開源的 Euler(圖深度學習框架)，X-DeepLearning(深度學習框架)，也值得大家學習參考。

作者所在公司主要采用 SparkMllib，Tensorflow，gensim 等框架來實現推薦系統算法的開發。

至于開發語言，Hadoop 生態圈基本采用 Java/Scala，深度學習生態圈基本采用 Python(Tensorflow、Pytorch 都采用 python 作為用戶使用軟件的開發語言，但它們的底層還是用 C++ 開發的)，所以采用 Java/Scala，Python 作為開發語言有很多開源框架可供選擇，相關的生態系統也很完善。

隨著大數據、云計算、深度學習驅動的人工智能浪潮的發展，越來越多的頂級科技公司開源出很多好用有價值的機器學習軟件工具，可以直接用于工程中，也算是創業公司的福音。

推薦系統的未來發展

隨著移動互聯網、物聯網的發展，5G 技術的商用，未來推薦系統一定是互聯網公司產品的標配技術和標準解決方案，推薦系統會被越來越多的公司采用，用戶也會越來越依賴推薦系統來做出選擇。

在工程實現上，推薦系統會越來越采用實時推薦技術來更快的響應用戶的興趣 (需求) 變化，給用戶強感知，提升用戶體驗，增加公司收益。

個人覺得未來會有專門的開源的推薦引擎出現，并且是提供一站式服務，讓搭建推薦系統成本越來越低。同時隨著人工智能的發展，越來越多的云計算公司會提供推薦系統的 PAAS 或者 SAS 服務 (現在就有很多創業公司提供推薦服務, 只不過還做的不夠完善)，創業公司可以直接購買推薦系統云服務，讓搭建推薦系統不再是技術壁壘，到那時推薦系統的價值將會大放異彩！到那時, 不是每個創業公司都需要推薦算法開發工程師了，只要你理解推薦算法原理, 知道怎么將推薦系統引進產品中創造價值, 就可以直接采購推薦云服務。就像李開復博士最新的暢銷書《AI 未來》中所說的，很多工作會被 AI 取代，所以推薦算法工程師也要有危機意識，要不斷培養對業務的敏感度，對業務的理解，短期是無法被機器取代的，到時候說不定可以做一個推薦算法商業策略師。

小結

本文是作者多年推薦系統學習、實踐經驗的總結，希望能夠幫助到即將入行推薦系統開發的讀者或者推薦系統開發人員，讓大家少走彎路。由于作者才疏學淺，雖殫精竭慮，不當之處在所難免，歡迎大家評判指正，以便作者有所提高！

作者介紹：gongyouliu，有近 10 年大數據與 ai 相關項目經驗，有 9 年推薦系統研究及實踐經驗，目前負責電視貓大數據與人工智能團隊。喜歡讀書，暴走，寫作。業余維護“大數據與人工智能”公眾號，ID：ai-big-data，持續輸出推薦系統相關文章。個人微信：liuq4360

原文鏈接：https://mp.weixin.qq.com/s/hccUo170_8lhdv6C3OzGzw

相關文章：
打造工業級推薦系統（一）：推薦算法工程師的成長之道
打造工業級推薦系統（二）：無處不在的推薦系統

文章版權歸極客邦科技 InfoQ 所有，未經許可不得轉載。 開源大數據AI

總結

以上是生活随笔為你收集整理的打造工业级推荐系统（三）：推荐系统的工程实现与架构优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。