作為一款面向 ToB 市場(chǎng)的產(chǎn)品——火山引擎 A/B 測(cè)試(DataTester)為了滿足客戶對(duì)數(shù)據(jù)安全、合規(guī)問題等需求，探索私有化部署是產(chǎn)品無(wú)法繞開的一條路。

在面向 ToB 客戶私有化的實(shí)際落地中，火山引擎 A/B 測(cè)試(DataTester)也遇到了字節(jié)內(nèi)部服務(wù)和企業(yè) SaaS 服務(wù)都不容易遇到的問題。在解決這些問題的落地實(shí)踐中，火山引擎 A/B 測(cè)試團(tuán)隊(duì)沉淀了一些流程管理、性能優(yōu)化等方面的經(jīng)驗(yàn)。

本文主要分享火山引擎 A/B 測(cè)試當(dāng)前的私有化架構(gòu)，遇到的主要問題以及從業(yè)務(wù)角度出發(fā)的解決思路。

火山引擎 A/B 測(cè)試私有化架構(gòu)

架構(gòu)圖

整套系統(tǒng)采用 Ansible+Bash 的方式構(gòu)建，為了適應(yīng)私有化小集群部署，既允許各實(shí)例對(duì)等部署，復(fù)用資源，實(shí)現(xiàn)最小三節(jié)點(diǎn)交付的目標(biāo),，又可以做在線、離線資源隔離提高集群穩(wěn)定性。集群內(nèi)可以劃分為三部分：

業(yè)務(wù)服務(wù): 主要是直接向用戶提供界面或者功能服務(wù)的, 例如實(shí)驗(yàn)管理、實(shí)驗(yàn)報(bào)告、OpenAPI、數(shù)據(jù)接入等。

基礎(chǔ)服務(wù): 不直接面向用戶,為上層服務(wù)的運(yùn)行提供支撐,例如支持實(shí)驗(yàn)報(bào)告的計(jì)算引擎、為指標(biāo)創(chuàng)建提供元信息的元信息服務(wù);基礎(chǔ)服務(wù)同時(shí)還會(huì)充當(dāng)一層對(duì)基礎(chǔ)設(shè)施的適配,用來(lái)屏蔽基礎(chǔ)設(shè)施在 SaaS 和私有化上的差異, 例如 SaaS 采用的實(shí)時(shí)+離線的 Lambda 架構(gòu), 私有化為了減少資源開銷,適應(yīng)中小集群部署只保留實(shí)時(shí)部分, 計(jì)算引擎服務(wù)向上層屏蔽了這一差異。

基礎(chǔ)設(shè)施: 內(nèi)部團(tuán)隊(duì)提供統(tǒng)一私有化基礎(chǔ)設(shè)施底座 minibase,采用宿主機(jī)和 k8s 結(jié)合的部署方式,由 minibase 適配底層操作系統(tǒng)和硬件, 上層業(yè)務(wù)直接對(duì)接 minibase。

私有化帶來(lái)的挑戰(zhàn)

挑戰(zhàn) 1：版本管理

傳統(tǒng) SaaS 服務(wù)只需要部署維護(hù)一套產(chǎn)品供全部客戶使用，因此產(chǎn)品只需要針對(duì)單個(gè)或幾個(gè)服務(wù)更新，快速上線一個(gè)版本特性，而不需要考慮從零開始搭建一套產(chǎn)品。SaaS 服務(wù)的版本發(fā)布周期往往以周為單位，保持每周 1-2 個(gè)版本更新頻率。

但是，在私有化交付中，我們需要確定一個(gè)基線版本并且綁定每個(gè)服務(wù)的小版本號(hào)以確保相同版本下每套環(huán)境中的交付物等價(jià)，以減輕后續(xù)升級(jí)運(yùn)維成本。通常，基線版本的發(fā)布周期往往以雙月為單位。

版本發(fā)布周期

由于私有化和 SaaS 服務(wù)在架構(gòu)、實(shí)現(xiàn)、基礎(chǔ)底座上均存在不同，上述的發(fā)布節(jié)奏會(huì)帶來(lái)一個(gè)明顯的問題：

• 團(tuán)隊(duì)要投入大量的開發(fā)和測(cè)試人力集中在發(fā)版周期內(nèi)做歷史 Feature 的私有化適配、私有化特性的開發(fā)、版本發(fā)布的集成測(cè)試，擠占其他需求的人力排期。
• 為了將周期內(nèi)集中完成的工作分散到 Feature 開發(fā)階段，重新規(guī)范了分支使用邏輯、完善私有化流水線和上線流程，讓研發(fā)和測(cè)試的介入時(shí)間前移。

解法：

1、分支邏輯

分支管理

SaaS 和私有化均基于 master 分支發(fā)布，非私有化版本周期內(nèi)不特別區(qū)分 SaaS 和私有化。

私有化發(fā)布周期內(nèi)單獨(dú)創(chuàng)建對(duì)應(yīng)版本的私有化分支，發(fā)布完成后向 master 分支合并。這樣保證了 master 分支在任何情況下都應(yīng)當(dāng)能同時(shí)在 SaaS 環(huán)境和私有化環(huán)境中正常工作。

2、發(fā)布流水線

功能上線流程

發(fā)布流水線

內(nèi)部搭建一套私有化預(yù)發(fā)布環(huán)境，建設(shè)了一套流水線，對(duì) master 分支的 mr 會(huì)觸發(fā)流水線同時(shí)在 SaaS 預(yù)發(fā)布環(huán)境和私有化預(yù)發(fā)布環(huán)境更新最新 master 分支代碼，并執(zhí)行自動(dòng)化回歸和人工回歸測(cè)試。這樣做的好處在于：

• 推動(dòng)了具體 Feature 的研發(fā)從技術(shù)方案設(shè)計(jì)層面考慮不同環(huán)境的 Diff 問題，減少了后期返工的成本
• 測(cè)試同學(xué)的工作化整為零,避免短時(shí)間內(nèi)的密集測(cè)試
• 減少研發(fā)和測(cè)試同學(xué)的上下文切換成本，SaaS 和私有化都在 Feature 開發(fā)周期內(nèi)完成

挑戰(zhàn) 2：性能優(yōu)化

火山引擎 A/B 測(cè)試工具的報(bào)告計(jì)算是基于 ClickHouse 實(shí)現(xiàn)的實(shí)時(shí)分析。SaaS 采用多租戶共用多個(gè)大集群的架構(gòu)，資源彈性大，可以合理地復(fù)用不同租戶之間的計(jì)算資源。

私有化則大部分為小規(guī)模、獨(dú)立集群，不同客戶同時(shí)運(yùn)行的實(shí)驗(yàn)個(gè)數(shù)從幾個(gè)到幾百個(gè)不等，報(bào)告觀測(cè)時(shí)間和用戶習(xí)慣、公司作息相關(guān)，有明顯的峰谷現(xiàn)象。因此實(shí)驗(yàn)報(bào)告產(chǎn)出延遲、實(shí)時(shí)分析慢等現(xiàn)象在私有化上更加容易暴露。

解法：

實(shí)驗(yàn)報(bào)告體系

首先，介紹下火山引擎 A/B 測(cè)試產(chǎn)品的實(shí)驗(yàn)報(bào)告體系。以下圖的實(shí)驗(yàn)報(bào)告為例:

從上往下看產(chǎn)出一個(gè)實(shí)驗(yàn)報(bào)告必要的輸入包含:

• 分析的日期區(qū)間及過濾條件
• 選擇合適的指標(biāo)來(lái)評(píng)估實(shí)驗(yàn)帶來(lái)的收益
• 實(shí)驗(yàn)版本和對(duì)照版本
• 報(bào)告類型, 例如:做多天累計(jì)分析、單天的趨勢(shì)分析等

指標(biāo)如何定義呢?

組成指標(biāo)的核心要素包括:

1、由用戶行為產(chǎn)生的事件及屬性

2、預(yù)置的算子

3、四則運(yùn)算符

即對(duì)于一個(gè)用戶的某幾個(gè)行為按照算子的規(guī)則計(jì)算 value 并使用四則運(yùn)算組合成一個(gè)指標(biāo)。

由此，我們可以大概想象出一個(gè)常規(guī)的 A/B 實(shí)驗(yàn)報(bào)告查詢是通過實(shí)驗(yàn)命中情況圈出實(shí)驗(yàn)組或?qū)φ战M的人群，分析這類群體中在實(shí)驗(yàn)周期內(nèi)的指標(biāo)值。

由于 A/B 特有的置信水平計(jì)算需求，統(tǒng)計(jì)結(jié)果中需要體現(xiàn)方差等其他特殊統(tǒng)計(jì)值，所有聚合類計(jì)算如：求和、PV 數(shù)均需要聚合到人粒度計(jì)算。

模型優(yōu)化

如何區(qū)分用戶命中哪一組呢?

集成 SDK 調(diào)用 A/B 分流方法的同時(shí)會(huì)上報(bào)一條實(shí)驗(yàn)曝光事件記錄用戶的進(jìn)組信息，后續(xù)指標(biāo)計(jì)算認(rèn)為發(fā)生在進(jìn)組之后的事件受到了實(shí)驗(yàn)版本的影響。舉個(gè)例子：

進(jìn)入實(shí)驗(yàn)版本 1 的事件 A 的 PV 數(shù)是 2，UV 數(shù)是 1，轉(zhuǎn)化為查詢模型是:

上述模型雖然最符合直覺，但是存在較多的資源浪費(fèi):

• 曝光事件和普通事件存儲(chǔ)在一張事件表中量級(jí)大
• 曝光事件需要搜索第一條記錄，掃描的分區(qū)數(shù)會(huì)隨著實(shí)驗(yàn)時(shí)間的增加而增加
• 曝光事件可能反復(fù)上報(bào)，計(jì)算口徑中僅僅第一條曝光為有效事件

針對(duì)上述問題對(duì)計(jì)算模型做出一些優(yōu)化，把曝光事件轉(zhuǎn)化為屬性記錄在用戶表中，新的模型變化為:

這么做帶來(lái)的優(yōu)點(diǎn)是:

• 用戶表不存在時(shí)間的概念,數(shù)據(jù)增長(zhǎng)=新用戶增速,規(guī)模可控
• 用戶表本身會(huì)作為維度表在原模型中引入,這類情況下減少一次 join 運(yùn)算 模型優(yōu)化后經(jīng)測(cè)試 14 天以上實(shí)驗(yàn)指標(biāo)多天累計(jì)報(bào)告查詢時(shí)長(zhǎng)減少 50%以上，且隨實(shí)驗(yàn)時(shí)長(zhǎng)增加提升。

預(yù)聚合

私有化部署實(shí)施前會(huì)做前期的資源預(yù)估，現(xiàn)階段的資源預(yù)估選擇了“日活用戶”和“日事件量”作為主要輸入?yún)?shù)。這里暫時(shí)沒有加入同時(shí)運(yùn)行的實(shí)驗(yàn)數(shù)量是因?yàn)椋?/p>

• 一是，我們希望簡(jiǎn)化資源計(jì)算的模型。
• 二是，同時(shí)運(yùn)行的實(shí)驗(yàn)數(shù)量在大多數(shù)情況下無(wú)法提前預(yù)知。

但是該公式會(huì)引入一個(gè)問題：相同資源的集群在承載不同數(shù)量級(jí)的實(shí)驗(yàn)時(shí)計(jì)算量相差較大。實(shí)驗(yàn)數(shù)量少的場(chǎng)景下，當(dāng)下數(shù)據(jù)處理架構(gòu)輕量化，計(jì)算邏輯后置到查詢側(cè),，指標(biāo)計(jì)算按需使用，大大減輕了數(shù)據(jù)流任務(wù)的壓力。

但是假設(shè)集群中同時(shí)運(yùn)行 100 個(gè)實(shí)驗(yàn)，平均每個(gè)實(shí)驗(yàn)關(guān)注 3 個(gè)指標(biāo)加上實(shí)驗(yàn)的進(jìn)組人數(shù)統(tǒng)計(jì)，在當(dāng)前查詢模型下每天至少掃描事件表 100*(3+1)次，如果再疊加使用自定義過濾模板等預(yù)計(jì)算條件，這個(gè)計(jì)算量會(huì)被成倍放大,直到導(dǎo)致查詢?nèi)蝿?wù)堆積數(shù)據(jù)產(chǎn)出延遲。

重新觀察實(shí)驗(yàn)報(bào)告核心元素以及指標(biāo)構(gòu)成能發(fā)現(xiàn):

• 指標(biāo)、報(bào)告類型、實(shí)驗(yàn)版本是可枚舉且預(yù)先知曉的
• 實(shí)驗(yàn)命中和人綁定,版本對(duì)比先劃分出進(jìn)入對(duì)照組和實(shí)驗(yàn)組的人,然后做指標(biāo)比較
• 基于假設(shè)檢驗(yàn)的置信水平計(jì)算需要按人粒度計(jì)算方差
• 現(xiàn)有的指標(biāo)算子均可以先按人粒度計(jì)算(按....去重除外)

是否能夠通過一次全量數(shù)據(jù)的掃描計(jì)算出人粒度的所有指標(biāo)和實(shí)驗(yàn)版本?

答案是可以的：掃描當(dāng)天的事件數(shù)據(jù),根據(jù)實(shí)驗(yàn)、指標(biāo)配置計(jì)算一張人粒度的指標(biāo)表 user_agg。

通過 user_agg 表可以計(jì)算出指標(biāo)計(jì)算需要的 UV 數(shù)、指標(biāo)的統(tǒng)計(jì)值、指標(biāo)的方差。如果對(duì) user_agg 表的能力做進(jìn)一步拓展,幾乎可以代替原始表完成實(shí)驗(yàn)報(bào)告中 80%以上的指標(biāo)計(jì)算,同時(shí)也很好地支持了天級(jí)時(shí)間選擇切換、用戶屬性標(biāo)簽過濾等。

修改后的指標(biāo)計(jì)算模型

通過經(jīng)驗(yàn)數(shù)據(jù)，一個(gè)用戶平均每天產(chǎn)生的事件量在 100-500 條不等，聚合模型通過少數(shù)幾次對(duì)當(dāng)天數(shù)據(jù)的全表掃描得到一張 1/100-1/500 大小的中間表，后續(xù)的指標(biāo)計(jì)算、用戶維度過濾均可以使用聚合表代替原始表參與運(yùn)算。當(dāng)然考慮到聚合本身的資源開銷，收益會(huì)隨著運(yùn)行實(shí)驗(yàn)數(shù)增加而提高，而實(shí)驗(yàn)數(shù)量過少時(shí)可能會(huì)造成資源浪費(fèi)，是否啟用需要在兩者之間需求平衡點(diǎn)。

挑戰(zhàn) 3：穩(wěn)定性

私有化服務(wù)的運(yùn)維通道復(fù)雜、運(yùn)維壓力大，因此對(duì)服務(wù)的可用性要求更加嚴(yán)格。A/B 測(cè)試穩(wěn)定性要求最高的部分是分流服務(wù)，直接決定了線上用戶的版本命中情況。

分流服務(wù)本身面向故障設(shè)計(jì)， 采用降級(jí)的策略避免調(diào)用鏈路上的失敗影響全部實(shí)驗(yàn)結(jié)果，犧牲一部分實(shí)時(shí)性使用多級(jí)緩存保障單一基礎(chǔ)設(shè)施離線的極端情況下分流結(jié)果依然穩(wěn)定。

分流服務(wù)總體架構(gòu)

我們將分流服務(wù)作為一個(gè)整體，一共使用了 3 級(jí)存儲(chǔ)，分別是服務(wù)內(nèi)存、Redis 緩存、關(guān)系型數(shù)據(jù)庫(kù)。實(shí)驗(yàn)變動(dòng)落庫(kù)的同時(shí)，將變動(dòng)消息寫入消息隊(duì)列，分流服務(wù)消費(fèi)消息隊(duì)列修改內(nèi)存和 Redis 緩存中的實(shí)驗(yàn)配置，保證多節(jié)點(diǎn)之間的一致性和實(shí)時(shí)性。同時(shí)分流服務(wù)開啟一個(gè)額外協(xié)程定期全量更新實(shí)驗(yàn)配置數(shù)據(jù)作為兜底策略，防止因?yàn)橄㈥?duì)列故障導(dǎo)致的配置不更新;將 Redis 視作 Mysql 的備組件，任意失效其中之一，這樣分流服務(wù)即使重啟依然可以恢復(fù)最新版本的分流配置，保障客戶側(cè)分流結(jié)果的穩(wěn)定。

總結(jié)

火山引擎 A/B 測(cè)試(DataTester)脫胎于字節(jié)跳動(dòng)內(nèi)部工具,集成了字節(jié)內(nèi)部豐富的業(yè)務(wù)場(chǎng)景中的 A/B 測(cè)實(shí)驗(yàn)經(jīng)驗(yàn);同時(shí)它又立足于 B 端市場(chǎng),不斷通過 ToB 市場(chǎng)的實(shí)踐經(jīng)驗(yàn)沉淀打磨產(chǎn)品來(lái)更好的為內(nèi)外部客戶創(chuàng)造價(jià)值。

本文是火山引擎 A/B 測(cè)試(DataTester)團(tuán)隊(duì)在當(dāng)前面向 ToB 客戶的私有化實(shí)踐中的實(shí)踐分享，文中所遇到的私有化問題的破解過程也是這一產(chǎn)品不斷打磨成熟，從 0-1 階段走向 1-N 階段的過程。