作为一款面向 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：版别办理

传统 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 选用多租户共用多个大集群的架构，资源弹性大，可以合理地复用不同租户之间的核算资源。

私有化则大部分为小规模、独立集群，不同客户一起运转的试验个数从几个到几百个不等，陈述观测时刻和用户习惯、公司作息相关，有明显的峰谷现象。因而试验陈述产出推迟、实时剖析慢等现象在私有化上愈加简单露出。

解法：

试验陈述系统

首先，介绍下火山引擎 A/B 测验产品的试验陈述系统。以下图的试验陈述为例:

图片

从上往下看产出一个试验陈述必要的输入包含:

  • 剖析的日期区间及过滤条件
  • 选择适宜的目标来评价试验带来的收益
  • 试验版别和对照版别
  • 陈述类型, 例如:做多天累计剖析、单天的趋势剖析等

目标怎么定义呢?

组成目标的中心要素包含:

  1. 由用户行为发生的事情及特点
  2. 预置的算子

图片

  1. 四则运算符

即关于一个用户的某几个行为依照算子的规矩核算 value 并运用四则运算组合成一个目标。

由此，我们可以大约幻想出一个常规的 A/B 试验陈述查询是经过试验射中情况圈出试验组或对照组的人群，剖析这类集体中在试验周期内的目标值。

因为 A/B 特有的置信水平核算需求，统计成果中需求体现方差等其他特殊统计值，一切聚合类核算如：求和、PV 数均需求聚合到人粒度核算。

模型优化

怎么区分用户射中哪一组呢?

集成 SDK 调用 A/B 分流办法的一起会上报一条试验曝光事情记载用户的进组信息，后续目标核算认为发生在进组之后的事情受到了试验版别的影响。举个比如：

图片

进入试验版别 1 的事情 A 的 PV 数是 2，UV 数是 1，转化为查询模型是:

图片

上述模型虽然最契合直觉，可是存在较多的资源糟蹋:

  • 曝光事情和普通事情存储在一张事情表中量级大
  • 曝光事情需求查找第一条记载，扫描的分区数会跟着试验时刻的添加而添加
  • 曝光事情可能反复上报，核算口径中只是第一条曝光为有效事情

针对上述问题对核算模型做出一些优化，把曝光事情转化为特点记载在用户表中，新的模型变化为:

图片

这么做带来的优点是:

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

预聚合

私有化布置实施前会做前期的资源预估，现阶段的资源预估选择了“日活用户”和“日事情量”作为首要输入参数。这儿暂时没有参加一起运转的试验数量是因为：

一是，我们期望简化资源核算的模型。

二是，一起运转的试验数量在大多数情况下无法提前预知。

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

可是假设集群中一起运转 100 个试验，均匀每个试验关注 3 个目标加上试验的进组人数统计，在当时查询模型下每天至少扫描事情表 100*(3+1)次，假如再叠加运用自定义过滤模板等预核算条件，这个核算量会被成倍扩大,直到导致查询任务堆积数据产出推迟。

从头观察试验陈述中心元素以及目标构成能发现:

  1. 目标、陈述类型、试验版别是可枚举且预先知晓的
  2. 试验射中和人绑定,版别对比先划分出进入对照组和试验组的人,然后做目标比较
  3. 依据假设检验的置信水平核算需求按人粒度核算方差
  4. 现有的目标算子均可以先按人粒度核算（按….去重在外）

是否可以经过一次全量数据的扫描核算出人粒度的一切目标和试验版别？

答案是可以的：扫描当天的事情数据,依据试验、目标装备核算一张人粒度的目标表 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 阶段的过程。

火山引擎A/B测验，限时免费，立即申请！

A/B 测验，摆脱猜测，用科学的试验衡量决议方案收益，打造更好的产品，让事务的每一步都通往添加。火山引擎首度发布添加助推「火种方案」，火山引擎 A/B 测验作为「火种方案」产品之一，将为您免费供给 2 亿事情量和 5 万 MAU，以及高达 12 个月的运用权。点击：www.volcengine.com/activity/da… 了解详情。