关于后端:大厂的数据质量中心系统设计

7次阅读

共计 5530 个字符,预计需要花费 14 分钟才能阅读完成。

日常工作中,数据开发上线完一个工作后并不是就能够居安思危,时常因上游链路数据异样或者本身解决逻辑的 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 布局

数据品质治理是一个长期的过程,将来在平台化方向咱们还有几个要害的局部有待持续推动:

  • 基于血缘关系建设全链路的数据品质监控。以后的监控粒度是工作级的,如果规定设置的是弱规定,上游对于数据问题仍旧很难感知
  • 数据品质的后果量化。需建设一套指标用于定量掂量数据品质
  • 反对实时数据的品质检测

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

作者简介:魔都技术专家兼架构,多家大厂后端一线研发教训,各大技术社区头部专家博主,编程严选网创始人。具备丰盛的引领团队教训,深厚业务架构和解决方案的积攒。

负责:

  • 地方 / 分销预订零碎性能优化
  • 流动 & 优惠券等营销中台建设
  • 交易平台及数据中台等架构和开发设计

    目前主攻升高软件复杂性设计、构建高可用零碎方向。

参考:

  • 编程严选网

本文由博客一文多发平台 OpenWrite 公布!

正文完
 0