總第373篇
2019年 第51篇
廣告系統中，一個好的實驗平臺可以令算法、工程、業務的迭代更多、更快、更好。本文詳細介紹了美團點評效果廣告引擎團隊結合自身業務實際，在廣告實驗配置平臺上的實踐。目前該平臺已經在搜索廣告中全面上線，支持線上所有實驗需求。
一. 背景
效果廣告的主要特點之一是可量化，即廣告系統的所有業務指標都是可以計算並通過數字進行展示的。因此，可以通過業務指標來表示廣告系統的迭代效果。那如何在全量上線前確認迭代的結果呢？通用的方法是採用AB實驗（如圖1）。所謂AB實驗，是指單個變量具有兩個版本A和B的隨機實驗。在實際應用中，是一種比較單個（或多個）變量多個版本的方法，通常是通過測試受試者對多個版本的反應，並確定多個版本中的哪個更有效。Google工程師在2000年進行了首次AB實驗，試圖確定在其搜索引擎結果頁上顯示的最佳結果數。到了2011年，Google進行了7000多次不同的AB實驗。現在很多公司使用“設計實驗”的方法來制定營銷決策，期望在實驗樣本上可以得到積極的轉化結果，並且隨着工具和專業知識在實驗領域的發展，AB實驗已成爲越來越普遍的一種做法。
圖1 什麼是AB實驗
我們都知道，機器學習在廣告投放中的作用是舉足輕重的，廣告收入的提升離不開算法模型的優化迭代，因此算法模型的迭代也需要進行AB實驗。除了算法模型的迭代之外，工程中較大規模的重構和優化也需要AB實驗來驗證效果的有效性和正確性。此外，目前在大部分應用中，應用參數配置採用最多是單鍵值的配置方式，這種配置方式的確滿足了大部分配置的需要，但是在結合業務需求的情況下，使用起來可能會很乏力。
因此，我們需要搭建一個平臺（Wedge），來滿足算法、工程在迭代過程中的實驗需求，並且滿足在不同流量下應用參數配置的需求。
二. 方案設計
目標
Wedge平臺的目標如下：
支持各類算法實驗場景，可靈活支持後續的功能擴展。
實驗配置、使用、效果回收等全鏈路對使用者透明，降低解釋成本。
提供不同流量下應用參數的配置，降低參數解析成本。
支持版本控制，可快速回滾。
提供簡潔、易用的操作界面。
設計思路
在《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》中，Google給出了一套通用的分層實驗解決方案。我們以此爲藍本，結合美團點評效果廣告的LBS特性，針對不同的業務場景，實現了更適合日常迭代的實驗配置框架。目前，該框架已在搜索廣告投放系統上全量上線。
實驗分類
基於Google分層實驗平臺，結合實際需求進行了以下實驗分類。
根據實驗種類分類
水平實驗：類似於Overlapping Layer中的實驗，是屬於同個“層”的實驗，實驗是互斥的，在同一“層”上實驗可以理解爲是同一種實驗，例如：關鍵詞“層”表示這一層的實驗都是關鍵詞相關的，該層上存在實驗H1和H2，那麼流量絕對不會同時命中H1和H2。
垂直實驗：類似於Non-overlapping Layer中的實驗，分佈於不同“層”之間，實驗是不互斥的，例如在關鍵詞“層”和CTR“層”上在相同的分桶上配置了實驗V1和V2，那麼流量可以同時命中V1和V2。
條件實驗：表示進入某“層”的實驗需要滿足某些條件，水平實驗和垂直實驗都可以是條件實驗。
根據流量類別分類
這種分類主要了爲了用戶體驗，使平臺在操作上更加的簡單、易用：
普通實驗：最基本的實驗，根據流量類別進行配置。
引用實驗：流量分類是整個配置中心基礎，但實際上存在一些實驗是跨流量了，而引用實驗則可以配置在不同的流量種類中。
全局實驗：可以理解爲特殊的引用實驗，全局實驗在所有流量上都生效。
架構圖
圖2爲整體架構圖，比較便於大家理解，我們可以看到整體架構分爲四層：
Web層：提供平臺UI，負責應用參數配置、實驗配置、實驗效果查看以及其他。
服務層：提供權限控制、實驗管理、拉取實驗效果等功能。
存儲層：主要是數據存儲功能。
業務層：業務層結合SDK完成獲取實驗參數和獲取應用參數的功能。
圖2 架構圖
三. 模型設計
1. 分流模型
實驗模型
如圖3所示，整體模型分爲以下幾個部分：
App：表示一個應用，不同的應用對應的實驗配置完全不同，首先從App上進行區分可以更加明確實驗的歸屬。
Scene：表示某一類流量的集合，例如：搜索、美食篩選、到綜篩選等，在這些流量上配置的實驗互不干擾。
Layer：表示某一層（種）實驗的集合。例如可以將在matching上做的實驗放入Matching Layer中。流量命中時依次進入每個Layer獲取實驗配置參數，此時的Layer更像一個抽象概念，與具體的業務或者邏輯相關。
條件Layer：是一種更加精細的流量控制方式，表示某一流量的某個或者某幾個參數在滿足一定條件下才會進行實驗。進一步說就是相同Scene下，某一流量的參數A滿足條件一時，採用一種實驗配置策略；滿足條件二時，採用另一種實驗配置策略，那可以分爲兩層，如圖3所示的Layer_3和Layer_4。例如：某流量需要在城市北京單獨做實驗，這種情況下，可以分爲參數相同但是先決條件（即城市）互斥的兩個Layer。此時的Layer在抽象的基礎上更加的具體化。
Exp：表示具體實驗，包括實驗的分桶、實驗參數、是否爲垂直流量等等。
圖3 實驗模型
水平、垂直分流模型
如圖4所示，水平、垂直分流模型分爲以下兩個部分：
僅包含水平實驗 ：最基礎的實驗需求，全部實驗獨佔一個Layer，每個實驗覆蓋若干個桶，例如圖4中的Layer_1，將流量分爲10份，包含三個實驗，這三個實驗分別佔用3、3、4份流量。
同時包含水平、垂直實驗：一個Layer中同時包含垂直、水平兩種類型的實驗。例如圖4中的Layer_2和Layer_3，將最後的4份流量用來做垂直實驗，包含兩個垂直實驗，分別是Exp_6和Exp_7。
圖4 水平、垂直分流模型
2. 實驗命中模型
實驗命中模型是指，當一個請求過來時，返回全局統一的實驗參數。所有的請求都會平均地落入每一個分桶中，並且不同的Layer之間能夠保證流量的正交。
名詞解釋
Bucket | 分桶 |
流量正交 | 流量在不同Layer之間的分桶是完全相互獨立的 |
Hash優先級 | 表示計算Hash值的先後順序，用於垂直和水平實驗切分 |
Hash因子 | 分桶的唯一標識 |
Hash串 | 計算Hash的字符串 |
取模數 | Hash值計算之後的除數 |
Hash優先級：在實驗命中過程中，第一次Hash首先判斷命中垂直流量，如果沒有命中，則進行第二次Hash再判斷水平流量。
Hash因子：目前美團側一般情況下爲uuid，點評側爲dpid。
垂直流量Hash串：Hash因子+scene_id。
水平流量Hash串：Hash因子+scene_id+layer_id+layer_name。
取模數：在Hash過程中，垂直流量按照總Bucket（默認取值100）取模；水平流量按照總Bucket數減去垂直流量Bucket數取模。這樣的命中模型能保證無論是垂直的Bucket，還是水平的Bucket都是全局的1%。
實例解析
以最複雜的流量分配爲例，如圖5，水平、垂直流量各佔全局50%流量。
水平流量上包含兩個實驗：Exp_1、Exp_2各佔全局20%流量，還有10%流量未分配實驗，垂直流量與水平流量相同。
圖5 流量分配示例
典型實驗命中如圖6所示：
當一個請求過來時，命中順序按照Hash優先級爲先垂直流量後水平流量。
首先利用垂直流量Hash串進行Hash並取模得到一個hashNum，如果命中了50～99，就會認爲命中了垂直流量，直接返回V_Exp_1、V_Exp_2或者未命中。
如果沒有命中50～99，則認爲命中了水平流量。再利用水平Hash因子進行Hash並取模得到一個hashNum，根據配置直接返回Exp_1、Exp_2或者未命中。
圖6 實驗命中流程
應用參數模型
應用參數模型如圖7所示，分爲兩層結構：
全局參數：所有流量都能拿到的參數。
同類型流量參數：相同類型的流量能拿到的參數。
圖7 應用參數模型
值得注意的是，應用參數的兩個層級以及之前提到的實驗參數可能出現重複的情況，在出現重複的情況下參數的優先級爲：實驗參數>同類型流量參數>全局參數。
3. 回滾模型
很明顯，平臺的分流模型是層次結構的，所以在數據設計上也是每一層一個table。這樣就會出現一個問題，一般的參數配置回滾都是單值的回滾，但是存在多個表的情況下沒有辦法這麼簡單地去回滾。
因此，我們設計瞭如下的回滾模型：
首先在配置發佈時，會將所有修改的表名、列名、列類型、列新舊值、修改類型存入表中。
回滾時獲取上次發佈的所有修改的表名、列名、列類型、列新舊值、修改類型，反向操作數據庫，達到回滾的目的。
圖8 回滾模型
數據庫表的設計如下：
列名 | 數據類型 | 說明 |
|---|---|---|
operation_id | BIGINT | 表示配置發佈的ID |
table_name | VARCHAR | 修改的數據表名 |
operation_step | INT | 修改的數據表的順序 |
operation_type | INT | 修改類型，包括增加、修改、刪除 |
column_name | VARCHAR | 列名 |
old_value | TEXT | 舊值 |
new_value | TEXT | 新值 |
value_type | INT | 值類型 |
四. AB實驗實時效果
實時效果指標包含實際CTR、預估CTR、請求PV、廣告密度、有效曝光、RPS等，由於很多數據分佈在不同的日誌中，所以需要實時處理。
廣告的打點一般分爲請求（PV）打點、SPV（Server PV）打點、CPV（Client PV）曝光打點和CPV點擊打點，在所有打點中都會包含一個流量的requestId和命中的實驗路徑。根據requestId和命中的實驗路徑可以將所有的日誌進行join，得到一個request中需要的所有數據，然後將數據存入Durid中。
計算各項效果指標，就是在日誌join後帶有實驗路徑的數據上做OLAP。爲了支持高效的實時查詢，平臺採用時序數據庫Druid作爲底層存儲。Druid作爲分佈式時序數據庫，提供了豐富的OLAP能力和強悍的性能。Druid將數據分爲時間戳、維度和指標三個部分，其中維度多用於過濾，指標用於聚合和計算等。平臺將數據中的實驗路徑同其他用於過濾的字段一同作爲維度，結合時間戳和指標字段，完成指定標籤的廣告效果指標計算。
五. 總結
目前Wedge平臺已經完全上線，除了滿足目標之外，還帶來了以下的成果：
配合完成算法工程架構調整、更新流大版本升級。
算法各方向之間可以任意做垂直實驗，滿足算法靈活、快速迭代。
具備配置審覈功能，保證配置發佈的正確性。
六. 作者簡介
哲琪、倉魁、劉錚，美團點評效果廣告引擎團隊工程師。
歡迎加入美團計算廣告技術交流羣，跟作者零距離交流。如想進羣，請加美美同學的微信（微信號：MTDPtech03），回覆：Wedge，美美會自動拉你進羣。
---------- END ----------
招聘信息
美團點評效果廣告引擎團隊，招募出色的後端開發工程師。我們希望您：具有紮實的後端服務開發功底，能夠熟練使用Java或C++開發語言，致力於互聯網技術領域。
有興趣的同學，歡迎投遞簡歷至：[email protected]（郵件標題註明：美團點評效果廣告引擎團隊）
也許你還想看
