大厂的数据质量中心系统设计

日常工作中，数据开发上线完一个任务后并不是就可以高枕无忧，时常因上游链路数据异常或者自身处理逻辑的 BUG 导致产出的数据结果不可信。而问题发现可经历较长周期（尤其离线场景），往往是业务方通过上层数据报表发现数据异常后 push 数据方去定位问题（对于一个较冷的报表，这个周期可能会更长）。

由于数据加工链路较长，需借助数据血缘关系逐个任务排查，也会导致问题定位难度增大，严重影响开发效率。如数据问题未及时发现，可能导致业务方作出错误决策。此类问题可统一归属为大数据领域数据质量问题。本文将向大家介绍伴鱼基础架构数据团队在应对该类问题时推出的平台化产品-数据质量中心的设计与实现。

1 调研

业内数据质量平台化产品介绍不多，主要对两个开源产品和一个云平台产品进行调研。

1.1 Apache Griffin

Apache Griffin，eBay 开源基于 Apache Hadoop 和 Apache Spark 的数据质量服务平台。

1.1.1 架构图

数据质量平台的核心流程：

Define：数据质检规则（指标）的定义
Measure：数据质检任务的执行，基于 Spark 引擎实现
Analyze：数据质检结果量化及可视化展示

平台对数据质检规则进行了分类（业内普遍认可的数据质量的六大标准）:

Accuracy：准确性。如是否符合表的加工逻辑
Completeness：完备性。如数据是否存在丢失
Timeliness：及时性。如表数据是否按时产生
Uniqueness：唯一性。如主键字段是否唯一
Validity：合规性。如字段长度是否合规、枚举值集合是否合规
Consistency：一致性。如表与表之间在某些字段上是否存在矛盾

该项目仅在 Accuracy 类的规则上实现。Griffin是完全闭环的平台化产品。质检任务执行依赖内置定时调度器的调度，调度执行时间由用户在 UI 上设定。任务将通过 Apache Livy 组件提交至配置的 Spark 集群。即质检实时性难保，无法强行阻断产出异常数据的任务，二者不是在同一调度平台被调度，时序也不能保持串行。

1.2 Qualitis

Qualitis，微众银行开源的一款数据质量管理系统。同样，它提供了一整套统一的流程来定义和检测数据集的质量并及时报告问题。从整个流程上看我们依然可以用 Define、Measure 和 Analyze 描述。它是基于其开源的另一款组件 Linkis 进行计算任务的代理分发，底层依赖 Spark 引擎，同时可以与其开源的 DataSphereStudio 任务开发平台无缝衔接，也就实现了在任务执行的工作流中嵌入质检任务，满足质检时效性的要求。可见，Qualitis 需借助微众银行开源一系列产品才好用。

1.3 DataWorks 数据质量

DataWorks，阿里云提供一站式大数据工场，包括数据质量在内的产品解决方案。实现依赖阿里云其他产品组件支持。DataWorks 数据质量部分的使用介绍从产品形态上给了我们很大的帮助，对我们产品设计有指导性作用。

2 设计目标

暂只支持离线部分数据质量管理
支持通用规则描述和规则管理
质检任务由公司内部统一的调度引擎调度执行，可支持对质检结果异常的任务进行强阻断。同时，尽量降低质检功能对调度引擎的代码侵入
支持质检结果可视化

3 系统设计

3.1 背景

离线调度开发平台基于 Apache Dolphinscheduler（简称DS）实现，分布式去中心化，易扩展的可视化 DAG 调度系统，支持包括 Shell、Python、Spark、Flink 等多种类型的 Task 任务，并具有很好的扩展性。

3.2 架构

Master 节点负责任务的监听和调度，Worker 节点则负责任务的执行。值得注意的是，每一个需要被调度的任务必然需要设置一个调度时间的表达式（cron 表达式），由 Quartz 定时为任务生成待执行的 DAG Command，有且仅有一个 Master 节点获得执行权，掌管该 DAG 各任务节点的调度执行。

3.3 整体架构

平台整体架构图：

DQC Web UI：质检规则等前端操作页
DQC(GO)：简单的实体元数据管理后台。主要包括：规则、规则模板、质检任务和质检结果几个实体。
DS(数据质量部分)：质检任务依赖 DS 调度执行，需要对 DS 进行一定的改造。
DQC SDK(JAR)：DS 调度执行任务时，检测到任务绑定了质检规则，将生成一类新的任务 DQC Task （与 DS 中其他类型的 Task 同级，DS 对于 TasK 进行了很好的抽象可以方便扩展），本质上该 Task 将以脚本形式调用执行 DQC SDK 的逻辑。DQC SDK 涵盖了规则解析、执行的全部逻辑。

各模块设计权衡。

4 规则表述

4.1 标准与规则

业界数据质量有六大标准，但：

如何将标准与平台的规则对应起来？
标准中涉及到的现实场景是否我们可以一一枚举？
即便可将标准一一细化，数据开发人员是否可轻松理解？

可将这些问题统一归类为：平台在规则设定上是否需要和业界数据质量标准所抽象出来的概念进行绑定。很遗憾没找到有关数据质量标准更细化和指导性的描述，作为一个开发，这些概念比较费解，更贴近程序员视角是「show me the code」，因此我们决定将这一层概念弱化。未来实践过程后再细思。

4.1.1 标量化

如何对规则提供一种通用描述（or DSL）？

跳脱出前文所描述一切背景和概念，仔细思考数据质检过程，本质就是通过一次真实的任务执行产出结果，对比输出结果与期望是否满足，以验证任务逻辑正确性。和 Unit Testing 类比:

Unit Testing 是通过模拟数据构造的一次代码逻辑的执行
数据任务执行产生的结果是一张二维结构的 Hive 表，需加工才能获取想要的统计结果

据此，可用 Unit Testing 概念从以下深入：

① Actual Value

数据任务执行产出结果是一张 Hive 表，要对这张 Hive 表数据加工、提取以获得需要Actual Value。涉及 Hive 表加工，就想到以 SQL 实现，通过 Query 和一系列 Aggregation 拿到结果，此结果结构又可分为：

二维数组
单行或单列的一维数组
单行且单列的标量

显然单行且单列标量是期望，因为易于结果比较（就目前能想到的规则，都可通过 SQL 提取为一个标量结果）。因此，规则设计中，需要规则创建者输入一段用于结果提取的 SQL，该段 SQL 执行结果需要为一个标量。

② Expected Value

既然 Actual Value 是标量，Expected Value 也是标量，需要规则创建者在平台输入。

③ Assert

上述标量的类型决定断言比较方式。目前只支持数值型标量的比较方式，包含「大于」、「等于」及「小于」三种比较算子。

三要素即可完整的描述规则想要表达的核心逻辑。如表述「字段为空异常」规则（潜在含义：字段为空的行数大于 0 时判定异常）：

Actual Value ：出现字段为空的行数
Expected Value：0
Assert：「大于」

4.2 规则管理

4.2.1 规则模板

为了规则复用抽象出的一个概念，模板中包含规则的 SQL 定义、规则的比较方式、参数定义（注：SQL 中包含一些占位符，这些占位符将以参数的形式被定义，在规则实体定义时需要用户明确具体含义）以及其他的一些元信息。

「字段空值的行数」模板示例：

4.2.2 规则实体

基于规则模板构建，是规则的具象表达。

在规则实体中将明确规则的 Expected Value、比较方式中具体的比较算子、参数的含义以及其他的一些元信息。基于同一个规则模板，可构造多个规则实体。

「某表 user_id 唯一性校验」规则示例：

规则可能不仅针对单表校验，多表case，这套规则模板同样适用，只要能将逻辑用 SQL 表达。

4.3 规则绑定

在 DS 的前端交互上支持为任务直接绑定校验规则，规则列表通过 API 从 DQC 获取，这种方式在用户的使用体验上存在一定的割裂（规则创建和绑定在两个平台完成）。同时，在 DQC 的前端亦可以直接设置关联调度，为已有任务绑定质检规则，任务列表通过 API 从 DS 获取。同一个任务可绑定多个质检规则，这些信息将存储至 DS 的 DAG 元信息中。但是：

规则的哪些信息应该存储至 DAG 的元信息中？
规则的更新 DAG 元信息是否可实时同步？

主要有两种方式：

大JSON将规则信息打包存储，计算时解析 JSON 逐个执行校验。在规则更新时，需要同步调用修改 JSON 信息
List 存储规则 ID，计算时需执行一次 Pull 操作获取规则具体信息然后执行校验。规则更新，无须同步更新 List 信息

最终选型后者，ID List可使对 DS 侵入最低。

4.4 规则执行

强规则和弱规则

规则的强弱性质由用户为任务绑定规则时设定，此性质决定了规则执行的方式。

强规则

和当前所执行的任务节点同步执行，一旦规则检测失败整个任务节点将置为执行失败的状态，后续任务节点的执行会被阻断。对应 DS 中的执行过程：

Step1：某一个 Master 节点获取 DAG 的执行权，将 DAG 拆分成不同的 Job Task 先后下发给 Worker 节点执行。
Step2：执行 Job Task 逻辑，并设置 Job Task 的 ExitStatusCode。
Step3：判断 Job Task 是否绑定了强规则。若是，则生成 DQC Task 并触发执行，最后根据执行结果修正 Job Task 的 ExitStatusCode。
Step4：Master 节点根据 Job Task 的 ExitStatusCode 判定任务是否成功执行，继续进入后续的调度逻辑。

弱规则

和当前所执行的任务节点异步执行，规则检测结果对于原有的任务执行状态无影响，从而也就不能阻断后续任务的执行。对应 DS 中的执行过程：

Step1：某一个 Master 节点获取 DAG 的执行权，将 DAG 拆分成不同的 Job Task 先后下发给 Worker 节点执行。
Step2：执行 Job Task 逻辑，并设置 Job Task 的 ExitStatusCode。
Step3：判断 Job Task 是否绑定了弱规则。若是，则在 Job Task 的 Context 中设置弱规则的标记。
Step4：Master 节点根据 Job Task 的 ExitStatusCode 判定任务是否成功执行，若成功执行再判定是否 Context 中带有弱规则标记，若有则生成一个新的 DAG（有且仅有一个 DQC Task，且新生成的 DAG 与当前执行的 DAG 没有任何的关联）然后继续进入后续的调度逻辑。
Step5：各 Master 节点竞争新生成的 DAG 的执行权。

可以看出在强弱规则的执行方式上，对 DS 调度部分的代码有一定的侵入，但这个改动不大，成本是可以接受的。

DQC Task & DQC SDK

上文提及到一个 Job Task 绑定的规则（可能有多个）将被转换为一个 DQC Task 被 DS 调度执行，接下来我们就讨论下 DQC Task 的实现细节以及由此引出的 DQC SDK 的设计和实现。

DQC Task 继承自 DS 中的抽象类 AbstractTask，只需要实现抽象方法 handle（任务执行的具体实现）即可。那么对于我们的质检任务，实际上执行逻辑可以拆分成以下几步：

提取 Job Task 绑定的待执行的 Rule ID List。
拉取各个 Rule ID 对应的详情信息。
构建完整的执行 Query 语句（将规则参数填充至模板 SQL 中）。
执行 Query。
执行 Asset。

最核心的步骤为 Query 的执行。Query 的实现方式又可分为两种：

Spark 实现

优点：实现可控，灵活性更高。
缺点：配置性要求较高。

Presto SQL 实现

优点：不需要额外配置，开发量少，拼接 SQL 即可。
缺点：速度没有 Spark 快。

选择后者，最易实现，离线场景计算耗时也可接受。同时由于一个 DQC Task 包含多条规则，在拼接 SQL 时将同表的规则聚合以减少 IO 次数。不同的 SQL 交由不同的线程并行执行。

上述执行逻辑其实是一个完整且闭环的功能模块，因此我们想到将其作为一个单独的 SDK 对外提供，并以 Jar 包的形式被 DS 依赖，后续即便是更换调度引擎，这部分的逻辑可直接迁移使用（当然概率很低）。那么 DS 中 DQC Task 的 handle 逻辑也就变得异常简单，直接以 Shell 形式调用 SDK ，进一步降低对 DS 代码的侵入。

4.5 执行结果

单条规则的质检结果将在平台上直接展现，目前我们还未对任务级的规则进行聚合汇总，这是接下来需要完善的。对于质检失败的任务将向报警接收人发送报警。

实践中的问题

平台解决了规则创建、规则执行的问题，而在实践过程中，对用户而言更关心：

一个任务应该需要涵盖哪些的规则才能有效地保证数据的质量？
我们不可能对全部的表和字段都添加规则，那么到底哪些是需要添加的？

这些是很难通过平台自动实现的，因为平台理解不了业务的信息，平台能做的只能是通过质量检测报告给与用户反馈。因此这个事情需要具体的开发人员对核心场景进行梳理，在充分理解业务场景后根据实际情况进行设定。话又说回来，平台只是工具，每一个数据开发人员应当提升保证数据质量的意识，这又涉及到组织内规范落地的问题了。

5 规划

数据质量管理是一个长期的过程，未来在平台化方向我们还有几个关键的部分有待继续推进：

基于血缘关系建立全链路的数据质量监控。当前的监控粒度是任务级的，如果规则设置的是弱规则，下游对于数据问题依旧很难感知
数据质量的结果量化。需建立一套指标用于定量衡量数据质量
支持实时数据的质量检测

关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主，编程严选网创始人。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责：

中央/分销预订系统性能优化

活动&优惠券等营销中台建设

交易平台及数据中台等架构和开发设计

目前主攻降低软件复杂性设计、构建高可用系统方向。

参考：