还原火山引擎 A/B 测试产品——DataTester 私有化部署实践经验

最新推荐文章于 2023-05-12 11:45:52 发布

字节数据平台

最新推荐文章于 2023-05-12 11:45:52 发布

阅读量563

点赞数

文章标签：服务器火山引擎 ab测试大数据

本文链接：https://blog.csdn.net/m0_60025795/article/details/128467738

版权

作为一款面向ToB市场的产品——火山引擎A/B测试（DataTester）为了满足客户对数据安全、合规问题等需求，探索私有化部署是产品无法绕开的一条路。

在面向ToB客户私有化的实际落地中，火山引擎A/B测试（DataTester）也遇到了字节内部服务和企业SaaS服务都不容易遇到的问题。在解决这些问题的落地实践中，火山引擎A/B测试团队沉淀了一些流程管理、性能优化等方面的经验。

本文主要分享火山引擎A/B测试当前的私有化架构，遇到的主要问题以及从业务角度出发的解决思路。

火山引擎A/B测试私有化架构

架构图整套系统采用 Ansible+Bash 的方式构建，为了适应私有化小集群部署，既允许各实例对等部署，复用资源，实现最小三节点交付的目标,，又可以做在线、离线资源隔离提高集群稳定性。集群内可以划分为三部分：

业务服务: 主要是直接向用户提供界面或者功能服务的, 例如实验管理、实验报告、OpenAPI、数据接入等。
基础服务: 不直接面向用户,为上层服务的运行提供支撑,例如支持实验报告的计算引擎、为指标创建提供元信息的元信息服务;基础服务同时还会充当一层对基础设施的适配,用来屏蔽基础设施在 SaaS 和私有化上的差异, 例如 SaaS 采用的实时+离线的 Lambda 架构, 私有化为了减少资源开销,适应中小集群部署只保留实时部分, 计算引擎服务向上层屏蔽了这一差异。
基础设施: 内部团队提供统一私有化基础设施底座 minibase,采用宿主机和 k8s 结合的部署方式,由 minibase 适配底层操作系统和硬件, 上层业务直接对接 minibase。

私有化带来的挑战

挑战 1：版本管理

传统 SaaS 服务只需要部署维护一套产品供全部客户使用，因此产品只需要针对单个或几个服务更新，快速上线一个版本特性，而不需要考虑从零开始搭建一套产品。SaaS 服务的版本发布周期往往以周为单位，保持每周 1-2 个版本更新频率。但是，在私有化交付中，我们需要确定一个基线版本并且绑定每个服务的小版本号以确保相同版本下每套环境中的交付物等价，以减轻后续升级运维成本。通常，基线版本的发布周期往往以双月为单位。

版本发布周期

由于私有化和 SaaS 服务在架构、实现、基础底座上均存在不同，上述的发布节奏会带来一个明显的问题：

团队要投入大量的开发和测试人力集中在发版周期内做历史 Feature 的私有化适配、私有化特性的开发、版本发布的集成测试，挤占其他需求的人力排期。

为了将周期内集中完成的工作分散到 Feature 开发阶段，重新规范了分支使用逻辑、完善私有化流水线和上线流程，让研发和测试的介入时间前移。

解法：

1、分支逻辑

分支管理

SaaS 和私有化均基于 master 分支发布，非私有化版本周期内不特别区分 SaaS 和私有化。

私有化发布周期内单独创建对应版本的私有化分支，发布完成后向 master 分支合并。这样保证了 master 分支在任何情况下都应当能同时在 SaaS 环境和私有化环境中正常工作。

2、发布流水线

功能上线流程

发布流水线

内部搭建一套私有化预发布环境，建设了一套流水线，对 master 分支的 mr 会触发流水线同时在 SaaS 预发布环境和私有化预发布环境更新最新 master 分支代码，并执行自动化回归和人工回归测试。这样做的好处在于：

推动了具体 Feature 的研发从技术方案设计层面考虑不同环境的 Diff 问题，减少了后期返工的成本
测试同学的工作化整为零,避免短时间内的密集测试
减少研发和测试同学的上下文切换成本，SaaS 和私有化都在 Feature 开发周期内完成

挑战2：性能优化

火山引擎 A/B 测试工具的报告计算是基于 ClickHouse 实现的实时分析。SaaS 采用多租户共用多个大集群的架构，资源弹性大，可以合理地复用不同租户之间的计算资源。

私有化则大部分为小规模、独立集群，不同客户同时运行的实验个数从几个到几百个不等，报告观测时间和用户习惯、公司作息相关，有明显的峰谷现象。因此实验报告产出延迟、实时分析慢等现象在私有化上更加容易暴露。

解法：

1、实验报告体系

首先，介绍下火山引擎 A/B 测试产品的实验报告体系。以下图的实验报告为例:

从上往下看产出一个实验报告必要的输入包含:

分析的日期区间及过滤条件
选择合适的指标来评估实验带来的收益
实验版本和对照版本
报告类型, 例如:做多天累计分析、单天的趋势分析等

指标如何定义呢?

组成指标的核心要素包括:

由用户行为产生的事件及属性
预置的算子

四则运算符

即对于一个用户的某几个行为按照算子的规则计算 value 并使用四则运算组合成一个指标。

由此，我们可以大概想象出一个常规的 A/B 实验报告查询是通过实验命中情况圈出实验组或对照组的人群，分析这类群体中在实验周期内的指标值。

由于 A/B 特有的置信水平计算需求，统计结果中需要体现方差等其他特殊统计值，所有聚合类计算如：求和、PV 数均需要聚合到人粒度计算。

2、模型优化

如何区分用户命中哪一组呢?

集成 SDK 调用 A/B 分流方法的同时会上报一条实验曝光事件记录用户的进组信息，后续指标计算认为发生在进组之后的事件受到了实验版本的影响。举个例子：

进入实验版本 1 的事件 A 的 PV 数是 2，UV 数是 1，转化为查询模型是:

上述模型虽然最符合直觉，但是存在较多的资源浪费:

曝光事件和普通事件存储在一张事件表中量级大
曝光事件需要搜索第一条记录，扫描的分区数会随着实验时间的增加而增加
曝光事件可能反复上报，计算口径中仅仅第一条曝光为有效事件

针对上述问题对计算模型做出一些优化，把曝光事件转化为属性记录在用户表中，新的模型变化为:

这么做带来的优点是:

用户表不存在时间的概念,数据增长=新用户增速,规模可控
用户表本身会作为维度表在原模型中引入,这类情况下减少一次 join 运算模型优化后经测试 14 天以上实验指标多天累计报告查询时长减少 50%以上，且随实验时长增加提升。

3、预聚合

私有化部署实施前会做前期的资源预估，现阶段的资源预估选择了“日活用户”和“日事件量”作为主要输入参数。这里暂时没有加入同时运行的实验数量是因为：

一是，我们希望简化资源计算的模型。

二是，同时运行的实验数量在大多数情况下无法提前预知。

但是该公式会引入一个问题：相同资源的集群在承载不同数量级的实验时计算量相差较大。实验数量少的场景下，当下数据处理架构轻量化，计算逻辑后置到查询侧,，指标计算按需使用，大大减轻了数据流任务的压力。

但是假设集群中同时运行 100 个实验，平均每个实验关注 3 个指标加上实验的进组人数统计，在当前查询模型下每天至少扫描事件表 100*(3+1)次，如果再叠加使用自定义过滤模板等预计算条件，这个计算量会被成倍放大,直到导致查询任务堆积数据产出延迟。

重新观察实验报告核心元素以及指标构成能发现:

指标、报告类型、实验版本是可枚举且预先知晓的
实验命中和人绑定,版本对比先划分出进入对照组和实验组的人,然后做指标比较
基于假设检验的置信水平计算需要按人粒度计算方差
现有的指标算子均可以先按人粒度计算（按....去重除外）

是否能够通过一次全量数据的扫描计算出人粒度的所有指标和实验版本？

答案是可以的：扫描当天的事件数据,根据实验、指标配置计算一张人粒度的指标表 user_agg。

通过 user_agg 表可以计算出指标计算需要的 UV 数、指标的统计值、指标的方差。如果对 user_agg 表的能力做进一步拓展,几乎可以代替原始表完成实验报告中 80%以上的指标计算,同时也很好地支持了天级时间选择切换、用户属性标签过滤等。

修改后的指标计算模型

通过经验数据，一个用户平均每天产生的事件量在 100-500 条不等，聚合模型通过少数几次对当天数据的全表扫描得到一张 1/100-1/500 大小的中间表，后续的指标计算、用户维度过滤均可以使用聚合表代替原始表参与运算。当然考虑到聚合本身的资源开销，收益会随着运行实验数增加而提高，而实验数量过少时可能会造成资源浪费，是否启用需要在两者之间需求平衡点。