引言
A/B測定義
A/B 測試以數據驅動爲導向，能夠實現靈活的流量切分，使得同一產品的不一樣版本能同時在線，經過記錄和分析用戶對不一樣版本產生的行爲數據，獲得效果對比，最大程度地保證結果的科學性和準確性，從而幫助人們進行科學的產品決策。算法
基於用戶行爲數據計算不一樣版本的指標數據，是評估實驗結果的惟一依據。sql
指標產品設計
圖1. 新增指標shell
指標系統產品設計上採用了指標註冊的方式，用戶能夠在本身的業務域和業務線下進行指標註冊，註冊須要指定指標計算公式（SQL），指標SQL必須遵照SQL模板，並支持自定義維度（自動註冊維度/關聯維表）。分析層面上，用戶能夠查看固定與預計算好的指標，也能夠進行指標的多維分析。緩存
產品需求上，須要計算當日以及累計（實驗開始時間~前一天）的樣本、指標。架構
指標技術架構
圖2. 指標設計架構圖性能
多個實驗採起並行計算，單個實驗多個指標採起串行計算。測試
單個實驗須要計算的數據以下：
優化
圖3. 實驗計算數據spa
指標計算的特色在於：對於每個實驗，須要先計算樣本，指標是架設在樣本之上的指標，基礎指標P值的計算須要依賴樣本和指標，複合指標P值的計算須要基於分母重建樣本。對於每一個實驗來說，樣本多是變化的，用戶能夠自定義樣本，也能夠選擇分流服務日誌做爲默認兜底樣本。設計
指標計算優化
階段一：引擎和架構優化
計算引擎Spark：基於性能和成熟度的考量，選擇Spark做爲核心計算引擎，它相對Hive的優點就不贅述了。
OLAP引擎Clickhouse：指標分析須要基於明細數據進行多維複雜分析，目前的成熟引擎均可以知足，選擇CK的重要緣由是：1> CK的性能和成熟度已經獲得驗證 2> 內部有CK集羣，方便咱們直接使用。
計算方式：多個實驗並行計算，單個實驗內部的多指標串行計算。實驗之間關聯性較小，並行計算時合適的。單個實驗內部，多個指標關聯性較強，如複合指標，須要先計算基礎指標，才能夠複合計算，串行計算是合理的。在實現上的話，是經過調度shell腳本動態循環實驗完成的。
實現方式：單個實驗的計算是經過一個通用的Spark程序來完成的，離線調度任務起來的時候，讀取實驗指標的配置，先算明細，再算指標值。
AB平臺上線初期，實驗和指標數量較少（10+實驗，50+指標），基本能夠知足需求，總體計算時間大約是2~3個小時。
平臺在運行半年以後，隨着實驗數量的增多，整個時間延長到了5~6個小時，並行度已經增長到10，單個任務的資源增長到100core, 800G內存，怎麼優化？
階段二：計算模型優化
咱們抓取一個典型的廣告實驗，打印每一個指標各個階段的消耗時長，通過對計算的每一個過程執行時間分析，發現花在樣本和指標累計值計算上的時間特別長。AB指標的累計值計算規則是從>=實驗開始運行日期<=計算日期，指標定義sql會要求必須輸入時間字段，程序會自動進行判斷和日期的處理，若是一個實驗運行了3個月，那須要掃描3個月的數據進行計算，數據量較大會形成計算效率差、計算時間很長。
咱們統計了3個月內已關閉實驗的運行時長:
圖4. 實驗運行時長統計
從上圖看到，大於1個月的實驗佔總實驗數接近60%，比例是比較高的。
如何優化累計計算呢？
以前的計算模型：
圖5. 原計算模型
這個計算模型的優勢是相對獨立，可隨意計算任意一個日期的累計值；缺點是1>須要掃描的數據量比較大2>計算不夠準確：將樣本發生時間在指標時間以後的數據也計算進去了，結果會出現輕微偏差，舉例來說：5月1號用戶發生了轉化，可是5月2號用戶才參加實驗，此算法會把這樣的數據算作實驗帶來的轉化。
優化後的模型：
圖6. 新計算模型
此計算模型的優勢：1>累計計算的性能有了大幅度的提高，再也不隨着時間的增加，數據計算愈來愈慢的狀況出現；2>計算結果更加準確。缺點是：第N天的累計計算依賴於第N-1天的累計明細，複雜程度提高了。
通過此優化以後，每一個指標的計算時間相對可控，再也不出現時間特別長的實驗指標了。總體的計算時長保持在3個小時左右。
階段三：率指標批量優化
通過階段二的優化以後，總體知足50+實驗，200+指標的計算，單個實驗（5個指標）的總體計算時長可穩定在40分鐘左右。
好景不長，指標計算又面臨新挑戰：年初網校資源管控平臺總體對接AB以後，實驗數直線上升，實驗數達到天天150+,指標數600+，總體的計算時間長達10個小時，如何優化？
經過對實驗和指標數據進行分析，發現經過從資源管控平臺過來的實驗，默認都勾選了固定的幾個指標，至關於同一個指標在N個實驗裏出現，那是否能夠對單個指標批量計算實驗數據呢？
AB指標計算在設計時之因此會設計成單個實驗串行，多個實驗並行的方式，緣由是每一個實驗容許用戶自定義樣本，未自定義纔會使用平臺分流日誌兜底。AB平臺適配了多種類型的指標，批量計算適合的指標是：指定定義SQL中自己包含了實驗名和組名，而且屬於基礎率指標，即無需和樣本進行關聯。
圖7. 率指標優化方案
此方案上線以後，平臺大部分的實驗均可以基於此方案進行批量計算，加快執行效率。總體指標計算的時間縮短到5個小時，提高了一倍的性能。
階段四：均值指標批量優化
階段三是針對率指標的批量優化，可是系統中存在很多的均值指標，被多個實驗勾選，部分指標計算比較複雜，即便計算單天的數據，計算時間也須要半個小時，如：
圖8. 指標SQL
這個是指標SQL，實際計算當中還須要再關聯樣本，計算基於樣本的均值明細和均值，整個計算會變得比較複雜，單次計算時間大約在半個小時。還能怎麼優化呢？
方案一：
咱們採用spark的checkpoint機制，將首次計算的明細數據經過checkpoint緩存起來，這樣計算均值、p值、置信區間就能夠直接用緩存的明細數據進行計算。
實施以後，發現總體的計算時長有下降，可是因爲checkpoint會涉及到把數據寫入hdfs，無形中將spark退回到了Hive的方式，總體有提高，可是不是很明顯。
方案二：
可否像階段三那邊，批量計算緩存到CK呢？ 是能夠的，模型會複雜一些。
圖9. 均值指標優化方案
此方案的核心在於：指標sql會先計算獲得臨時明細數據，在計算指標明細時，直接從CK中獲取，依賴於Spark的RDD跨數據源的能力，實現計算時的動態選取，最終明細數據再回寫CK。
總結
AB測指標計算優化以後，150+實驗、600+指標，總體的計算時長保持在2~3個小時，最重要的是隨着實驗和指標的增長，總體的計算時長增長是可控的，不會幾何級數的增加，達到了咱們優化的效果。
想要了解更多關於教育行業的技術乾貨可掃碼下方二維碼加入好將來官方交流羣