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

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

你們接觸推薦系統的機率會愈來愈大。做爲程序員，瞭解推薦系統也愈來愈必要，甚至能夠主動選擇「推薦系統算法工程師」的相關職位。那你們必定會關心推薦算法工程師須要哪些知識儲備，以及做爲一個推薦算法工程師，將來的發展道路怎樣？

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

推薦系統與大數據

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

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

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

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

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

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

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

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

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

1. 數據收集模塊

構建推薦模型須要收集不少數據，包括用戶行爲數據，用戶相關數據及推薦「標的物」相關數據。若是將推薦系統比喻爲廚師作菜，那麼這些數據是構建推薦算法模型的原材料。巧婦難爲無米之炊, 要構建好的推薦算法收集到足夠多的有價值的數據是很是關鍵和重要的。

2. ETL 模塊

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

用戶相關數據及推薦「標的物」相關數據通常是結構化的數據，通常是經過後臺管理模塊將數據存儲到 MySQL、ProgreSQL 等關係型數據庫中。

3. 特徵工程模塊

推薦系統採用各類機器學習算法來學習用戶偏好，並基於用戶偏好來爲用戶推薦「標的物」, 而這些推薦算法用於訓練的數據是能夠「被數學所描述」的，通常是向量的形式，其中向量的每個份量 / 維度就是一個特徵，因此特徵工程的目的就是將推薦算法須要的，以及上述 ETL 後的數據轉換爲推薦算法能夠學習的特徵。

固然，不是全部推薦算法都須要特徵工程，好比，若是要作排行榜相關的熱門推薦，只須要對數據作統計排序處理就能夠了。最經常使用的基於物品的推薦和基於用戶的推薦也只用到用戶 id，標的物 id，用戶對標的物的評分三個維度，也談不上特徵工程。像 logistic 迴歸等複雜一些的機器學習算法須要作特徵工程，通常基於模型的推薦算法都須要特徵工程。

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

4. 推薦算法模塊

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

好的推薦工程實現，但願儘可能將這兩個過程解耦合，作到通用，方便用到各類推薦業務中，後面在推薦系統架構設計一節中會詳細講解具體的設計思路和哲學。

5. 推薦結果存儲模塊

做者在最開始作推薦系統時因爲沒有經驗，開始將推薦結果存儲在 Mysql 中，當時遇到最大的問題是天天更新用戶的推薦時，須要先找到用戶存儲的位置，再作替換，操做複雜，而且當用戶規模大時，高併發讀寫，大數據量存儲，Mysql 也扛不住，如今最好的方式是採用 CouchBase，Redis 等能夠橫向擴容的數據庫，能夠徹底避開 MySQL 的缺點。

在計算機工程中有「空間換時間」的說法，對於推薦系統來講，就是先計算好每一個用戶的推薦，將推薦結果存儲下來，經過預先將推薦結果存下來，能夠更快的爲用戶提供推薦服務, 提高用戶體驗。因爲推薦系統會爲每一個用戶生成推薦結果, 而且天天都會 (基本全量) 更新用戶的推薦結果，通常採用 NoSql 數據庫來存儲，而且要求數據庫可拓展，高可用，支持大規模併發讀寫。

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

6. Web 服務模塊

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

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

類似影片業務流

推薦系統支撐模塊

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

推薦系統核心支撐模塊

1. 評估模塊

推薦評估模塊的主要做用是評估整個推薦系統的質量及價值產出。通常來講能夠從兩個維度來評估。

• 離線評估：主要是評估訓練好的推薦模型的「質量」，模型在上線服務以前須要評估該模型的準確度，通常是將訓練數據分爲訓練集和測試集，訓練集用於訓練模型，而測試集用來評估模型的預測偏差。

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

2. 調度模塊

一個推薦業務要產生價值，全部依賴的任務都要正常運行。推薦業務能夠抽象爲有向無環圖 (第六節推薦系統架構設計會講到將推薦業務抽象爲有向無環圖)，所以須要按照該有向圖的依賴關係依次執行每一個任務，這些任務的依賴關係就須要藉助合適的調度系統 (好比 Azkaban) 來實現，早期咱們採用 Crontab 來調度，當任務量多的時候就不那麼方便了，Crontab 也沒法很好解決任務依賴關係。

3. 監控模塊

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

4. 審查模塊

審查模塊是對推薦系統結果數據格式的正確性、有效性進行檢查，避免錯誤產生，通常的處理策略是根據業務定義一些審查用例 (相似測試用例)，在推薦任務執行前或者執行階段對運算過程作 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 大原則作簡要說明，闡述清楚它們的目標和意義。

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

2. 模塊化：模塊化的目的在於將一個業務按照其功能作拆分，分紅相互獨立的模塊，以便於每一個模塊只包含與其功能相關的內容，模塊之間經過一致性的協議調用。將一個大的系統模塊化以後，每一個模塊均可以被高度複用。模塊化的目的是爲了重用，模塊化後能夠方便重複使用和插撥到不一樣平臺，不一樣推薦業務邏輯中。

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

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

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

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

6. 抽象性：將類似的操做和流程抽象爲統一的操做，主要目的是簡化系統設計，讓系統更加簡潔通用。針對推薦系統採用數學上的概念抽象以下：

操做 / 算法抽象：咱們先對數據處理或者算法作一個抽象，將利用輸入數據經過「操做」獲得輸出的的過程抽象爲「算子」，按照這個抽象,ETL、機器學習訓練模型、機器學習推斷都是算子。其中輸入輸出能夠是數據或者模型。

算法或者操做的算子抽象

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

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

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

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

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

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

3. 數據流出組件：相似數據讀入組件，將推薦結果插入最終存儲 (如 Redis，CouchBase 等) 的操做封裝成算子，咱們通常是將推薦結果流入 Kafka，利用 Kafka 做爲數據管道，最終再從 Kafka 將數據插入推薦存儲服務器；

4. 算法組件：這個是整個推薦系統的核心。在工程實現過程當中，咱們將推薦系統中涉及到的算子抽象爲 3 個接口， AlgParameters(算子依賴的參數集合)、 Algorithm/AlgorithmEx (具體的算法實現，若是算法依賴模型，採用 AlgorithmEx，好比利用模型作推斷)、Model(算法訓練後的模型，包括模型的導入、導出等接口)。全部的算子實現實現上面 3 個接口的抽象方法。下圖給出了這 3 個接口包含的具體方法以及 Spark mllib 中的矩陣分解基於該抽象的實現。

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

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

6. 其餘支撐組件：好比 AB 測試等，均可以整合到 Doraemon 框架中；

這裏要特別說一下數據 (模型)，數據做爲算子的輸入輸出，必定要定義嚴格的範式 (具有固定的數據結構，好比矩陣分解訓練依賴的數據有三列，一列用戶 id，一列物品 id，一列用戶對物品的評分)，Spark 的 DataFrame 能夠很好的支撐各類數據類型。數據格式定義好後，在算子讀入或者輸出時，能夠對類型作校驗，能夠很好的避免不少因爲業務開發疏忽致使的問題。這有點相似強類型編程語言，在編譯過程 (相似算子) 能夠檢查出類型錯誤。

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

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

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

基於上面的設計原則，推薦業務能夠抽象爲「數據流」和「算子流」兩個流的相互交織，利用 Doraemon 框架構建一個完善的推薦業務流程以下圖。

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

另外，若是公司作產品線的拓展，好比今日頭條拓展新產品抖音、西瓜視頻、火山小視頻等，能夠基於上面所提到的「推薦算法的範式」實現不少推薦業務 (好比猜你喜歡、類似影片、熱門推薦等)，將這些業務封裝到一個 DoraemonBiz.jar 的 jar 包，這樣這些能力能夠直接平移到新的產品線，賦能新業務。這種操做就是二次封裝，具備極大的威力，下面給一個形象的圖示來講明這種二次賦能的邏輯，讓你們更好理解這種思想。

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

從上面的介紹，相信你們已經感覺到了 Doraemon 框架的威力了，有了這套框架，咱們能夠高效的開發算法了，若是有新的技術突破，咱們能夠將這些新算法實現並封裝到 Doraemon 框架中，不斷拓展 Doraemon 的能力，讓 Doraemon 成長爲具有更多技能 (算子) 的巨人！

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

要爲推薦系統設計一套好用高效的工程框架並不容易，每每須要踩過不少坑，經過多年經驗的積累才能深入領悟。前面在「推薦系統架構設計」一節已經說了不少構建 Doraemon 框架的設計原則，本節試圖從整個推薦業務工程實現的角度給出一些可供參考的設計哲學, 以便你們能夠更好的將推薦系統落地到業務中。

1. 什麼是好的推薦系統工程實現？

我的認爲好的工程實現須要知足以下幾個原則：

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

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

• 便於 debug；

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

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

• 儘可能將邏輯拆解爲獨立的小單元；

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

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

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

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

3. 怎麼設計好的推薦系統工程架構？

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

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

• 肯定核心功能模塊；

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

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

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

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

近實時個性化推薦

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

推薦系統的 lambda 架構

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

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

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

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

3. 推薦系統冷啓動：冷啓動是推薦系統很是重要的一塊，特別是對新產品，這塊設計策略好很差直接影響用戶體驗, 冷啓動有不少實現方案，做者之後會單獨介紹冷啓動的實現策略；

4. 推薦系統的解釋：給用戶提供一個推薦理由有時會達到事半功倍的效果，可以提高用戶體驗，促進用戶的點擊購買。推薦理由又是很難作的，主要是由於如今不少推薦算法 (特別是深度學習算法) 可解釋性不強，給你作出了推薦可能很精準，可是整個系統沒法給你解釋爲何給你推薦。拿推薦系統給你推薦了電影 A 來講明，咱們能夠從其餘的途徑來作解釋， 好比「由於你喜歡 B」(電影 B 跟 A 有必定的類似性)，「今天是國慶節，爲你推薦 A」，「今天是雨天，爲你推薦 A」，「跟你興趣類似的人都喜歡 A」等等，只要能夠挖掘出用戶的行爲，場景 (時間，空間，上下文等)，跟推薦的電影的某種聯繫，這種聯繫均可以做爲推薦解釋的理由，沒必要拘泥於必定要從推薦算法原理中尋找解釋；

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

好的 UI 和交互的價值甚至比好的算法大不少

6. 推薦系統的價值度量：讓推薦系統發揮價值，首先要度量出推薦系統的價值，咱們須要將推薦系統的價值量化出來，只有量化出推薦系統的價值，推薦工程師的價值纔可以被公司承認，老闆才願意在推薦系統上投入資源。這裏我簡單說一下推薦系統的價值產出方式 (拿視頻推薦舉例說明)。

（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