（在说正事之前，我要推荐一个福利：你还在原价购买阿里云、腾讯云、华为云服务器吗？那太亏啦！来这里，新购、升级、续费都打折，能够为您省60%的钱呢！2核4G企业级云服务器低至69元/年，点击进去看看吧>>>)

作者 DataWorks产品经理 陈振

一、DataWorks数据质量模块的介绍

在正式介绍数据质量模块之前 首先要了解我们为什么要关注数据质量。

上图是阿里巴巴淘宝网早期遇到的一些数据质量问题 这些问题的共同点是 因为很小的数据质量问题导致业务上很大的误差。某些数据质量问题从数据工程师的角度来看很小 比如基础表中的金额单位由元变成了分 但是对业务的影响却是非常大的 会导致下游信贷模型口径变大 会给业务带来风险。

?

总而言之 数据质量问题虽然从数据工程师的角度来看是个简单问题 但是从业务的角度来看是个很严重的问题。所以数据质量是数据开发和治理全生命周期中 非常重要的一个环节。在DataWorks产品版图里 数据质量也是非常重要的模块之一。

数据质量问题产生的原因有很多 既有底层系统层面的问题 比如来自业务系统的脏数据 也有业务系统和数仓平台对接过程中系统层面不一致导致的数据传输和转换产生的问题 更有可能是由于业务变化而产生的 前后端业务系统中某些数据字段定义不一致造成的 比如日期格式、金额格式。业务不一致不一定报错 所以在技术层面就很难察觉了。

数据质量问题带来的后果 如上图所示是非常严重的。对于一些轻量级的问题 可能仅仅影响到数据加工链路的时间浪费 影响数据产出的时效性 也会造成数据计算和存储成本的浪费。更严重的影响是 当有问题的数据流入上层应用 会影响业务决策。

数据质量在DataWorks业务版图中是重要的一环 是数据治理版块的核心部分。数据质量同时也依赖底层统一元数据服务和任务调度服务。

DataWorks数据质量模块的特色有三点

第一点 与数据开发调度深度集成 这也是区分于市面上其他数据质量产品的不同点。

全面支持DataWorks底层离线数据存储的引擎 比如MaxCompute、EMR Hive、MC-Hologres、ADB-PG等。DataWorks数据质量规则由调度系统触发 好处是可以在最佳时间点调度数据质量监控规则去扫描表。在节省计算资源的同时可以及时发现问题。如果是强规则 还能自动阻塞下游任务运行 防止问题数据污染下游。

第二点 便捷灵活的规则定义。

DataWorks数据质量模块 拥有37种内置模板规则和自定义规则。应用内置模板可以快速的配置数据监控 如果遇到内置模板不能覆盖的场景 也可以通过自定义的方式来适配更多业务。应用内置模板规则 有动态阈值模式 即不需要设置具体监控指标阈值 后台算法会自动判断异常值。自定义规则可以沉淀为模板 方便用户或其他用户下次使用 这就方便了组织内部数据质量的标准化。

第三点 支持实时数据监控。

除了离线的数据质量监控 也支持实时数据质量监控。基于阿里云大数据系列产品实时数据通道Datahub和实时计算Flink的组合 能够支持实时数据流的监控。实时数据质量监控也支持Kafka。目前支持断流、延迟和自定义三种规则。支持维度表。

下图是数据质量模块的功能架构 主要分为离线和实时两部分。

离线数据质量监控支持MaxCompute、EMR-Hive、Hologres和ADB-PG四种不同引擎。同时支持内置模板规则、自定义SQL规则和自定义模板规则。所有规则都支持四种不同的监控方式 包含绝对值监控、同比/环比监控 与上一周期业务比较 、波动率监控和动态阈值。数据质量问题报警都可以支持短信、邮件和钉钉群通知的方式实现 这些数据质量问题和指标都会汇总到一个自定义质量报表上 然后通过邮件周期性发出来 也可以通过网页端实时查看。

数据质量模块也支持Open API。Open API有一整套包括规则、分区表达、订阅人等对象的增删改查 都是可以通过Open API完成。

数据质量规则是绑定在调度任务上的。如何绑定呢

首先每一条规则都有对应的表要去扫描 另外规则是需要绑定到具体的任务节上点的 这个任务节点推荐是产出表的任务节点。比如有个任务是由某段SQL脚本写入的 每天或每小时会通过这个任务节点把数据写入到表内 这种情况就建议把监控的规则绑定到任务上 这样每当任务执行完之后 就会自动的触发规则并扫描表 这个时机是最佳的 如果有问题第一时间就能发现。如果问题很严重 还会有进一步措施 如下图所示 当任务节点扫描出问题 会同时产出橙色或红色阈值 无论是哪一种阈值都会触发短信、邮件或钉钉的报警。如果是红色阈值并且是强规则 还会阻塞任务节点的下游节点 防止数据质量问题扩散 也避免了计算资源的浪费。

这就是数据质量离线监控的特色功能 即把规则和任务节点绑定在一起 决定一个合适的质量监控时间点。

下图是数据质量监控所支持的37种不同模板规则 包含数值型和波动率型两种。其中数值型是指对某个特定指标本身来进行监控 比如表行数、字段的最大值最小值等。波动率型规则是指与历史趋势进行对比。后台会有历史指标的存储 方便用户根据历史波动值来判断新指标是否存在异常。

同时 数据质量监控也支持自定义SQL方式来定义数据质量规则。这个定义出来的规则也支持数值型和波动率型的校验。

实时数据质量监控方面。由于业务对数据的时效性要求越来越高 实时数仓的理念越来越深入人心 实时数据一旦出现数据质量问题 相对离线数据质量问题它的排查和解决的困难度都大得多。

实时数据的吞吐量很大 一旦有问题就会被淹没在海量的数据中 排查起来就很困难 所以需要一个自动化的系统来监控。另外 实时数据质量问题会直接影响在线业务。离线的数据可能有一定的缓冲时间去修复 而实时数据质量问题会直接体现到在线业务上 所以实时数据质量问题的敏感度要比离线数据质量要高。由于数据都会归档到离线的数据仓 所以实时数据质量问题最终也会影响离线数据的质量。

在DataWorks数据质量模块里 支持三种不同的方式来监控实时数据质量 包括断流监控、延迟监控和用自定义SQL的方式来定义业务层数据质量规则来监控。

断流和延迟监控。断流是指数据通道在一段时间内没有新数据进来 这个断流的阈值用户可以自己设定。延迟是指数据流中的时间戳字段和系统时钟的差值过大 就说明数据延迟了 并已经失去实时系统的时效性了。

自定义SQL规则更灵活 可以引用一张维度表与实时数据关联 也可以引用两条实时数据链路对它进行双流或多流的Join。具体做法是和业务的实际场景有关联的。

二、数据质量使用说明

离线质量校验 离线质量校验是在图形化界面上的。

以MaxCompute表数据监控为例 首先选择一张表 然后定义一个特殊对象值 叫分区表达式。在离线系统里 数据都会分次写到不同的分区中 大部分情况下分区与时间或业务日期有关联 因此最新的数据一般只会写到最新的分区中 定义分区表达式的目的就是为了限定质量监控范围 这样每次只扫描最新分区就可以了。不同的表最新的分区名称的定义方式不一样 所以需要分区表达式来定义最新的分区名称。这个定义是很灵活的 拥有完整的变量体系。

最常用的是$[yyyymmdd-1] 因为通常是第二天去处理前一天的全量业务数据 所以最新的业务日期的分区名一般是前一天的日期。这就是为什么要把日期减1了。小时任务则是$[hh24miss-1/24]的形式 表示前一小时。

创建完分区表达式后 就可以在对应的分区表达式下创建数据质量监控规则。

点击模板规则下的添加监控规则 来添加一个内置模板规则。如上图所示 会有很详细的配置项。其中“强规则”会阻塞下游链路 “弱规则”仅仅会把报警发出 不阻塞下游 “动态阈值”是指是否由系统来判断异常指标。“规则字段”选项里 可以选择表级或字段级 字段级是可以精确到某个字段的规则。

“模板类型”包含采样方式、校验方式 可根据字段类型不同而不同。“比较方式1”和“比较方式2”是针对数值型模板和波动型模板的比较。

如果模板规则不符合用户要求 用户也可以去设置自定义规则。自定义规则使用起来很简单 在上述创建规则的窗口选择自定义规则 然后写下自己的SQL 符合一定规则的SQL可被纳入 并补充规则描述即可。

这里强调两个离线质量校验的功能

一个是动态阈值功能 在配置规则的界面如果把动态阈值选项勾选“是” 意味着用户需要配置动态阈值方式的规则 下面的配置选项就会简单很多 不需要阈值设定 而只需要做算法参考样本量的设定 即系统需要关注多少天之内的样本量 然后通过平滑的算法来判断指标点是否在预期的区间范围内。如果在预期范围内 就是正常值 反之就是问题值。

另外一个是自定义模板功能 是自定义规则的进阶用法。上面已经讲解了自定义规则 如果出现需要自定义规则去校验的表比较多 配置起来工作量很大的情况 自定义规则SQL脚本维护也比较困难。这就可以用到自定义模板库的功能。它本质上是可以把自定义规则固化成模板 这样在使用这个规则的时候就可以像使用内置模板一样简单了。

操作方法是在数据质量界面里进入到规则模板库 找到模板库的目录树 然后可以像配置SQL规则一样去配置一个模板 唯一不同的是可以用${table_name}指代表名$[yyyymmdd-1]指代分区表达式。建好后 在使用这个模板规则的时候 可以在规则来源中选择规则模板库 然后选择配置好的模板。

无论是自制模板规则还是自定义模板规则 都需要有一个方法把扫描的结果通知给用户 这就需要设定一个订阅人。设置订阅人的方法是在DataWorks界面的订阅管理里 配置不同的订阅方式 如短信、邮件或是钉钉。

另外还有试跑功能 点击试跑后就可以立即运行刚刚设置的规则 以校验配置是否正确。

在数据质量界面可以把规则绑定到一个调度任务上。绑定调度任务有两个入口 一个是数据质量界面 另外一个是运维中心界面。绑定成功后就能让两侧联动起来 从而连通数据开发和治理的流程。

无论是手动运行 试跑 还是调度触发的规则 任务的校验结果都可以在任务查询菜单中看到。

一 实时质量校验

实时质量校验和离线质量校验 无论是从界面上的操作还是概念的定义上 都很相似。

实时质量校验只需在配置规则界面上 选择一个Datahub Topic 系统就会自动判断用户需要配置实时质量校验 然后关联一个Flink项目 把实时质量校验任务运行到这个Flink项目上 然后再去配置一些规则 就完成了。

二 自定义质量报告

在配置了实时和离线的规则后 用户可以周期性的收到数据质量报告。设置这个质量报告只需要在菜单中进入报告模板管理 然后创建一个报告模板 创建时可以设定报告中显示的内容。

可显示的内容如下图所示 用户可以自主选择。

三、数据质量最佳实践

首先来了解下数仓系统的数据质量规则该如何配置。因为质量规则类型很多 内置模板多 同时也支持自定义配置规则 那么该如何选择呢

通常来讲 在数仓入口层 即数据引入层或基础层 一般会检测主外键是否缺失 周期性数据量波动是否过大 无周期性则判断数据是否大于固定值 数据是否有重复导入问题。

在数据清洗层和加工层 一般会增加对清洗逻辑的监控 对数据的重复性和唯一性进行监控。比如在Join或者分组的时候出现重复数据的可能性。

在高度/轻度汇总层 对汇总逻辑进行平衡值监控 基于统计 比如求和、求平均、最大最小值等指标在汇总时是否产生了一些业务语义的变形 比如明细表某些数值列的求和值一定要和汇总表上对应列的求和值一致 监控这些平衡值以确保加工过程中汇总值不会出现业务语义上的形变。

维度表和事实表 需要关注主外键的一致性和维度值 离散值 数量监控。

在出口层、应用层和报表层 需要通过特殊的业务逻辑 监控多表之间的平衡关联和特定业务的逻辑监控 可能就会用到自定义SQL规则。

总而言之 有些规则应用会更广泛 在表级规则中 表行数和表大小用的比较多。监测某些分区是否为空 或者数据猛增的情况。

在字段型规则中 下图中展示的是用得比较多的。

需要用户合理的选择规则的强弱性。针对比较关键的脏数据 需要控制不要流入到下游表中 就需要强规则 其他情况基本上是设置成弱规则。波动率的趋势有上升、下降和绝对值等 用户可以根据业务需要设置。

橙色阈值不会阻塞下游任务 红色阈值的强规则才会触发阻塞下游链路任务。无论是橙色还是红色阈值 都要精确到百分比小数点后两位。

最后是一些常见问题

问 数据质量模块是否收费

答 对公共云用户 按照质量规则实例运行数量计费 其中部分功能仅在DataWorks企业版中开启。详见https://help.aliyun.com/document_detail/118793.html

问 自定义规则使用怎样的SQL语法

答 离线自定义规则使用MaxCompute SQL 实时自定义规则使用Flink SQL。目前只接受查询语句 并限制为单行单列输出。

问 收到了数据质量报警 怎样才能快速定位触发的业务流程节点

答 在数据质量-任务查询界面 找到报警对应的节点ID 再去到运维中心查询即可。

问 数据质量与智能监控一起使用 需要特别注意什么

答 对离线数据来说 强弱规则运行的时机不同

弱规则优先级较低 且与下游任务并发执行 基本不影响基线产出。强规则优先级高 会在下游任务运行前执行 计入基线运行时间。强规则还可能阻塞下游任务 如果下游有基线 请为后面的同学负责。

动态阈值和自定义数据质量报告以及规则模板库等功能需要企业版及以上才能使用。

离线自定义规则使用对应引擎的SQL语法 Hologres使用PostgreSQL EMR使用Hive SQL 实时使用Flink SQL。

运维中心智能监控的基线功能是监控任务时效性的 而数据质量的强规则会在下游任务运行前执行 触发强规则报警还会阻塞下游 都会影响任务时效性。如果下游有基线 需慎用。

数据质量介绍及实践请参考 https://developer.aliyun.com/learning/course/81/detail/1233

DataWorks官网 https://www.aliyun.com/product/bigdata/ide

大数据 AI体验馆 https://workbench.data.aliyun.com/experience.htm

本文转自网络，原文链接：https://developer.aliyun.com/article/785867