❝ 關注公衆号:【高性能架構探索】， 回複[pdf]，免費擷取 ❞
大家好，我是蟲爸。今天給大家分享一款億級流量實驗平台。在網際網路行業，要上線一個政策(CTR預估、CVR預估等)，或者一個功能，如果貿然全量上線，那麼如果新政策效果不佳，可能會造成不小的損失，要麼丢失使用者，要麼損失收入。
那麼怎樣才能避免此問題發生呢？這就引入了實驗平台，通過對流量打标簽，然後分析實驗效果，進而再決定是否實驗推全還是下線。
實驗平台，從字面意思來看，就是一個用來做實驗的平台。其 「基本原理」 就是把流量進行分流，特定流量，比對特定政策。不同批次的使用者，看到的不同的政策。然後通過曝光、點選等資料進行統計分析，得出實驗效果的好壞，進而決定是否推全該實驗。
換句話說，就是為同一個目标制定兩個方案（比如兩個頁面），将産品的使用者流量根據特定政策分割成 A/B 兩組，一組實驗組，一組對照組，兩組實驗同時運作一段時間後分别統計兩組使用者的表現，再将相關結果資料（比如 pv/uv、商機轉化率等）進行對比，就可以科學地幫助決策。
通過對流量進行分流，運作實驗，統計實驗資料，進行資料分析，然後得出實驗效果。如下【圖一】
圖一
再根據實驗效果，進行反向資料分析，定位出實驗效果不好的源，進行頭腦風暴，再次做實驗，進而最終達到理想的實驗目的。如下【圖二】
圖二
在進行實驗平台講解之前，先介紹下實驗平台的理論基礎，以便大家能夠更好的了解後面的内容。
現在業界大部分實驗平台，都基于谷歌2017年的一篇論文《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》,其模型架構如下圖【圖三】所示：
圖三
在該模型中，有幾個概念：
域（domain）：劃分的一部分流量
層（layer）：系統參數的一個子集
實驗（exp）：在一個域上，對一個或者多個參數修改，都将影響效果
流量在每個層被打散(配置設定函數)，層與層之間流量正交
下圖【圖四】為筆者線上實驗的一個簡略圖，在該圖中，總共有三個實驗層，分别為CTR預估層，使用者畫像層和頻次政策層。
從圖四可以看到，流量在層之間穿梭，而一個流量隻能命中一個層中的一個實驗，一個流量請求過程可能會命中多個層中的多個實驗(每層命中一個實驗)。
使用分層實驗模型，需要滿足以下幾點：
相關聯的政策參數位于同一實驗層（即都是做CTR預估，那麼CTR預估相關的實驗，就放在同一層，即CTR預估層，以友善做實驗對比）
互相獨立的政策參數分屬于不同的實驗層（如上圖中 ，CTR預估的實驗和頻次實驗是兩種性質不同的實驗，是以要放在兩層來實作，如果在一層的話，由于實驗性質不同，難以比較實驗效果）
一個流量隻能命中一個層中的一個實驗
層之間的流量正交，不會互相影響（即層與層之間的實驗不會互相影響,如【圖五】）
圖五
使用該分層模型作為實驗平台理論基礎的好處有以下幾點：
可以作為一個獨立的部分，不與系統中的其他業務或者功能互相 影響
每一層流量都是100%的全量，可以避免流量切分過細，保證明驗間的可對比性、客觀性
層與層之間，流量獨立正交，不會互相影響
一個可用或者完善的實驗平台，需要有以下幾個功能：
支援多實驗并發疊代
支援白名單體驗
提供便捷的管理工具
便捷的檢視實驗效果分析資料
支援實驗的切流和關閉
保證線上實驗安全性
支援實驗推全
支援功能定制化
下面，我們将從幾個功能點出發，詳細講述各個功能的原理。
支援多實驗并發疊代，指的是一個完善的實驗平台，在功能上，需要支援多個實驗同時運作(包括同一層和不同層之間)。
支援白名單體驗：因為實驗分流有自己的政策，建立實驗的使用者不一定能夠命中這個實驗，而白名單的功能就是讓在白名單的使用者能夠每次都命中該實驗。
便捷的管理工具：這個指的是實驗背景，一個實驗背景需要能夠建立實驗，打開關閉實驗等
檢視實驗效果分析資料：判斷一個實驗效果的好壞，就是通過實驗标簽分析實驗資料，能夠很直覺的觀察到實驗效果，從進行下一步實驗決策
實驗的切流和關閉：實驗的切流，指的是該實驗需要一定百分比的流量進行實驗，而實驗關閉，則指的是停掉該實驗
支援線上安全性：實驗平台，本身就是起錦上添花的作用，其隻是用來打實驗标簽的，不可本末倒置，影響了線上業務的正常功能
支援實驗推全：一個實驗效果如果好的話，就需要将全部的流量都命中該實驗，而實驗推全就是達到此效果
支援功能定制：沒有一個實驗平台能夠滿足不同公司，甚至同一個公司不同部門之間的業務需求，但是，為了盡可能的向這個目标靠攏，實驗平台需要盡可能的靈活，低耦合，能夠盡量的配置化。
實驗平台必備的三個子產品，分别為：
管理背景
實驗背景
分流平台
管理背景主要是管理實驗的，包括建立和停止實驗等。實驗背景與管理背景進行資料上的互動，将管理背景的消息轉換成特有的消息，進行轉發和持久化。而分流平台，其一接收實驗背景的實驗消息建立内部次元索引，其二接收線上流量，根據流量屬性，給流量打上對應的标簽。
上圖，是一個實驗平台架構圖，下面從建立實驗角度，和流量的角度進行講解。
建立實驗角度：
1、在管理背景建立對應的實驗
2、管理背景将建立的實驗資訊發送給實驗背景
3、實驗背景将實驗首先發送至消息系統(kafka等)，然後将實驗落地持久化(DB)
4、分流平台消耗消息系統中的實驗消息，加載至記憶體
流量角度：1、 流量攜帶其基本屬性(使用者畫像，app資訊等)請求分流平台
2、 分流平台根據流量屬性，進行定制化比對，然後使用分流算法，計算實驗标簽
3、流量傳回至調用方SDK後，SDK上報曝光、點選等資訊至資料總線(大資料叢集)
4、資料計算服務分析大資料叢集的資料，計算對應的名額展示在管理背景。
實驗平台，從子產品劃分上 ，如下圖所示：
在具體介紹下文之前，我們先了解一個概念，以便能更友善的了解下述内容。
桶
bucket即桶。實驗平台最底層，将流量進行hash之後，隻能流入某一個桶裡。
一般有以下幾種劃分方式：
完全随機
使用者id哈希。
該流量劃分會使同一個使用者會一直命中同一實驗，進而保證了使用者體驗的一緻性；而且也滿足對同一使用者具有累積效應的政策的實驗需求。但存在的問題就是，對于一些工具類屬性，沒有使用者id一說，隻有裝置id比如idfa和imei這些标記，但是随着系統更新，這倆标記很難再擷取到，是以就需要系統能夠生成使用者唯一id
使用者id + 日期作為一個整體進行哈希 這是一種更為嚴格的保證流量均勻性的分流方式，可以保證流量劃分在跨時間次元上更為均勻。
會犧牲使用者請求跨時間區間的一緻性
跟上面這種使用者id哈希存在同樣的問題
使用者id尾号進行哈希
流量不均勻
也會存在使用者id所存在的問題
為了相容上述幾種哈希劃分方式的優點，而摒棄其缺點，我們引入了第四種流量劃分方式：
常見的雜湊演算法有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 系統，友善實驗效果資料的快速檢索和二度加工。實驗效果實時名額資料計算延遲控制在一定的範圍内。
最後需要提的是，實驗平台在效果跟蹤決策方面是有一定的局限性的。實驗平台可以進行實驗效果的快速跟蹤，但是卻很難進行實驗效果好壞的決策。比如：如果對比實驗效果名額值全部提高或下降了，可以簡單認為對比實驗的政策調整起正向作用或者反向作用；如果對比實驗的實驗效果名額值部分提高了，部分下降了，就不太好認定了。還有，實驗效果的短期效應和長期效應也可能是不一緻，這将大大增加了實驗效果好壞的決策難度。
是以，實驗平台是可以快速提升廣告業務政策疊代效率的工具，但是要想進行實驗好壞評定的決策，還需要很長的路要走。