为什么工作流中的数据质量要尽早验证，经常验证？

海豚调度 2023-04-11

604

点击蓝字关注我们

摘要

做数据的同学经常会遇到的一种情况是：业务同学经常说我们做的报表看起来数据不准确，有什么办法改善吗？这就是今天我们要聊的常见数据质量管理的一种常见情况。

数据质量管理（Data Quality Management）一直是数字化转型中的热门话题，是指对数据生命周期的每个阶段可能引发的数据质量问题，进行识别、度量、监控、预警等一系列管理活动，并通过改善和提高组织的管理水平使得数据质量获得进一步提高。

为什么要做数据质量管理

在今天，数据已经成为企业的新型资产，有效的数据能够支撑企业的分析和决策，而错误的数据却可能会带来负面的影响，我们一起来看下数据质量差会带来什么问题：

数据可信度低
影响数据分析和数据挖掘的准确性
可能会导致错误的决策
数据开发层面的工作越来越多，链路也越来越长，如果没有在一些关键的节点配置好相应的检查，一旦出现数据错误的问题就比较难定位。

通常引起数据质量问题的原因有多种，产生的因素通常有以下业务上的原因和技术上的原因：

由此可知做好数据质量管理是数据开发工作的重中之重，做好数据质量管理可以带来提高数据的可信度、及时发现数据错误问题，更好地定位问题和提高工作效率的好处，, 也是数据治理中最重要的一环，数据质量做不好，数据治理一定会失败。

针对数据层的数据质量保障，通常可以分为四个方面：数据及时性、完整性、准确性、一致性。

“

数据及时性

数据及时性，指的是数据是否能够按时地产生。影响数据及时性的 3 个要素是：定时调度时间、优先级以及数据基线。其中任务的优先级决定了它获取数据计算资源的多少，影响了任务执行时长。数据基线则是数据的最晚产出时间的保障。

这 3 个要素在一些调度系统上是可以直接设置的。

“

数据完整性

数据完整性，指的是数据是否存在缺失的情况，这里的缺失可以是整个数据集的记录缺失，也可以是某个字段记录的缺失，对应的规则包括空值检查，表总行数检查。

“

数据准确性

数据准确性，指的是数据是否存在反常或者错误的情况，例如数值反常地过大或者过小，或者超过记录的波动值，对应的规则包括数值波动检查，最大值、最小值检查，跨表准确性等。

“

数据一致性

数据一致性，指的是检查数据是否符合逻辑，数据内单项或多项数据间存在逻辑关系，例如 pv > uv 对应的规则是表逻辑检查。

如何做好数据质量管理

数据质量管理一般采用事前、事中、事后三阶段保障体系来做数据质量管理。

“

事前制定规范

数据开发人员需要提高数据质量保障意识，构建完善的数仓建设规范，保障数据模型的设计、ETL/ELT 开发流程方法论能够落实到实际。

1）规范制定

大部分数据质量问题是因为没有遵循数据开发规范导致。我们可以根据数据质量特性制定相关开发规范并在事前进行约定遵守。

数据模型规范：
数据结构清晰、分层明确-层级依赖(星型建模或维度建模)等。
元数据规范：
字段描述、字段类型-长度-取值范围、枚举范围、主键唯一等。
命名规范：
表、字段名称，项目名称，文件名称、函数名称、编码规范等。
安全规范：
隐私字段脱敏、权限层级管控等。

当然数据源的质量也是一个不可忽视的因素，好的数据源直接能起到事半功倍的效果。

“

事中数据质量监控(验证)

数据质量监控。通过建立一套切实可行的数据质量监控体系、设计数据质量稽核规则、加强从数据源头控制数据质量、把控整个数仓设计和开发过程，形成覆盖数据全生命周期的数据质量管理。

数据质量的落地实施，最核心还是需要通过数据质量监控系统，通过自动化的质量检核方式，极大的减少人力的投入和过程干预，提升效率，减少误差。围绕完备性、真实性性、一致性、及时性等指标监控分析数据质量问题并进行整改优化。

1）监控规则制定

利用系统定义的各种校验规则对业务表、字段进行多角度的数据质量监控，对关键业务数据的质量情况进行全方位把握，大体包含以下几种：

唯一值监控：监控某个字段值是否唯一，例如 ID，如果唯一值字段出现重复数据，则代表数据质量异常。
空值监控：某个字段必须有值，例如付款记录中的金额。此规则监控此类字段是否为空，为空则判断异常。
指标波动监控：某个指标例如 GMV，如果当天指标比昨天暴涨 10 倍，大概率为异常。
取值范围监控：例如年龄字段，值是否超过常规范围。枚举字段，值是否超过定义范围。
记录数量波动监控：如果当前表日均增加 1W 条记录，某天新增超过 2W 条，大概率出现异常。
数据规范校验：字段格式规范（例如时间字段是否按照指定格式）

这块后面内容还有更细粒度的介绍。

2）监控异常告警

对上述监控规则中，出现异常的任务进行告警至责任人。包括但不限于：邮件、Slack、微信、钉钉等方式。

3）异常修复及记录

责任人接收到异常告警后，及时对数据任务进行排查以及修复，同时对当前异常进行记录用于后续整改。

“

事后监督

事后监督。出现数据质量问题，清晰定位数据技术责任人，进行整改迭代，保证数据质量管理形成一个良性循环，实现数据向优质资产的转变。

事实上，再严格的预防措施和监控都无法完全避免数据质量问题的发生，事后的管理和评估就尤为重要了。

要想真正解决数据质量问题，就要明确业务需求并从需求开始控制数据质量，并建立数据质量管理机制。

从业务出发做问题定义，由工具自动、及时发现问题，明确问题责任人，通过邮件、短信等方式进行通知，保证问题及时通知到责任人。跟踪问题整改进度，保证数据质量问题全过程的管理。

既然数据质量的落地实施，最核心还是需要通过数据质量验证来实现，下面就着重来说说如何进行数据质量验证。

如何做好数据质量验证

首先想聊的话题是为何我建议你基于调度系统去做数据质量检查。

“

3.1、基于调度系统去做数据质量检查的优势

基于调度系统做数据质量检查的优势

接着本文最重要的部分来了，不要眨眼...

“

3.2 为什么基于 Apache DolphinScheduler 来做？

在探讨完数据数据质量检查的重要性以后，我们接下来一起看看我们为什么要基于 DolphinScheduler 来开发数据质量检查。

3.2.1 Apache DolphinScheduler 是什么？

Apache DolphinScheduler 是一个分布式易扩展的可视化工作流任务调度平台。致力于解决数据处理流程中错综复杂的依赖关系，使各种任务在数据处理流程中开箱即用。

它具备以下的特性：

高可靠性，去中心化的多 Master 和多 Worker 架构设计, 可以避免单 Master 压力过大，另外采用任务缓冲队列来避免任务过载
简单易用，所有流程定义都是可视化，通过拖拽任务可完成工作流创建，也可通过 API 或 PyDolphinScheduler 这种 Python 方式或 YAML 创建或与第三方系统集成, 一键部署
具有丰富的应用场景，支持多租户，支持暂停恢复操作. 紧密贴合大数据生态，提供 Spark, Hive, M/R, Python, Sub_process, Shell 等 20+ 种任务类型
高扩展性，支持自定义任务类型，调度器使用分布式调度，调度能力随集群线性增长，Master 和 Worker 支持动态上下线
高性能，调度能力通常是同类开源调度系统的 N 倍以上

简单点儿来理解，DolphinScheduler 最重要的 2 个组成是 Master 和 Worker，Master 负责工作流(任务)状态的分发和管理，Worker 负责具体任务的执行。

3.2.2 数据质量监控的目标

基于本文前面的描述，可以看到我们想要的的数据质量监控的样子：

具备丰富的内置规则，能够满足我们日常的各种检查需求
能够无缝地接入到工作流当中，当出现严重数据错误问题时能及时进行告警和阻断
有较为完善的结果处理机制
能够查看数据检查结果和错误数据，方便排查问题

在确定目标以后，社区朝和同学(DolphinScheduler Committer)调研了现有的开源方案是否能够满足这样的需求，开源方案中较为知名的有几个：

Apache Griffin：

Apache 顶级项目，是一个优秀并且完备的数据质量检查系统，
具有独立的UI、调度和内置规则，依赖于 Apache Livy 来提交 Spark 作业
一个独立的系统，较难无缝地接入到工作流当中来实现当出现严重数据质量问题时的阻断。

Qualitis：

微众开源的数据质量系统，具备较丰富的内置规则，界面简洁容易使用
依赖于 Linkis 作为执行 Spark 作业的引擎
如果想要实现无缝接入工作流需要依赖 DataSphere Studio，有点儿重

Great Expectations

可能不少同学对 Great Expectations 比较陌生，但在数据科学领域 great_expectations 是一个不错的框架
Python 编写，目前最新版本为 0.15

3.2.3 基于 DolphinScheduler 开发数据质量检查的优势

在调研完现有的开源方案以后，朝和决定基于 DolphinScheduler 来开发数据质量检查服务。那么基于 DolphinScheduler 来开发数据质量检查有什么优势呢？

DolphinScheduler 作为一个任务调度系统，具备了执行任务的基础，不需要引入新的组件来提交任务
数据质量检查可以作为一种任务类型无缝接入到工作流当中
无需新增其他服务来增加运维的难度
可以很好地与社区共建开源

数据质量监控的设计和实现

首先来看一下数据质量监控整体的运行流程：

运行流程

用户创建数据质量检查任务时会在前端页面选择一个规则，填入所需要的参数，保存任务。

然后 DolphinScheduler 服务端检查流程如下：

数据质量任务开始执行，由 Master 下发任务到 Worker ，Master 是DolphinScheduler中的调度工作流和任务的组件，Worker 是DolphinSchduler中负责实际执行任务的组件。
Worker 接收到任务以后会进行参数的解析和构造，执行 DQCApplicaiton，DQCApplicaiton 执行完成后会将结果写入到相应的存储引擎，当前数据质量任务结果存储在 t_ds_dq_execute_result 表中, Worker 会发送 TaskResponse 给 Master。
Master 接收到 TaskResponse 后会对任务类型进行判断，如果是数据质量检查任务的话会进行数据质量结果判断，一旦发现数据异常就会进行告警或者阻断。

从上面的流程中我们可以看到下面几个核心的组成部分：

规则管理：规则定义以及规则的使用
数据处理：Worker 将规则定义转化为 DQCAppliccation 所需的参数以及 DQCApplicaiton 执行数据处理
结果处理：结果检查以及异常后的处理

“

4.1 规则管理

4.1.1 规则的定义

规则是整个数据质量检查的核心部分，每一条规则对应着一个检查指标，那么一条完整的规则应该包含什么内容呢？规则主要是由两个部分组成。

参数输入项：在数据质量检查规则中核心的输入项包括：

统计值指的是我们对要检验的数据执行一系列操作后得到的值，例如表总行数或者为某字段为空的行数。
比对值指的是用来作为比较目标的值，比对值可以是固定值，也可以是由定义好的计算逻辑计算出来的值
数据源输入项，定义了要检查哪些数据
统计值参数和比对值参数
结果判断相关的参数，包括检查的方式、比较符和阈值以及失败，这部分的参数主要是用来定义怎样判断数据是否异常和异常如何处理。

SQL 定义：需要定义 SQL 来计算得到统计值、比对值以及获取错误数据

在设计规则的时候做了如下考虑：

后续新增规则不希望频繁修改前端页面
保证用户良好的体验包括输入项的联动比如数据源、表和列的选择联动等等。

我们决定使用前端表单自动生成技术 form-create，后端读取规则参数输入项转换成 form-create 所规定的 JSON 字符串传输给前端，由前端去自动生成表单输入项，实现规则灵活的增删改，同时也保证前端代码简洁和用户体验。

下图是我们定义数据质量任务时所展示的表单，选择不同的规则前端就会生成不同的表单输入项

数据质量任务前端表单输入项

我们按照准确性、完整性、及时性、唯一性、规范性、一致性和自定义检查七种分类定义了十几个规则(完整规则见附录1)。下面有几种前面没讲的分类定义和对应的一些规则。

唯一性指的是检查哪些数据是重复数据或者数据的哪些属性是重复的，对应的规则例如主键唯一性检查。
规范性指的是检查数据是否符合规范，是否按照规定的格式存储，对应的规则包括正则表达式检查，字段长度检查，枚举集合检查，数值范围等。
自定义指的是用户可以通过自定义 SQL 的方式来定义要检查的逻辑，支持的规则包括单表自定义 SQL 和跨表值比对。

4.1.2 比对值的管理

比对值在规则中也是相对比较重要的组成部分，我们对目标数据进行计算统计以后得到的统计值去和比对值进行一定方式的比较才能得到一个校验结果。

比对值类型和内置规则将决定了我们数据质量校验方式的丰富性，我们系统里面内置较为丰富的比较值:

固定值
最近 7 天波动
最近 30 天波动
日波动
周波动
月波动
源表总行数
目标表总行数

同时也支持用户去自定义比对值，只需要定义好以下参数：

execute_sql：该 sql 是用来计算出比对值
output_table_name：将 execute_sql 执行的结果注册到临时视图所用的表名
comparison_name：是比对值的名称，结合 output_table_name 可用于其他 SQL 中

“

4.2 数据处理

规则定义好了，用户也填好参数，这个时候就需要一个可以执行计算任务的组件来完成实际数据处理，DQCApplication 就是这么一个组件，它主要是由两个部分组成：

执行引擎：我们选择了 Spark 作为任务的执行引擎。Spark 支持多种数据源类型的连接同时计算比较快。
执行链路组件：我们设计了 Reader、Transformer 和 Writer 三种类型的组件， Reader 用于连接数据源，Transformer 用于执行 sql 进行数据的处理，Writer 用于将数据输出到指定的存储引擎中

4.2.1 执行流程

整个应用的执行流程是这样的:

DolphinScheduler Worker 接收到任务以后，会将规则的参数输入项和 SQL 定义转换成 DQCApplication 所需要的参数传给 DQCApplication 去执行
DQCApplication 解析参数选择相应的引擎，构造出引擎对应的 RuntimeEnviroment 和 Execution
同时也会根据参数创建一系列的 Reader、Transformer 和 Writer ， Execution 会按照一定的顺序去执行这些组件中的逻辑，来完成整个数据质量校验任务

在上图里我们看到可以定义一个或者多个 Reader 来满足不同场景的需求，最后通过 Writer 输出的数据包括校验结果、统计数据以及错误数据。

当 DQCApplicaiton 执行完计算逻辑，把统计值、比对值计算出来写到存储引擎中以后，会把 TaskResponse 发送给 Master ，由 Master 来执行最后一步的结果处理。

当 Master 接收到 TaskResponse 以后，判断任务类型为 DATA_QUALITY 后会进行结果判断，如果判断结果为异常的话，那么就会根据所选择的失败策略进行处理

4.2.2 结果处理

怎么去判断我们所检查的数据是否异常呢？

这里我们提供了一个校验的公式，请看下图

在这图里面我们可以看这个校验的公式由是三个部分组成，检查方式，比较符和用户定义的阈值，只要将统计值和比对值填入到由这三个组成的公式就可以得到检查结果，接下来我们来看一个例子，校验表总行数能否达标。

我们这里选择的的检查方式是比对值减去统计值，假设统计值是 9800，比对值是 10000，比较符我们选择大于等于，阈值设置为 100。

这个表达式想要达到的意图是当比对值减去统计值的差大于等于 100 时，检查结果是失败的。我们把统计值和比对值套入这个公式当中，发现 10000-9800 = 200 是大于 100 ,那么检查结果为失败。

一旦发现检查结果为异常，那么就要执行相应的失败策略，我们提供两个等级的失败策略：

告警，告警等级是当检查结果为异常时会进行告警，但不会将任务结果设置为 false，不导致整个工作流的阻断。
阻断：当检查结果为异常时，首先是进行告警，同时会将任务的结构设置为 false，对整个工作流进行阻断。

4.2.3 结果数据查看

当有数据异常的时候我们可以在结果列表中去看相关的结果数据：

在这个列表中可以较为清晰地了解统计值、比对值、比较方式等信息，帮助我们了解数据异常的情况。

有时候光看统计值并不能很好地了解数据异常的原因，这个时候我们也可以查看错误数据，看看是哪些数据出了问题，帮我们更好地去修复数据。

这样，数据质量监控就这么容易的在 DolphinScheduler 上实现啦！如果你有这样的数据质量监控需求，DolphinScheduler 是你的不二选择！

最后回到今日的数据质量管理话题上，数据质量工作做的好坏如何评价呢？

数据质量管理的评价体系

在公司实施了一系列的数据质量管理策略之后，可从以下维度对目前数据质量管理工作进行评价：

数据完整性
☆ 考量数据项信息是否全面、完整、无缺失
★ 指标公式：表完整性和字段完整性的平均值

监控覆盖率
☆ 确保数据遵循统一的数据标准或规范要求
★ 指标公式：已监控作业个数/作业总个数

告警响应度
☆ 通过日常管理、应急响应，降低或消除问题影响，避免数据损毁、丢失

★ 指标公式：已处理告警个数/告警总个数

作业准确性
☆ 考量数据是否符合预设的质量要求，如唯一性约束、记录量校验等
★ 指标公式：1 - 告警作业个数/监控作业总个数

作业稳定性
☆ 考量作业的运行稳定性，是否经常报错，导致数据事故
★ 指标公式：1 - 错误作业个数/作业总个数

作业时效性
☆ 考量数据项信息可被获取和使用的时间是否满足预期要求
★ 指标公式：延迟的高价值作业个数/高价值作业总个数

作业性能分
☆ 考量作业的执行效率和健康度，诊断作业是否倾斜等性能问题
★ 指标公式：1 - 危急作业个数/作业总个数

Apache DolphinScheduler 已经提供了以上绝大部分数据质量管理指标能力、监控告警以及数据质量监控工具，相信你在 DolphinScheduler 上实现数据质量管理一定会事半功倍。

附录 1：

编号	数据质量维度	检查对象	检查项	检查项说明
1	准确性	数据行数	有效性检查，单字段、详细结果	将输入数据的值与一个既定的值域作比较
2	准确性	汇总数据	有效性检查，卷积汇总	汇总有效性检查的详细结果，将卷积的有效/无效值计数和百分比与历史水平作比较
3	重复性	数据行数	重复性检查，单字段、详细结果	将输入数据的值与一个既定的值域数据作比较，检查数据是否重复
4	重复性	汇总数据	重复性检查，卷积汇总	汇总重复性检查的详细结果，将卷积的重复数据计数和百分比与历史水平作比较
5	一致性	数据行数	一致性剖析	合理性检查，将记录数据的分布，与国企填充相同的字段的数据实例作比较
6	一致性	汇总数据	数据集内容的一致性，所表示的实体的不重复计数和记录数比率	合理性检查，将数据集内所表示的实体的不同值计数与阈值、历史计数、或总记录数作比较
7	一致性	汇总数据	数据集内容的一致性，二个所表示的实体的不重复计数的比率	合理性检查，将重要字段/实体的不同值计数的比率与阈值或历史比率作比较
8	一致性	数据行数	一致性多列剖析	合理性检查，为了测试业务规则，将跨多个字段的值的记录数分布和历史百分比作比较
9	一致性	日期时间类型检查	表内时序与业务规则的一致性	合理性检查，将日期与时序的业务规则作比较
10	一致性	日期时间类型检查	用时一致性	合理性检查，将经过的时间与过去填充相同字段的数据的实例作比较
11	一致性	数值类型检查	数额字段跨二级字段计算结果的一致性	合理性检查，将跨一个或多个二级字段的数额列的计算结果、数量总和、占总数的百分比和平均数量与历史计数和百分比作比较，用限定符缩小比较结果
12	完整性/有效性	数据行数	有效性检查，表内多列，详细结果	将同一个表中相关列的值与映射关系或业务规则中的值作比较
13	完整性/完备性	接收数据状态	数据集的完备性——重复记录的合理性检查	合理性检查，将数据集中重复记录占总记录的比例与数据集以前的实例的这个比例作比较
14	完备性	数据接收	数据集的完备性——将大小与过去的大小作比较	合理性检查，将输入的大小与以前运行同样的过程时的输入大小、文件记录数据、消息的数目或速率、汇总数据等作比较
15	完备性	接收数据状态	字段内容的完备性——来自数据源的默认值	合理性检查，将数据源提供的关键字段的默认值记录数据和百分比与一个既定的阈值或历史数量和百分比作比较
16	完备性	接收数据状态	基于日期标准的数据集的合理性	确保关键日期字段的最小和最大日期符合某个合理性规则
17	完备性	数据处理	数据集的完备性——拒绝记录的理由	合理性检查，将出于特定原因而被删除的记录数据和百分比与一个既定的阈值或历史数据和百分比作比较
18	完备性	数据处理	经过一个流程的数据集的完备性——输入和输出的利率	合理性检查，将处理的输入和输出之间的比率与数据集以前的实例的这个比率作比较
19	完备性	数值类型检查	字段内容的完备性——汇总的数额字段数的比率	数额字段合理性检查，将输入和输出数额字段汇总数的比率与数据集以前的实例的比率作比较，用于不完全平衡
20	完备性	数据处理	字段内容的完备性——推导的默认值	合理性检查，将推导字段的默认值记录数和百分比与一个既定的阈值或历史数量和百分比作比较
21	及时性	流程处理检查	用于处理的数据的交付及及时性	把数据交付的实际时间与计划数据交付时间作比较
22	及时性	数据处理	数据处理用时	合理性检查，将处理用时和历史处理用时或一个既定的时间限制作比较
23	及时性	流程处理检查情况	供访问的数据的及时可用性	将数据实际可供数据的消费者访问的时间与计划的数据可用时间作比较
24	一致性	数据模型	一个字段内的格式一致性	评估列属性和数据在字段内数据格式一致性
25	一致性	数据模型	一个字段默认值使用的一致性	评估列属性和数据在可被赋予默认值的每个字段中的默认值
26	完整性/一致性	数据模型	跨表的格式一致性	评估列属性和数据在整个数据库中相同数据类型的字段内数据格式的一致性
27	完整性/一致性	数据模型	跨表的默认值使用的一致性	评估列属性和数据在相同数据类型的字段默认值上的一致性
28	完备性	总体数据库内容	数据集的完备性——元数据和参考数据的充分性	评估元数据和参考数据的充分性
29	一致性	汇总数据日期检查	按聚合日期汇总的记录数的一致性	合理性检查，把与某个聚合日期关联的记录数和百分比与历史记录数和百分比作比较
30	一致性	汇总数据日期检查	按聚合日期汇总的数额字段数据的一致性	合理性检查，把按聚合日期汇总的数额字段数据总计和百分比与历史总计和百分比
31	一致性	总体数据库内容	与外部基准比较的一致性	把数据质量测量结果与一组基准，如行业或国家为类似的数据建立的外部测量基准作比较
32	一致性	总体数据库内容	数据集的完备性——针对特定目的的总体充分性	把宏观数据库内容(例如：数据域、记录数、数据的历史广度、表示的实体)与特定数据用途的需求作比较
33	一致性	总体数据库内容	数据集的完备性——测量和控制的总体充分性	评估测量和控制的成效
34	完整性/有效性	跨库跨表数据检查	有效性检查，跨表，详细结果	比较跨表的映射或业务规则的关系中的值，以保证数据关联一致性
35	完整性/一致性	跨库跨表数据检查	跨表多列剖析一致性	跨表合理性检查，将跨相关表的字段的值的记录数据分布于历史百分比作比较，用于测试遵从业务规则的情况
36	完整性/一致性	跨库跨表时序检查	跨表的时序与业务规则的一致性	跨表合理性检查，对日期值与跨表的业务规则进行时序比较
37	完整性/一致性	跨表的数值类型检查	跨表数额列计算结果的一致性	跨表合理性检查，比较相关表的汇总数额字段总计，占总计百分比、平均值或它们之间的比率
38	完整性/一致性	跨表的汇总数据日期检查	按聚合日期汇总跨表数额列的一致性	跨表合理性检查，比较相关表的按聚合日期汇总的数额字段总计、占总计百分比
39	完整性/完备性	跨库跨表数据检查	父/子参考完整性	确定父表/子表之间的参考完整性，以找出无父记录的子记录和值
40	完整性/完备性	跨库跨表数据检查	子/父参考完整性	确定父表/子表之间的参考完整性，以找出无子记录的父记录和值
41	完整性/完备性	接收数据状态	数据集的完备性——重复数据删除	确定并删除重复记录
42	完备性	数据接收	数据集的完备性——对于处理的可用性	对于文件，确认要处理的所有文件都可用
43	完备性	数据接收	数据集的完备性——记录数与控制记录相比	对于文件，对文件中的记录数据和在一个控制记录中记载的记录数作比较
44	完备性	数据接收	数据集的完备性——汇总数额字段数据	对于文件，对数额字段的汇总值和在一个控制记录中的汇总值作比较
45	完备性	接收数据状态	记录的完备性——长度	确保记录的长度满足已定义的期望
46	完备性	接收数据状态	字段的完备性——不可为空的字段	确保所有不可为空的字段都被填充
47	完备性	接收数据状态	基于日期标准的数据集的完备性	确保关键日期字段的最小和最大日期符合确定加载数据参数的规定范围
48	完备性	接收数据状态	字段内容的完备性——接收到的数据缺少要处理的关键字段	在处理记录前检测字段的填充情况
49	完备性	数据处理	数据集的完备性——经过一个流程的记录数据的平衡	整个数据处理过程的记录数、被拒绝的记录数据平衡，包括重复记录数平衡，用于完全平衡的情况
50	完备性	数据处理	经过一个流程的数据集的完备性—— 数额字段的平衡	整个过程中的数额字段内容平衡，用于完全平衡的情况