阿里推薦引擎使用總結

智慧推薦系統 2018-12-20 21:21:21

一、阿里推薦引擎概述

推薦引擎（RecommendationEngine，以下簡稱RecEng，特指阿里雲推薦引擎）是在阿里雲端計算環境下建立的一套推薦服務框架，目標是讓廣大中小網際網路企業能夠在這套框架上快速的搭建滿足自身業務需求的推薦服務。

推薦服務通常由三部分組成：日誌採集，推薦計算和產品對接。推薦服務首先需要採集產品中記錄的使用者行為日誌到離線儲存，然後在離線環境下利用推薦演算法進行使用者和物品的匹配計算，找出每個使用者可能感興趣的物品集合後，將這些預先計算好的結果推送到線上儲存上，最終產品在有使用者訪問時通過線上API向推薦服務發起請求，獲得該使用者可能感興趣的物品，完成推薦業務。

RecEng的核心是推薦演算法的定製。RecEng為推薦業務定義了一套完整的規範，從輸入，到計算，到輸出，客戶可以在這個框架下自定義演算法和規則，以此滿足各種行業的需求，包括電商，音樂，視訊，社交，新聞，閱讀等。同時，RecEng也提供了相應的方法供客戶便捷的接入使用者訪問日誌，以及自定義滿足其自身業務需求的線上API。

二、費用

推薦引擎費用如下：

API呼叫次數加1（百萬次／月），則每個月增加100元費用。

大資料計算服務MaxCompute費用分兩種方式，分別是預付費（包年包月）和按量付費，具體如下：

三、使用步驟

3.1 建立MaxCompute專案

3.2 資源管理----新增雲端計算資源

3.3 業務列表----新建業務

此處的大資料計算資源就選擇3.2新增的計算資源。

注：呼叫API介面時的bizCode值即是新建業務時填寫的“業務code”。

業務列表頁面展示已經新增的業務的列表。業務是推薦引擎中的基本管理單元，業務包含基本屬性、資料和場景三類資訊。

業務基本屬性，包含業務code、業務名稱、大資料計算資源和線上儲存資源。業務code是業務的唯一標識，大資料計算資源是您在資源管理中配置的大資料計算服務MaxCompute資源，線上儲存資源是系統內建的線上資源或您在資源管理中配置的表格儲存TableStore資源。

資料，定義了所能使用的資料範圍。例如商品推薦業務的資料範圍是使用者資料、商品資料和行為資料等，視訊推薦業務的資料範圍是使用者資料、視訊資料和行為資料等。在推薦業務中，資料是至關重要的一環，資料的質量決定了推薦效果的上限。

場景，是指在您的APP或網站中使用推薦功能的模組，這些模組直接觸達您的使用者提供推薦服務。例如在商品推薦業務中，商品詳情頁的下方要提供一個相關商品推薦模組，那麼場景就可以描述為”詳情頁商品相關推薦“。場景主要負責演算法的配置和API呼叫，測試環境下的場景用於開發測試，線上環境下的場景用於和您的業務系統對接。

3.4 配置業務資料

3.5 建立推薦場景

測試沒問題可釋出到線上：

線上的場景也可以下線進行測試。

注：呼叫推薦API時，引數scnCode即為此處新建場景時的“場景Code”欄位。

四、資料規範

4.1 資料格式規範

推薦引擎的基礎資料模型如下：

該資料模型總共包括了7張表，這些表有以下特點：

1、在MaxCompute（原來ODPS）中需要自己手工建立這些表；

2、表名沒有固定要求，可以按照自己的習慣命名；

3、每張表的表結構必須符合推薦引擎的要求，列名、欄位型別和分割槽格式需要和規範中保持一致（參考下面的表結構說明）；

4、每張表中填充的資料，必須符合推薦引擎的要求；

5、 每張表中是否都有記錄取決於業務場景和業務資料現狀，其中以下幾張表中必須有資料：使用者資訊表、物品資訊表、使用者行為表；

6、對於業務資料中無法提供的欄位可以填NULL；

7、每張表都必須是分割槽表，以’yyyyMMdd’格式的字元型欄位ds作為分割槽欄位；

8、除了行為表需要每日上傳外，其他meta表如果不發生變化可以不導，推薦引擎會自動獲取最近一個有資料的分割槽中的meta表資料進行演算法計算。

9、如果未傳可推薦物品表，則將物品表全量作為可推薦物品表，繼承item_info 欄位；

10、推薦引擎在對資料進行離線計算時，會產生資料結果資料和中間資料。其中中間資料的資料量大小取決於所使用的離線流程中的演算法複雜度。例如一個標準的協同過濾演算法其中間表資料量可能是原始資料輸入表資料量的5到10倍。推薦引擎預設對中間資料保留一天。

4.2 日誌埋點規範

推薦引擎的日誌格式為標準的JSONObject。其中對於實時行為日誌，可以使用日誌API這個API進行上傳，將每條日誌put到demo中的logs中。

五、附錄（阿里推薦引擎常用詞語及解釋）

• 客戶/租戶（org/tenant）

指RecEng的使用者，系統中由其阿里雲賬號代表。通常客戶是一個組織，RecEng中常用org表示客戶。

• 使用者（user）

指客戶的使用者，即RecEng使用者的使用者。推薦是一個2C的服務，使用推薦服務的客戶必然有其自己的使用者，RecEng使用者的使用者簡稱為“使用者”，系統中常用user表示使用者。

• 物品（item）

指被推薦給使用者的內容，可以是商品，也可以是歌曲，視訊等其他內容，系統中常用item表示物品。

• 業務（biz）

業務針對資料集定義，定義了演算法所能使用的資料範圍。一個客戶在RecEng上可以有多個業務，不同的業務必然有不同的資料集。RecEng要求每個業務提供四類資料（不要求全部提供）：使用者資料，物品資料，使用者行為資料，推薦效果資料。每一組這樣的資料就構成一個業務。系統中常用biz表示業務。

比如某客戶A有兩類被推薦的物品，分別是視訊和歌曲，於是客戶A可以在RecEng上建立兩個業務M和N，其中M的物品資料為視訊，N的物品資料為歌曲，其他的資料（指使用者資料，使用者行為資料等）可以都相同。在這種方案下，業務M和N的資料是獨立的，即業務M雖然能看到使用者對於歌曲的行為，但是業務M中不包含歌曲的物品資料，所以會丟棄使用者對於歌曲的行為；如果業務M中某使用者只對歌曲有行為，對視訊沒有行為，業務M也會丟棄這類使用者。反之對業務N亦然。

一個業務最好只推薦一類物品。多類物品的推薦在後續的行業模板會有支援，需要引入板塊(plate)的概念，一份業務資料可以生成多個板塊的資料集，場景繫結某個板塊進行推薦演算法計算。

• 場景（scn）

場景指的是推薦的上下文，每個場景都會輸出一個API，場景由推薦時可用的引數決定。有兩種場景最為常見，分別是首頁推薦場景和詳情頁推薦場景。顧名思義，在執行首頁推薦時，可用的引數只有使用者資訊；而在執行詳情頁推薦時，可用的引數除了使用者資訊，還包括當前詳情頁上所展示的物品資訊。系統中常用scn表示場景。

一個業務可以包含多個場景，即對於某個業務A，它包含多個首頁場景也是完全可以的。

事實上，回到場景的原始定義，場景只是由推薦的上下文決定，客戶完全可以根據自己的需求建立全新的場景，比如針對搜尋關鍵詞的推薦場景，這時可用的引數除了使用者資訊，還有使用者所輸入的關鍵詞。

• 流程（flow）

演算法流程指資料端到端的處理流程，一部分流程屬於業務範疇，如資料匯入流程，效果計算流程，資料質量分計算流程；一部分屬於場景，比如場景演算法流程。從資料來源型別和產出來劃分，又分為離線流程，近線流程，線上流程。

• 離線流程

一般情況下，離線流程的輸入和輸出都是MaxCompute（原ODPS）表，所以離線資料規範其實上是一組MaxCompute表的格式規範，包括接入資料、中間資料和輸出資料三類資料的格式規範。接入資料指客戶離線提供的使用者、物品、日誌等資料，中間資料是在離線演算法流程中產生的各種中間性質的結果資料表，輸出資料是指推薦結果資料表，該結果最終將會被匯入到線上儲存中，供線上計算模組使用。

• 近線流程

推薦引擎的的近線流程主要處理使用者行為發生變化、推薦物品發生更新時，對離線推薦結果進行更新。不像離線演算法，天然以MaxCompute（原ODPS）表作為輸入和輸出，近執行緒序的輸入資料可以來自多個數據源，如線上的表格儲存（原OTS），以及使用者的API請求，又或者是程式中的變數；輸出可以是程式變數，或者寫回線上儲存，或者返回給使用者。出於安全性考慮，推薦引擎提供了一組SDK供客戶自定義線上程式碼讀寫線上儲存（Table Store），不允許直接訪問，所以需要定義每類線上儲存的別名和格式。對於需要頻繁使用的線上資料，無論其來自線上儲存還是使用者的API請求，RecEng會預先讀好，儲存在線上程式的變數中，客戶自定義程式碼可以直接讀寫這些變數中的資料。

• 線上流程

推薦引擎的的線上流程負責的任務是推薦API接收到API請求時，實時對離線和近線修正產生的推薦結果進行過濾、排重、補足等處理；後者主要處理使用者行為發生變化、推薦物品發生更新時，對離線推薦結果進行更新

一個場景只包含一個離線流程和一個近線流程，可以包含多個線上流程，用於支援A/BTest。

• 演算法策略（Algorithm Strategy）

演算法策略定義了一套離線/近線流程。並且透出相關的演算法引數，幫助客戶構建自己的演算法流程。一個場景可以配置多個演算法策略，最終會合並執行，產出一系列推薦候選集和過濾集，線上流程通過引用這些候選集來完成個性化推薦。

• 作業/任務（task）

作業指執行中的離線流程例項，作業和離線流程的關係完全等同於程序和程式的關係。每個作業都是不可重入的，即對每個離線流程，同一時間只允許執行一份例項。作業直接存在上下游關係，如果上游作業失敗，下游任務也會被取消。