微軟 AB/Testing EXP 實驗管理平臺

Conference Paper · May 2018 The Anatomy of a Large-Scale Online
Experimentation Platform。

由於工做負責和ABTest相關的事情，因此對ABTest系統理論與工程落地狀況一直在調研，根據上面這篇論文，咱們一塊兒來學習下微軟EXP系統的工程實現。摘要及其相關工做啥的廢話略過，先放一張架構圖：

整個系統包含四部分：

1. experiment portal：

portal屬於一個實驗管理後臺系統，爲實驗者與實驗系統之間提供交互接口，實驗者能夠方便的在系統中建立，配置，運行並分析實驗。其中系統包含三個重要的組件：

1. experiment management

實驗管理界面應具備如下功能：

• 選擇實驗地域羣體（US CN等）
• targeting or traffic filters（瀏覽器，操做系統，應用版本以及更復雜的實驗條件，好比剛滿一個月的新用戶等）
• Overall Evaluation Criteria (OEC) 綜合評價標準，實驗者要選擇好評估指標，能夠內置一些經常使用的CTR，PV，UV等產品優化指標
• 配置實驗組和對照組流量，以及實驗的開始和結束時間
• 支持re-randomization ：使用歷史數據批量作AA實驗，通常經過AA實驗選擇最合適的hash算法，目的是爲了讓樣本儘量均勻，而後才能作AB實驗，爲了提升銷量，巧妙的使用歷史數據作AA，這個過程叫作SeedFinder。
• 實驗管理界面 對不一樣產品提供不一樣的實驗配置模版
• isolation group 是一個變量集合，每一個變量都會被打上所屬的isolation group，實驗裏的全部變量共享一樣的isolation group，若是兩個變量所屬的isolation group有交集，那麼說明這兩個變量會是相互影響的，對於這兩個變量，在作實驗的時候應該是互斥的
• 後端管理系統可以控制變量所對應的線上業務行爲。對於server端實驗，代碼能夠隨時從新發布上線，對於client端實驗，好比app發版都是週期性的，因此須要可以在管理系統配置feature的開關
• 後端管理系統還可讓用戶自定義metric，微軟開發了Metric Definition Language (MDL)，去構造metric，如ctr等，底層會從新翻譯成SQL等其它語言。對於各類metric：產品效果指標，實驗的置信度，實驗是否分流均勻

2.experiment execution service

這個是ABTest的核心服務，爲各個接入AB的服務分配實驗變量。每一個變量V是一個參數集合，實驗能夠表示爲E{V1, V2}， 如V1實驗組，V2對照組。isolation group 會切分紅多個變量，以下圖：

每一個變量都會被關聯上一個或多個isolation group，好比存在兩個實驗E1{V1, V2}， E2{V3, V4}，E1關聯隔離組G1，G2。同時E2的變量也關聯G1，G2。 會發現兩個實驗變量所關聯的隔離組是有交集的，那麼這時候說明兩個實驗是會相互影響的，不能同時進行。

列舉了三種實驗組參數配置下發方式：

總之都是從experiment execution service拿到實驗組參數配置並緩存在本地。

1. 能夠經過應用程序在啓動時直接經過服務接口調用，去請求實驗組參數配置，這樣作到用戶在session內有一致的用戶體驗。服務端和客戶端都可採用這種方式
2. Edge Node能夠類比nginx，能夠負載均衡服務， 它和experiment execution service交互，對請求進行增強（填充改次請求 所對應的實驗參數配置）。這種方式不適合客戶端實驗， 由於客戶端用戶操做不少都是本地行爲，沒有發生網絡交互
3. 第三種方式經過爲AB實驗打包一個專門的lib， 客戶端實驗不須要將實驗參數在各個組件傳來傳去，而是每次都從這個lib去拿就能夠了。lib負責和experiment execution service週期性交互

還有個配置管理服務 去控制experiment execution service 進行一個實驗下不一樣的變量分配的開關， 該開關配置應該放到lib裏