推ter A/B測試技術概覽
A/B測試在推ter的整個產品流程中是著非常核心的一個環節，推ter通過它來驗證新功能是否有效。前段時間，推ter發布了 博客 介紹了他們是如何實施A/B測試的。日前，他們又 介紹 了A/B測試背后的系統。
概覽
推ter從2010年開始使用他們的A/B測試工具DDG（Duck Duck Goose ），它已經成為聚合數據、記錄用戶行為、分析指標的系統性平臺。
下圖為A/B測試工具概要數據流。
A/B測試的基本流程
通常來說，A/B測試需要事先設置一些參數和度量值。通過DDG，測試人員可以直接通過網頁設置A/B測試的細節：
- 實驗范圍，比如限定語言、國家、操作系統等參數；
- 實驗對照組，確定測試修改點和當前產品的區別；
- 實驗指標，設置需要追蹤的指標，DDG默認會采集一些基礎數據，其他指標可以自定義，或者從庫中選取；
通過上述設置，DDG會提供給實驗人員一些代碼，作為“需求開關”。然后，系統會開始記錄實驗過程中需要度量的數據。
指標定義
DDG提供三種指標類型：
- 內置指標，大部分由實驗團隊定義和維護（例如登錄次數、發推次數等），在實驗中這些指標值會被自動追蹤；
- 實驗者定義和配置的指標，實驗者可以通過輕量級的領域專用語言（Domain Specific Language，DSL）定義需要記錄的事件，DDG的管道會為實驗者計算這些指標；
- 導入的指標，這些指標完全由推ter工程師創建，實驗者可以創建自定義聚合方法，度量自定義內容；
這些可以被聚合到“指標組”中，以方便實驗人員選擇。同時，每個指標組都由創建人維護，所有修改記錄都會被記錄。
數據處理管道
指標數據收集，都會通過管道進行運算。聚合數據也是整個系統中最大的挑戰。一個指標源數據每天可能會產生非常大數量級的數據。
實驗平臺使用Hadoop的Map-Reduce任務來解決運算的性能問題。為了盡可能提高性能，推ter團隊還和Hadoop團隊共同合作，做了大量調優。
另外有一些輕量級的流處理任務，會通過 TSAR 在推ter的 Heron平臺 進行實時計算。
上圖中的Scalding管道，可以被認為有三個不同的階段。
首先，將原始數據聚合成每個用戶、每個小時的基礎數據集。這些數據會被作為下一階段的輸入數據，同時也會被用作計算其他數據。
然后，第一階段生成的數據會加入A/B測試的表達式，并在實驗過程中計算每個指標、每個用戶的聚合數據。第二階段的結果可以被用于深入挖掘結果。
最后，第三階段會匯總所有實驗數據。這些實驗數據會被加載到 Manhattan 中，產品團隊可以在內部看板中進行瀏覽。
總結
支撐推ter A/B測試平臺的技術設施非常廣泛，究其原因主要是因為龐大的數據量。平臺需要對大量數據加以處理，以進行分析和實驗。通過管道的設計，也使得平臺可以對多粒度數據進行不同類型的分析。