作为一款面向 ToB 商场的产品——火山引擎A/B测验(DataTester)为了满足客户对数据安全、合规问题等需求,探索私有化布置是产品无法绕开的一条路。

在面向 ToB 客户私有化的实际落地中,火山引擎A/B测验(DataTester)也遇到了字节内部服务和企业 SaaS 服务都不简单遇到的问题。在解决这些问题的落地实践中,火山引擎 A/B 测验团队沉积了一些流程办理、功能优化等方面的经历。

本文首要共享火山引擎A/B测验当时的私有化架构,遇到的首要问题以及从事务视点出发的解决思路。

火山引擎 A/B 测验私有化架构

火山引擎 A/B 测试产品——DataTester 私有化架构分享

架构图整套体系选用 Ansible+Bash 的方式构建,为了习气私有化小集群布置,既答应各实例对等布置,复用资源,完结最小三节点交给的方针,,又可以做在线、离线资源隔离提高集群安稳性。集群内可以划分为三部分:

  1. 事务服务: 首要是直接向用户供给界面或许功能服务的, 例如试验办理、试验陈述、OpenAPI、数据接入等。
  2. 根底服务: 不直接面向用户,为上层服务的运转供给支撑,例如支撑试验陈述的核算引擎、为目标创建供给元信息的元信息服务;根底服务一起还会充任一层对根底设施的适配,用来屏蔽根底设施在 SaaS 和私有化上的差异, 例如 SaaS 选用的实时+离线的 Lambda 架构, 私有化为了削减资源开支,习气中小集群布置只保存实时部分, 核算引擎服务向上层屏蔽了这一差异。
  3. 根底设施: 内部团队供给一致私有化根底设施底座 minibase,选用宿主机和 k8s 结合的布置方式,由 minibase 适配底层操作体系和硬件, 上层事务直接对接 minibase。

私有化带来的应战

应战 1:版别办理

传统 SaaS 服务只需求布置维护一套产品供悉数客户运用,因而产品只需求针对单个或几个服务更新,快速上线一个版别特性,而不需求考虑从零开始搭建一套产品。SaaS 服务的版别发布周期往往以周为单位,坚持每周 1-2 个版别更新频率。可是,在私有化交给中,咱们需求确定一个基线版别而且绑定每个服务的小版别号以确保相同版别下每套环境中的交给物等价,以减轻后续晋级运维本钱。通常,基线版别的发布周期往往以双月为单位。

火山引擎 A/B 测试产品——DataTester 私有化架构分享

版别发布周期

由于私有化和 SaaS 服务在架构、完结、根底底座上均存在不同,上述的发布节奏会带来一个显着的问题:

团队要投入很多的开发和测验人力会集在发版周期内做前史 Feature 的私有化适配、私有化特性的开发、版别发布的集成测验,抢占其他需求的人力排期。

为了将周期内会集完结的作业分散到 Feature 开发阶段,从头规范了分支运用逻辑、完善私有化流水线和上线流程,让研制和测验的介入时刻前移。

解法:

1、分支逻辑

火山引擎 A/B 测试产品——DataTester 私有化架构分享

分支办理

SaaS 和私有化均基于 master 分支发布,非私有化版别周期内不特别区别 SaaS 和私有化。

私有化发布周期内单独创建对应版别的私有化分支,发布完结后向 master 分支兼并。这样确保了 master 分支在任何状况下都应当能一起在 SaaS 环境和私有化环境中正常作业。

2、发布流水线

火山引擎 A/B 测试产品——DataTester 私有化架构分享

功能上线流程

火山引擎 A/B 测试产品——DataTester 私有化架构分享

发布流水线

内部搭建一套私有化预发布环境,建设了一套流水线,对 master 分支的 mr 会触发流水线一起在 SaaS 预发布环境和私有化预发布环境更新最新 master 分支代码,并履行自动化回归和人工回归测验。这样做的优点在于:

  • 推动了具体 Feature 的研制从技术方案规划层面考虑不同环境的 Diff 问题,削减了后期返工的本钱
  • 测验同学的作业化整为零,防止短时刻内的密布测验
  • 削减研制和测验同学的上下文切换本钱,SaaS 和私有化都在 Feature 开发周期内完结

应战 2:功能优化

火山引擎 A/B 测验工具的陈述核算是基于 ClickHouse 完结的实时剖析。SaaS 选用多租户共用多个大集群的架构,资源弹性大,可以合理地复用不同租户之间的核算资源。

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

解法:

1、 试验陈述体系

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

火山引擎 A/B 测试产品——DataTester 私有化架构分享

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

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

目标怎么界说呢?

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

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

火山引擎 A/B 测试产品——DataTester 私有化架构分享

  • 四则运算符

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

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

由于 A/B 特有的置信水平核算需求,核算成果中需求体现方差等其他特别核算值,所有聚合类核算如:求和、PV 数均需求聚合到人粒度核算。

2、 模型优化

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

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

火山引擎 A/B 测试产品——DataTester 私有化架构分享

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

火山引擎 A/B 测试产品——DataTester 私有化架构分享

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

  • 曝光事情和普通事情存储在一张事情表中量级大
  • 曝光事情需求搜索第一条记录,扫描的分区数会跟着试验时刻的添加而添加
  • 曝光事情或许重复上报,核算口径中仅仅第一条曝光为有用事情

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

火山引擎 A/B 测试产品——DataTester 私有化架构分享

这么做带来的优点是:

  • 用户表不存在时刻的概念,数据增长=新用户增速,规划可控

  • 用户表本身会作为维度表在原模型中引进,这类状况下削减一次 join 运算 模型优化后经测验 14 天以上试验目标多天累计陈述查询时长削减 50%以上,且随试验时长添加提高。

3、 预聚合

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

一是,咱们期望简化资源核算的模型。

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

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

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

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

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

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

答案是可以的:扫描当天的事情数据,依据试验、目标装备核算一张人粒度的目标表 user_agg。

经过 user_agg 表可以核算出目标核算需求的 UV 数、目标的核算值、目标的方差。假如对 user_agg 表的才能做进一步拓展,简直可以替代原始表完结试验陈述中 80%以上的目标核算,一起也很好地支撑了天级时刻挑选切换、用户特点标签过滤等。

火山引擎 A/B 测试产品——DataTester 私有化架构分享

修改后的目标核算模型

经过经历数据,一个用户均匀每天发生的事情量在 100-500 条不等,聚合模型经过少量几次对当天数据的全表扫描得到一张 1/100-1/500 大小的中间表,后续的目标核算、用户维度过滤均可以运用聚合表替代原始表参加运算。当然考虑到聚合本身的资源开支,收益会跟着运转试验数添加而提高,而试验数量过少时或许会造成资源糟蹋,是否启用需求在两者之间需求平衡点。

应战 3:安稳性

私有化服务的运维通道复杂、运维压力大,因而对服务的可用性要求愈加严格。A/B 测验安稳性要求最高的部分是分流服务,直接决议了线上用户的版别射中状况。

分流服务本身面向毛病规划, 选用降级的战略防止调用链路上的失败影响悉数试验成果,牺牲一部分实时性运用多级缓存保障单一根底设施离线的极点状况下分流成果仍然安稳。

火山引擎 A/B 测试产品——DataTester 私有化架构分享

分流服务整体架构

咱们将分流服务作为一个整体,总共运用了 3 级存储,分别是服务内存、Redis 缓存、联系型数据库。试验变化落库的一起,将变化音讯写入音讯队列,分流服务消费音讯队列修改内存和 Redis 缓存中的试验装备,确保多节点之间的一致性和实时性。一起分流服务开启一个额外协程定期全量更新试验装备数据作为兜底战略,防止由于音讯队列毛病导致的装备不更新;将 Redis 视作 Mysql 的备组件,恣意失效其中之一,这样分流服务即便重启仍然可以恢复最新版别的分流装备,保障客户侧分流成果的安稳。

总结

火山引擎 A/B 测验(DataTester)脱胎于字节跳动内部工具,集成了字节内部丰富的事务场景中的 A/B 测验验经历;一起它又立足于 B 端商场,不断经过 ToB 商场的实践经历沉积打磨产品来更好为内外部客户发明价值。

本文是火山引擎 A/B 测验(DataTester)团队在当时面向 ToB 客户的私有化实践中的实践共享,文中所遇到的私有化问题的破解过程也是这一产品不断打磨成熟,从 0-1 阶段走向 1-N 阶段的过程。

点击跳转 火山引擎A/B测验DataTester 了解更多