基于 DolphinScheduler 的数据质量检查实践

今天给大家带来的分享是基于 Apache DolphinScheduler 的数据质量检查实践，分享的内容主要为以下四点：

“

• 为什么要做数据质量检查？

• 为什么要基于 DolphinScheduler 做数据质量检查？

• 基于 DolphinScheduler 的数据质量服务的设计和实现

• 不足和规划

1 为什么要做数据质量检查

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

• 数据可信度低

• 影响数据分析和数据挖掘的准确性

• 可能会导致错误的决策

• 数据开发层面的工作越来越多，链路也越来越长，如果没有在一些关键的节点配置好相应的检查，一旦出现数据错误的问题就比较难定位。

由此可知做好数据质量监控是数据开发工作的重中之重，做好数据质量检查可以带来提高数据的可信度、 及时发现数据错误问题，更好地定位问题和提高工作效率的好处。

2 为什么基于 DS 来做？

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

2.1 DolphinScheduler 是什么？

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

它具备以下的特性：

• 高可靠性，去中心化的多 Master 和多 Worker 服务架构, 避免单 Master 压力过大，另外采用任务缓冲队列来避免任务过载

• 简单易用，所有流程定义都是可视化，通过拖拽任务可完成定制 DAG ，也可通过 API 方式与第三方系统集成, 一键部署

• 具有丰富的应用场景，支持多租户，支持暂停恢复操作. 紧密贴合大数据生态，提供 Spark, Hive, M/R, Python, Sub_process, Shell 等近20种任务类型

• 高扩展性，支持自定义任务类型，调度器使用分布式调度，调度能力随集群线性增长，Master 和 Worker 支持动态上下线

2.2 数据质量检查的目标

我们想要的的数据质量检查的样子：

• 具备丰富的内置规则，能够满足我们日常的检查需求

• 能够无缝地接入到工作流当中，当出现严重数据错误问题时能及时进行告警和阻断

• 有较为完善的结果处理机制

• 能够查看数据检查结果和错误数据，方便排查问题

在确定我们的目标以后，我们调研了现有的开源方案是否能够满足我们的需求，目前开源方案中使用 Java 语言开发的较为知名的有两个：

• Griffin：

• • Apache 顶级项目，是一个优秀并且完备的数据质量检查系统，

  • 具有独立的UI、调度和内置规则，依赖于 Apache Livy 来提交 Spark 作业

  • 一个独立的系统，较难无缝地接入到工作流当中来实现当出现严重数据质量问题时的阻断。

• Qualitis：

• • 微众开源的数据质量系统，具备较丰富的内置规则，界面简洁容易使用

  • 依赖于 Linkis 作为执行Spark作业的引擎

  • 如果想要实现无缝接入工作流需要依赖DataSphere Studio，不够轻量级

2.3 优势

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

• DolphinScheduler作为一个任务调度系统，具备了执行任务的基础，不需要引入新的组件来提交任务

• 数据质量检查可以作为一种任务类型无缝接入到工作流当中

• 无需新增其他服务来增加运维的难度

• 可以很好地与社区共建开源

3 设计和实现

我们来看一下整体的运行流程：

运行流程

• 用户侧：

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

• 系统侧：

• • 数据质量任务开始执行，由 Master 下发任务到 Worker ，Master 是DolphinScheduler中的调度工作流和任务的组件，Worker 是DolphinSchduler中负责实际执行任务的组件。

  • Worker 接收到任务以后会进行参数的解析和构造，执行 DQCApplicaiton，DQCApplicaiton 执行完成后会将结果写入到相应的存储引擎，Worker 会发送 TaskResponse 给 Master。

  • Master 接收到 TaskResponse 后会对任务类型进行判断，如果是数据质量检查任务的话会进行数据质量结果判断，一旦发现数据异常就会进行告警或者阻断。

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

• 规则管理：规则定义以及规则的使用

• 数据处理：Worker 将规则定义转化为 DQCAppliccation 所需的参数以及 DQCApplicaiton 执行数据处理

• 结果处理：结果检查以及异常后的处理

3.1 规则管理

3.1.1 规则的定义

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

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

• • 统计值指的是我们对要检验的数据执行一系列操作后得到的值，例如表总行数或者为某字段为空的行数。

  • 比对值指的是用来作为比较目标的值，比对值可以是固定值，也可以是由定义好的计算逻辑计算出来的值

  • 数据源输入项，定义了要检查哪些数据

  • 统计值参数和比对值参数

  • 结果判断相关的参数，包括检查的方式、比较符和阈值以及失败，这部分的参数主要是用来定义怎样判断数据是否异常和异常如何处理。

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

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

• 后续新增规则不希望频繁修改前端页面

• 保证用户良好的体验包括输入项的联动比如数据源、表和列的选择联动等等。

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

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

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

我们按照准确性、完整性、及时性、唯一性、规范性、一致性和自定义监控七种分类定义了十几个规则。下面简单讲下几种分类的定义和对应的一些规则。

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

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

• 及时性检查指的是检查数据是否能够按时地产生。

• 唯一性检查指的是检查哪些数据是重复数据或者数据的哪些属性是重复的，对应的规则例如主键唯一性检查。

• 规范性检查指的是检查数据是否符合规范，是否按照规定的格式存储，对应的规则包括正则表达式检查，字段长度检查，枚举集合检查，数值范围等。

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

• 自定义监控指的是用户可以通过自定义SQL的方式来定义要检查的逻辑，支持的规则包括单表自定义SQL和跨表值比对。

3.1.2 比对值的管理

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

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

• 固定值

• 最近7天波动

• 最近30天波动

• 日波动

• 周波动

• 月波动

• 源表总行数

• 目标表总行数

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

• execute_sql：该sql是用来计算出比对值

• output_table_name：将execute_sql执行的结果注册到临时视图所用的表名

• comparison_name：是比对值的名称，结合output_table_name可用于其他SQL中

3.2 数据处理

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

• 执行引擎：我们选择了 Spark 作为任务的执行引擎。Spark 支持多种数据源类型的连接同时计算比较快。

• 执行链路组件：我们设计了Reader、Transformer和Writer三种类型的组件， Reader用于连接数据源，Transformer用于执行sql进行数据的处理，Writer用于将数据输出到指定的存储引擎中

3.2.1 执行流程

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

• Worker 接收到任务以后，会将规则的参数输入项和 SQL 定义转换成 DQCApplication 所需要的参数传给 DQCApplication 去执行

• DQCApplication 解析参数选择相应的引擎，构造出引擎对应的 RuntimeEnviroment 和 Execution

• 同时也会根据参数创建一系列的 Reader、Transformer 和 Writer ， Execution 会按照一定的顺序去执行这些组件中的逻辑，来完成整个数据质量校验任务

数据处理执行流程

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

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

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

3.2.2 结果处理

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

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

校验公式

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

举个例子

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

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

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

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

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

3.2.3 结果数据查看

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

校验结果

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

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

我们支持两种错误数据的输出方式:

• 写入到 ElasticSearch 中，可以通过 Kibana 或者其他工具去查看.

• 写到 HDFS 中，这样不用新增新的组件，也可以查看错误数据，只是没那么方便。

4 不足和规划

不足：

• 目前的数据质量校验只支持离线数据的校验

• 只支持 Jdbc 和 Hive 两种类型的数据源

• 没有提供页面让用户去自定义规则

规划：

• 我们会支持实时数据的校验

• 增加新的数据源类型，例如 Hdfs、ES 等

• 支持用户可以自定义单表检查规则

结束语

目前，我们已经将数据质量校验功能贡献给社区，1.0 版本的代码在 dolphinscheduler 的主仓库的 data_quality_design 分支上，2.0 版本也会在近期完成pr的提交，也希望能有更多感兴趣的小伙伴一起来参与，和社区一起共建开源，谢谢大家。

下面视频是 ApacheCon Asia 上做的分享演讲: