2. 实验数据资产盘点
实验数据变更之所以难以评估影响，根本原因在于数据资产之间并非孤立存在，而是通过一条条隐式或显式的依赖链相互咬合。一次看似只改了一个字段类型的操作，可能沿着“数据表→特征→标签→指标→模型→报表”的链路一路传导，最终让某个业务看板上的核心指标发生偏移。因此，变更影响分析的第一步不是急着改代码，而是先把这条链上的资产和依赖关系盘清楚，形成一份可查询、可追溯的数据资产清单。
一、七类资产：盘点的基本对象
在实验数据体系中，需要盘点的资产可以归纳为七类，它们构成了依赖链上的不同节点：
- 实验对象：实验所作用的业务实体，如“用户”“订单”“商品”“门店”。它决定了数据的主键粒度和分区方式。
- 数据表：承载原始或加工数据的物理/逻辑表，如
dwd_user_action_di、dws_order_agg_1d。需记录表名、分层、分区字段、更新频率、负责人。 - 特征：从数据表加工出的模型输入变量，如“近7日下单次数”“客单价分位”。特征往往有明确的加工口径和窗口。
- 标签：监督学习的目标变量或实验的分组标识，如“是否复购”“实验组/对照组”。标签口径变化会直接改变模型训练目标。
- 指标：用于衡量实验效果的统计量，如“转化率”“人均GMV”“次日留存”。指标依赖特征或标签的聚合结果。
- 模型：消费特征与标签的算法产物，如排序模型、转化率预估模型。模型对输入特征的分布和类型高度敏感。
- 报表：面向业务决策的展示层，如实验日报、AB 看板。报表通常消费指标，是变更影响的最终暴露面。
这七类资产之间存在方向明确的依赖：数据表产出特征与标签，特征与标签共同支撑指标和模型，指标与模型结果最终汇入报表。盘点的目标，就是为每个资产建立“它依赖谁、谁依赖它”的双向记录。
二、依赖关系的三种类型
依赖关系不能只记“有关系”，而要区分类型，因为不同类型的变更传导方式不同：
- 结构依赖：字段名、类型、分区键的引用关系。例如特征
user_7d_orders直接引用dws_order_agg_1d.order_cnt_7d。改字段类型会直接破坏特征计算。 - 口径依赖：计算逻辑或过滤条件的继承关系。例如指标“有效订单数”依赖标签“有效订单”的判定规则。口径变更不会报错，但会静默改变数值。
- 时序依赖：上游产出时间与下游调度时间的先后约束。例如报表 T+1 早上 8 点刷新，要求指标表在 6 点前完成。上游延迟会直接导致报表空窗。
把依赖类型标注清楚，才能在变更时快速判断：这次改动是会让任务直接失败（结构依赖），还是让结果悄悄偏移（口径依赖），或是让链路整体延迟（时序依赖）。
三、资产清单的字段设计
一份可用的数据资产清单，不是简单的资产罗列，而应包含足够的元信息支撑影响分析。建议每条资产记录以下字段：资产唯一标识、资产类型、所属分层、负责人、上游依赖列表、下游影响列表、依赖类型、变更敏感度、最近变更时间。其中“变更敏感度”用于标记该资产被改动后影响范围的大小，可粗分为高、中、低三档，便于排优先级。
下面给出一份可直接参考的清单示例，覆盖从数据表到报表的完整链路。示例中的表名、特征名和数值均为教学假设，用于说明字段填写方式。
| 资产标识 | 类型 | 上游依赖 | 下游影响 | 依赖类型 | 敏感度 |
|---|---|---|---|---|---|
| dwd_user_action_di | 数据表 | ods_user_action_log | feat_user_active_7d | 结构 | 高 |
| feat_user_active_7d | 特征 | dwd_user_action_di | model_repurchase_v3 | 结构+口径 | 高 |
| label_repurchase_30d | 标签 | dws_order_agg_1d | model_repurchase_v3 | 口径 | 高 |
| metric_conversion_rate | 指标 | label_repurchase_30d | rpt_ab_daily | 口径 | 中 |
| model_repurchase_v3 | 模型 | feat_user_active_7d, label_repurchase_30d | rpt_ab_daily | 结构+口径 | 高 |
| rpt_ab_daily | 报表 | metric_conversion_rate, model_repurchase_v3 | 业务决策 | 时序 | 中 |
四、依赖链的可视化：从表到报表的传导路径
清单是表格化的记录，而依赖链更适合用图来表达。下图展示了本节示例链路中，一次数据表字段变更如何沿依赖关系逐级传导到报表，并标注了每一跳的依赖类型。图中实线表示结构依赖，虚线表示口径依赖，点线表示时序依赖。
五、盘点落地的关键动作
资产清单不是一次性文档，而是需要持续维护的活数据。落地时建议抓住三个动作。第一，从下游反推上游：先列出所有报表和模型，再逐层向上追问“它读了哪些指标、特征、标签、表”，这样不容易遗漏隐式依赖。第二，为每条依赖标注类型和敏感度：结构依赖优先做字段级血缘，口径依赖优先记录计算 SQL 或规则版本，时序依赖优先记录调度时间和 SLA。第三，把清单接入变更流程：任何一次数据表或特征变更，都先查清单中的下游影响列表，按敏感度决定回归验证的范围和深度。
完成资产盘点后，团队就拥有了一张“变更影响地图”。后续无论是字段类型调整、特征口径修订，还是标签规则升级，都可以先在地图上定位受影响的下游资产，再决定回归验证的优先级和范围。这正是把变更影响分析从被动救火转为主动防控的基础。