京东零售：数据编织在AB实验自动化中的应用与实践

摘要：导读本文将从数据应用的视角介绍数据编织的作用，不同于传统的指标看板 BI 分析场景，这里的数据应用更多聚焦于 AB 实验。文中将分享京东零售数据中台基于数据编织的 AB 实验自动化实践。

导读本文将从数据应用的视角介绍数据编织的作用，不同于传统的指标看板 BI 分析场景，这里的数据应用更多聚焦于 AB 实验。文中将分享京东零售数据中台基于数据编织的 AB 实验自动化实践。

主要内容包括：

1. 实验场景面临挑战

2. 数据编织管理理念

3. AB 自动化技术详解

4. 当前进展未来展望

5. Q&A

分享嘉宾｜王赫京东零售数据架构师

编辑整理｜马同学

内容校对｜李瑶

出品社区｜DataFun

实验场景面临挑战

AB 实验的核心是通过控制变量法观察不同分组间指标差异，以达到科学量化的效果。其本质仍旧在于观测指标要素，并结合科学处理进行实验分析。

AB 的重要性体现在，它能帮助企业实现二次增长和精细化决策，避免人为主观经验的影响。例如，策略更新或功能迭代后，人们往往认为自己的想法能达到预期效果，但实际情况可能并非如此。微软的报告显示，人们的想法中只有三分之一能实现真实转化，其余三分之二仅停留在想法阶段。因此，AB 实验对于企业发展显得尤为重要。

1. AB 实验面临的挑战

在 AB 实验中，会面临的核心数据挑战如下。

首先，相较于传统的 BI 分析场景，AB 实验背后的数据科学性挑战，这涉及到指标或数据背后的统计量，进而引发关于 p 值和置信区间的相关计算逻辑。其次，所有数据场景都离不开的生产与消费效率问题，在 AB 实验中同样重要。

具体来说，有三个层面的问题需要解决：

一致性要求：指标作为观测的基准或媒介，其定义不应因消费场景的变化而有所差异。无论是在实验场景下观测指标的科学性，还是在看板中监控订单 GMV 等指标的正常波动，其定义逻辑都应保持一致，如聚合方式（例如 sum(amount)）、数据类型（例如 double/long）以及所涉及的数据资产表。我们希望能够通过某种模式或方法统一指标在不同消费场景下的计算链路，避免人工线下进行口径对齐或 SQL 文档传递。科学性挑战：AB 实验需要针对实验组与对照组下某个指标的分布或变化波动情况进行科学验证，前提是分析的两个组别样本同质可比。由于不同实验观测的指标可能因业务场景、算法或优化策略的差异而产生不同程度的噪声，就需要关注对于一、二类错误率的控制，通过在数据层面叠加相关的降噪逻辑，以提升不同实验场景下对同一指标的灵敏度。时效性问题：不同实验有不同的降噪逻辑或提升灵敏度的方式，这就要求我们能够针对单个实验铺开数据链路。对于大型公司而言，当天的在线实验量可能达到上万级，大规模的任务调度和时效保障则变得十分关键。单纯通过人工开发和定制编排的方式，一定会面临交付模式不可持续以及需求承接效率低的窘境。针对上述挑战，我们希望探索自动化计算整个数据链路、自动实现指标口径对齐的解决方案。这涉及到指标平台与实验平台的结合，在后续章节中，我们将重点讨论实验自动化如何通过技术能力叠加解决这些问题和挑战的。

2. 只谈数据、不谈科学

AB 实验平台通常包括管理平台，供用户来订阅实验、配置分流信息、订阅指标、进行效果分析等，同时也包括分流引擎来确保实验组和对照组用户进组的纯随机性。而本文则聚焦于 AB 实验中数据引擎部分去聊一下数据编织在其中能起到的作用。

AB 实验平台数据层面的核心要素，具体包括以下四大部分：

分流维表：分析实验组与对照组用户在指标上的表现差异时，关键在于找到指标对应的事实表或资产表，并关联到分流维表信息，以确定用户所属的实验版本或实验 ID。相较于埋点上报实验信息的方式优势在于，针对一些情况下业务开发在后置链路才上报实验信息，却希望在前置链路就对用户行为变化进行灵活观测。例如，在京东 APP 中用户可能首先看到直播列表页，进入直播页面并添加购物车，后续产生购买行为。如果仅在加购行为时上报实验信息，则无法观测到用户进入列表页的数据效果，因此需要采用维表关联方式会更加灵活。需要注意的是，在维表关联时，应避免使用 Inner Join，以确保实验组和对照组用户在实验开始时是同质可比的，即人群分布随机均匀。单实验单算：不同的实验可能因个性化降噪逻辑的引入或不同业务诉求产生的单点回溯场景，需要架构或实现方式支持针对单个实验单独实现计算链路的生成。累计统计：实验场景下，累计行为和累计进组的概念尤为重要。累计行为对应指标在事实表内的多周期状态；而累计进组则关注用户在分流维表内的实验信息。例如，分流算法确保第一天实验组与对照组用户是可比的，但如果实验组转化效果更好，可能导致第二天进组的用户因复购差异产生偏移量，这时就需要依赖于对前两天数据的累计观测。指标继承：无论指标聚焦于科学的因果洞察还是静态观测监控，其来源应保持一致，包括指标的涉及的事实表、过滤逻辑和聚合方式等。实现指标源头的真正统一而非人为干预。

以上要素构成了 AB 实验中数据编织的核心部分，对于实现有效的实验分析至关重要。

数据编织管理理念

接下来，将简要介绍数据编织的理念和技术解决方案。

数据编织提供了一种新的思路，帮助我们面对数据应用场景。这需要数据虚拟化、逻辑化数据集成和按需加速等技术支持。

1. 逻辑数据平台构建方法

上图展示了逻辑数据平台大致层级结构。最底层是数据资产层，可以理解为企业内的传统数据仓库。我们倾向于将这一层定义为资产，因为需要在这一层确保所有数据口径的完备性以及唯一性。详细来说，可以进一步分为事实资产表和维度资产表。

在资产表之上，抽象出了数据虚拟层，用户可以通过语义化模型的录入来完成逻辑层的定义。这里提供了类似指标市场、维度中心、数据源管理等界面功能，使用户能够可视化地完成语义信息的录入和定义。基于这些定义，相当于会形成一个非常宽、非常高的表，但是这个表在任何媒介中并不是实际存在的，是一个虚拟层面的载体。

真正的物化过程，或称为物理集成过程，发生在数据物化层。不同企业可能有不同的预设规则，并且可能会根据消费场景的不同，选择不同的媒介。在数据物化层，实现按需的、全域主题的数据资产物化，同时也会伴随着相关的退化策略。通过自动的物化和退化过程，就能实现全域资产的主动治理。

最上层是统一的数据服务层，为多端消费场景提供数据产出能力。这样的层级结构确保了数据的一致性和多端复用的能力，同时提高了数据管理的效率和灵活性。

2. 关键技术、核心要素

在企业内部构建或实施数据编织相关的数据应用场景时，以下四个关键点是不可或缺的：

标准语义的建立：企业必须能够抽象出一套标准规范，以在自身业务场景中实现从业务语言到数据语言的转换，即在逻辑层面上定义一套标准。这构成了数据编织的前置条件。自动逻辑编排：基于定义好的标准语义，企业需要实现自动的逻辑编排，也就是 DAG 拓扑自动组装。在此过程中，任务的自动部署是必不可少的，同时也会涉及到相关的数据模型，即物理表的创建和维护。物化与退化策略：需要确定哪些表应该被物化、何时进行物化，以及何时进行退化处理。同时，还需了解中间表的 schema 信息、表的粒度，以及根据不同的消费场景选择合适的表。这要求系统具备自适应选择，或者消费的能力。SQL 优化与自调整：无论是在生产还是消费场景中，处理不同的表都需要 SQL 能力的组装或者其它类 SQL 方式的叠加，都依赖 SQL 优化组件和系统自动调优的能力，包括谓词下推、裁剪、多表合并等技术。

这四个要素或核心技术点是构建数据编织理念时必不可少的。

AB 自动化技术详解

接下来将详细介绍零售体系下 AB 实验链路是如何实现自动化的。

1. 技术详解-整体架构

上图中的上半部分是传统的在实验平台上交付需求的链路。首先，用户提出需求，例如观测 GMV 的涨跌或 DAU 的变化。开发人员需将业务需求人工映射到数据模型上，寻找相应的物理表，并梳理出用户希望观测的指标的口径信息，完成 SQL 逻辑的梳理。接着，将拿到的资产表与实验场景下的分流维表进行物理关联，这可能涉及多个主题之间的多种关联脚本开发，并伴随着人工任务部署和实验平台配置操作。最后会有测试的回归介入，以确保整个流程的准确性和有效性。

在整个流程中，需要大量的人工介入。信息从业务传递到数据开发，再到实验产品页面，最终到测试介入，存在很多信息传递偏差的风险，面临着口径频繁对齐的困境。

而引入数据链路自动化后，如上图中下半部分所示，系统将自动生成和构建所有内容。用户仅需完成业务语言到数据语言的转换，系统即可根据指标定义逻辑，自动完成事实表和分流维表的自动关联。由于实验科学场景的要素叠加，逻辑表会在后续的物化或 DAG 编排过程中会分裂出类似于当天、累计等加速策略。同时不同的实验分析场景可能需要不同的数据粒度或表 schema 信息，如明细轻聚合或预计算，物化的过程会将数据按需同步到相关媒介中。同时，AB 实验场景下对指标的计算还会涉及样本量、样本平方和、斜方差等诸如此类统计量的计算，这些要素的叠加也会在链路中的 SQL 层面体现出来。

这样，开发模式就从面向模型或任务的开发方式，转变为面向定义的逻辑表组装，提高了实验的效率和准确性。

2. 技术详解-指标语言

在指标层面，如果单独讨论各个指标，可能存在信息分散、数据获取渠道混乱等问题。因此，企业必须构建一套与自身业务相符的指标体系。

以零售行业为例，宏观层面，指标可分为衍生指标和复合指标。衍生指标，又可以进一步拆分为主指标和子指标，其中子指标是在主指标基础上增加一些修饰或函数，例如观测主站的 GMV、特定业务线的 GMV，或是剔除恶意数据后的 GMV 等。而复合指标择是基于衍生指标的四则运算。

3. 技术详解-指标体系

通过上图可以更形象地理解指标体系。基于成交购买用户数和浏览 UV 这两个衍生指标，可以定义出 UV 用户转化率这一复合指标。而基于衍生指标 UV，可以进一步进行树形拆分，拆分出浏览 UV 与商详 UV 到达率。一个指标本身可能包含同比和环比等信息项，我们将其抽象为函数。另外，如商详 UV 可能有一个修饰的叠加，称为新品商详 UV，当新品被物化下来，该指标就被定义为一个子指标。因此，可以看到这里提到了两个关键要素：第一个是函数，第二个是修饰。

那么在 AB 实验场景下，对于这个指标体系有哪些引入项呢？第一个是函数上的叠加，即在实验场景下需要对指标进行统计量的计算，例如计算一个指标的样本和、样本平方和，或者分子分母的乘积和等。这些信息在指标中被定义为统计函数。同时在实验场景下，与传统的指标定义或物化相比，有一个细微的区别，即实验场景下对指标的观测属性变化非常频繁，可能因为策略的迭代，修饰信息会发生剧烈变化。因此，这里会引入一种称为虚拟修饰的概念，这种修饰或指标信息不会在指标平台的元信息层面直接沉淀下来，它更多的作为实验数据系统运转时，单次观测或一段时间内观测而存在。

4. 技术详解-指标拆解

对于业务人员而言，至关重要的一步是将业务语言转化为前文所述的数据编织相关要素，只有当用户能够独立完成从业务语言到数据语言的转换时，才能真正推动后续自动生产逻辑的运行。

以一个实例来说明，假设用户表示希望在今天的实验中观测用户的平均贡献金额。当用户提出这一需求时，可以发现，所指的平均贡献金额在我们的指标体系中对应一个复合指标，即成交金额除以成交用户数。同时，用户还表达了希望观察同一时间内该指标是上升还是下降，在这里对应于同比函数，并带有一定的限定条件，例如要求在主站范围内，针对特定业务线，可能有其它一些特殊项，这些将被定义为修饰集合。修饰可能因为通用性不同或在不同团队中的生效情况不同，进一步被直接沉淀至指标定义要素中，称之为裁剪口径。大家可以简单地理解为依旧是业务限定或修饰逻辑。

当我们完成了上述要素的拆分，剩下的部分即为最基本的原子信息。不同企业对原子信息的分类或层级结构可能有所不同，以京东零售为例，主要涉及 4W1H（Who、What、When、Where、How），在此不展开详述。

5. 技术详解-逻辑建模 & 数据加速

逻辑建模和数据加速的过程如下图所示。

例如，在 A 实验中，用户订阅了相关指标。用户完成操作后，底层流程将驱动整个数据链路的自动构建。这一自动化过程包括，基于实验中所需观测的指标找到对应的资产逻辑表信息，并在此基础上进行扩展，关联实验所需的分流维表信息。由于不同实验可能有不同的分流字段，如 PIN 或 UUID，不同维度的维值信息可能有所差异，因此在逻辑层面上会执行变高操作，即同一维度可能来自两个维表内，维值范围存在差异。

总的来说，在逻辑表的一二步中，我们完成了逻辑变宽和逻辑变高的过程。这些操作尚未实际发生，即尚未涉及计算和存储。这一阶段发生在数据加速层，或称为智能物化层，系统基于实验内所需观测的指标或维度动态选择应物化的表，而不是直接对最全最宽的表执行数据层面的加速。

基于此，可以看到局部物化的操作。由于消费场景或诉求不同，可能衍生出不同的 schema 信息或数据粒度，我们可能有全量的明细或裁剪的明细，再到轻聚合和预计算的结。我们将整个过程称之为 FLOW NODE 节点编排形式。同时上述整个 DAG 也会面临到节点间的动态调整，即节点可能跳过或引入新的节点依赖。这种动态流式的编排决定哪些节点应执行，哪些不应执行，这同样是整个数据编织中非常重要的一部分。

上述步骤可以归纳为三点：首先，需要提供逻辑表物料的资产信息；在此基础上，完成组装逻辑的定义，即要有一套标准语义，定义出逻辑表；最后，根据不同的规则或业务场景实现按需的不同粒度的表的构建。

6. 技术详解-智能编排 & SQL 引擎

在 AB 实验场景中，由于需要观测当日与累计指标，可能涉及不同的加入策略。由于同一时间内订阅的指标可能来自不同主题，可能产生不同的逻辑表操作路径，因此一个实验背后的数据链路或数据任务可能不止一个，可能会有成比例的增长。这必然面临大规模 DAG 编排与调度的挑战，以及任务级的合并与拆分，伴随队列资源的并发控制。整个 DAG 的动态调度是技术挑战的重要部分。

在任务执行的背后，离不开 SQL，在实验场景下，前面提到的裁剪明细、轻聚合和预算阶段会有哪些区别呢？

以裁剪明细阶段为例，本质上是将指标对应的事实表，如订单大盘表，与所需的实验分流维表信息关联，补充或扩展指标在哪些实验 ID 或版本下展示相关信息。

第二个阶段是轻聚合阶段，由于实验需要计算当日数据或累计数据，因此需要对当日数据进行聚合操作，并对累积数据进行聚合。

在预计算层面，除了传统的看板分析链路计算指标的具体值外，在实验场景下，要计算指标的 P 值或置信区间，用统计方法证明指标增长的可信度，这就离不开指标样本和、指标平方和，以及乘积和斜方差的统计量计算，这些要素的叠加会在预计算的层面体现出来。

7. 技术详解-复合指标 DAG

下面在简单介绍下自动化链路中关于处理复合指标时需要执行的步骤。

假设四个实验，每个实验都订阅了自己需要观测的特定指标，例如某个实验可能关注 GMV，另一个可能关注 ARPU，还有一个可能关注点击 CTR。这些不同的指标将在语义解析层完成逻辑拆分，分解为分子和分母。

完成指标的逻辑拆分后，逻辑表和衍生指标将统一按照衍生指标的计算逻辑进行处理。不同的指标可能归属于不同的逻辑表，例如，订单逻辑表、曝光逻辑表或点击逻辑表。逻辑表拆分完成后，接下来是针对单个逻辑表下的不同加入策略生成，分为当天、累计的时间策略，每个时间策略对应的 FLOW NODE 节点中将叠加前述的不同消费场景或应用场景的所需的数据 schema 信息，并在此基础上按需进行数据粒度变更或数据存储媒介变更。

从实验的创建、语义解析到计划的生成，整个过程能够完成针对实验场景下所需观测指标的一系列数据加工，同时也能直观感受到多实验对任务数量膨胀带来的影响，这也对我们的任务编排或任务自动拆分合并提出了较高要求。

当前进展未来展望

最后，讨论一下当前进展和对未来工作的展望。

1. 当前进展

在实验场景下，存在 4 种指标类型、3 种分析模式、2 种检验方法和 3 种应用形态。其中红色字体列出的是已经支持的部分，而灰色是尚未实现的部分。目前，60% 的指标可以通过实验订阅驱动自动计算，无需人工介入，即可在数据面板或报告面板上实现秒级分析。直观地看，业务部门提出一个关于实验的需求后，交付效率已从周级别提升到天级别。

2. 未来规划

未来规划在四大方面实现提升，包括指标覆盖度、大规模使用的时效和性能、实验的灵活性，以及问题排查的便捷性。

以上就是本次分享的内容，谢谢大家。

Q&A

Q：在 AB 实验中存在众多过程量，并且在口径生成到数据科学结果产出的过程中会产生大量数据膨胀，包括众多任务。在这一过程中如何实现数据的主动治理和任务合并？

A：实际上，通过观察 03.7 章节图表可以发现，在实验过程中，数据膨胀的效果是显而易见的。例如，在一个实验中，我可能订阅了 ARPU，这可能涉及订单和用户表；同时，我还可能订阅了 UCTR，这可能涉及点击和曝光表。因此，一个实验中尽管订阅了两个指标，但可能会分裂出四个逻辑表。每个逻辑表又会由于当天和累积的时间策略叠加，可能会分裂出八种不同的加速策略，每种策略下可能又会对应不同的任务，如 HiveTask、TransformAB、SyncCK。因此可见，实验场景下可能会产生大量任务级别的分裂，当面对大规模实验时，分裂现象将更加显著。

核心点在于，存在一个称为语义解析层的层面，我们的合并动作和未来合并方向也将集中于此。尽管不同实验可能订阅不同的指标，或在不同时间订阅的指标分布不同，但指标所能路由到的逻辑表相对固定。例如，点击必须被路由到与点击相关的逻辑表，订单必须被路由到相关的订单逻辑表。基于逻辑表本身，它可能支持多个实验的数据产出。

因此，合并的整体思路是，当多个实验一起处理时，我们针对每个实验内的指标完成语义层面的解析，并将其路由到不同的逻辑表。在单个逻辑表内，可以合并多个实验。例如，如果一个逻辑表下计算了四个实验，那么这四个实验在关联维表操作时，其实可以在其限定条件中设定一个实验 ID 列表的范围。这样，原本可能由四个实验触发的订单逻辑表的四次计算任务，现在可以在一个任务内完成。这种合并逻辑将原来的四个任务减少为一个任务，随着实验数量的增加，尤其是对于那些每天有上万级实验的公司来说，合并效果将更加明显。

以上就是本次分享的内容，谢谢大家。