微软 AB/Testing EXP 实验管理平台

Conference Paper · May 2018 The Anatomy of a Large-Scale Online
Experimentation Platform。

因为工作负责和 ABTest 相关的事情，所以对 ABTest 系统理论与工程落地情况一直在调研，根据上面这篇论文，我们一起来学习下微软 EXP 系统的工程实现。摘要及其相关工作啥的废话略过，先放一张架构图：

整个系统包含四部分：

1. experiment portal：

portal 属于一个实验管理后台系统，为实验者与实验系统之间提供交互接口，实验者可以方便的在系统中创建，配置，运行并分析实验。其中系统包含三个重要的组件：

1. experiment management

实验管理界面应具有以下功能：

• 选择实验地域群体（US CN 等）
• targeting or traffic filters（浏览器，操作系统，应用版本以及更复杂的实验条件，比如刚满一个月的新用户等）
• Overall Evaluation Criteria (OEC) 综合评价标准，实验者要选择好评估指标，可以内置一些常用的 CTR，PV，UV 等产品优化指标
• 配置实验组和对照组流量，以及实验的开始和结束时间
• 支持 re-randomization ：使用历史数据批量做 AA 实验，一般通过 AA 实验选择最合适的 hash 算法，目的是为了让样本尽可能均匀，然后才能做 AB 实验，为了提高销量，巧妙的使用历史数据做 AA，这个过程叫做 SeedFinder。
• 实验管理界面 对不同产品提供不同的实验配置模版
• isolation group 是一个变量集合，每个变量都会被打上所属的 isolation group，实验里的所有变量共享同样的 isolation group，如果两个变量所属的 isolation group 有交集，那么说明这两个变量会是相互影响的，对于这两个变量，在做实验的时候应该是互斥的
• 后端管理系统能够控制变量所对应的线上业务行为。对于 server 端实验，代码可以随时重新发布上线，对于 client 端实验，比如 app 发版都是周期性的，所以需要能够在管理系统配置 feature 的开关
• 后端管理系统还可以让用户自定义 metric，微软开发了 Metric Definition Language (MDL)，去构造 metric，如 ctr 等，底层会重新翻译成 SQL 等其它语言。对于各种 metric：产品效果指标，实验的置信度，实验是否分流均匀

2.experiment execution service

这个是 ABTest 的核心服务，为各个接入 AB 的服务分配实验变量。每个变量 V 是一个参数集合，实验可以表示为 E{V1, V2}， 如 V1 实验组，V2 对照组。isolation group 会切分成多个变量，如下图：

每个变量都会被关联上一个或多个 isolation group，比如存在两个实验 E1{V1, V2}， E2{V3, V4}，E1 关联隔离组 G1，G2。同时 E2 的变量也关联 G1，G2。 会发现两个实验变量所关联的隔离组是有交集的，那么这时候说明两个实验是会相互影响的，不能同时进行。

列举了三种实验组参数配置下发方式：

总之都是从 experiment execution service 拿到实验组参数配置并缓存在本地。

1. 可以通过应用程序在启动时直接通过服务接口调用，去请求实验组参数配置，这样做到用户在 session 内有一致的用户体验。服务端和客户端均可采用这种方式
2. Edge Node 可以类比 nginx，可以负载均衡服务， 它和 experiment execution service 交互，对请求进行加强（填充改次请求 所对应的实验参数配置）。这种方式不适合客户端实验， 因为客户端用户操作很多都是本地行为，没有发生网络交互
3. 第三种方式通过为 AB 实验打包一个专门的 lib， 客户端实验不需要将实验参数在各个组件传来传去，而是每次都从这个 lib 去拿就可以了。lib 负责和 experiment execution service 周期性交互

还有个配置管理服务 去控制 experiment execution service 进行一个实验下不同的变量分配的开关， 该开关配置应该放到 lib 里