支付宝商家开放离线数据质量保障方案

原创源武蚂蚁质量AnTest

1. 背景

随着业务的逐步增长，支付宝商家开放2022年的数据量呈指数型增长，截止2022年底商家开放的离线有效表数占比支付宝总的离线表数已经过半，具体数据分布如下图所示

有效表定义：节点状态正常且不是临时表。

从上面的饼状图可以看出，商家开放有效表在支付宝占比已经超过50%，且离线数据的增长速度非常快，相较于21年上升65%。在如此快的一个增速下，数据的潜在风险也是日益剧增。所以当前我们商家开放在数据这块面临了以下几个问题：

数据增速快，保障成本高

在商家开放数据增速如此快的背景下，不断增加保障人力肯定是不现实的解决方案。所以如何低成本的自动保障数据质量是一个亟待解决的问题。

离线数据应急机制不够健全

业务系统都有标准的应急模式，数据还没有纳入标准的应急体系中

如何度量数据质量好坏

1.1 传统数据保障流程

如上图所示，基于我们面临的问题先看看传统的数据保障方式。传统数据保障流程里，事前做了很对事情，在数据开发式依据需求设计用例，待数据产出之后进行数据预览、探查、依据规则配置，这种重事前的方式，在前期需要投入大量人力，跟我们现状不太符合。

1.2 商家开放数据保障流程

基于传统的数据保障流程，结合商家开放业务数据的特点，我们发现商家开放的离线数据一般风险适中，且回流到线上的数据才是风险最高的，在离线链路自己玩的数据相对风险较低，所以我们调整了下保障流程，将保障视角着重放在数据回流。

目前数据回流的流程是，回流数据任务开发->代码review->规则布防->场景关联->发布->监控。回流到线上一定要关联场景，场景就是这个回流数据的线上应用场景，主要用于风险分级。整体流程如下图所示：

对于数据保障最有效的方式就是加上校验规则，离线数据不会实时造成风险，所以针对业务数据不涉资、T+1生效、风险中这些特点，我们采取轻事前&事中，重事后的模式，着重增加事后的规则布防。整体一个想法就是，所有的数据先依据风险等级挑选出重点保障数据，所有重点数据不需人为去铺设，能自动生成规则，规则生成之后能能自动验证这些规则在线上起到防护作用，并依据验证结果自动调整布防策略。

2. 数据保障解决方案

2.1 数据保障架构

上述保障架构图按照流程可以从上往下分两块，上面一块是布防侧，下面是验证侧，整体架构思路就是先圈出重要的资产，然后对重要资产进行布防，布防之后对规则发出的告警进行应急快反，最后对我们布防的结果进行一个正反验证（正向：度量大盘；反向：攻防验证）。在布防侧我们主要是以规则布防为主，标准化应急为辅来保障我们布防的全面性。在验证侧，我们主要是以质量大盘和无感攻防，这么一正一反的手段去验证布防的有效性。接着将分别从资产、布防、验证这三块来详细阐述我们的保障方案。

2.2 资产

从2.1保障架构图中，我们能看到最开始就是资产分级，所以我们首要的就是要圈选出我们要保障的资产范围。之前我们也有过描述，我们重点保障范围是我们的重点资产。但是这个重点资产怎么去划分，这就要回到我们数据质量最基本需要保障的两个关键点：时效（基线）和内容（场景）。

对于内容的风险等级，数据架构提出了数据场景的概念，并根据场景风险等级定义确定数据风险等级（R1/R2/R3/R4）。将场景末节点录入到场景系统后就会自动倒推上游全链路任务，将链接上各任务节点对应的表全部按照场景末节点的风险等级打上R1/R2/R3/R4这样的等级标，这样就要求上下游各方以共同的R级标准来保障数据质量。(其中:R1>R2>R3>R4)

对于时效性的等级划分，需要按照数据业务的重要性定义其数据资产等级，按照需要保障的优先级来定义基线。基线等级：按照保障重要程度，分为4个等级：8、7、5、3。（8>7>5>3）

基于上述对内容和时效的风险等级描述，自然就能推导出，我们保障的重点资产范围是：挂载在R1/R2场景或7/8级基线上的资产。

2.2.1 资产分级

确定了重点资产的划分方式之后，那么怎么把这些数据从上百万节点里识别出来，并打上风险等级标就是重中之重，否则那么多任务我们根本不知道重点去高保哪些。目前我们筛选重点资产的方法就是通过场景和基线等级来确认资产的重要性，所以我们要从场景和基线这两块出发，去保障对应风险等级的准确性。整体思路如下图所示：

场景（动静结合）

对于场景分级准确性，我们采用动静结合，人肉加自动巡检的模式来保障准确性。

事前（流程卡点+人肉打标）

流程卡点：回流节点发布需要增加绑定场景卡点。这个卡点其实就是在，回流节点发布过程中，会自动校验这个节点有没有绑定对应的场景，如果没有，该节点必须关联或者新增场景绑定之后才能正常发布成功。增加这个卡点的目的就是为了给我们的回流节点都打上一个场景风险等级标，然后通过回流节点自动推到上游全链路任务节点风险等级，最终能实现所有的数据都有内容风险等级。
人肉打标：优化现有场景审批流程，场景审批流增加业务质量节点，提升场景风险等级准确性

事后（自动巡检）

增加事后场景风险等级巡检机制，来校验场景风险等级的正确性。目前巡检的方法是通过对线上流量进行统计，筛选出线上访问流量大于100qps的R3/R4场景的回流节点，并结合极光抛出场景等级不准告警信息。

基线

节点挂载基线优化现有审批流，增加业务质量审批节点，保障基线等级的准确性。

2.3 布防

2.3.1 离线表规则自动布防

目前对离线数据最有效的保障手段就是配置DQC规则，但是在大量的离线数据上去手动配置DQC规则会耗费很大的成本，所以我们想要一个低成本能自动配置DQC规则的方法。结合内部平台的能力，我们能整合成一个低沉本自动布防的方案，具体方案架构如下图所示:

正如上图描述的，整体的一个数据流转就是，我们将圈选的重点表数据同步到规则生成模块，规则生成模块有一个任务队列去给他们底表中的数据进行字段识别->规则推到->DQC规则的生成->规则部署上线，规则生成之后，会直接在DP平台（数据开发平台）上对生成的规则进行维护。具体串联的流程见下面的流程图：

2.3.2 应急

在所有规则上线之后需要对数据有一个标准的应急方式，目前我们与极光应急通道打通，将重点表信息定时同步到极光应急底表数据中。当这些表节点出现异常或者DQC规则执行异常之后，会及时投递极光告警信息至应急群，并@对应的owner和质量接口人。

2.4 验证

对于生成的这些规则，我们要确保在线上真实有效，所以如何验证这些规则的有效性，也是比较重要的命题。我们想到的是通过正向和反向两种方式去验证，正向的就是从一些规则底表里面去洗出对应这些重点表的生效规则，然后以报表的形式呈现出来，形成数据质量大盘，通过大盘能直观看到当前数据的一个布防水位。反向的验证方式就是用过攻防验证，通过攻防的这种形式，我们能验证规则是否真实在线上起到防护作用，同时也能挖掘出我们的一些布防漏洞，然后调整布防策略，完善布防。

2.4.1 数据质量大盘

以报表的形式不仅要呈现出当前商家开放的资产数据、资产分布和资产增长趋势，还要展现出当前数据的布防水位，能够基于报表的数据做出下一步布防的决策。DI报表需要有资产指标和布防指标两大类（资产指标：所有离线表数、离线有效表数、场景数及分布、基线数及分布；布防指标：表级DQC覆盖率、字段级DQC覆盖率）。

2.4.2 攻防验证

对于数据攻防，我们有常态化攻防、1218数据攻防等手段。对于这些常见的攻防手段，如上图所示，本节就不再赘述。鉴于我们对攻防的目标是验证生成规则的有效性和潜在风险的挖掘，所以本节提出了一个轻量级常态化无感攻防的方案，无需业务人员投入，无需应急，攻防平台直接打通榜单平台，攻防结束之后榜单结果直接以群消息和邮件的形式知会给各业务红军进行查漏补缺。

具体思路如下：

整体流程：

3. 数据质量评估方案

衡量数据质量需要从表级DQC规则覆盖率和字段级DQC规则覆盖率这两个视角去衡量。表级DQC主要衡量一个表整体的质量情况，字段级DQC主要衡量表中每条数据的质量水位。

3.1 字段级DQC规则覆盖率

从字段出发，在数据的字段上配置规则，这样能最大程度上保障我们的每一条数据的质量。但是每条数据都有多个字段，如果我们保障数据所有的字段的话，对于如今这么大的数据体量来说肯定是相当困难，所以对于这些海量的字段我们要区分优先级。经过对字段的数据血缘分析，我们发现有些字段是被下游消费的，有些字段是不被消费的，所以我们更应该关注那些有被下游消费的字段。圈选重点保障的字段范围方法如下如所示：

圈选出字段集之后，我们要将所有字段分为三大类，每类字段按照类别特性布防对应的规则，具体字段分类和布防规则如下：

枚举字段

非空
枚举范围
稳定性

字符串字段

非空/空值率
自定义校验规则（正则等）

数值字段

非空
数值范围
波动

所有的字段都打上分类标之后，按照每类字段的规则要求，我们就能统计出整体的一个字段规则覆盖率了，具体统计公式如下所示：

4. 后续规划及思考

无感攻防中如何结合LLM自动生成高质量的攻击case，形成数据质量的风险挖掘模型
链路规则核对
高危变更播报

如对本文有任何建议或问题，请关注我们的微信公众号，我们将私信回复 ❤️

继续滑动看下一个