摘要：搭建這個平台最費時耗力的事莫過於對批、流作業的編排，作業組織管理以及任務調度了。但是這一切，用DAYU的數據開發功能幾個任務可通通搞定。
大多數電商類企業都會搭建自己的個性化推薦系統，利用自己擁有的用戶數據、商品數據、用戶行為數據以及各種維度計算得來的標簽畫像計算用戶偏好，推薦最佳商品給用戶，最大化地促進交易。
一個典型的推薦系統包括批處理計算、實時處理層、推薦應用3部分，是典型的Lamda架構。
搭建這個平台最費時耗力的事莫過於對批、流作業的編排，作業組織管理以及任務調度了。但是這一切，用DAYU的數據開發功能幾個任務可通通搞定。當然，你可能會說，不是有專門的個性化推薦雲服務嗎，直接用它不香嗎？這里我們不比賽舉杠鈴，如果企業還不具備利用各種推薦算法的能力，那直接花點錢買推薦服務是最佳選擇；但是你如果想最大化地、持續地優化推薦算法的效果，框架還是自己搭比較靠譜。這里給一個例子，展示如何利用DAYU快速完成一個簡單的推薦系統。除了DAYU的數據開發，還需要搭配華為雲的DLI、DIS、MRS-HBase。
首先介紹下DAYU開發的兩種作業類型：
- 批作業
批作業只能被調度觸發，任務執行一段時間必須結束，換句話說就是任務不能無限時間持續運行。作業是多個算子（一個也可以）組成的Pipeline，Pipeline作為一個整體被調度。 - 實時作業
實時作業這個名字其實不准確，實際上它可以是一個流、批混合的作業，也可以是個純實時流處理作業，也可以是個單純的批作業。作業是由多個算子組成的Pipeline，相對批作業，實時作業中每個算子可單獨被配置調度策略，而且算子啟動的任務可以永不下線，這樣就可以調度那些always online的Flink、SparkStreaming流處理作業。在實時作業里，帶箭頭的連線僅代表業務上的關系，而非任務執行流程，更不是數據流。
這個推薦系統的后台就使用實時作業來實現，一個流、批混合的作業，直接給個全景圖：
這里涵蓋了一個簡單推薦系統的主要計算流程。更多算法的任務流程這里沒有完全展示出來，例如基於模型的算法、基於深入學習的推薦算法，也不包含各種推薦指標的計算過程，有興趣的同學可以百度學習。
整個任務中包括9組數據處理流程，6個批作業流程，3個實時作業：
批處理流程
從上到下，依次計算：
1）基於個用戶特征、標簽計算推薦列表
周期：每天一次
計算：每天通過CDM從RDS抽取用戶數據到DLI，基於每個用戶的基本信息，年齡、性別、職業、收入、地域等等各種屬性信息，以及來自360度畫像系統的標簽信息，生成推薦列表，保存到HBase中。
2）基於商品的相似性特征，計算推薦列表
周期：每天一次
計算：每天通過CDM從RDS抽取新增商品信息到DLI，然后計算出來的基於商品相似特征的推薦列表，存入HBase中。
3）計算當天用戶的偏好，生成日推薦列表
周期：每天一次
計算：通過DIS dump轉儲任務，把網站實時搜集的用戶行為信息轉儲到OBS中，通過一批Spark算法（批量的用戶協同、商品協同、基於內容相似性、LR等算法），基於一天的行為數據計算推薦列表。然后把列表推到HBase中。
4）計算本周用戶的偏好，生成周推薦列表
周期：每天一次
計算：計算行為同上，區別是基於一周的行為數據計算推薦列表。
5）計算3個月內的偏好，生成長期偏好推薦列表
周期：每天一次
計算：計算行為同上，區別是基於3個月的行為數據計算推薦列表。
6）計算流行產品的列表
周期：每天或者數小時
計算：通過用戶總體商品的點擊、搜索、評分等行為，基於OBS上用戶的行為數據，按類別計算熱門商品Top50。這個列表也可作為補齊列表，當其他推薦列表還不足以填滿網站的推薦位，可以用這個列表補齊。
實時流處理流程
1）實時計算用戶偏好--Item-Based協同算法
計算：通過Flink任務對DIS用戶行為通道的數據進行消費，先把用戶行為日志轉換為標准行為（Time,userid,ItemID,Score)，再通過流式Item-Based協同算法計算推薦列表，更新到HBase中。
2）實時計算用戶偏好--User-Based協同算法
計算：同上，區別是使用流式User-Based協同算法計算推薦列表，更新到HBase中。
3）實時計算用戶偏好--Content-Based算法
計算：同上，區別是使用流式Content-Based協同算法計算推薦列表，更新到HBase中。
以上一頓操作，在HBase中會有一堆以UserID、Item為Key的推薦列表，形如：
用戶推薦列表結果：
userid_001:item100, item899, item 433, item 666,....
userid_002:item220, item334, item 720 item 666,....
userid_003:item728, item899, item 333, item 632,....
根據用戶實時行為、歷史行為不同周期，有若干組不同的推薦列表。
基於商品的推薦列表結果：
Item_0001: Item1000,Item333,time5213,...
Item_0002: Item1000,Item333,time5213,...
Item_0003: Item1000,Item333,time5213,...
另外，推薦系統平台還需要一個提供rest接口的服務，供web網站推薦位調用。當用戶打開網頁時，自動向該服務請求當前用戶的推薦列表，服務訪問HBase，獲取前面作業計算出來的多個推薦列表，並按一定策略組合成一個推薦列表返回給網頁，就此，完成了一個端到端的推薦業務流程。
一個完整的推薦系統要更復雜一些，這里並沒有討論推薦系統的專題內容。從例子可以看出DAYU具備強大的編排和調度能力，單單一個任務就可以涵蓋非常復雜的場景。實時上，大型的推薦系統平台還是需要針對性的定制，因為涉及到一些管理上的流程需要應對、閉環。不過基於華為雲體系下各種平台、應用，有了DAYU這個助手，數據相關的方方面面的事務處理，將變得既簡潔又高效。
本文分享自華為雲社區《基於DAYU的實時作業開發，分分鍾搭建企業個性化推薦平台》，原文作者：Loading... 。