簡介：整理自 5 月 29 日 阿里云開發者大會，秦江杰和劉童璇的分享，內容包括實時推薦系統的原理以及什么是實時推薦系統、整體系統的架構及如何在阿里云上面實現，以及關于深度學習的細節介紹

本文整理自 5 月 29 日阿里云開發者大會，大數據與 AI 一體化平臺分論壇，秦江杰和劉童璇帶來的《基于實時深度學習的推薦系統架構設計和技術演進》。分享內容如下：

實時推薦系統的原理以及什么是實時推薦系統

整體系統的架構及如何在阿里云上面實現

關于深度學習的細節介紹。

GitHub 地址
https://github.com/apache/flink
歡迎大家給 Flink 點贊送 star~

一、實時推薦系統的原理

在介紹實時推薦系統的原理之前，先來看一個傳統、經典的靜態推薦系統。

用戶的行為日志會出現在消息隊列里，然后被ETL到特征生成和模型訓練中。這部分的數據是離線的，離線的模型更新和特征更新會被推到在線系統里面，比如特征庫和在線推理的服務中，然后去服務在線的搜索推廣應用。這個推薦系統本身是一個服務，前端展示的服務推廣應用可能有搜索推薦、廣告推薦等。那么這個靜態系統到底是怎么工作的？我們來看下面的例子。

1. 靜態推薦系統

截取現在用戶的行為日志，倒入離線系統中去做特征生成和模型訓練，這段日志表示用戶 1 和用戶 2 同時瀏覽了 page#200 這個頁面和其他一些頁面，其中用戶 1 瀏覽了 page#100 并且點擊了 ads#2002。那么這個日志會被 ETL 到離線，然后送去做特征生成和模型訓練。生成的特征和模型里面會看到，用戶 1 和用戶 2 都是中國男性用戶，“中國男性”是這兩個用戶的一個特征，這個學習模型最終結果是：中國男性用戶瀏覽了 page#100 的時候，需要給他推 ads#2002。這里面的邏輯就是把相似用戶的行為歸到一起，說明這類用戶應該有同樣的行為。

用戶特征推進特征庫建立的模型，在推送至在線服務里的時候如果有一個用戶 4 出現，在線推理的服務就會到特征庫里面去查這個用戶的特征，查到的特征可能是這個用戶正好是中國的男性用戶，模型之前學到了中國男性用戶訪問 page#100 時候要推 ads#2002，所以會根據學習模型給用戶 4 推薦了 ads#2002。以上就是靜態推薦系統的基本工作流程。

但是這個系統也有一些問題，比如第一天的模型訓練完成后，發現用戶 4 第二天的行為其實跟用戶 3 更像，不是和用戶 1、用戶 2 類似 。但是之前模型訓練的結果是中國男性用戶訪問 page#100 時候要推 ads#2002，并且會默認進行這種推薦。只有經過第二次模型計算后才能發現用戶 4 和用戶 3 比較像，這時再進行新的推薦，是有延遲的。這是因為模型和特征都是靜態的。

對于靜態推薦系統來講，特征和模型都是靜態生成的。比如以分類模型為例，根據用戶的相似度進行分類，然后假設同類用戶都有相似的行為興趣和特征，一旦用戶被化成了某一類，那么他就一直在這個類別中，直到模型被重新訓練。

2. 靜態推薦系統問題

• 第一，用戶行為其實是非常多元化的，沒有辦法用一個靜態的事情去描述這個用戶的行為。
• 第二，某一類用戶的行為可能比較相似，但是行為本身發生了變化。例如中國男性用戶訪問page#100時候要推ads#2002，這是昨天的行為規律；但是到了第二天的時候發現不是所有的中國男性用戶看到page#100時候都會點擊ads#2002。

3. 解決方案

3.1 加入實時特征工程后能夠靈活推薦

在推薦系統中加入實時特征工程，把消息隊列里面的消息讀一份出來，然后去做近線的特征生成。舉個例子，中國男性用戶最近訪問 page#100 的時候點擊最多的 10 個廣告，這件事情是實時去追蹤的。就是說中國男性用戶最近 10 分鐘或者半個小時之內訪問 page#100 的時候點的最多 10 個廣告，個事情不是從昨天的歷史數據里面得到的信息，而是今天的用戶實時行為的數據，這就是實時特征。

有了這個實時特征以后，就能解決剛才那個隨大流的問題。同樣的，如果這里的特征是對某一個用戶最近 3 分鐘或者 5 分鐘的行為采集的，就能夠更加準確的追蹤到這個用戶當時當刻的意圖，并且給這個用戶去做更準確的推薦。

所以說，在推薦系統中加入實時特征后能精準推薦。比如剛才的例子，如果用戶 4 在這個情況下訪問 page#100，新的學習內容為：中國男性用戶最近訪問 page#100 的時候，點的最多的是 ads#2001。那我們會直接推薦 ads#2001，而不是按照昨天的信息給他推 ads#2002。

3.2 實時特征推薦體系的局限性

之前的用戶 1 和用戶 2 的行為是非常相似的，加了實時特征就能知道它當前的意圖。但是，如果用戶 1 和用戶 2 在做相同的特征時，他們的行為產生了不一致；也就是說在模型里面被認為是同一類的用戶，他們的行為產生分化了，變成了兩類用戶。如果是靜態的模型，即使加入了實時特征，也無法發現這一類新的用戶；需要對模型進行重新訓練以后，才能夠產生一個新的分類。

加入實施特征工程推薦系統后，可以追蹤某一類用戶的行為，貼合一個大流的變化；也可以實時追蹤用戶的表現，了解用戶當時的意圖。但是當模型本身的分類方式發生變化的時候，就沒有辦法找到最合適的分類了，需要重新對訓練模型進行分類，這種情況會遇到很多。

比如說當有很多新產品上線時，業務在高速增長，每天都會產生很多的新用戶，或者說用戶行為分布變化得比較快。這種情況下即使使用了實時特征系統，由于模型本身是一個逐漸退化的過程，也會導致昨天訓練的模型今天再放到線上去，不一定能夠 work 的很好。

3.3 解決方案

在推薦系統中新增兩個部分：近線訓練和近線樣本生成。

假設有用戶 1 和用戶 2 分別是上海和北京的用戶，這個時候會發現之前的模型不知道上海和北京的用戶是有區別的，它認為都是中國男性用戶。而在加入實時訓練這個模型后，就會逐漸的學習北京的用戶和上海的用戶，兩者的行為是有區別的，確認這一點后再進行推薦就會有不一樣的效果。

再比如說，今天北京突然下暴雨了或者上海天氣特別熱，這個時候都會導致兩邊用戶的行為不太一樣。這時再有一個用戶 4 過來，模型就會分辨這個用戶是上海還是北京的用戶。如果他是上海的用戶，可能就會推薦上海用戶所對應的內容；如果不是的話，可以繼續推薦別的。

加入實時模型訓練，最主要的目的是在動態特征的基礎上，希望模型本身能夠盡可能的貼合此時此刻用戶行為的分布，同時希望能夠緩解模型的退化。

二、 阿里巴巴實時推薦方案

首先了解下阿里內部實施完這套方案之后有什么好處：

• 第一個是時效性。目前阿里大促開始常態化，在大促期間整個模型的時效性得到了很好的提升；
• 第二個是靈活性。可以根據需求隨時調整特征和模型；
• 第三個是可靠性。大家在使用整個實時推薦系統的時候會覺得不放心，沒有經過離線當天晚上大規模的計算驗證，直接推上線，會覺得不夠可靠，其實已經有一套完整的流程去保證這件事情的穩定性和可靠性；

這個推薦模型從圖上看，從特征到樣本到模型，再到在線預測這個過程，和離線其實沒有區別。主要的區別就是整個的流程實時化，用這套實時化的流程去服務在線的搜索推廣應用。

1. 如何實施

根據經典離線架構進行演變。

首先，用戶群行為會從消息隊列來走離線存儲，然后這個離線存儲會存儲所有的歷史用戶行為；然后在這個離線存儲上面，通過靜態特征計算樣本；接下來把樣本存到樣本存儲里，去做離線模型訓練；之后把離線的這個模型發布到模型中心，去做模型驗證；最后把模型驗證過的模型推到推理服務去服務在線業務。這個就是完整的離線體系。

我們將通過三件事情進行實時化改造：

• 第一是特征計算；
• 第二是樣本生成；
• 第三是模型訓練。

相比之前，消息隊列不僅僅存入離線存儲，還要分出來兩鏈路：

• 第一鏈路會做實時的特征計算，比如說最近幾分鐘之內中國男性用戶看 page#100 的時候點了什么廣告，這個是實時計算算出來的，即最近一段時間的一些用戶可能產生的一些行為特征等。
• 另外一條鏈路是消息隊列，可以進行實時樣本拼接，就是說不需要手動去打標簽，因為用戶自己會告訴我們標簽。比如我們做了一個推薦，如果用戶點擊了，那么它一定是個正樣本；如果過了一段時間用戶沒有點擊，那我們認為它就是個負樣本。所以不用人工去打標簽，用戶會幫我們打標簽，這個時候很容易就能夠得到樣本，然后這部分樣本會放到樣本存儲里面去，這個跟之前是一樣的。區別在于這個樣本存儲不僅服務離線的模型訓練，還會去做實時的模型訓練。

離線模型訓練通常還是天級的 T+1 的，會訓練出一個 base model ，交給實時模型訓練去做增量的訓練。增量模型訓練的模型產出就可能是 10 分鐘、15 分鐘這樣的級別，然后會送到模型存儲做模型驗證，最后上線。

架構圖中綠色的部分都是實時的，這部分有一些是新加出來的，有一些則是由原本的離線變成實時的。

2. 阿里云企業級實時推薦解決方案

在阿里云企業級實時推薦解決方案中，如何使用阿里云產品搭建？

消息隊列會用 DataHub；實時的特征和樣本使用實時計算 Flink 版；離線的特征存儲和靜態特征計算都會用 MaxCompute；特征存儲和樣本中心使用 MaxCompute 交互式分析（Hologres）；消息隊列的部分都是 DataHub；模型訓練的部分會用到 PAI，模型存儲和驗證，還有在線推理服務這一套流程都是 PAI 里面的。

2.1 實時特征計算及推理

特征和推理就是把用戶日志實時采集過來，導入實時計算 Flink 版里面去做實時特征計算。然后會送到 Hologres 里面去，利用 Hologres 流式的能力，拿它做特征中心。在這里，PAI 可以去直接查詢 Hologres 里面的這些用戶特征，也就是點查的能力。

在實時計算 Flink 版計算特征的時候，比如說用戶最近 5 分鐘的瀏覽記錄，包括商品、文章、視頻等，根據不同的業務屬性，實時特征是不一樣的。也可能包括比如最近 10 分鐘每個品類點擊率最高的 50 個商品，最近 30 分鐘瀏覽量最高的文章、視頻、商品，最近 30 分鐘搜索量最高的是 100 個詞等。在這不同的場景，比如搜索推薦，有廣告、有視頻、有文本、有新聞等。這些數據拿來做實時特征計算的和推理的這一條鏈路，然后在這個鏈路基礎之上，有的時候也是需要靜態特征回填的。

2.2 靜態特征回填

比如新上線一個特征，這個新的特征在實時鏈路上線了之后，如果需要最近 30 天用戶的行為，不可能等 30 天之后再計算。于是需要找到離線數據，然后把最近 30 天的這個特征給它補上。這就叫特征回填，也就是 backfill 。通過 MaxCompute 去算這個特征回填一樣也是寫到 Hologres，同時實施起來也會把新的特征給加上，這是一個新特征的場景。

當然還有一些其他場景，比如算一些靜態特征；再比如可能線上特征有一個 bug 算錯了，但是數據已經落到離線去了，這時候對離線特征要做一個糾錯，也會用到 backfill 的過程。

2.3 實時樣本拼接

實時樣本拼接本質上對于推薦場景來講，就是展示點擊流之后，樣本獲得一個正樣本或者負樣本。但是這個 label 顯然是不夠的，還需要有特征，才能夠做訓練。特征可以從 DataHub 中來，在加入了實時特征以后，樣本的特征是時時刻刻在發生變化的。

舉一個例子，做出某一個商品的推薦行為的時候，是早上 10:00，用戶的實時特征是他 9:55 到 10:00 的瀏覽記錄。但是當看到這個樣本流回來的時候，有可能是 10:15 的時候了。如果說這個樣本是一個正樣本，當給到用戶推薦的商品且他產生了購買行為，這段時間我們是無法看到用戶實時特征的。

因為那個時候的特征已經變成了用戶從 10:10 瀏覽到 10:15 的時候的瀏覽記錄了。但是在做預測的時候，并不是根據這個 5 分鐘內的瀏覽記錄來推薦的這個商品，所以需要把當時做推薦的時候所采用的那些特征給它保存下來，在這個樣本生成的時候給它加上，這就是 DataHub 在這里的作用。

當使用 ES 做實時推薦的時候，需要把當時用來做推薦的這些特征保存下來，拿去做這個樣本的生成。樣本生成后，可以存儲到 Hologres 和 MaxCompute 里面去，把實時樣本存儲到 DataHub 里面。

2.4 實時深度學習和 Flink AI Flow

這個部分會有離線訓練是以 “天“ 為級別的；也會有在線的實時訓練是 “分鐘級” 的；有的可以做的比較極致，是按 “秒” 級的。不管是哪邊出來的模型，最后都會送到這個模型中去，進行模型的驗證以及上線。

這個其實是一個非常復雜的工作流。首先，靜態特征計算是周期性的，也可能是手動的。當需要做 backfill 的時候，有手動觸發的一個過程。根據這個模型圖能看出它是批的訓練，當它訓練完了之后，需要到線上去做一個實時模型驗證。這個模型驗證可能是一個流作業，所以這里是從批到流的一個觸發過程，模型是從流作業里面出來的，它是一個 long running 的作業，每 5 分鐘產生一個模型，這每 5 分鐘的模型也需要送進去做這個模型驗證，所以這是一個流觸發流動作的過程。

再比如說這個實時樣本拼接，大家都知道 Flink 有一個 watermark 的概念，比如說到某一個時刻往前的數據都到收集齊了，可以去觸發一個批的訓練，這個時候就會存在一個流作業。當他到了某一個時刻，需要去觸發批訓練的時候，這個工作流在傳統的工作流調度里面是做不到的，因為傳統的工作流調度是基于一個叫做 job status change 的過程來做的，也就是作業狀態發生變化。

假設說如果一個作業跑完了并且沒有出錯，那么這個作業所產生的數據就已經 ready 了，下游對這些數據有依賴的作業就可以跑了。所以簡單來說，一個作業跑完了下一個作業延續上繼續跑，但是當整個工作流里面只要有一個流作業的存在，那么這整個工作流就跑不了了，因為流作業是跑不完的。

比如說這個例子的實時計算，數據是不斷變化的跑動，但是也會存在隨時可能 ready 的，也就是說可能跑到某一個程度的時候數據就 ready 了，但其實作業根本沒有跑完。所以需要引入一個工作流，這個工作流我們把它叫做 Flink AI Flow，去解決剛才那個圖里面各個作業之間的協同關系這個問題。

Flink AI Flow 本質上是說節點都是一個 logical 的 processing unit，是一個邏輯處理節點，節點和節點之間，不再是上一個作業跑完跑下一個作業的關系了，而是一個 event driven 的 conditions，是一個事件觸發的一個概念。

同樣在工作流執行層面，調度器也不再基于作業狀態發生變化去做調度動作，而是基于事件的調度。比方說事件調度這個例子，當一個流作業的 water mark 到了的時候，就是說這個時間點之前的所有數據都到全了，可以去觸發批作業去跑，并不需要流作業跑完。

對于每一個作業來講，通過調度器提作業或者停作業是需要條件的。當這些事件滿足一個條件的時候，才會進行調度動作。比如說有一個模型，當模型生成的時候，會滿足一個條件，要求調度器把一個 validation 的作業模型驗證的作業給拉起來，那這個就是由一個 event 產生了一個 condition，要求 schedule 去做一件事情的過程。

除此之外，Flink AI Flow 除了調度的服務之外，還提供了三個額外的支持服務來滿足整個 AI 工作流語義，分別是元數據服務、通知服務和模型中心。

• 元數據服，是幫大家管理數據集和整個工作流里面的一些狀態；
• 通知服務，是為了滿足基于事件調度語義；
• 模型中心，是去管理這個模型當中的一些生命周期。

三、實時深度學習訓練 PAI-ODL

Flink 生成實時樣本之后，在 ODL 系統有兩個流。

• 第一個流是實時流，生成的實時樣本送到 stream data source 上面比如像 kafka，在 kafka 中的這個樣本會有兩個流向，一個是流到 online training 中，另一個是流到 online evaluation 。
• 第二個流是離線訓練的數據流，拿離線的數據流向數倉來做這種 offline T+1 的 training 。

在 online training 中支持用戶可配置生成模型的頻率，比如說用戶配置 30 秒或者 1 分鐘生成一次模型更新到線上。這個滿足在實時推薦場景中，特別是時效性要求高的場景。

ODL 支持用戶設定一些指標來自動判斷生成的模型是否部署線上，當 evaluation 這邊達到這些指標要求之后，這個模型會自動推上線。因為模型生成的頻率非常高，通過人工去干預不太現實。所以需要用戶來設定指標，系統自動去判斷當指標達到要求，模型自動回推到線上。

離線流這邊有一條線叫 model calibration，也就是模型的校正。離線訓練生成 T+1 的模型會對在線訓練進行模型的校正。

PAI-ODL 技術點分析

1. 超大稀疏模型訓練

超大稀疏模型的訓練，是推薦搜索廣告這類稀疏場景里常用的一個功能。這里實際上是一個典型、傳統的深度學習引擎，比如像 TensorFlow，它原生的內部實現的就是 fix size 這種固定 size variable，在稀疏場景使用中會有一些常見問題。

就像 static shape，比如在通常的場景里邊，像手機 APP 這種，每天都會有新用戶來加入，每天也會有新的商品，新聞和新的視頻等更新。如果是一個固定大小的 shape 的話，其實是無法表達稀疏場景中這種變化的語義的。而且這個 static shape 會限制模型本身長期的增量訓練。如果說一個模型可增量訓練時長是一兩年，那很可能之前設定的這個大小已經遠遠不能滿足業務需求，有可能帶來嚴重的特征沖突，影響模型的效果。

如果在實際的模型中設置的 static shape 比較大，但是利用率很低，就會造成內存的浪費，還有一些無效的 IO。包括生成全量模型的時候，造成磁盤的浪費。

在 PAI-ODL 中基于 PAI-TF 引擎，PAI-TF 提供了 embedding variable 功能。這個功能提供動態的彈性特征的能力。每個新的特征會新增加一個 slot。并支持特征淘汰，比如說下架一個商品，對應的特征就會被刪掉。

增量模型是說可以把一分鐘內稀疏特征變化的部分記錄下來，產生到這個增量模型中。增量模型記錄了稀疏的變化的特征和全量 Dense 的參數。

基于增量模型的導出，就可以實現 ODL 場景下模型的快速更新。快速更新的增量模型是非常小的，可以做到頻繁的模型上線。

2. 支持秒級的模型熱更新

通常在我們接觸的用戶中，通常是關注的主要是三點：

• 第一點就是模型的效果，我上線之后效果好不好？
• 第二點就是成本，我到底花多少錢。
• 第三點就是性能，能不能達到我對RT的要求。

embedding store 多級的混合存儲支持用戶可配置不同的存儲方式。可以在滿足用戶性能的前提下，更大程度的降低用戶的成本。

embedding 場景是非常有自己場景特點的，比如說我們的特征存在很明顯的冷熱區別。有些商品或者視頻本身特別熱；有些則是用戶的點擊行為特別多，也會造成它特別熱。有些冷門的商品或者視頻就沒人點，這是很明顯的冷熱分離，也是符合這種二八原則的。

EmbeddingStore 會把這些熱的特征存儲到 DRAM 上面，然后冷的特征存放在 PMEM 或者是 SSD 上。

3. 超大稀疏模型預測

此外，EmbeddingStore 支持分布式存儲 Service。在 serving 的時候，每個 serving 的節點其實都需要去做一個全量的模型的加載。如果使用 EmbeddingStore 的分布式 service，就可以避免每個 serving 節點加載全量模型。

EmbeddingStore 支持用戶可配置這種分布式的 embedding， 獨立的 isolated 這種 embedding store service。每個 serving 節點查詢稀疏特征時從 EmbeddingStore Service 查詢。

EmbeddingStore 的設計充分的考慮了稀疏特征的數據格式和訪問特點。舉個簡單的例子：稀疏特征的 key 和 value ，key 是 int64 ， value 就是一個 float 數組。無論是在 serving 還是在 training，訪問都是大批量的訪問。此外 Inference 階段對稀疏特征的訪問是無鎖化的只讀訪問。這些都是促使我們設計基于 embedding 場景的稀疏特征存儲的原因。

4. 實時訓練模型校正

為什么 PAI-ODL 會支持離線訓練模型對 online training 有一個模型校正？

通常在實時訓練過程中，會存在這種 label 不準以及樣本分布的問題。因此使用天級別的模型會自動校正到 online training，增強模型的穩定性。PAI-ODL 提供的模型校正用戶是無干預的，用戶基于自己業務特點配置相關配置后，每天自動根據新產生的全量模型進行 online training 端的 base 模型校正。當離線訓練生成 base 模型，online training 會自動發現 base model，并且在 data stream source 會自動跳轉到對應的樣本，基于最新的 base 模型和新的 online training 的訓練樣本點開始 online training。

5. 模型回退及樣本回放

雖然有樣本的異常樣本檢測以及異常樣本處理，仍然無法避免線上的更新模型會有效果問題。

當用戶收到報警，線上的指標下降。需要提供給用戶一個能力，可以回滾這個模型。

但是在 online training 的場景中，從發現問題到去干預可能經過了好幾個模型的迭代，產出了若干模型了。此時的回滾包含：

1）線上 serving 的模型回滾到問題時間點的前一個模型；

2）同時 online training 需要回跳到問題模型的前一個模型；

3）樣本也要回跳到那個時間點來重新開始進行訓練。

原文鏈接：https://developer.aliyun.com/article/785005?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的基于实时深度学习的推荐系统架构设计和技术演进的全部內容，希望文章能夠幫你解決所遇到的問題。

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