引言
A/B测定义
A/B 测试以数据驱动为导向，能够实现灵活的流量切分，使得同一产品的不一样版本能同时在线，经过记录和分析用户对不一样版本产生的行为数据，获得效果对比，最大程度地保证结果的科学性和准确性，从而帮助人们进行科学的产品决策。算法
基于用户行为数据计算不一样版本的指标数据，是评估实验结果的惟一依据。sql
指标产品设计
图1. 新增指标shell
指标系统产品设计上采用了指标注册的方式，用户能够在本身的业务域和业务线下进行指标注册，注册须要指定指标计算公式（SQL），指标SQL必须遵照SQL模板，并支持自定义维度（自动注册维度/关联维表）。分析层面上，用户能够查看固定与预计算好的指标，也能够进行指标的多维分析。缓存
产品需求上，须要计算当日以及累计（实验开始时间~前一天）的样本、指标。架构
指标技术架构
图2. 指标设计架构图性能
多个实验采起并行计算，单个实验多个指标采起串行计算。测试
单个实验须要计算的数据以下：
优化
图3. 实验计算数据spa
指标计算的特色在于：对于每个实验，须要先计算样本，指标是架设在样本之上的指标，基础指标P值的计算须要依赖样本和指标，复合指标P值的计算须要基于分母重建样本。对于每一个实验来说，样本多是变化的，用户能够自定义样本，也能够选择分流服务日志做为默认兜底样本。设计
指标计算优化
阶段一：引擎和架构优化
计算引擎Spark：基于性能和成熟度的考量，选择Spark做为核心计算引擎，它相对Hive的优点就不赘述了。
OLAP引擎Clickhouse：指标分析须要基于明细数据进行多维复杂分析，目前的成熟引擎均可以知足，选择CK的重要缘由是：1> CK的性能和成熟度已经获得验证 2> 内部有CK集群，方便咱们直接使用。
计算方式：多个实验并行计算，单个实验内部的多指标串行计算。实验之间关联性较小，并行计算时合适的。单个实验内部，多个指标关联性较强，如复合指标，须要先计算基础指标，才能够复合计算，串行计算是合理的。在实现上的话，是经过调度shell脚本动态循环实验完成的。
实现方式：单个实验的计算是经过一个通用的Spark程序来完成的，离线调度任务起来的时候，读取实验指标的配置，先算明细，再算指标值。
AB平台上线初期，实验和指标数量较少（10+实验，50+指标），基本能够知足需求，总体计算时间大约是2~3个小时。
平台在运行半年以后，随着实验数量的增多，整个时间延长到了5~6个小时，并行度已经增长到10，单个任务的资源增长到100core, 800G内存，怎么优化？
阶段二：计算模型优化
咱们抓取一个典型的广告实验，打印每一个指标各个阶段的消耗时长，通过对计算的每一个过程执行时间分析，发现花在样本和指标累计值计算上的时间特别长。AB指标的累计值计算规则是从>=实验开始运行日期<=计算日期，指标定义sql会要求必须输入时间字段，程序会自动进行判断和日期的处理，若是一个实验运行了3个月，那须要扫描3个月的数据进行计算，数据量较大会形成计算效率差、计算时间很长。
咱们统计了3个月内已关闭实验的运行时长:
图4. 实验运行时长统计
从上图看到，大于1个月的实验占总实验数接近60%，比例是比较高的。
如何优化累计计算呢？
以前的计算模型：
图5. 原计算模型
这个计算模型的优势是相对独立，可随意计算任意一个日期的累计值；缺点是1>须要扫描的数据量比较大2>计算不够准确：将样本发生时间在指标时间以后的数据也计算进去了，结果会出现轻微偏差，举例来说：5月1号用户发生了转化，可是5月2号用户才参加实验，此算法会把这样的数据算作实验带来的转化。
优化后的模型：
图6. 新计算模型
此计算模型的优势：1>累计计算的性能有了大幅度的提高，再也不随着时间的增加，数据计算愈来愈慢的状况出现；2>计算结果更加准确。缺点是：第N天的累计计算依赖于第N-1天的累计明细，复杂程度提高了。
通过此优化以后，每一个指标的计算时间相对可控，再也不出现时间特别长的实验指标了。总体的计算时长保持在3个小时左右。
阶段三：率指标批量优化
通过阶段二的优化以后，总体知足50+实验，200+指标的计算，单个实验（5个指标）的总体计算时长可稳定在40分钟左右。
好景不长，指标计算又面临新挑战：年初网校资源管控平台总体对接AB以后，实验数直线上升，实验数达到天天150+,指标数600+，总体的计算时间长达10个小时，如何优化？
经过对实验和指标数据进行分析，发现经过从资源管控平台过来的实验，默认都勾选了固定的几个指标，至关于同一个指标在N个实验里出现，那是否能够对单个指标批量计算实验数据呢？
AB指标计算在设计时之因此会设计成单个实验串行，多个实验并行的方式，缘由是每一个实验容许用户自定义样本，未自定义才会使用平台分流日志兜底。AB平台适配了多种类型的指标，批量计算适合的指标是：指定定义SQL中自己包含了实验名和组名，而且属于基础率指标，即无需和样本进行关联。
图7. 率指标优化方案
此方案上线以后，平台大部分的实验均可以基于此方案进行批量计算，加快执行效率。总体指标计算的时间缩短到5个小时，提高了一倍的性能。
阶段四：均值指标批量优化
阶段三是针对率指标的批量优化，可是系统中存在很多的均值指标，被多个实验勾选，部分指标计算比较复杂，即便计算单天的数据，计算时间也须要半个小时，如：
图8. 指标SQL
这个是指标SQL，实际计算当中还须要再关联样本，计算基于样本的均值明细和均值，整个计算会变得比较复杂，单次计算时间大约在半个小时。还能怎么优化呢？
方案一：
咱们采用spark的checkpoint机制，将首次计算的明细数据经过checkpoint缓存起来，这样计算均值、p值、置信区间就能够直接用缓存的明细数据进行计算。
实施以后，发现总体的计算时长有下降，可是因为checkpoint会涉及到把数据写入hdfs，无形中将spark退回到了Hive的方式，总体有提高，可是不是很明显。
方案二：
可否像阶段三那边，批量计算缓存到CK呢？ 是能够的，模型会复杂一些。
图9. 均值指标优化方案
此方案的核心在于：指标sql会先计算获得临时明细数据，在计算指标明细时，直接从CK中获取，依赖于Spark的RDD跨数据源的能力，实现计算时的动态选取，最终明细数据再回写CK。
总结
AB测指标计算优化以后，150+实验、600+指标，总体的计算时长保持在2~3个小时，最重要的是随着实验和指标的增长，总体的计算时长增长是可控的，不会几何级数的增加，达到了咱们优化的效果。
想要了解更多关于教育行业的技术干货可扫码下方二维码加入好将来官方交流群