億級流量實驗平臺設計精要

作爲架構師，你如何設計億級流量 A/B Test 平臺？

在互聯網行業，要上線一個策略 (CTR 預估、CVR 預估等)，或者一個功能，如果貿然全量上線，那麼如果新策略效果不佳，可能會造成不小的損失，要麼丟失用戶，要麼損失收入。

那麼怎樣才能避免此問題發生呢？

這就需要引入了實驗平臺，通過對流量打標籤，然後分析實驗效果，從而再決定是否實驗推全還是下線，一起來看看吧！

一、概念

實驗平臺，從字面意思來看，就是一個用來做實驗的平臺。

其 基本原理 就是把流量進行分流，特定流量，匹配特定策略。不同批次的用戶，看到的不同的策略。然後通過曝光、點擊等數據進行統計分析，得出實驗效果的好壞，從而決定是否推全該實驗。

換句話說，就是爲同一個目標制定兩個方案（比如兩個頁面），將產品的用戶流量根據特定策略分割成 A/B 兩組，一組實驗組，一組對照組，兩組實驗同時運行一段時間後分別統計兩組用戶的表現，再將相關結果數據（比如 pv/uv、商機轉化率等）進行對比，就可以科學地幫助決策。

通過對流量進行分流，運行實驗，統計實驗數據，進行數據分析，然後得出實驗效果。如下圖所示：

再根據實驗效果，進行反向數據分析，定位出實驗效果不好的源，進行頭腦風暴，再次做實驗，從而最終達到理想的實驗目的。如下圖所示：

二、分層實驗模型

在進行實驗平臺講解之前，先介紹下實驗平臺的理論基礎，以便大家能夠更好的理解後面的內容。

現在業界大部分實驗平臺，都基於谷歌 2017 年的一篇論文《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》, 其模型架構如下圖所示：

在該模型中，有幾個概念：

• 域（domain）：劃分的一部分流量

• 層（layer）：系統參數的一個子集

• 實驗（exp）：在一個域上，對一個或者多個參數修改，都將影響效果

• 流量在每個層被打散 (分配函數)，層與層之間流量正交

下圖【圖四】爲筆者線上實驗的一個簡略圖，在該圖中，總共有三個實驗層，分別爲 CTR 預估層，用戶畫像層和頻次策略層。

從圖四可以看到，流量在層之間穿梭，而一個流量只能命中一個層中的一個實驗，一個流量請求過程可能會命中多個層中的多個實驗 (每層命中一個實驗)。

使用分層實驗模型，需要滿足以下幾點：

• 相關聯的策略參數位於同一實驗層（即都是做 CTR 預估，那麼 CTR 預估相關的實驗，就放在同一層，即 CTR 預估層，以方便做實驗對比）

• 相互獨立的策略參數分屬於不同的實驗層（如上圖中 ，CTR 預估的實驗和頻次實驗是兩種性質不同的實驗，因此要放在兩層來實現，如果在一層的話，由於實驗性質不同，難以比較實驗效果）

• 一個流量只能命中一個層中的一個實驗

• 層之間的流量正交，不會互相影響（即層與層之間的實驗不會互相影響, 如【圖五】）

圖五

使用該分層模型作爲實驗平臺理論基礎的好處有以下幾點：

• 可以作爲一個獨立的部分，不與系統中的其他業務或者功能相互 影響

• 每一層流量都是 100% 的全量，可以避免流量切分過細，保證實驗間的可對比性、客觀性

• 層與層之間，流量獨立正交，不會互相影響

三、功能特點

一個可用或者完善的實驗平臺，需要有以下幾個功能：

• 支持多實驗併發迭代

• 支持白名單體驗

• 提供便捷的管理工具

• 便捷的查看實驗效果分析數據

• 支持實驗的切流和關閉

• 保證線上實驗安全性

• 支持實驗推全

• 支持功能定製化

下面，我們將從幾個功能點出發，詳細講述各個功能的原理。

支持多實驗併發迭代，指的是一個完善的實驗平臺，在功能上，需要支持多個實驗同時運行 (包括同一層和不同層之間)。

支持白名單體驗：因爲實驗分流有自己的策略，創建實驗的用戶不一定能夠命中這個實驗，而白名單的功能就是讓在白名單的用戶能夠每次都命中該實驗。

便捷的管理工具：這個指的是實驗後臺，一個實驗後臺需要能夠創建實驗，打開關閉實驗等

查看實驗效果分析數據：判斷一個實驗效果的好壞，就是通過實驗標籤分析實驗數據，能夠很直觀的觀察到實驗效果，從進行下一步實驗決策

實驗的切流和關閉：實驗的切流，指的是該實驗需要一定百分比的流量進行實驗，而實驗關閉，則指的是停掉該實驗

支持線上安全性：實驗平臺，本身就是起錦上添花的作用，其只是用來打實驗標籤的，不可本末倒置，影響了線上業務的正常功能

支持實驗推全：一個實驗效果如果好的話，就需要將全部的流量都命中該實驗，而實驗推全就是達到此效果

支持功能定製：沒有一個實驗平臺能夠滿足不同公司，甚至同一個公司不同部門之間的業務需求，但是，爲了儘可能的向這個目標靠攏，實驗平臺需要儘可能的靈活，低耦合，能夠儘量的配置化。

** 未命名公衆號 ** 我是蟲爸，85 後程序員，現任某互聯網公司高級技術專家一職。分享一些工作中的心得，雜談。聊聊架構，扯扯算法，就醬😭。 0 篇原創內容 公衆號

流量劃分

一般有以下幾種劃分方式：

• 完全隨機

• 用戶 id 哈希。

• 該流量劃分會使同一個用戶會一直命中同一實驗，從而保證了用戶體驗的一致性；而且也滿足對同一用戶具有累積效應的策略的實驗需求。但存在的問題就是，對於一些工具類屬性，沒有用戶 id 一說，只有設備 id 比如 idfa 和 imei 這些標記，但是隨着系統升級，這倆標記很難再獲取到，所以就需要系統能夠生成用戶唯一 id

• 用戶 id + 日期作爲一個整體進行哈希 這是一種更爲嚴格的保證流量均勻性的分流方式，可以保證流量劃分在跨時間維度上更爲均勻。

• 會犧牲用戶請求跨時間區間的一致性

• 跟上面這種用戶 id 哈希存在同樣的問題

• 用戶 id 尾號進行哈希

• 流量不均勻

• 也會存在用戶 id 所存在的問題

爲了兼容上述幾種哈希劃分方式的優點，而摒棄其缺點，我們引入了第四種流量劃分方式：

bucket_id = hash(uid + layer_id) % 1000

常見的哈希算法有 md5，crc 以及 MurmurHash 等。

• MD5 消息摘要算法（英語：MD5 Message-Digest Algorithm），一種被廣泛使用的密碼散列函數，可以產生出一個 128 位（16 字節）的散列值（hash value），MD5 算法將數據（如一段文字）運算變爲另一固定長度值，是散列算法的基礎原理。由美國密碼學家 Ronald Linn Rivest 設計，於 1992 年公開並在 RFC 1321 中被加以規範。

• CRC 循環冗餘校驗（Cyclic Redundancy Check）是一種根據網絡數據包或電腦文件等數據，產生簡短固定位數校驗碼的一種散列函數，由 W. Wesley Peterson 於 1961 年發表。生成的數字在傳輸或者存儲之前計算出來並且附加到數據後面，然後接收方進行檢驗確定數據是否發生變化。由於本函數易於用二進制的電腦硬件使用、容易進行數學分析並且尤其善於檢測傳輸通道干擾引起的錯誤，因此獲得廣泛應用。

• MurmurHash 是一種非加密型哈希函數，適用於一般的哈希檢索操作。由 Austin Appleby 在 2008 年發明，並出現了多個變種，與其它流行的哈希函數相比，對於規律性較強的鍵，MurmurHash 的隨機分佈特徵表現更良好。

其中，第三種 MurmurHash 算法，已經被很多開源項目使用，比如 libstdc++ (4.6 版)、Perl、nginx (不早於 1.0.1 版)、Rubinius、 libmemcached、maatkit、Hadoop 以及 redis 等。而且經過大量的測試，其流量分佈更加均勻，所以筆者採用的是此種哈希算法。

白名單

白名單，在實驗平臺中算是比較重要的功能，其目的就是存在於白名單中的用戶優先於流量分桶，命中某個實驗。

需要注意的一點是，假如白名單所在實驗和流量經過哈希分桶之後的實驗是兩個不同的實驗，這就只能以白名單優先級爲最高，換句話說，如果白名單命中了某個實驗，那麼在該層上，就不該再命中其他實驗。

管理後臺

用來管理實驗的，比如權限管理、層管理等，如下圖：

在上圖中，管理後臺，主要有以下幾個模塊：

• 實驗管理，顧名思義，管理現有實驗和創建新實驗

• 實驗列表：現有已經創建的所有實驗

• 創建實驗：創建新實驗

• 基礎配置，一些配置管理信息都在此模塊中

• 實驗層：增刪改實驗層

• 其他：針對實驗做的一些定製化，比如增加廣告位定向、年齡定向等

• 系統管理，主要針對用戶及其分組

• 分組管理，管理用戶屬於某個分組

• 實驗平臺的用戶權限管理，比如普通權限或者管理員權限

需要注意的是，用戶管理這塊的權限非常重要，因爲實驗平臺可能涉及到很核心的實驗，比如商業化中策略影響的實驗，所以用戶之間不能看到其他人創建的實驗，這層物理隔離非常重要。

分流平臺

分流評估 ，顧名思義，對流量進行分離，有兩個功能：

• 承接實驗後臺的實驗消息，建立維度索引

• 接收線上流量，根據維度索引、白名單以及對用戶設備哈希分桶後，給流量打標籤

分流平臺，是整個實驗平臺的核心模塊，一定要高性能，高可靠。

六、實驗效果

請求的實驗信息會以標籤的形式上報給 sdk，sdk 在進行曝光點擊的時候，會將這些信息上報，比如 "123_456_789" 格式。最終，這些會經過廣告實時流系統進行消費、數據清洗、實驗效果指標計算等工作。由於廣告系統是多業務指標系統，包括售賣率，ECPM， CTR， ACPE，負反饋率、財務消耗計算等。廣告實時流系統還需要日誌的關聯工作，比如關聯廣告互動日誌，廣告負反饋日誌。實時流的計算的結果，會落地到 druid 系統，方便實驗效果數據的快速檢索和二度加工。實驗效果實時指標數據計算延遲控制在一定的範圍內。

七、結語

最後需要提的是，實驗平臺在效果跟蹤決策方面是有一定的侷限性的。實驗平臺可以進行實驗效果的快速跟蹤，但是卻很難進行實驗效果好壞的決策。比如：如果對比實驗效果指標值全部提高或下降了，可以簡單認爲對比實驗的策略調整起正向作用或者反向作用；如果對比實驗的實驗效果指標值部分提高了，部分下降了，就不太好認定了。還有，實驗效果的短期效應和長期效應也可能是不一致，這將大大增加了實驗效果好壞的決策難度。

因此，實驗平臺是可以快速提升廣告業務策略迭代效率的工具，但是要想進行實驗好壞評定的決策，還需要很長的路要走。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/duU9OrEt9PceCKMxA1H4Tg