共计 3844 个字符，预计需要花费 10 分钟才能阅读完成。
作为一款面向 ToB 市场的产品——火山引擎 A / B 测试（DataTester）为了满足客户对数据安全、合规问题等需要，摸索私有化部署是产品无奈绕开的一条路。
在面向 ToB 客户私有化的理论落地中，火山引擎 A / B 测试（DataTester）也遇到了字节外部服务和企业 SaaS 服务都不容易遇到的问题。在解决这些问题的落地实际中，火山引擎 A / B 测试团队积淀了一些流程治理、性能优化等方面的教训。
本文次要分享火山引擎 A / B 测试以后的私有化架构，遇到的次要问题以及从业务角度登程的解决思路。
火山引擎 A / B 测试私有化架构
架构图整套零碎采纳 Ansible+Bash 的形式构建，为了适应私有化小集群部署，既容许各实例对等部署，复用资源，实现最小三节点交付的指标,，又能够做在线、离线资源隔离进步集群稳定性。集群内能够划分为三局部：
1. 业务服务: 次要是间接向用户提供界面或者性能服务的, 例如试验治理、实验报告、OpenAPI、数据接入等。
2. 根底服务: 不间接面向用户, 为下层服务的运行提供撑持, 例如反对实验报告的计算引擎、为指标创立提供元信息的元信息服务; 根底服务同时还会充当一层对基础设施的适配, 用来屏蔽基础设施在 SaaS 和私有化上的差别, 例如 SaaS 采纳的实时 + 离线的 Lambda 架构, 私有化为了缩小资源开销, 适应中小集群部署只保留实时局部, 计算引擎服务向下层屏蔽了这一差别。
3. 基础设施: 外部团队提供对立私有化基础设施底座 minibase, 采纳宿主机和 k8s 联合的部署形式, 由 minibase 适配底层操作系统和硬件, 下层业务间接对接 minibase。
私有化带来的挑战
挑战 1：版本治理
h 传统 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 大小的两头表，后续的指标计算、用户维度过滤均能够应用聚合表代替原始表参加运算。当然思考到聚合自身的资源开销，收益会随着运行试验数减少而进步，而试验数量过少时可能会造成资源节约，是否启用须要在两者之间需要平衡点。
挑战 3：稳定性
私有化服务的运维通道简单、运维压力大，因而对服务的可用性要求更加严格。A/B 测试稳定性要求最高的局部是分流服务，间接决定了线上用户的版本命中状况。
分流服务自身面向故障设计，采纳降级的策略防止调用链路上的失败影响全副试验后果，就义一部分实时性应用多级缓存保障繁多基础设施离线的极其状况下分流后果仍然稳固。
分流服务总体架构咱们将分流服务作为一个整体，一共应用了 3 级存储，别离是服务内存、Redis 缓存、关系型数据库。试验变动落库的同时，将变动音讯写入音讯队列，分流服务生产音讯队列批改内存和 Redis 缓存中的试验配置，保障多节点之间的一致性和实时性。
同时分流服务开启一个额定协程定期全量更新试验配置数据作为兜底策略，避免因为音讯队列故障导致的配置不更新；将 Redis 视作 Mysql 的备组件，任意生效其中之一，这样分流服务即便重启仍然能够复原最新版本的分流配置，保障客户侧分流后果的稳固。
总结
火山引擎 A/B 测试（DataTester）脱胎于字节跳动外部工具, 集成了字节外部丰盛的业务场景中的 A/B 测试验教训；同时它又立足于 B 端市场, 一直通过 ToB 市场的实践经验积淀打磨产品来更好为内外部客户发明价值。
本文是火山引擎 A/B 测试（DataTester）团队在以后面向 ToB 客户的私有化实际中的实际分享，文中所遇到的私有化问题的破解过程也是这一产品一直打磨成熟，从 0-1 阶段走向 1-N 阶段的过程。
点击跳转 火山引擎 DataTester 官网 理解更多