互聯網流量下的分層實驗平臺是咋作的

前言

對於如今擁有大流量的互聯網平臺來講，一個微小的頁面改版或者是一個微小的後臺內容推薦模型參數的修改都會產生很是大的影響，如何安全的在線上流量驗證這些改進是否真有助於提升公司的收益或者是用戶的體驗呢？

A/B Test

很容易想到作A/B Test，咱們能夠用一種方式把全網流量分紅100份，取其中兩份流量來進行實驗：一份做爲對照組，一份做爲實驗組。因爲實驗所佔流量爲全網的1%，故而影響範圍小，即便出現了負收益也不影響大盤。

假設每次請求中都有req_id，咱們對req_id取模，而後根據餘數來劃分流量。在實際工程開發中，一般會對每一個實驗產生一個惟一的sample_id做爲試驗標識，後端日誌記錄該sample_id的相關信息，統計組對離線日誌進行統計，對一個實驗下的兩個sample_id（對照組sample_id，實驗組sample_id）的各類統計指標進行對比，來確認試驗效果。以下圖所示：

有兩個實驗：實驗1和實驗n。 每一個實驗又分爲對照組（基線）和實驗組，每組流量大小相等。 實驗1對照組流量是req_id % 100 = 0，實驗組是req_id % 100 = 1；實驗n對照組流量是req_id % 100 = 98，實驗組是req_id % 100 = 99。只要req_id最後兩位分佈夠均勻，那麼每份流量大小基本相同。

實驗分層

可是這麼作有一個問題，就是最多容許同時進行50個實驗（每一個實驗佔用兩份流量）。在今天的互聯網企業中，可能同時進行成千上萬的功能開發，而每一個功能背後都須要進行實驗，如何儘量同時知足這些需求呢？咱們對實驗進行分層：即同一份流量可能同時命中兩個或者多個實驗，以下圖所示，一份流量能夠同時命中實驗1和實驗n：

可是這麼作須要有一個前提，就是兩個層的實驗不能互相沖突，每一個層只能修改本身的參數，即若是實驗1和實驗n同時修改參數A，則這兩個實驗必須在同一層，層與層之間的劃分就看層間參數是否有交集。

最終咱們根據參數來劃分層，有依賴關係的參數必須劃分在同一層（例如頁面背景顏色和字體顏色必須在同一層，若是頁面背景顏色和字體顏色都被設置成藍色，那麼咱們就看不到頁面上的字了），沒有依賴關係的參數能夠劃分在不一樣層，每一個參數只出如今一個層中，不會出如今多層中。

原來每層能作50個實驗，如今把參數分了n層，每層均可以同時進行50個實驗，那麼如今可同時進行50 * n 個實驗，n爲實驗層數。

流量正交

可是如今還有一個問題，如上圖所示實驗1和實驗n用的是徹底相同的流量，這可能會有一些問題：咱們雖然確認實驗1和實驗n沒有參數衝突，可是沒法肯定實驗1和實驗n的實驗效果是否互相影響。好比實驗1進行頁面改版使得頁面更美觀，實驗n對後端推薦模型進行參數優化使得推薦內容更有趣，這兩個實驗不修改相同的參數因此能夠分在不一樣的層中，可是這兩個實驗都會影響用戶頁面停留時長和用戶的點擊率，若是流量徹底同樣，咱們統計的結果究竟是實驗1產生的影響仍是實驗n產生的影響呢？咱們必須消除這個影響。

• 流量正交：實驗1的流量必須均勻分佈在後一層中，這樣才能保證明驗1觀察的效果主要是由頁面改進帶來的效果，一樣實驗n的流量也必須均勻分佈在後一層而且均勻來自於前一層。咱們採用哈希值取模代替原始req_id取模，而且哈希時傳入層ID，這樣層與層之間的哈希值不一樣，從而達到均勻分佈。

以下圖所示：

實驗1的流量均勻分佈在下一層，實驗n的流量來源均勻分佈在前一層

流量劃分

大多時候，咱們須要保持用戶在產品使用上的體驗一致性，例如：不能前一次看到頁面字體顏色爲藍色，刷新一次頁面字體變成綠色。這就提醒咱們在進行流量劃分的時候，不是全部實驗都可以用req_id的哈希值進行劃分，咱們必須使用uid的哈希值進行劃分，若是沒有uid咱們可使用cookie的哈希值進行劃分。因此，這裏面有一個流量優先級劃分順序： uid > cookie > req_id。

實驗轉全

當咱們在小流量下驗證了一種改進是有效的，那麼如何把這個改進在全流量上生效呢？有如兩種方法。

• 直接修改代碼，使其在全流量上生效。這種方式比較暴力，若是直接在全流量上修改代碼使其生效，那麼當遇到一些在大流量下才能發現的問題時，咱們不得不從新回滾代碼。
• 慢慢增大實驗流量，最終使其在全流量上生效。這種方式比較穩妥，即便發生沒有預料到的問題也能經過控制實驗流量來止損，可是它會擠佔同一層的其它實驗流量，若是實驗流量增大到100%，那麼同一層其它實驗就得不到流量。

咱們針對第二種方式對試驗平臺進行一個改進，對每個參數增長一個新的發射層(Launch Layer)，以下圖所示：

• 每一個實驗參數能夠同時既在發射層，又在實驗層。
• 實驗層能夠覆蓋發射層的參數值。
• 每一個參數最多隻能在一個發射層。

當小流量實驗須要全量上線時，實驗進行層間轉移：把實驗從實驗層搬到發射層，經過調節發射層的實驗組與對照組（通常是基線，即線上流量用的參數默認值）比例來使得改進最終用於全流量，這樣既不影響原有的實驗流量分配，又可以快速調節流量大小。在調節期間，若是發現問題，能夠控制發射層實驗組與對照組的流量比例來止損。當咱們的改進在發射層上全流量上線後，觀察一段時間沒有什麼問題，就能夠放心經過修改代碼來把改進應用到線上全流量，而且撤掉髮射層。

工程開發與實驗評估

到此爲止，咱們討論了實驗平臺的設計的理論依據，接下來就是工程開發。實驗平臺應該在一次訪問的入口處，根據本次請求的相關信息來決定命中哪一個實驗並生成一個惟一的sample_id，以後把sample_id傳遞到下游服務；下游各個服務根據sample_id來人爲修改代碼，根據sample_id作不一樣的動做，而且記錄相關日誌。

對於一個成熟的實驗平臺來講，其應該具有以下幾個功能：

• 可以靈活配置試驗流量並快速生效（一般使用配置下發）。
• 可以檢查實驗配置合法性。
• 有一套信服的評估標準體系（由專門的統計組人員進行專業評估）。

結語

以上就是一個實驗平臺建設時須要考慮的基本的原理性的東西，但願能對小夥伴有幫助。因爲水平有限，文中某些地方講的不合理或者不對，但願小夥伴留言指教。

參考文獻

《Overlapping Expeeriment Infrastructure: More, Better, Faster Experimentation》, Diane Tang, Ashish Agarwal, Deirdre O'Brien, Mike Meyer, Google, Inc.