摘要：互聯網行業朝夕萬變，產品和決策都需要快速得到用戶反饋的數據去迭代更新，所以AB測試在互聯網公司中就顯得非常重要，日前，大眾點評負責AB測試框架的架構師樊聰分享了該公司此系統的原理、架構和設計思路。
眾所周知，互聯網行業朝夕萬變，產品和決策都需要快速得到用戶反饋的數據去迭代更新，所以AB測試在互聯網公司中就顯得非常重要，是data-driven product的基礎，微軟、Google、Amazon都在這方面做了大量研究和工作，有興趣的可以參考 EXP 這個網站，上面有大量各個公司如何做AB實驗的文章和資料。日前，大眾點評數據中心研發經理樊聰（@卡斯fan）給分享了點評的AB測試框架（codename Gemini）和平臺搭建的實戰經驗。
以下為正文：
我加入點評的負責的個項目就是點評的AB測試框架（codename Gemini）和平臺的搭建，目前這個系統已經在搜索、PC主站、廣告等業務廣泛使用，給業務部門更好的做算法優化和產品設計提供了數據支持的決策方法。下面給大家介紹一下這個系統的原理、架構和設計思路。
總體架構
Gemini 架構圖
如上圖所示，Gemini主要由4個部分組成：
靜態緩存服務器（Vanish）里面的cookie filer
業務web server里面的ClientLib
實驗配置平臺
數據中心的計算處理鏈路
這種架構的選擇也是由點評本身的基礎架構相關，我們知道業界AB測試框架的方案大致有兩種：
1. 兩套代碼：顧名思義，是把control(基準代碼)和treatment（實驗代碼）分別部署在不同的機器，通過統一的router分發流量。百度和使用的是這套架構的好處是對業務侵入性小，灰度發布和正式上線都非常方便。但要求就是開發流程是分支開發模式且代碼部署需要和分流路由可用統一配置和聯動。
2. 一套代碼：業務邏輯中把control和treatment的分支都寫好，通過在業務服務器里面嵌入AB測試框架的client，判斷流量是該走control還是treatment。這種思路的好處是對外部系統依賴小，全部邏輯都在業務服務器完成，適合主干開發的模式，但是對業務侵入大，灰度發布不方便，代碼維護還有整潔度下降。微軟和amazon是使用這套架構。
我們當時根據點評的自身開發流程和運維基礎設施，終選擇了一套代碼的方案。
分層的實驗模型
在詳細介紹Gemini幾個模塊的設計之前，先需要介紹框架的分層模型的概念。我們當時的需求一個是業務和功能會包含多個實驗并向的進行，比如商戶搜索頁：可能有主站的在進行頁面改版，搜索的在優化搜索排序，推薦的在優化個性化推薦。第二個是流量能夠按照一些屬性切割，業務組可以獨占100%的流量。基于這兩個需求，我們參考了在2010年KDD上公布的自己的 分層實驗框架 。Google提出將實驗空間橫向和縱向進行劃分，縱向上流量可以進入獨占實驗區域或者是并行實驗區域。在獨占實驗區域，只有一層，實驗可以獨享流量且不受其他實驗的干擾。在分層區域，不同的應用屬于不同layer，每個應用內部，又可以劃分為多層，層與層之間相互不影響。流量可以橫向經過多層，每一層可有多個實驗。流量在每一層都會被重新打散。
分層實驗模型示意圖
我們將Google的思想進行了一定程度的簡化：
橫向上分為多層，每一層含一個bucket集合（默認為100），流量按照其cookie中的guid和layerid被哈希到某一個bucket中，并綁定該實驗的參數取值。這個策略的本質所在就是在hash的時候考慮了兩個變量:guid和layerid，從而在不同層之間實現了流量的重新打散，保證層與層之間實驗的正交性。
縱向上，按照流量的屬性：如地域，用戶特征等把空間劃分為segment，這些segment被某個實驗獨占，從而可以實現多個實驗在不同流量域進行且占有該域下面的所有流量。變形可以用來進行灰度發布：比如我們團購優化就是現在某些城市進行實驗，再擴展到全國。
有了上面的概念，其他模塊就容易理解了：
1. 實驗平臺：
實驗平臺的主要是提供了一個web portal，供開發人員進行流量劃分和實驗參數的配置，支持按照多個維度配置流量劃分：如城市，cookie值，供service使用的自定義值。同時對于上面提到的guid，我們默認是點評的userid，同時也提供deviceid和自定義的id供流量進行hash。參數的配置統一保存在點評的configuration服務（Lion）里面，實驗參數命名需要在應用域，命名規范為：應用名＋模塊名＋參數名，從而實現了參數的動態修改和綁定。
同時，實驗平臺還管理實驗的啟停，修改和報表dashoboard展現等功能。
2. 實驗客戶端：
這一部分主要是一個RPC的API client，業務方在web服務器的filter里面和邏輯service中，用于從lion中讀取配置信息和參數信息，并根據流量的hash值判斷范圍怎樣的參數取值。如下面的示例代碼：
UseCase 代碼
public class UsageTest {
@Test
//正常場景：在web容器內
public void test_normal_usage(){
ABTestFactor factor = ABTestManager.getFactor();
int factor1 = factor.getInt("factor1", 1);
//use factor1
}
@Test
//特殊場景：1. 在RPC的服務端，2. 在線程池內的線程中
//需要用戶傳給框架上下文context
public void test_rpc_or_threadPool_usage(){
HttpServletRequest request = null;
HttpServletResponse response = null;
// 傳入一個request 對象
DefaultABTestContext context = new DefaultABTestContext(request, response);
// 直接傳入
context.addKey(“deviceId”, “adf2345sdf”);
ABTestFactor factor = ABTestManager.getFactor(context);
int factor1 = factor.getInt("factor1", 1);
//use factor1
}
}
這部分模塊的另外一個功能是把實驗的一些標識信息打到日志中，針對不同的場景，我們提供后端日志打印和cookie回傳到前端，然后前端打印的兩種方式。
3. 數據中心的數據處理：
實驗啟動后，效果如何跟蹤就是數據中心的內容了。這里主要包含幾個階段：日志的傳輸，解析，報表和dashboard的展現。Gemini結合數據模型內置了幾個常用的指標：PV，UV，CTR等，用戶可以直接看到相應的AB兩組的效果，對于其他指標，目前還是需要用戶自行配制報表，或者通過hive寫腳本統計。另外現在點評已經實現了日志的實時傳輸，但對流量數據的計算和ETL還是T+1的，如果用戶要實時的效果跟蹤，需要自己編寫基于storm的統計應用進行分析。另外提一點，我們還內設了計算置信區間(pvalue)的功能，幫助實驗的同學更好的根據實驗的流量大小和實驗時間長短，判斷當前實驗效果的可信程度。
4. 靜態緩存服務器的問題：
另外一個比較有意思的一點是我們在靜態緩存服務器上的處理，因為點評在一些業務場景中大量使用了vanish靜態緩存服務器，會使得一些流量無法透傳到后端，用戶得不到正確的AB版本，我們的解決方案是植入一個vanish的腳本，通過URL+cookie判斷和存儲control和treatment的不同版本，簡單來說：當用戶次請求，如果判斷是要做實驗的，那么在header中設置cache-control=no-cache，并回寫cookie；如果不是要做實驗的，不做任何事情，當用戶第二次請求，如果沒有含有cookie，那么直接命中vanish。如果有cookie，再穿一次后端，后端不設cache-control=no-cache，這個頁面被緩存。下次再來請求就可以命中了。
除了上述主要模塊外，Gemini上線后，我們也根據反饋在易用性和功能性上進行了優化和升級，包括：
克隆實驗和在線修改實驗配置：在實驗正式上線前，開發同學往往是先在測試和ppe環境中配置好實驗，并進行正確性驗證，在確認沒有問題后再發布到線上，如果每次測試到發布都要重新配置實驗，會顯得比較繁瑣，特別是對于一些參數特別多的實驗。針對這個問題，我們開發了實驗克隆的功能，實現了在不同環境中實驗的同步，提高了系統的易用性。同樣的，實驗上線后，經常需要對實驗進行一些微調（某些情況下，可以視為一個新實驗），我們配置管理是基于zookeeper的推送，在客戶端內存中保留一份配置的cache。這樣我們就可以方便的在客戶端設置一個回調函數，當zk中配置修改后，更新內存中的配置即可實現實驗的在線修改，避免了每次都重新上線一個實驗的過程。
自定義實驗條件：在某些業務中，實驗框架是位于service層，流量進入后，已經被包裝了其他的屬性，而這些屬性往往還需要作為實驗分流的條件。為了支持這個需求，Gemini加入了一個自定義實驗條件的功能，可以通過key/value 對的形式在實驗平臺上添加定制的實驗條件，分流時會統一考慮進分流策略。
以上就是點評AB測試框架Gemini的簡單介紹，后續系統的改進點其實還有很多：
根據條件啟停實驗
灰度發布的集成（考慮把整個框架放到底層基礎組件中）
效果數據的實時化和更完善的評價體系等
大家有什么問題和建議也歡迎和我們聯系，一同探討。
參考資料
exp-platform: http://www.exp-platform.com/Pages/default.aspx
Overlapping Experiment Infrastructure: More, Better, Faster Experimentation : http://research..com/pubs/pub36500.html
Online Conrolled Experiments at Large Scale: http://www.exp-platform.com/Documents/2013%20controlledExperimentsAtScale.pdf
本文來自：樊聰（ 微博）
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
