全面解析廣告和推薦系統的兩種架構
廣告和推薦系統是機器學習是最成熟的應用領域。那麼廣告和推薦系統是怎麼在線上部署機器學習模型的呢？
1.預測函式上線
剛剛學習機器學習時候，我認為廣告和推薦系統過程如下圖所示：
1）線下部分，從使用者和廣告（物品）屬性抽取使用者和物品特徵，將抽取的特徵合併進日誌生成訓練資料，訓練機器學習模型；
2）線上部分，來了一個請求，從使用者和廣告（物品）屬性抽取請求中的使用者和物品的特徵，將這些特徵合併請求生成預測例項，用線上模型得到預測結果。
但是這個架構有兩個問題：
1）從使用者和廣告（物品）屬性抽取特徵的程式有線上線下兩套，這兩套程式必須保持完全一致。但由於調參的原因，特徵抽取是機器學習系統中最經常發生變化的模組。經常變化的模組需要保持一致，這很困難。那麼我們能不能強行地用一套程式呢？比如，我們把特徵抽取和特徵處理模組寫成 .so 檔案。這樣也有問題：線下要求快速變化以方便工程師調特徵，可能會使用一些訓練框架（比如 Spark）；線上要求程式快速實時，要求工程師編碼嚴謹。寫成嚴謹的 .so 檔案，能夠保證線上的需求，但無法快速變化，也不能在 Spark 上使用。
2）線上特徵抽取要求非常快速，特別在線上吞吐量很大的情況。但有些重度特徵不可能在短時間內抽取出來，比如廣告的歷史點選率（生成這個特徵需要遍歷一段時間的點選日誌）。在此我向大家推薦一個大資料技術交流圈： 658558542 突破技術瓶頸，提升思維能力 。
在這期間，這兩個問題困擾了我很久, 直到我知道了神器 Redis。Redis 是一個開源記憶體資料庫，支援叢集模式、持久化和 Key-Value 資料結構。在使用時，我們可以將 Redis 看成一個巨大的雜湊表。Redis 在後臺開發中經常用作 cache 伺服器, 後來被工程師們用於廣告和推薦系統中的特徵伺服器。工程師將使用者和廣告（物品）的 ID 作為 Key，將使用者和廣告（物品）的特徵作為 Value 存入 Redis，這樣線上程式只需要使用者和廣告（物品）的 ID 就能知道特徵。引入 Redis 之後，廣告和推薦系統過程如下所示：
1）線下部分，從使用者和廣告（物品）屬性抽取使用者和廣告（物品）特徵，把抽取的特徵合併進日誌生成訓練資料用於訓練機，並把抽取的特徵上載到線上 Redis 伺服器；
2）線上部分，來了一個請求，從 Redis 伺服器取出使用者和廣告（物品）特徵，將特徵合併進請求生成預測例項，用線上模型得到預測結果。
這種架構還有一個變種：線上下抽取特徵之後不生成訓練資料而是直接送到 Redis，在線上用 Storm 實時拼接訓練資料。但我對這個變種的前因後果不太瞭解，就不展開討論了。這種架構將預測函式（也就是訓練出來的模型）部署在線上。為了和下面的架構區分開來，我們將這種架構稱為預測函式上線架構。
2.預測結果上線
瞭解預測函式上線架構之後，我將之作為廣告和推薦系統線上部署模型的 “正統”。 因此我接觸到另一種架構時，我內心是拒絕的。這種架構的要點在於把預測結果上線，具體過程如下所示：
1）在線上，從使用者和廣告（物品）屬性抽取使用者和物品特徵，將抽取的特徵合併進日誌生成訓練資料，訓練機器學習模型；將幾乎所有可能的請求合併特徵，進而生成預測例項，用模型得到預測結果；
2）線上就很簡單了，接入線下傳過來的預測結果。這裡稍微難理解的是 “窮盡幾乎所有可能的請求”，疑惑那麼多可能的請求怎麼可能窮盡呢？微博廣告系統（虛構的）所有可能的請求貌似很多，但每個使用者只需要匹配若干個廣告就行了。因此微博廣告系統的預測結果 “userid,adid1,adid2…,adidn” 上載到線上，一旦線上傳一個 userid 請求展示廣告，線上模組就按照一定的邏輯返回預測結果中這個使用者對應的廣告。這種架構是將預測結果部署到線上，我們將之稱為預測結果上線架構。
慢慢地我也開始明白預測結果上線的好處了。預測結果上線架構將機器學習全過程和絕大部分控制邏輯都搬到線下，規避了線上的各種隱患。這樣不那麼厲害的工程師用不那麼厲害的機器也能搞定線上模組了，畢竟線上模組只需要實現少量的控制邏輯和展示。這大大降低了建立一個廣告系統或者推薦系統的難度。在此我向大家推薦一個大資料技術交流圈： 658558542 突破技術瓶頸，提升思維能力 。
我正式工作之後，組裡支援運營活動的推薦系統採用了預測結果上線的架構。我發現有不少時間浪費在重跑資料上，原因在於有時需要臨時增加或者刪除物品。一旦增加或者刪除物品，預測結果上線的推薦系統就需要重新生成預測資料（因此之前跑的資料要麼沒有要加的物品，要麼有要刪的資料）。另外一個問題就是預測結果上線架構有延時性：今天線上展示的是昨天準備的預測結果，今天準備的預測結果要等明天才能展示，這會導致節奏慢一些。最後還有一個問題，預測結果上線架構只適用於幾乎所有可能的請求能夠窮盡的場景。比如，預測結果上線架構不適用於搜尋廣告系統，因為搜尋廣告系統不能窮盡所有可能的請求。
3.總結
預測函式上線架構能夠覆蓋預測結果上線架構的適用場景，但是預測結果上線架構不能夠覆蓋預測函式上線架構的適用場景。同時預測函式上線架構更具靈活性。預測函式上線架構不愧為部署機器學習模型的 “堂堂正正” 之法。
預測結果上線架構的好處就是難度比較低。預測結果上線架構將機器學習全過程和絕大部分控制邏輯，規避了線上的各種隱患。在機器、時間和人力等各種條件不充足的情況，預測結果上線架構不失為一個好的選擇。預測結果上線架構是 “劍走偏鋒” 的機器學習模型部署之法。兵法有云：以正合以奇勝，選擇哪一種架構還是需要仔細的分析和權衡。
感謝您的觀看，如有不足之處，歡迎批評指正。
在此我向大家推薦一個大資料開發交流圈：
658558542 （ ☛點選即可加入群聊 ）
裡面整理了一大份學習資料，全都是些乾貨，包括大資料技術入門，大資料離線處理、資料實時處理、Hadoop 、Spark、Flink、推薦系統演算法以及原始碼解析等，送給每一位大資料小夥伴，讓自學更輕鬆。這裡不止是小白聚集地，還有大牛線上解答！歡迎初學和進階中的小夥伴一起進群學習交流，共同進步！
最後祝福所有遇到瓶頸的大資料程式設計師們突破自己，祝福大家在往後的工作與面試中一切順利。