Google 重叠实验框架：更多，更好，更快地实验

Google是一个数据驱动型公司，这意味着所有对用户的改动的发布，都要决策者以相应的经验数据作为依据。这些数据大部分是由在线流量上的实验产生的。在web的语境下，一个实验是由一股流量（比如，用户的请求）和在这股流量上进行的相对对比实验的修改组成的。修改包括用户可见的修改（比如，修改顶部广告的背景色），以及不可见的修改，比如测试一个新的广告点击率(CTR)预测算法，都可以通过实验的方式进行的。

要支持数据驱动方法论的挑战在于要跟上创新的速度。我们想支持进行尽可能多的实验，如果实验框架要限制同时进行的实验的数量，那是绝不可被接受的。我们进行实验是为了测试一些新的特性和挖掘一些已有特性的提升空间。对于已有特性，实验可以学习到用户的反应并可以对特性进行优化。试想一下，如果在搜索结果页上的内容都是通过参数控制的，包括展示方式和算法。通过对参数设置不同的参数值进行实验，我们可以用衡量指标(用户体验，收入或其它指标)来决定是否要进行哪些修改以得到最好的结果。

对UI的修改通常会使用实验来评价用户反应，但需要注意的是算法的修改同样也需要实验。例如：假设一些团队想测试一个新的机器学习算法来预测广告CTR，或是测试对现有算法的调整(比如，修改学习速度或是收敛速度)。虽然线下评估可以进行一些分析后，可以缩小参数的最佳取值区间(不是最佳取值)，但最终这些参数还是需要在线上流量进行评估，分析这些参数在真实的流量上的效果(因为修改可能会影响用户的行为，并改变流量本身的模式，这是不可能在线下环境评估的)。所以，评价这些机器学习算法是需要通过线上实验的方式进行的。

设计我们实验框架的目标是：更多，更好，更快。

更多：我们需要能同时进行多个实验的可扩展性。但是我们也需要灵活性：不同的实验需要不同的配置和不同的流量来衡量实验的统计意义上的效果显著性。有些实验只需要修改流量的一个子集，比如只是日语的流量，并需要取一个合理的流量规模。其它的实验有可能需要修改所有的流量，并对指标造成很大影响，这种才可以在小流量上进行测试。

更好：不合理的实验是不应该让它在线上流量进行的。合理的但是很差的实验（比如，有bug的实验或是无意中产生的很差的实验结果）都应该能很快的被捕获并且停止它的进行。标准化的标价指标可以让所有的实验进行公平的比较：比如在计算CTR指标的时间，两个实验应该用相同的过滤器去掉爬虫流量。

更快：能够很容易并且很快地建立一个实验。容易到非工程师不需要写代码就可以创建一个实验。评价指标应该很快的被统计出来，以便分析。简单的迭代可以很快速地进行。理想状态是，实验系统不仅支持实验，并且可以控制放量，比如，以一种系统的和容易理解的方式对实验进行放量。

为了达到这些设计的目标，我们不仅需要实验架构来进行更多的实验，并且需要一些工具和指导过程来支持更多和更快的实验。

对于实验架构，有两个很明显的选择，或是要支持单层实验或是要支持多因素实验。单层实验意味着每个请求最多只会通过一个实验，单层实验是很容易使用的，并且也具有灵活性，但是扩展性不足。多因素实验在统计学上进行了大量的讨论，多因素实验中每个参数（因素）都可以被独立地实验，在实验中每个参数（因素）都可以独立地被实验，每个实验中只测试一个参数，这个参数会覆盖所有其它实验中的其它参数。每个查询可以同时在N个实验中，其中N是参数的个数。虽然这种方法进行了多年的研究和实践，但对于Google的系统却不适用，因为Google有几千个参数，并且不能被独立的分析。例如：要对两个参数进行分析，一个参数是web页面的背景色，另一个是文字的颜色，虽然“蓝色”对两个参数都是合法值，但是如果两个参数都取“蓝色”，那么页面是不可读的。

本文提出的解决方案是将参数分成子集，每个参数子集包含相互不能独立修改的参数。一个参数子集会与一个包含实验(s)的层相关联，不同层的实验的流量是正交的。每个query可以在N个实验中，其中N是层的数量 。

实验环境

在讨论Google的实验之前，我们先描述一下我们实验架构所处的环境，这样能更清楚的理解我们实验架构所要设计的目标和所受到的限制。

宏观上看，用户通过它们浏览器发送请求与Google交互。请求进入Google的服务系统后，会先后被多个服务处理（运行在服务器上的程序），然后产生面向用户的结果页。比如，可能有一个服务决定与查询最相关的原生搜索结果，另一个服务决定与查询最相关的广告(s)，还有一个服务将原生搜索结果和广告结果组织到结果页，返回给用户。见图1。一方面，这种模块化可以让我们降低延时（不相互依赖的过程可以并行），显然，原生的搜索过程与广告搜索过程是相互独立的，并能更快速的试验（每个服务都可以独立地进行，并且模块化的测试可以进行更快速的发布）。另一方面，如果要求每个请求最多只进入一个实验，那么模块化就需要更精心地设计。可能存在的问题有流量饥饿（上游模块的实验可能优先处理了所有请求，导致下游模块的实验没有请求），和偏置(bias)（比如，比如，上游模块的实验处理了所有英语的请求，导致下游模块的实验就只有非英语请求）。

图1：一个请求经过多个模块的例子，信息（和时间）都是从左流向右

每个服务都有二进制推送和数据推送。二进制推送是指发布新的程序（bug修复，性能提升，新特性，等等），它一定时期进行一次（比如，每周）。数据推送更频繁（比如，按需或是每几小时推送一次），并且这还涉及了推送更新的数据到相应的程序。数据推送中还包含了默认参数配置，参数是用来配置程序如何运行，比如，控制结果如何展示的服务也许有一个参数是决定顶部广告块的背景色。再比如，预测CTR的服务可能有参数是控制学习速度和收敛速度的。程序可能有几百个参数。新的特性可能会添加一个或多个参数：最简单的场景是，一个参数可以控制打开或关闭新特性，在更复杂的场景中，也许有多个参数决定新特性如果展示，有数值阈值决定新的特性是否被展示，等等。将程序和数据分离，意味着如果我们可以找到合适的分离方式，我们就可以同时得到快速影响线上服务的通路，和慢速影响线上服务的通路（程序是慢的通路，改变参数值是快速的通路）。

一个web搜索中的实验是指将一部分请求流量转向一个特定的处理路径，这个处理路径会改变向用户展示的内容。一个对照实验将一部分请求流量转向一个处理路径，但它并不改变向用户展示的内容。我们用数据推送来决定实验的配置。在数据推送中，有一个文件决定程序的默认参数配置。另一个文件决定实验所需要改变的参数的值，实验只用指定实验所要改变的参数，对于其它参数，都采用默认值。比如，在一个简单实验中，它只改变顶部广告的背景色这一个参数，它可以改变黄色（默认值）到粉色（实验值）。

实验还需要决定实验所用的流量如何分配。最简单的分配方式是用随机流量，即对每个请求都进行随机分配。但这样做的问题是如果实验是用户可见的改变（比如，改变背景色），那么一个用户可能就得到不同的用户体验（背景色不断地在黄色和粉色间转换），这会造成用户体验不一致。在web实验中常用的方法是用cookie作为流量分配的依据，cookie被网站用来定位唯一用户。实践中，cookie是机器/浏览器相关的，并可能被清除。然而，虽然一个cookie不能唯一定位一个用户，但对于连续的查询，它可以提供给用户一致性的用户体验。对于实验流量分配，我们并不直接对每单个cookie进行分配，而是用cookie取模进行分配：用一个ID表示一个cookie，对这个ID模1000，将模相等的流量聚合为实验流量，比如模等于42的流量（译注：42这个例子绝对不是巧合，Hacker必读的《银河系漫游指南》中42是万事万物的答案）。假设cookie的分配是随机的，那么随意cookie的模数的请求数据也应该是大致相等的。在实验配置中使用cookie的模，也可以很容易地检查流量之间是否有冲突：实验1可能会用cookie模1和模2，实验2可能使用cookie模3和模4，这两个实验就会有相近的大小，理论上，是可以进行比较的流量。

在数据文件中配置实验，可以让实验更快更方便地创建：数据文件是可读的，并容易手工编辑，不需要进行代码变更，并可以由非工程师进行创建，而且配置数据的推动会比二进制程序的发布更加频繁，它使创建仅包含已有参数的实验更加方便快捷。

在开发我们的实验架构之前，我们使用一个简单的单层实验框架，在这个架构中，每个请求最多进行一种实验。先分配Cookie取模的流量的实验，再分配随机流量的实验。上游服务会优先分配流量，所以如果上游（即cookie取模的实验）进行了很多实验，那么下游可能会得不到足够的流量，即流量饥饿问题。除了这些问题之外（包括前面提到的流量饥饿和偏置问题），单层实验可以满足我们设计目标中的易用和相对的灵活性。但是在Google数据驱动的文件中，单层的方法没有足够的可扩展性：我们无法快速地进行足够多的实验。

实验基础设施与框架