本文來自《大數據專場：阿里云數加平臺》，阿里云技術專家鄭重(盧梭)題為“21天搭建推薦系統”的重要演講。
我們特別整理了鄭重的演講稿，其中有搭建一個個性化推薦系統所需的環境準備、基本配置和離線技術等基本功能的搭建，也有效果報表、算法優化和實時修正等高級功能的剖析，讓我們一起先睹為快吧。
大數據有三個非常經典的應用：計算廣告、搜索、推薦。每一種應用最核心的地方都離不開三個字——個性化。廣告不用說了，計算廣告的基本要求就是要精準，為廣告選擇對其感興趣的目標受眾;搜索可以理解為對搜索關鍵詞的個性化;而推薦，則需要在用戶和物品之間建立興趣關系。推薦的業態比較復雜，有類似淘寶天貓這樣的真正意義上大數據場景，也有很多中小網站、應用，數據量其實并不是很大。阿里云推薦引擎的初衷，是為了幫助阿里云的客戶、創業者、中小網站，讓他們能夠更好的運營自己的產品或網站。
推薦系統一般包括展現子系統、日志子系統和算法子系統三個部分，三者互為一體。
推薦系統
“展現”部分不僅要負擔展現，還是數據采集的窗口，用戶在展現系統的所有行為通過日志錄入，采集到的數據經過算法子系統的計算，可以得到用戶的偏好或者個性化興趣，然后回過頭來指導“展現”部分怎樣做的更聚焦。
阿里云推薦引擎(RecEng)是推薦系統的一部分，主要實現的是算法子系統，需要和其他子系統配合工作。
使用阿里云推薦引擎分為兩大階段
第一階段：基本功能的搭建
Day1. 環境準備
環境準備
環境準備分為兩部分。圖中左側為云上資源的準備，我們需要擁有阿里公有云賬號，然后開通云監控服務(可選)和阿里云數加服務(必選);開通數加賬號后，大數據計算服務(MaxCompute，原名ODPS)和大數據開發Data IDE就默認開通了(Data IDE相當于MaxCompute的可視化包裝)，最后開通推薦引擎。未來客戶在推薦引擎中用到的數據，以及相關離線計算，都在客戶自己的MaxCompute項目中完成。右側為客戶側的準備，前端的展現，以及日志的采集和管理都需要客戶自己完成，通過推薦引擎提供的API與推薦引擎進行交互。通常情況下，客戶側的后臺相關功能會集中在推薦服務器中實現，這也是阿里云推薦引擎墻裂建議的方案。推薦服務器可以是客戶自己的物理機，也可以是阿里云的虛擬機ECS，都是可以的。
Day2-3. 數據準備
DT時代的基本要求是數據要能夠“存、通、用”。采集日志，并將其上傳到公共云實現了數據“存”的過程;推薦引擎負責解決數據的“通”和“用”。“用”比較好理解，“通”則指的是所有進入推薦引擎的數據必須滿足推薦引擎所定義的格式規范。推薦有三類數據：用戶數據、物品數據和行為數據，我們定義了這三種表的格式規范，比較簡單。
那么，如何把數據傳到公共云上來呢?目前主要有兩種方法，一是利用集成在MaxCompute console中的Tunnel命令，該命令的缺點只能上傳文本格式數據;另一種方法是定制DataX上傳，DataX作為連接各種數據庫中間的節點，它除了可以作為文本上傳，還可以把各種數據庫打通。DataX的缺點是目前只能在Linux環境下運行。
當然，未必每一個業務的數據都滿足規范的要求，所以還需要做一些格式轉換。Data IDE提供了比較友好的格式轉換界面，還可以把配置好的任務設置為定時任務，每天定時調度;也可以在MaxCompute console下直接執行格式轉換的SQL腳本，再利用系統的crontab命令實現定時任務。
Day4-5. 基本配置和離線計算
環境和數據都準備好了之后，接下來需要進入阿里云推薦引擎產品，真正開始使用推薦引擎了。不過在此之前，還需要對產品中的一些關鍵概念進行必要的說明。
第一個概念是業務。在阿里云推薦引擎中，業務指的是一組可被用來進行推薦算法計算的完備數據集，包括物品表、行為表、用戶表這三張表。也可以簡單的認為這三張表就構成了一個業務。
第二個概念是場景，所謂場景就是推薦的上下文。換句話說，就是在進行推薦時有哪些可用的參數。比如在進行首頁推薦的時候，可用的參數只有用戶的ID;在進行詳情頁推薦的時候，可用的參數除了用戶ID，還可以由詳情頁上展示的物品ID，這樣首頁推薦和詳情頁推薦就是兩個推薦的場景。一個業務可以包括多個場景。
第三個概念是算法流程，算法流程指的是數據端到端的處理流程，從客戶的輸入數據開始，到產出最終結果為止。推薦算法流程從屬于場景，一個場景可以包含多個算法流程。每個推薦算法流程都包括兩部分，離線計算流程和在線計算流程。離線計算流程負責從原始的業務數據(用戶、物品、行為)開始，計算用戶對物品的興趣，輸出本場景下用戶可能會感興趣的物品集合;在線計算流程實時接受推薦請求，從離線計算流程得到的物品集合中根據業務規則挑選出最合適的若干個物品返回給請求方。一個場景包含多個推薦算法流程這種設定使得我們在做效果對比變的比較容易，后面會介紹A/B Testing，在A/B Testing中，每個推薦算法流程都是一個可被效果指標度量的最小單元。在做完A/B Testing之后，通常只會在一個場景下保留一個效果最好的推薦算法流程。
產品里的配置都比較簡單，配置業務基本信息、配置業務依賴的云資源、配置業務數據表，接著配置場景、配置API參數，最后配置算法流程，阿里云推薦引擎提供了兩個默認的推薦算法流程模板，分別針對首頁場景和詳細頁場景，圖為首頁場景的離線計算流程模板，圖中每一個節點就是一個算法，最終產出離線計算結果。
Day6-8. 推薦API集成
推薦API集成
到了這一步，云端推薦引擎里的推薦算法邏輯已經配置完成，剩下的事情就是把系統串起來，讓推薦引擎和日志、展示兩個子系統結合起來，成為推薦系統。阿里云推薦引擎提供了一組API，這里要做的就是把這些API集成到推薦服務器中。
首先需要把離線數據傳上來，可以用前面提到的方法，Tunnel啊，DataX啊，都可以，但是一定要是定時任務，我們總不能每天都去手工執行數據上傳。上傳完成之后首先調用數據預處理API，對數據做一些預處理;然后調用離線計算API，啟動離線計算。待離線計算完成后，通過推薦API就可以實時獲取用戶的推薦結果了。在離線計算的過程中，還可以通過查看計算任務狀態API實時獲取計算任務的狀態，便于及時發現異常。
上圖也展示了我們對推薦服務器的一些基本建議。諸如數據上傳、啟動離線計算這些功能建議由一個相對獨立的數據管理組件來負責;而實時性要求比較高的推薦結果獲取建議由專門的推薦管理組件來負責。推薦管理組件和數據管理組件為什么要有一個交互呢?這是因為從推薦引擎返回的結果中可能只包括了物品的ID，展示時不能只展示一個ID，還有很多材料，這些東西可以放在推薦服務器中，由數據管理模塊負責管理。UI可以提供人工管理數據的界面，比如新錄入了一個物品，或者某個物品賣完了要下線，需要做實時修正時就可以用到了。
這些工作都完成之后，一個具備最基本功能的推薦系統就可以運行起來了。
第二階段：高級功能的搭建
Day9-11. 效果報表
Trace ID的生命周期
推薦系統run起來了之后，也意味著我們從系統搭建階段進入了運營階段。運營階段最關心的就是效果，度量效果的東西，就是指標。用戶在訪問網站或者應用時會留下很多行為日志，在度量推薦系統的效果時，我們只關心和推薦有關的行為。為了和其他無關的行為區分開來，阿里云推薦引擎在每次推薦API的返回結果中都附帶有一個Trace ID(這次推薦API返回的所有物品共享這一個Trace ID)，客戶需要按照一定的規范把這些Trace ID埋入日志，這樣才能利用阿里云推薦引擎提供的效果報表功能。
Trace ID的埋點有三個原則：其一是在推薦列表展示時，需要把對應的Trace ID埋入推薦列表中所有物品的鏈接里;其二是如果用戶點擊了包含有Trace ID的物品鏈接，需要把這個Trace ID帶入下一個頁面，且要在新頁面中所有該物品的鏈接里都埋入這個Trace ID;其三是如果用戶點擊了不含Trace ID的物品，或點擊了包含有其他Trace ID的物品鏈接，之前的Trace ID失效。
完成了Trace ID的埋點，就可以使用阿里云推薦引擎的效果報表功能了，首先需要按照以下步驟在阿里云推薦引擎中進行配置：
1. 定義/選擇效果算法。系統默認提供了一些用于計算效果指標的算法，如統計PV，UV，計算不同行為的轉化率等，客戶也可以開發自定義效果算法，開發完成后注冊到推薦引擎即可
2. 定義效果指標。效果算法不針對具體的行為類型，而定義效果指標則需要明確行為類型，比如瀏覽的PV，點擊的UV等
3. 選擇效果指標，定義效果指標計算任務。有可能不是所有定義出來的效果指標都有必要計算出來，阿里云推薦引擎允許客戶做一次篩選，推薦引擎會針對客戶的篩選結果自動生成指標計算任務。
4. 定制效果報表。就是選擇效果指標的展示方式，餅圖折線圖之類的，比較簡單。
最后，按照慣例，需要在推薦服務器中把啟動效果計算任務的API集成進來，每天定時啟動，自動生成每日的效果報表。
Day12-15. 優化
優化的目標可以有很多種，對于業務來講，最關心的莫過于提升各種轉換率指標。前面的效果指標為我們提供了轉換率的度量方法，以此為基礎，通過A/B Testing來比較不同推薦算法流程的轉換效果，從中選擇最優的結果。到了這一步，問題就歸結為如果去構造不同的推薦算法流程，這樣我們才能夠進行比較和選擇。
算法流程
前面已經介紹過，推薦算法流程分為離線和在線兩部分，上圖進一步給出了離線、在線算法流程的內部細節，圖中的曲邊矩形表示數據(集)，矩形表示算法(集)。具體每個節點的技術細節就不展開了，重點想說明的是阿里云推薦引擎中每個算法，對其輸入和輸出的數據，都有明確的格式要求，客戶可以根據業務需求按照規范要求自行實現。對于任何滿足輸入輸出數據格式規范的算法，在算法流程中都是可以互相替換的，這樣可以構造出不同的算法流程，從而進行對比和優化。
Day16-20. 實時修正
阿里云推薦引擎支持兩類實時修正，分別通過數據修正API和實時的用戶行為日志提交到推薦引擎。數據修正API一般用來解決物品的實時變更需求，比如有新物品上線，或者老物品下架，需要及時調整;利用用戶行為日志的修正一般用來調整用戶的興趣偏好，根據用戶實時行為進行更有針對性的推薦。阿里云推薦引擎會提供默認的修正算法，客戶也可以根據業務需求自己定義。
按照慣例，如果要使用實時修正功能，需要在推薦系統中接入相應的API：數據更新API和實時日志API。
Day21. 監控和告警
最后是監控和報警。開通云監控后，我們還需要做一些配置，首先配置自定義監控項(按照文檔配置即可)，可得到該監控項的云監控code，把云監控code注冊到推薦引擎。然后添加監控人員報警組和設置報警規則。監控默認對于任務計算失敗或者數據異常給出告警。阿里云推薦引擎會對每一張數據表上都掛有一個數據質檢算法，用于檢查表中數據是否合格。數據是否合格取決于所使用的算法，如果客戶有自定義算法，可以自己編寫相應的數據質檢算法，并掛載到對應的數據表上。
未來工作和總結
阿里云推薦引擎還有很多需要完善和優化的地方，接下來我們將著重于以下兩點：
簡化基于規則的推薦：很多客戶數據量不是很大，算法起到的作用很有限，一定要能夠適應到小客戶的需求，方便客戶發現數據中的規則，結合業務和運營積累的知識，將其應用在推薦系統中。
提供更多的算法：實現更多的推薦算法，針對行業的算法模板(視頻、音頻、O2O、電商等)。
簡單的總結一下：阿里云推薦引擎的特點是接入簡單便捷，算法開放。
目標：讓客戶專注于推薦業務，不再被系統問題困擾。
方法：通用的推薦引擎，集中實現與業務無關的內容。
效果：推薦是個系統工程，算法很重要，但不是全部。
以上就是我的全部分享內容，謝謝大家。
